kaniko
v1.23.2
次の条件を満たす必要があります。
目的のアーキテクチャを実行するビルドマシンにアクセスする必要があります (エミュレータで Kaniko を実行することも可能です。たとえば、QEMU も可能ですが、このドキュメントの範囲を超えます)。これは、github.com や gitlab.com などの SaaS ビルド ツールを使用するときに留意すべき点です。このツールの執筆時点では、どちらも非 x86_64 SaaS ランナー (GitHub、GitLab) をサポートしていないため、独自のものを用意する必要があります。マシン (GitHub、GitLab.
Kaniko は、目的のアーキテクチャ上で実行できる必要があります。執筆時点では、公式 Kaniko コンテナは linux/amd64、linux/arm64、linux/s390x、および linux/ppc64le (*-debug イメージではサポートされていません) をサポートしています。
選択したコンテナ レジストリは、OCIv1 または Docker v2.2 と互換性がある必要があります。
ニーズに最適な自動化ツールを見つけるのはあなた次第です。 GitHub ワークフローや GitLab CI などの最新の CI/CD システムを使用することをお勧めします。私たち (著者) はたまたま GitLab CI を使用しているため、以下の例はこの特定のプラットフォームに合わせて調整されていますが、基礎となる原則は他のどこにでも適用できるはずであり、例は十分に単純に保たれているため、何も持たなくても理解できるはずです。この特定のプラットフォームでの以前の経験。疑問がある場合は、gitlab-ci.yml リファレンス ページにアクセスして、GitLab CI キーワードの包括的な概要を確認してください。
gitlab-ci.yml:
# コンテナをビルドするためのジョブを定義しますbuild-container: stage:container-build
# 目的のアーキテクチャに対して並列ビルドを実行します
並列:行列:
- アーチ: amd64 - アーチ: arm64
tags:# 事前構成された適切なランナー上で各ビルドを実行します (ターゲット アーキテクチャと一致する必要があります)-runner-${ARCH}
画像:名前: gcr.io/kaniko-project/executor:debugentrypoint: [""]
script:# kaniko- >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" を使用して現在のアーチのコンテナ イメージをビルドします。 # イメージを GitLab コンテナ レジストリにプッシュします。現在のアーチをタグとして追加します。 --destination "${CI_REGISTRY_IMAGE}:${ARCH}"gitlab-ci.yml:
# マージされたマニフェストmerge-manifestsを作成してプッシュするジョブを定義します: stage:container-build
# すべてのコンテナはマージする前にビルドする必要があります
# あるいは、ジョブを後の段階で実行するように構成することもできます
ニーズ：
- ジョブ: コンテナーのビルド アーティファクト: false
tags:# は、manifest-tool image-runner-xyz によってサポートされる任意のアーキテクチャ上で実行できます。
画像: 名前: mplatform/manifest-tool:alpineentrypoint: [""]
スクリプト：
- >-manifest-tool # コンテナー レジストリに対して承認します --username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} Push from-args # マージするアーキテクチャを定義します --platforms linux/amd64,linux/arm64 # 「ARCH」は、manifest-tool によって自動的に置き換えられます # プラットフォーム定義からの適切なアーチ --template ${CI_REGISTRY_IMAGE}:ARCH # レジストリにプッシュされる最終的な結合イメージの名前 --target ${CI_REGISTRY_IMAGE}わかりやすくするために、前の例では、バージョン管理されたタグ付きイメージ (すべてのビルドに「最新」のタグが付けられます) の使用を意図的に控えました。これは、多くのプラットフォームおよびワークフロー固有のコードが追加されると思われるためです。
それでも、GitLab で (動的) バージョニングをどのように処理するかに興味がある人のために、ここで簡単に概要を説明します。
タグ付きリリースの構築のみに興味がある場合は、タグ パイプラインの実行時に GitLab の事前定義されたCI_COMMIT_TAG変数を使用するだけです。
(私たちと同じように) リリース以外でコンテナ イメージを追加でビルドしたい場合、状況は少し複雑になります。この例では、ビルド ジョブとマージ ジョブの前に実行される追加のジョブを追加しました (それに応じてビルド ジョブとマージ ジョブのneedsセクションを拡張することを忘れないでください)。これにより、デフォルト ブランチで実行するときにタグがlatestに設定されます。他のブランチで実行する場合はコミット ハッシュに、タグ パイプラインで実行する場合はリリース タグに送信します。
gitlab-ci.yml:
コンテナ取得タグ: ステージ: コンテナ構築前ステージ
タグ:
- ランナーxyz
画像: ビジーボックス
script:# 他のすべてのブランチには、現在構築されているコミット SHA ハッシュがタグ付けされます。 # パイプラインがデフォルトのブランチで実行される場合: タグを「latest」に設定 if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; then tag="latest" # パイプラインがタグ パイプラインの場合、tag を git commit タグに設定します。 elif test -n "$CI_COMMIT_TAG"; then tag="$CI_COMMIT_TAG" # それ以外の場合は、タグを git commit sha else tag="$CI_COMMIT_SHA" fi - echo "tag=$tag" > build.env に設定します
# タグをビルドおよびマージ ジョブに解析します。
# 参照: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
アーティファクト:レポート: dotenv: build.env同様のツールには次のようなものがあります。
ビルドキット
画像
オルカビルド
ウモチ
ビルダ
FTL
Bazel ルール_ドッカー
これらのツールはすべて、さまざまなアプローチでコンテナー イメージを構築します。
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はサポートされていません。
Kaniko - Docker を使用せずに Kubernetes でコンテナ イメージを構築します。
