Buildah vs Kaniko

Question

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

Answer 1

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

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

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

这些是我在 GitLab CI 管道中使用的一些功能，由 GitLab 运行器在Kubernetes中执行（他们应该希望阐明 kan 的设置和使用）：

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 "com.qwant.ci.job.id=${CI_JOB_ID}" \
        --label "com.qwant.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

Answer 2

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

--isolation chroot，将使 buildah 在 kubernetes 中工作更容易一些。