BuildKit v0.11 は、Dockerfile 構文の Buildx v0.10 および v1.5 と共に利用可能になりました。 すべての Docker ビルド ツールの新機能、バグ修正、パフォーマンスの向上、 および改善されたドキュメントを リリースしました。
新機能に飛び込みましょう! ハイライトをカバーしますが、ストーリー全体は 完全な変更ログ.
この投稿の内容:
1. SLSAの来歴
BuildKit は、 SLSA Provenance 構成証明を作成してビルドをソースまでさかのぼり、ビルドがどのように作成されたかを理解しやすくできるようになりました。 新しいバージョンの Buildx と BuildKit でビルドされたイメージには、ソース コードへのリンク、ビルドのタイムスタンプ、ビルド中に使用されるマテリアルなどのメタデータが含まれています。 新しい来歴をアタッチするために、BuildKitはデフォルトで OCI準拠のイメージを作成するようになりました。
既定では、すべての新しい画像に来歴証明が追加されますが docker buildx 、より詳細にオプトインすることもできます。 これらの追加の詳細には、Dockerfile ソース、ソースマップ、および BuildKit で使用される中間表現が含まれます。 Buildx の新しい フラグを使用して --provenance 、これらの新しい来歴レコードをすべて有効にすることができます。
$ docker buildx build --provenance=true -t <myorg>/<myimage> --push .
または、来歴生成モードを手動で最小または最大に設定します(さまざまなモードの詳細をご覧ください)。
$ docker buildx build --provenance=mode=max -t <myorg>/<myimage> --push .
サブコマンドを使用して、画像の imagetools 出所を調べることができます。 たとえば、moby/buildkit イメージ自体では次のように表示されます。
$ docker buildx imagetools inspect moby/buildkit:latest --format '{{ json .Provenance }}'
{
"linux/amd64": {
"SLSA": {
"buildConfig": {
この来歴を使用して、ビルド元のgitリポジトリなど、ビルド環境に関する重要な情報を見つけることができます。
$ docker buildx imagetools inspect moby/buildkit:latest --format '{{ json (index .Provenance "linux/amd64").SLSA.invocation.configSource }}'
{
"digest": {
"sha1": "830288a71f447b46ad44ad5f7bd45148ec450d44"
},
"entryPoint": "Dockerfile",
"uri": "https://github.com/moby/buildkit.git#refs/tags/v0.11.0"
}
または、GitHubアクションでそれをビルドしたCIジョブでさえ:
$ docker buildx imagetools inspect moby/buildkit:latest --format '{{ (index .Provenance "linux/amd64").SLSA.builder.id }}'
https://github.com/moby/buildkit/actions/runs/3878249653
SLSA 来歴証明 の詳細や BuildKit の SLSA フィールドを調べるには、ドキュメントを参照してください。
2. ソフトウェア部品表
来歴の構成証明はビルドがどのように完了したかを記録するのに役立ちますが、ソフトウェア部品表 (SBOM) は使用されたコンポーネントを記録します。 これは のような docker sbomツールに似ていますが、独自のスキャンを実行する代わりに、イメージの作成者が結果をイメージに組み込むことができます。
組み込みの SBOM は、Buildx の新しいフラグを使用して --sbom 有効にできます。
$ docker buildx build --sbom=true -t <myorg>/<myimage> --push .
デフォルトでは、BuildKit は docker/buildkit-syft-scanner ( Anchore の Syft プロジェクトを搭載) を使用して、結果のイメージから SBOM をビルドします。 ただし、 BuildKit SBOMスキャンプロトコル に従うスキャナーは、ここで使用できます。
$ docker buildx build --sbom=generator=<custom-scanner> -t <myorg>/<myimage> --push .
SLSA の来歴と同様に、イメージツールを使用して、イメージに添付された SBOM をクエリできます。 たとえば、で使用されている検出されたすべての依存関係 moby/buildkitを一覧表示すると、次のようになります。
$ docker buildx imagetools inspect moby/buildkit:latest --format '{{ range (index .SBOM "linux/amd64").SPDX.packages }}{{ println .name }}{{ end }}'
github.com/Azure/azure-sdk-for-go/sdk/azcore
github.com/Azure/azure-sdk-for-go/sdk/azidentity
github.com/Azure/azure-sdk-for-go/sdk/internal
github.com/Azure/azure-sdk-for-go/sdk/storage/azblob
...
詳細については、 SBOM 構成証明のドキュメント を参照してください。
3. SOURCE_DATE_EPOCH
Dockerfilesから再現可能なビルドを取得することは、歴史的に非常にトリッキーでした—完全な再現可能なビルドには、毎回まったく同じ結果を生成するビットごとの精度が必要です。 完全に決定論的なビルドでも、実行間で異なるタイムスタンプを取得します。
新しい SOURCE_DATE_EPOCH ビルド引数は、 再現可能ビルド プロジェクトの標準化された環境変数に従って、これを解決するのに役立ちます。 ビルド引数が Buildx によって環境で設定または検出された場合、BuildKit はイメージ構成とレイヤーのタイムスタンプを指定された Unix タイムスタンプに設定します。 これにより、ビルドでビットごとの完全な再現性を得ることができます。
SOURCE_DATE_EPOCH は、環境から Buildx によって自動的に検出されます。 イメージ内のすべてのタイムスタンプをUnixエポックに強制するには:
$ SOURCE_DATE_EPOCH=0 docker buildx build -t <myorg>/<myimage> .
または、最新のコミットのタイムスタンプに設定するには:
$ SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) docker buildx build -t <myorg>/<myimage> .
BuildKit が をどのように処理 SOURCE_DATE_EPOCH するかの詳細については 、ドキュメント を参照してください。
4. 名前付きコンテキストとしてのOCIイメージ・レイアウト
BuildKitは、しばらくの間、 OCIイメージ・レイアウト をエクスポートできるようになりました。 v0.11以降、BuildKitは 名前付きコンテキストを使用してこれらの結果を再度インポートできます。 これにより、中間結果をレジストリにプッシュすることなく、完全にローカルでコンテキストを簡単に構築できます。
たとえば、いくつかの開発ツールを含む Alpine に基づく独自のカスタム中間イメージを構築するとします。
$ docker buildx build . -f intermediate.Dockerfile --output type=oci,dest=./intermediate,tar=false
これにより、の intermediate.Dockerfile コンテンツが構築され、OCIイメージ・レイアウトのディレクトリに intermediate/ エクスポートされます(OCIエクスポートの新しいオプションを使用 tar=false )。 この中間結果を Dockerfile で使用するには、メインの Dockerfile のステートメントで FROM 任意の名前を使用して参照します。
FROM base
RUN ... # use the development tools in the intermediate image
その後、フラグの新しい oci-layout:// --build-context URIスキーマを使用して、このDockerファイルをOCIレイアウトに接続できます:
$ docker buildx build . -t <myorg>/<myimage> --build-context base=oci-layout://intermediate
イメージベースをDocker Hubに解決する代わりに、BuildKitは現在のディレクトリから oci-layout://intermediate イメージベースを読み取るため、中間イメージをリモートレジストリにプッシュして使用する必要はありません。
フラグでの使用 --build-context の詳細については oci-layout:// 、ドキュメント を参照してください。
5.クラウドキャッシュバックエンド
CI パイプラインなどの一時的な環境でビルドするときに優れたビルド パフォーマンスを得るには、キャッシュをリモート バックエンドに格納する必要があります。 BuildKit の最新リリースでは、 Amazon S3 と Azure Blob Storage という 2 つの新しいストレージ バックエンドがサポートされています。
イメージをビルドするときに、S3 バケットまたは Azure BLOB ストアの詳細を指定して、ビルド キャッシュを自動的に保存し、将来のビルドに取り込むことができます。 このビルドキャッシュは、CIまたはローカルランナーが破棄されて再作成される場合でも、何も変更されていないときにリモートキャッシュにアクセスしてクイックビルドを取得できることを意味します。
新しいバックエンドを使用するには、and --cache-from フラグを使用して --cache-to バックエンドを指定します。
$ docker buildx build --push -t <user>/<image> \
--cache-to type=s3,region=<region>,bucket=<bucket>,name=<cache-image>[,parameters...] \
--cache-from type=s3,region=<region>,bucket=<bucket>,name=<cache-image> .
$ docker buildx build --push -t <registry>/<image> \
--cache-to type=azblob,name=<cache-image>[,parameters...] \
--cache-from type=azblob,name=<cache-image>[,parameters...] .
また、キャッシュバックエンドのどちらかを選択する必要もありません。 BuildKit v0.11 は一度に複数のキャッシュ エクスポートをサポートしているため、必要な数だけ使用できます。
新しい S3 バックエンドの詳細については、 Amazon S3 キャッシュと Azure BLOB ストレージ キャッシュ バックエンド のドキュメントを参照してください。
6. OCIイメージのアノテーション
OCI イメージ・アノテーションを使用すると、マニフェスト・レベルでメタデータをコンテナ・イメージにアタッチできます。 これらは、より一般的なラベルの代替であり、マルチプラットフォーム イメージに簡単に添付できます。
すべての BuildKit イメージエクスポータで、イメージエクスポータに注釈を設定できるようになりました。 選択した注釈を設定するには、次のフラグを使用します --output 。
$ docker buildx build ... \
--output "type=image,name=foo,annotation.org.opencontainers.image.title=Foo"
注釈は、出力の任意のレベル (イメージ インデックスなど) で設定できます。
$ docker buildx build ... \
--output "type=image,name=foo,annotation-index.org.opencontainers.image.title=Foo"
または、プラットフォームごとに異なる注釈を設定することもできます。
$ docker buildx build ... \
--output "type=image,name=foo,annotation[linux/amd64].org.opencontainers.image.title=Foo,annotation[linux/arm64].org.opencontainers.image.title=Bar"
BuildKitイメージでのOCIアノテーションの作成の詳細については、 ドキュメントを参照してください。
7.ビルド検査 --print
Dockerfilesを使用してコードベースから始めている場合、それらの使用方法を理解するのは難しい場合があります。 Buildx では、ビルドに関する詳細を出力するための新しい --print フラグがサポートされています。 このフラグを使用すると、必要なビルド引数とシークレット、およびビルドできるターゲットに関する情報をすばやく簡単に取得できます。
たとえば、BuildKit の Dockerfile の概要を取得する方法は次のとおりです。
$ BUILDX_EXPERIMENTAL=1 docker buildx build --print=outline https://github.com/moby/buildkit.git
TARGET: buildkit
DESCRIPTION: builds the buildkit container image
BUILD ARG VALUE DESCRIPTION
RUNC_VERSION v1.1.4
ALPINE_VERSION 3.17
BUILDKITD_TAGS defines additional Go build tags for compiling buildkitd
BUILDKIT_SBOM_SCAN_STAGE true
ビルドするさまざまなターゲットをすべてリストすることもできます。
$ BUILDX_EXPERIMENTAL=1 docker buildx build --print=targets https://github.com/moby/buildkit.git
TARGET DESCRIPTION
alpine-amd64
alpine-arm
alpine-arm64
alpine-s390x
BuildKit サブリクエストインターフェイスを実装するフロントエンドは、buildx --print フラグとともに使用できます。 独自の印刷関数を定義することもでき、 または targets に限定されません outline。
この機能は --print まだ実験段階であるため、インターフェイスが変更されたり、時間の経過とともに新しい機能が追加されたりする可能性があります。 フィードバックがある場合は、 docker / buildx GitHubで問題またはディスカッションを開いてください。
8.ベイク機能
ビルドをオーケストレーションするための Bake ファイル形式 も改善されました。
Bake はより強力な変数補間をサポートし、同じブロックまたは他のブロックのフィールドを使用できるようになりました。 これにより、重複が減り、ベイク処理ファイルが読みやすくなります。
target "foo" {
dockerfile = target.foo.name + ".Dockerfile"
tags = [target.foo.name]
}
bake はビルド引数の null 値もサポートしており、ラベルで Dockerfile に設定された既定値を使用できるため、ベイク定義がそれらをオーバーライドしないようにします。
variable "GO_VERSION" {
default = null
}
target "default" {
args = {
GO_VERSION = GO_VERSION
}
}
詳細については、 Bake のドキュメント を参照してください。
その他の改善とバグ修正
この投稿では、最新リリースの新機能の表面をかじっただけです。 上記のすべての機能に加えて、最新のリリースには生活の質の向上とバグ修正が含まれています。 詳細については、完全な変更ログをお読みください。
バグレポートや貢献を歓迎しているため、リリースで問題を見つけた場合は、GitHubの問題またはプルリクエストを開いてお知らせいただくか、 Docker コミュニティ Slack の #buildkit チャンネルでご連絡ください。