ビルドキット v0.11 リリースのハイライト

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 チャンネルでご連絡ください。

build, BuildKit, Buildx, dockerfile

フィードバック

「ビルドキットv0リリースのハイライト」に関する0.11の考え

ビルドキット v0.11 リリースのハイライト

この投稿の内容:

1. SLSAの来歴

2. ソフトウェア部品表

3. SOURCE_DATE_EPOCH

4. 名前付きコンテキストとしてのOCIイメージ・レイアウト

5.クラウドキャッシュバックエンド

6. OCIイメージのアノテーション

7.ビルド検査 `--print`

8.ベイク機能

その他の改善とバグ修正

フィードバック

掲示される

投稿タグ

カテゴリ

ビルドキット v0.11 リリースのハイライト

この投稿の内容:

1. SLSAの来歴

2. ソフトウェア部品表

3. SOURCE_DATE_EPOCH

4. 名前付きコンテキストとしてのOCIイメージ・レイアウト

5.クラウドキャッシュバックエンド

6. OCIイメージのアノテーション

7.ビルド検査 --print

8.ベイク機能

その他の改善とバグ修正

フィードバック

DockerとJFrogが提携し、Docker Hubのセキュリティを強化し、悪意のあるリンクを含む何百万ものイメージレスリポジトリを削除

JavaでGenAIアプリケーションをテストするための有望な方法論

より良いデバッグ:Signal0neDocker拡張機能がAIを使用してコンテナのトラブルシューティングを簡素化する方法

掲示 される

投稿タグ

カテゴリ

7.ビルド検査 `--print`

掲示される