[英]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.