男
v1.23.2
次の条件を満たす必要があります。
ニーズに最適な自動化ツールを見つけるのはあなた次第です。 GitHub ワークフローや GitLab CI などの最新の CI/CD システムを使用することをお勧めします。私たち (著者) はたまたま GitLab CI を使用しているため、以下の例はこの特定のプラットフォームに合わせて調整されていますが、基礎となる原則は他のどこにでも適用できるはずであり、例は十分に単純に保たれているため、何も持たなくても理解できるはずです。この特定のプラットフォームでの以前の経験。疑問がある場合は、gitlab-ci.yml リファレンス ページにアクセスして、GitLab CI キーワードの包括的な概要を確認してください。
gitlab-ci.yml:
# define a job for building the containers
build-container :
stage : container-build
# run parallel builds for the desired architectures
parallel :
matrix :
- ARCH : amd64
- ARCH : arm64
tags :
# run each build on a suitable, preconfigured runner (must match the target architecture)
- runner-${ARCH}
image :
name : gcr.io/kaniko-project/executor:debug
entrypoint : [""]
script :
# build the container image for the current arch using kaniko
- >-
/kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile
"${CI_PROJECT_DIR}/Dockerfile" # push the image to the GitLab container
registry, add the current arch as tag. --destination
"${CI_REGISTRY_IMAGE}:${ARCH}" gitlab-ci.yml:
# define a job for creating and pushing a merged manifest
merge-manifests :
stage : container-build
# all containers must be build before merging them
# alternatively the job may be configured to run in a later stage
needs :
- job : container-build
artifacts : false
tags :
# may run on any architecture supported by manifest-tool image
- runner-xyz
image :
name : mplatform/manifest-tool:alpine
entrypoint : [""]
script :
- >-
manifest-tool # authorize against your container registry
--username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push
from-args # define the architectures you want to merge --platforms
linux/amd64,linux/arm64 # "ARCH" will be automatically replaced by
manifest-tool # with the appropriate arch from the platform definitions
--template ${CI_REGISTRY_IMAGE}:ARCH # The name of the final, combined
image which will be pushed to your registry --target ${CI_REGISTRY_IMAGE} わかりやすくするために、前の例では、バージョン管理されたタグ付きイメージ (すべてのビルドに「最新」のタグが付けられます) の使用を意図的に控えました。これは、多くのプラットフォームおよびワークフロー固有のコードが追加されると思われるためです。
それでも、GitLab で (動的) バージョニングをどのように処理するかに興味がある人のために、ここで簡単に概要を説明します。
CI_COMMIT_TAG変数を使用するだけです。needsセクションを拡張することを忘れないでください)。これにより、デフォルト ブランチで実行するときにタグがlatestに設定されます。他のブランチで実行する場合はコミット ハッシュに、タグ パイプラインで実行する場合はリリース タグに送信します。gitlab-ci.yml:
container-get-tag :
stage : pre-container-build-stage
tags :
- runner-xyz
image : busybox
script :
# All other branches are tagged with the currently built commit SHA hash
- |
# If pipeline runs on the default branch: Set tag to "latest"
if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; then
tag="latest"
# If pipeline is a tag pipeline, set tag to the git commit tag
elif test -n "$CI_COMMIT_TAG"; then
tag="$CI_COMMIT_TAG"
# Else set the tag to the git commit sha
else
tag="$CI_COMMIT_SHA"
fi
- echo "tag=$tag" > build.env
# parse tag to the build and merge jobs.
# See: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
artifacts :
reports :
dotenv : build.env 同様のツールには次のものがあります。
これらのツールはすべて、さまざまなアプローチでコンテナー イメージを構築します。
BuildKit (およびimg ) はコンテナ内から非 root ユーザーとして実行できますが、ネストされたコンテナを作成するには seccomp と AppArmor を無効にする必要があります。 kaniko実際にはネストされたコンテナを作成しないため、seccomp と AppArmor を無効にする必要はありません。 BuildKit は、QEMU を活用してマルチ アーキテクチャ コンテナーの「クロスビルド」をサポートします。
orca-build Dockerfile からイメージをビルドするためにruncに依存していますが、コンテナ内で実行することはできません (上記のimgと同様の理由により)。 kaniko runc使用しないため、カーネル名前空間技術を使用する必要はありません。ただし、 orca-build Docker や特権デーモンを必要としません (そのため、ビルドは完全に特権なしで実行できます)。
umoci特権なしで動作し、抽出されるルート ファイルシステムに対する制限もありません (ただし、ファイル システムが十分に複雑な場合は追加の処理が必要です)。ただし、 Dockerfileのようなビルド ツールはありません ( orca-buildなど、そのようなビルダーをビルドするために使用できる少し低レベルのツールです)。
Buildah OCI イメージの構築を専門としています。 Buildah のコマンドは、Dockerfile にあるすべてのコマンドを複製します。これにより、root 権限を必要とせずに、Dockerfile の有無にかかわらずイメージを構築できます。 Buildah の最終目標は、イメージをビルドするための下位レベルの coreutils インターフェイスを提供することです。 Dockerfile を使用せずにイメージを構築できる柔軟性により、他のスクリプト言語を構築プロセスに統合できます。 Buildah は単純な fork-exec モデルに従っており、デーモンとしては実行されませんが、golang の包括的な API に基づいており、他のツールにベンダー化できます。
FTLとBazelイメージのサブセットに対して Docker イメージを可能な限り高速に作成することを目指しています。これらは、kaniko が提供する一般的な Dockerfile のサポートと組み合わせて使用できる、特殊なケースの「高速パス」と考えることができます。
kaniko-users Google グループ
kaniko に貢献するには、DEVELOPMENT.md および CONTRIBUTING.md を参照してください。
スナップショットを取得するとき、kaniko のハッシュ アルゴリズムには、ファイルが変更されたかどうかを判断するためのファイルのmtimeが含まれます ( --snapshot-mode=timeの場合はのみ使用されます)。残念ながら、ファイルに変更が加えられてからmtimeが更新されるまでには遅延が発生します。これはつまり：
--snapshot-mode=time ) を使用すると、kaniko はRUNコマンドによって導入された変更を完全に見逃す可能性があります。--snapshot-mode=full ) では、 RUNコマンドがファイルを変更しても内容が変わらない場合に kaniko がレイヤーを追加するかどうかは、理論的には非決定的です。これは正しい内容には影響しませんが、レイヤーの数には影響します。これらの問題は現時点では理論上のものにすぎないことに注意してください。この問題が発生した場合は、問題を開いてください。
--chownサポートKaniko は現在、 COPY --chownおよびADD --chown Dockerfile コマンドをサポートしています。 RUN --chownはサポートされていません。
