簡體   English   中英

Buildah vs Kaniko

[英]Buildah vs Kaniko

我正在使用 ArgoWorkflow 來自動化我們的 CI/CD 鏈。 為了構建鏡像,並將它們推送到我們的私有注冊表,我們面臨着選擇 buildah 或 kaniko。 但我無法指出兩者之間的主要區別。 利弊,以及這些工具如何處理並行構建和緩存管理。 誰能澄清這些觀點? 或者甚至建議另一種可能以更簡單的方式完成工作的工具。 關於這個主題的一些澄清將非常有幫助。 提前致謝。

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

buildah 將需要具有多個 UID 的特權容器或使用 CAP_SETUID、CAP_SETGID 運行的容器來構建容器映像。 它不是像 kanicko 那樣對文件系統進行黑客攻擊來繞過這些要求。 它在構建時運行完整的contianers。

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

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM