BuildKit v 0 . 11 、 Buildx v 0 . 10と共に利用可能になりました。およびDockerfile 構文の v 1 . 5 。Docker Build ツール全般について、新機能の追加、バグ修正、パフォーマンスの改善、ドキュメントの改訂を行いました。
新機能について詳しく見ていきましょう！主な変更点については後ほど説明しますが、詳細については完全な変更履歴をご覧ください。
この投稿の内容:
1. SLSAの来歴
BuildKitは、 SLSAプロベナンス証明書を作成できるようになり、ビルドのソースまで遡って追跡し、ビルドがどのように作成されたかをより簡単に理解できるようになりました。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のようなツールに似ていますが、自分でスキャンを実行する必要はなく、イメージの作成者がその結果をイメージに組み込むことができます。
Buildx の新しい--sbomフラグを使用すると、組み込み 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
その後、 --build-context フラグ用の新しい oci-layout:// URIスキーマを使用して、このDockerfileをOCIレイアウトに接続できます。
$ docker buildx build . -t <myorg>/<myimage> --build-context base=oci-layout://intermediate
イメージベースをDocker Hubに解決する代わりに、BuildKitは現在のディレクトリから oci-layout://intermediate イメージベースを読み取るため、中間イメージをリモートレジストリにプッシュして使用する必要はありません。
oci-layout:// を --build-context フラグとともに使用する方法の詳細については、 ドキュメント を参照してください。
5.クラウドキャッシュバックエンド
CIパイプラインなどの一時的な環境でビルドを行う際に、良好なビルドパフォーマンスを得るには、キャッシュをリモートバックエンドに保存する必要があります。BuildKit の最新リリースでは、Amazon S 3と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 は一度に複数のキャッシュ エクスポートをサポートしているため、必要な数だけ使用できます。
新しい S 3バックエンドの詳細については、 Amazon S 3キャッシュおよびAzure Blob Storage キャッシュ バックエンドのドキュメントを参照してください。
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 Community Slack の #buildkit チャンネルでご連絡ください。
