布达塔 vs 卡尼科

Question

我正在使用 ArgoWorkflow 来自动化我们的 CI/CD 链。为了构建镜像并将它们推送到我们的私有注册表，我们面临着 buildah 或 kaniko 的选择。但我无法指出两者之间的主要区别。优点和缺点，以及这些工具如何处理并行构建和缓存管理。谁能澄清这些要点？或者甚至建议另一个可以以更简单的方式完成工作的工具。关于这个主题的一些澄清将会非常有帮助。提前致谢。

Answer 1

buildah将需要具有多个 UID 的特权容器或使用 CAP_SETUID、CAP_SETGID 运行的容器来构建容器映像。它不像通过黑客攻击文件系统kaniko来绕过这些要求。它在构建时运行完整的容器。

--isolationchroot，将使buildah在 kubernetes 中工作变得更容易一些。

Answer 2

kaniko的设置非常简单，并且有一些神奇之处，可以让它在 kubernetes 中无需任何要求即可工作:)

我也尝试过buildah，但无法配置它，并且发现它太复杂，无法在 kubernetes 环境中设置。

您可以使用内部 Docker 注册表作为kaniko的缓存管理，但也可以配置本地存储（尚未尝试）。只需使用最新版本的kaniko (v1.7.0)，它修复了缓存图层管理中的一个重要错误。

这些是我在 GitLab CI 管道中使用的一些函数（在文件中声明ci/libkaniko.sh），由 GitLab kubernetes 运行程序执行。他们应该希望澄清kaniko的设置和用法。

function kaniko_config
{
    local docker_auth="$(echo -n "$CI_REGISTRY_USER:$CI_REGISTRY_PASSWORD" | base64)"

    mkdir -p $DOCKER_CONFIG
    [ -e $DOCKER_CONFIG/config.json ] || \
        cat <<JSON > $DOCKER_CONFIG/config.json
{
    "auths": {
        "$CI_REGISTRY": {
            "auth": "$docker_auth"
        }
    }
}
JSON
}

# Usage example (.gitlab-ci.yml)
#
# build php:
#   extends: .build
#   variables:
#     DOCKER_CONFIG: "$CI_PROJECT_DIR/php/.docker"
#     DOCKER_IMAGE_PHP_DEVEL_BRANCH: &php-devel-image "${CI_REGISTRY_IMAGE}/php:${CI_COMMIT_REF_SLUG}-build"
#   script:
#     - kaniko_build
#       --destination $DOCKER_IMAGE_PHP_DEVEL_BRANCH
#       --dockerfile $CI_PROJECT_DIR/docker/images/php/Dockerfile
#       --target devel

function kaniko_build
{
    kaniko_config
    echo "Kaniko cache enabled ($CI_REGISTRY_IMAGE/cache)"
    /kaniko/executor \
        --build-arg http_proxy="${HTTP_PROXY}" \
        --build-arg https_proxy="${HTTPS_PROXY}" \
        --build-arg no_proxy="${NO_PROXY}" \
        --cache --cache-repo $CI_REGISTRY_IMAGE/cache \
        --context "$CI_PROJECT_DIR" \
        --digest-file=/dev/termination-log \
        --label "ci.job.id=${CI_JOB_ID}" \
        --label "ci.pipeline.id=${CI_PIPELINE_ID}" \
        --verbosity info \
        $@

    [ -r /dev/termination-log ] && \
        echo "Manifest digest: $(cat /dev/termination-log)"
}

使用这些函数可以构建新图像：

stages:
  - build

build app:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.7.0-debug
    entrypoint: [""]
  variables:
    DOCKER_CONFIG: "$CI_PROJECT_DIR/app/.docker"
    DOCKER_IMAGE_APP_RELEASE_BRANCH: &app-devel-image "${CI_REGISTRY_IMAGE}/phelps:${CI_COMMIT_REF_SLUG}"
    GIT_SUBMODULE_STRATEGY: recursive
  before_script:
    - source ci/libkaniko.sh
  script:
    - kaniko_build
      --destination $DOCKER_IMAGE_APP_RELEASE_BRANCH
      --digest-file $CI_PROJECT_DIR/docker-content-digest-app
      --dockerfile $CI_PROJECT_DIR/docker/Dockerfile
  artifacts:
    paths:
      - docker-content-digest-app
  tags:
    - k8s-runner

请注意，您必须使用debugkaniko 执行程序的版本，因为此图像标签提供了一个 shell（以及其他基于 busybox 的二进制文件）。