ビルドキット

その他のソースコード

0.17.0

ダウンロード

ビルドキット

BuildKit は、効率的、表現力豊か、再現可能な方法でソースコードを変換して成果物を構築するためのツールキットです。

主な特徴:

自動ガベージコレクション
拡張可能なフロントエンド形式
同時依存関係の解決
効率的な命令キャッシュ
ビルドキャッシュのインポート/エクスポート
ネストされたビルドジョブの呼び出し
分散可能なワーカー
複数の出力フォーマット
プラグイン可能なアーキテクチャ
root権限なしでの実行

moby/moby#32925 からの提案を読む

紹介ブログ投稿 https://blog.mobyproject.org/introducing-buildkit-17e056cc5317

Docker Community Slack の#buildkitチャンネルに参加してください

注記

RUN --mount=type=(bind|cache|tmpfs|secret|ssh)などの BuildKit のみの Dockerfile 機能を使用するためにこのリポジトリにアクセスしている場合は、Dockerfile リファレンスを参照してください。

注記

Docker Engine 23.0 以降、 docker buildデフォルトで Buildx と BuildKit を使用します。フル機能のスタンドアロンバージョンの BuildKit を使用しない限り、このドキュメントを読む必要はありません。

使用者
クイックスタート

イメージ/レジストリ
ローカルディレクトリ
ドッカーのtarボール
OCI tarボール
コンテナードイメージストア
buildctlを使用して Dockerfile をビルドする
外部フロントエンドを使用して Dockerfile を構築する
Linuxのセットアップ
Windowsのセットアップ
macOS のセットアップ
ソースからビルドする
LLB を探索する
Dockerfile の探索
出力

キャッシュ

インライン (画像とキャッシュを一緒にプッシュ)
レジストリ (イメージとキャッシュを個別にプッシュ)
ローカルディレクトリ
GitHub アクションキャッシュ (実験的)
S3 キャッシュ (実験的)
Azure Blob Storage キャッシュ (実験的)
ガベージコレクション
キャッシュのエクスポート
一貫したハッシュ化

メタデータ
Systemd ソケットのアクティベーション
BuildKit を TCP サービスとして公開する

負荷分散

BuildKit のコンテナ化

ポッドマン
オタク
Kubernetes
デーモンレス

OpenTelemetry のサポート
root権限なしでBuildKitを実行する
マルチプラットフォームイメージの構築

カラー出力コントロール
ログ行数 (tty モードのアクティブなステップの場合)
buildctlの構成

貢献する

使用者

BuildKit は次のプロジェクトで使用されます。

Moby & Docker ( DOCKER_BUILDKIT=1 docker build )
画像
OpenFaaSクラウド
コンテナビルドインターフェース
Tekton Pipelines (以前の Knative Build Templates)
Sanic ビルドツール
ヴァブ
リオ
キム
パウチコンテナ
Docker buildx
オクテトクラウド
地球の地球ファイル
Gitpod
短剣
環境
デポ
名前空間
ユニクラフト
デヴゼロ
ダック

クイックスタート

Kubernetes のデプロイメントについては、 examples/kubernetesを参照してください。

BuildKit は、 buildkitdデーモンとbuildctlクライアントで構成されます。 buildctlクライアントは Linux、macOS、および Windows で使用できますが、 buildkitdデーモンは現在 Linux と *Windows でのみ使用できます。

Linux、macOS、Windows 用の BuildKit の最新バイナリはここから入手できます。

Linuxのセットアップ

buildkitdデーモンには、次のコンポーネントがインストールされている必要があります。

ルンクまたはクラン
containerd (containerd ワーカーを使用する場合)

buildkitdデーモンの開始:ホスト上で root ユーザーとしてbuildkitd実行する必要があります。

 $ sudo ビルドキット

buildkitd非 root ユーザーとして実行するには、 docs/rootless.md参照してください。

buildkitd デーモンは、OCI (runc) とcontainerd という 2 つのワーカーバックエンドをサポートします。

デフォルトでは、OCI (runc) ワーカーが使用されます。 --oci-worker=false --containerd-worker=trueを設定すると、containerd ワーカーを使用できます。

さらにバックエンドを追加することも歓迎します。

systemd ソケットのアクティベーションを使用して buildkitd デーモンを起動するには、buildkit systemd ユニットファイルをインストールします。「Systemd ソケットのアクティベーション」を参照してください。

buildkitd デーモンは、デフォルトで/run/buildkit/buildkitd.sockで gRPC API をリッスンしますが、TCP ソケットを使用することもできます。「BuildKit を TCP サービスとして公開する」を参照してください。

Windowsのセットアップ

docs/windows.mdの手順と注意事項を参照してください。

macOS のセットアップ

macOSではHomebrew公式(非公式)が利用可能です。

 $ brew インストール ビルドキット

Homebrew の式にはデーモン ( buildkitd ) が含まれていません。

たとえば、Lima は、Linux VM 内でデーモンを起動するために使用できます。

 brew install limalimactl start template://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"

ソースからビルドする

ソースから BuildKit をビルドするには、 .github/CONTRIBUTING.md参照してください。

buildctlリファレンスについては、このドキュメントを参照してください。

LLB を探索する

BuildKit ビルドは、ビルドの一部を実行するプロセスの依存関係グラフを定義するために使用される LLB と呼ばれるバイナリ中間形式に基づいています。 tl;dr: Dockerfile にとっての LLB は、C にとっての LLVM IR と同じです。

Protobuf メッセージとしてマーシャリングされる
同時実行可能
効率的にキャッシュ可能
ベンダー中立 (つまり、Dockerfile 以外の言語も簡単に実装できます)

形式の定義については、 solver/pb/ops.proto参照してください。LLB アプリケーションの例については、 ./examples/README.mdを参照してください。

現在、LLB には次の高級言語が実装されています。

Dockerfile (「Dockerfile の探索」を参照)
ビルドパック
モッカーファイル
ゴッカーファイル
bldr (パッケージファイル)
HLB
アースファイル (地球)
貨物埠頭(錆び)
ニックス
モピー（Python）
envd (スターラーク)
脂肪
ベース
kraft.yaml (ユニクラフト)
r2d4/llb (JSON ゲートウェイ)
(PR を開いて独自の言語を追加します)

Dockerfile の探索

フロントエンドは、BuildKit 内で実行され、ビルド定義を LLB に変換するコンポーネントです。ゲートウェイ ( gateway.v0 ) と呼ばれる特別なフロントエンドがあり、任意のイメージをフロントエンドとして使用できます。

開発中、Dockerfile フロントエンド ( dockerfile.v0 ) も BuildKit リポジトリの一部です。将来的には、これは廃止され、外部イメージを使用して Dockerfile を構築できるようになります。

`buildctl`を使用して Dockerfile をビルドする

buildctl ビルド
     --frontend=dockerfile.v0
     --ローカルコンテキスト=。
     --local dockerfile=.# orbuildctl ビルド
     --frontend=dockerfile.v0
     --ローカルコンテキスト=。
     --local dockerfile=。
     --opt ターゲット=foo
     --opt ビルド引数:foo=bar

--local 、ローカルソースファイルをクライアントからビルダーに公開します。 contextとdockerfile 、Dockerfile フロントエンドがビルドコンテキストと Dockerfile の場所を探す名前です。

Dockerfile に別のファイル名がある場合は--opt filename=./Dockerfile-alternativeで指定できます。

外部フロントエンドを使用して Dockerfile を構築する

Dockerfile フロントエンドの外部バージョンは https://hub.docker.com/r/docker/dockerfile-upstream および https://hub.docker.com/r/docker/dockerfile にプッシュされ、ゲートウェイフロントエンドで使用できます。。外部フロントエンドのソースは現在./frontend/dockerfile/cmd/dockerfile-frontendにありますが、将来的にはこのリポジトリから移動される予定です (#163)。このリポジトリの master ブランチからの自動ビルドには、 docker/dockerfile-upstream:masterまたはdocker/dockerfile-upstream:master-labsイメージを使用できます。

 buildctl ビルド
     --フロントエンド ゲートウェイ.v0
     --opt ソース=docker/dockerfile
     --ローカルコンテキスト=。
     --local dockerfile=。
buildctl ビルド
     --フロントエンド ゲートウェイ.v0
     --opt ソース=docker/dockerfile
     --opt context=https://github.com/moby/moby.git
     --opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.org

出力

デフォルトでは、ビルド結果と中間キャッシュは BuildKit の内部にのみ残ります。結果を取得するには出力を指定する必要があります。

イメージ/レジストリ

buildctl build ... --output type=image,name=docker.io/username/image,push=true

イメージを複数のレジストリにエクスポートするには:

 buildctl build ... --output type=image,"name=docker.io/username/image,docker.io/username2/image2",push=true

キャッシュ埋め込みをイメージとともにエクスポートし、一緒にレジストリにプッシュするには、キャッシュをインポートするためにタイプregistryが必要です。 --export-cache type=inlineおよび--import-cache type=registry,ref=...を指定する必要があります。。キャッシュをローカルに直接エクスポートするには、 --export-cache type=local指定する必要があります。詳細はエクスポートキャッシュを参照してください。

 buildctl ビルド ...
  --output type=image,name=docker.io/username/image,push=true
   --export-cache タイプ=インライン
   --import-cache type=registry,ref=docker.io/username/image

画像出力でサポートされているキー:

name= : イメージ名を指定します
push=true : イメージ作成後にプッシュします
push-by-digest=true : 名前のない画像をプッシュします
registry.insecure=true : 安全でない HTTP レジストリにプッシュします
oci-mediatypes=true : Docker の代わりに構成 JSON で OCI メディアタイプを使用します
unpack=true : 作成後にイメージを解凍します (containerd で使用するため)
dangling-name-prefix= : prefix@が付いた名前画像。匿名画像に使用されます。
name-canonical=true : 追加の正規名name@を追加します
compression= : 新しく作成されキャッシュされたレイヤーの圧縮タイプを選択します。gzip はデフォルト値です。 estargz はoci-mediatypes=trueとともに使用する必要があります。
compression-level= : gzip、estargz (0 ～ 9)、および zstd (0 ～ 22) の圧縮レベル
rewrite-timestamp=true : ファイルのタイムスタンプをSOURCE_DATE_EPOCH値に書き換えます。 SOURCE_DATE_EPOCH値を指定する方法については、 docs/build-repro.mdを参照してください。
force-compression=true : すべてのレイヤー (既存のレイヤーを含む) にcompressionオプションを強制的に適用します。
store=true : 結果のイメージをワーカー (containerd など) のイメージストアに保存し、イメージにコンテンツストア内のすべての BLOB が確実に含まれるようにします (デフォルトはtrue )。ワーカーにイメージストアがない場合 (OCI ワーカーなど) は無視されます。
annotation.= : それぞれのkeyとvalueを含む注釈をビルドされたイメージに添付します

拡張構文annotation-.= 、 annotation[].=を使用し、両方をannotation-[].=と組み合わせます。 annotation-[].=使用すると、注釈を付ける場所を正確に構成できます。
、アタッチするオブジェクトを指定します。 manifest (デフォルト)、 manifest-descriptor 、 index 、 index-descriptorのいずれかを指定できます。
、アタッチするオブジェクト (デフォルトではすべて) を指定します。これは、 platform opt に渡されるキーと同じです。 docs/multi-platform.mdを参照してください。
詳細については、 docs/annotations.md参照してください。

認証情報が必要な場合、 buildctl Docker 構成ファイル$DOCKER_CONFIG/config.jsonを読み取ろうとします。 $DOCKER_CONFIGのデフォルトは~/.dockerです。

ローカルディレクトリ

ローカルクライアントはファイルをクライアントに直接コピーします。これは、BuildKit がコンテナーイメージ以外のものをビルドするために使用されている場合に便利です。

 buildctl build ... --output type=local,dest=path/to/output-dir

特定のファイルをエクスポートするには、スクラッチステージでマルチステージビルドを使用し、必要なファイルをCOPY --fromでそのステージにコピーします。

 ...FROM スクラッチ as testresultCOPY --from=builder /usr/src/app/testresult.xml 。
...

 buildctl build ... --opt target=testresult --output type=local,dest=path/to/output-dir

マルチプラットフォームビルドでは、各ターゲットプラットフォームに一致するサブフォルダーが宛先ディレクトリに作成されます。

 FROMbusybox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROMScratchCOPY --from=build /out /

 $ buildctl ビルド
   --フロントエンド dockerfile.v0
   --opt プラットフォーム=linux/amd64、linux/arm64
   --output type=local,dest=./bin/release

$ ツリー ./bin
./bin/
└── リリース
    §── linux_amd64
    │ └── hello-linux-amd64
    ━── linux_arm64
        └── hello-linux-arm64

platform-split=falseを設定すると、すべてのプラットフォームのファイルを同じディレクトリにマージできます。

 $ buildctl ビルド
   --フロントエンド dockerfile.v0
   --opt プラットフォーム=linux/amd64、linux/arm64
   --output type=local,dest=./bin/release,platform-split=false

$ ツリー ./bin
./bin/
└── リリース
    §── hello-linux-amd64
    └── hello-linux-arm64

Tar エクスポーターはローカルエクスポーターと似ていますが、tarball を通じてファイルを転送します。

 buildctl build ... --output type=tar,dest=out.tar
buildctl build ... --output type=tar > out.tar

ドッカーのtarボール

# エクスポートされた tarball は OCI specbuildctl build とも互換性があります ... --output type=docker,name=myimage |ドッカーロード

OCI tarボール

buildctl build ... --output type=oci,dest=path/to/output.tar
buildctl build ... --output type=oci > Output.tar

コンテナードイメージストア

Containerd ワーカーを使用する必要があります

buildctl build ... --output type=image,name=docker.io/username/image
ctr --namespace=buildkit イメージ ls

containerd 名前空間を変更するには、 /etc/buildkit/buildkitd.tomlのworker.containerd.namespace変更する必要があります。

キャッシュ

ローカルビルドキャッシュ ( /var/lib/buildkit ) を表示するには:

 buildctl du -v

ローカルビルドキャッシュを削除するには:

 buildctlプルーン

ガベージコレクション

./docs/buildkitd.toml.mdを参照してください。

キャッシュのエクスポート

BuildKit は次のキャッシュエクスポーターをサポートしています。

inline : キャッシュをイメージに埋め込み、一緒にレジストリにプッシュします
registry : イメージとキャッシュを別々にプッシュします
local : ローカルディレクトリにエクスポートします
gha : GitHub Actions キャッシュにエクスポート

ほとんどの場合、 inlineキャッシュエクスポーターを使用します。ただし、 inlineキャッシュエクスポーターはminキャッシュモードのみをサポートすることに注意してください。 maxキャッシュモードを有効にするには、 registryキャッシュエクスポーターを使用してイメージとキャッシュを別々にプッシュします。

inlineエクスポーターとregistryエクスポーターはどちらもキャッシュをレジストリに保存します。キャッシュをインポートする場合、キャッシュ形式を指定する必要はないため、両方ともtype=registryで十分です。

インライン (画像とキャッシュを一緒にプッシュ)

 buildctl ビルド ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache タイプ=インライン
   --import-cache type=registry,ref=docker.io/username/image

--import-cache type=registry,ref=...が指定されない限り、インラインキャッシュはインポートされないことに注意してください。

インラインキャッシュは、キャッシュメタデータをイメージ構成に埋め込みます。キャッシュ情報のない画像と比較して、画像内のレイヤーはそのまま残ります。

Docker に統合された BuildKit ( DOCKER_BUILDKIT=1 docker build ) とdocker buildxでは、 inlineキャッシュエクスポータを有効にするために--build-arg BUILDKIT_INLINE_CACHE=1指定する必要があります。ただし、スタンドアロンのbuildctl --opt build-arg:BUILDKIT_INLINE_CACHE=1必要とせず、build-arg は単に無視されます。

レジストリ (イメージとキャッシュを個別にプッシュ)

 buildctl ビルド ...
   --output type=image,name=localhost:5000/myrepo:image,push=true
   --export-cache type=registry,ref=localhost:5000/myrepo:buildcache
   --import-cache type=registry,ref=localhost:5000/myrepo:buildcache

--export-cacheオプション:

type=registry
mode= : エクスポートするキャッシュレイヤーを指定します (デフォルト: min )

min : 結果の画像のレイヤーのみをエクスポートします
max : すべての中間ステップのすべてのレイヤーをエクスポートします。

ref= : キャッシュを保存するためのリポジトリ参照を指定します (例: docker.io/user/image:tag )
image-manifest= : キャッシュ・マニフェストをマニフェスト・リスト/インデックスではなくOCI互換のイメージ・マニフェストとしてエクスポートするかどうか(デフォルト: false 、 oci-mediatypes=trueとともに使用する必要があります)
oci-mediatypes= : エクスポートされたマニフェストでOCIメディアタイプを使用するかどうか(デフォルト: true 、 BuildKit v0.8以降)
compression= : 新しく作成されキャッシュされたレイヤーの圧縮タイプを選択します。gzip はデフォルト値です。 estargz および zstd はoci-mediatypes=trueとともに使用する必要があります
compression-level= : gzip、estargz (0 ～ 9)、および zstd (0 ～ 22) の圧縮レベルを選択します。
force-compression=true : すべてのレイヤーにcompressionオプションを強制的に適用します
ignore-error= : キャッシュのエクスポートが失敗した場合にエラーを無視するかどうかを指定します (デフォルト: false )

--import-cacheオプション:

type=registry
ref= : キャッシュを取得するリポジトリ参照を指定します (例: docker.io/user/image:tag )

ローカルディレクトリ

buildctl build ... --export-cache type=local,dest=path/to/output-dir
buildctl build ... --import-cache type=local,src=path/to/input-dir

ディレクトリのレイアウトは OCI Image Spec v1.0 に準拠しています。

--export-cacheオプション:

type=local
mode= : エクスポートするキャッシュレイヤーを指定します (デフォルト: min )

min : 結果の画像のレイヤーのみをエクスポートします
max : すべての中間ステップのすべてのレイヤーをエクスポートします。

dest= : キャッシュエクスポータの宛先ディレクトリ
tag= : ローカルインデックスに書き込む画像のカスタムタグを指定します (デフォルト: latest )
image-manifest= : キャッシュ・マニフェストをマニフェスト・リスト/インデックスではなくOCI互換のイメージ・マニフェストとしてエクスポートするかどうか(デフォルト: false 、 oci-mediatypes=trueとともに使用する必要があります)
oci-mediatypes= : エクスポートされたマニフェストでOCIメディアタイプを使用するかどうか(デフォルトはtrue 、 BuildKit v0.8以降)
compression= : 新しく作成されキャッシュされたレイヤーの圧縮タイプを選択します。gzip はデフォルト値です。 estargz および zstd はoci-mediatypes=trueとともに使用する必要があります。
compression-level= : gzip、estargz (0 ～ 9)、および zstd (0 ～ 22) の圧縮レベル
force-compression=true : すべてのレイヤーにcompressionオプションを強制的に適用します
ignore-error= : キャッシュのエクスポートが失敗した場合にエラーを無視するかどうかを指定します (デフォルト: false )

--import-cacheオプション:

type=local
src= : キャッシュインポーターのソースディレクトリ
tag= : ローカルインデックスから読み取る画像のカスタムタグを指定します (デフォルト: latest )
digest=sha256: : インポートするマニフェストリストの明示的なダイジェストを指定します

GitHub アクションキャッシュ (実験的)

 buildctl ビルド ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache type=gha
   --import-cache type=gha

GitHub Actions キャッシュは、キャッシュメタデータとレイヤーの両方を GitHub のキャッシュサービスに保存します。このキャッシュには現在、リポジトリ内の異なるキャッシュ間で共有される 10 GB のサイズ制限があります。この制限を超えると、GitHub はキャッシュを保存しますが、合計サイズが 10 GB 未満になるまでキャッシュの削除を開始します。キャッシュを頻繁にリサイクルしすぎると、全体的な実行時間が遅くなる可能性があります。

アクション/キャッシュの使用と同様に、キャッシュはブランチごとにスコープが設定され、デフォルトブランチとターゲットブランチがすべてのブランチで利用可能になります。

GitHub Actions Cache サービス API に対して認証するには、次の属性が必要です。

url : キャッシュサーバーのURL (デフォルトは$ACTIONS_CACHE_URL )
token : アクセストークン (デフォルト$ACTIONS_RUNTIME_TOKEN )

このタイプのキャッシュは、 urlとtokenが自動的に設定される Docker Build Push アクションで使用できます。インラインrunステップでこのバックエンドを使用するには、ワークフローにcrazy-max/ghaction-github-runtimeを含めてランタイムを公開する必要があります。

--export-cacheオプション:

type=gha
mode= : エクスポートするキャッシュレイヤーを指定します (デフォルト: min )

min : 結果の画像のレイヤーのみをエクスポートします
max : すべての中間ステップのすべてのレイヤーをエクスポートします。

scope= : キャッシュオブジェクトが属するスコープ (デフォルトのbuildkit )
ignore-error= : キャッシュのエクスポートが失敗した場合にエラーを無視するかどうかを指定します (デフォルト: false )
timeout= : キャッシュエクスポートのタイムアウト期間を設定します (デフォルト: 10m )

--import-cacheオプション:

type=gha
scope= : キャッシュオブジェクトが属するスコープ (デフォルトのbuildkit )
timeout= : キャッシュインポートのタイムアウト期間を設定します (デフォルト: 10m )

S3 キャッシュ (実験的)

 buildctl ビルド ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache type=s3、region=eu-west-1、bucket=my_bucket、name=my_image
   --import-cache type=s3、region=eu-west-1、bucket=my_bucket、name=my_image

次の属性が必要です。

bucket : AWS S3 バケット (デフォルト: $AWS_BUCKET )
region : AWS リージョン (デフォルト: $AWS_REGION )

保管場所:

BLOB: s3://// 、デフォルト: s3:///blobs/
マニフェスト: s3://// 、デフォルト: s3:///manifests/

S3 構成:

blobs_prefix : s3 で BLOB を保存/読み取りするためのグローバルプレフィックス (デフォルト: blobs/ )
manifests_prefix : s3 にマニフェストを保存/読み取るためのグローバルプレフィックス (デフォルト: manifests/ )
endpoint_url : 特定の S3 エンドポイントを指定します (デフォルト: 空)
use_path_style : trueに設定すると、ホスト名ではなく URL にバケット名を入力します (デフォルト: false )。

AWS認証:

最も簡単な方法は、IAM インスタンスプロファイルを使用することです。他のオプションは次のとおりです。

AWS Go SDK でサポートされる環境変数/設定ファイルを使用するシステム。構成は、クライアントではなく、ビルドキットデーモンで使用できる必要があります。
次の属性を使用します。

access_key_id : アクセスキーID
secret_access_key : シークレットアクセスキー
session_token : セッショントークン

--export-cacheオプション:

type=s3
mode= : エクスポートするキャッシュレイヤーを指定します (デフォルト: min )

min : 結果の画像のレイヤーのみをエクスポートします
max : すべての中間ステップのすべてのレイヤーをエクスポートします。

prefix= : s3 にファイルを保存/読み取りするためのグローバルプレフィックスを設定します (デフォルト: 空)
name= : 使用するマニフェストの名前を指定します (デフォルトのbuildkit )

; で区切って複数のマニフェスト名を同時に指定できます; 。標準的な使用例は、名前として git sha1 を使用し、重複としてブランチ名を使用し、2 つのimport-cacheコマンドで両方をロードします。

ignore-error= : キャッシュのエクスポートが失敗した場合にエラーを無視するかどうかを指定します (デフォルト: false )
touch_refresh=24h : 変更されない場合は再度アップロードされるのではなく、BLOB ファイルはtouch_refreshごとに s3 で「タッチ」されます。デフォルトは 24 時間です。このため、S3 バケットに有効期限ポリシーを設定して、不要なファイルを自動的にクリーンアップできます。マニフェストファイルは体系的に書き換えられるため、触れる必要はありません。
upload_parallelism=4 : このパラメータは、s3 に並行してアップロードされるレイヤーの数を変更します。個々のレイヤーは、AWS SDK が提供するアップロードマネージャーを使用して、5 つのスレッドでアップロードされます。

--import-cacheオプション:

type=s3
prefix= : s3 にファイルを保存/読み取りするためのグローバルプレフィックスを設定します (デフォルト: 空)
blobs_prefix= : s3 に BLOB を保存/読み取りするためのグローバルプレフィックスを設定します (デフォルト: blobs/ )
manifests_prefix= : s3 にマニフェストを保存/読み取りするためのグローバルプレフィックスを設定します (デフォルト: manifests/ )
name= : 使用するマニフェストの名前 (デフォルトのbuildkit )

Azure Blob Storage キャッシュ (実験的)

 buildctl ビルド ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache type=azblob、account_url=https://myaccount.blob.core.windows.net、name=my_image
   --import-cache type=azblob、account_url=https://myaccount.blob.core.windows.net、name=my_image

次の属性が必要です。

account_url : Azure Blob Storage アカウントの URL (デフォルト: $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL )

保管場所:

BLOB: /// 、デフォルト: //blobs/
マニフェスト: /// 、デフォルト: //manifests/

Azure Blob Storage の構成:

container : Azure Blob Storage コンテナー名 (デフォルト: buildkit-cacheまたは設定されている場合は$BUILDKIT_AZURE_STORAGE_CONTAINER )
blobs_prefix : Azure Blob Storage コンテナー ( ) に BLOB を保存/読み取るためのグローバルプレフィックス (デフォルト: blobs/ )
manifests_prefix : Azure Blob Storage コンテナー ( ) 上で BLOB を保存/読み取りするためのグローバルプレフィックス (デフォルト: manifests/ )

Azure Blob Storage 認証:

Azure Blob Storage 認証では 2 つのオプションがサポートされています。

Azure SDK for Go でサポートされている環境変数を使用するシステム。構成は、クライアントではなく、ビルドキットデーモンで使用できる必要があります。
シークレットアクセスキーsecret_access_key属性を使用して、Azure Blob Storage アカウントのプライマリアカウントキーまたはセカンダリアカウントキーを指定します。 Azure Blob Storage アカウントキー

注記

アカウント名がアカウント URL ホストの一部でない場合は、 account_name属性 (または$BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ) でアカウント名を指定することもできます。

--export-cacheオプション:

type=azblob
mode= : エクスポートするキャッシュレイヤーを指定します (デフォルト: min )

min : 結果の画像のレイヤーのみをエクスポートします
max : すべての中間ステップのすべてのレイヤーをエクスポートします。

prefix= : Azure Blob Storage コンテナー ( ) にファイルを保存または読み取るためのグローバルプレフィックスを設定します (デフォルト: 空)
name= : 使用するマニフェストの名前を指定します (デフォルト: buildkit )

; で区切って複数のマニフェスト名を同時に指定できます; 。標準的な使用例は、名前として git sha1 を使用し、重複としてブランチ名を使用し、2 つのimport-cacheコマンドで両方をロードします。

ignore-error= : キャッシュのエクスポートが失敗した場合にエラーを無視するかどうかを指定します (デフォルト: false )

--import-cacheオプション:

type=azblob
prefix= : Azure Blob Storage コンテナー ( ) にファイルを保存または読み取るためのグローバルプレフィックスを設定します (デフォルト: 空)
blobs_prefix= : Azure Blob Storage コンテナー ( ) に BLOB を保存/読み取りするためのグローバルプレフィックスを設定します (デフォルト: blobs/ )
manifests_prefix= : Azure Blob Storage コンテナー ( ) にマニフェストを保存/読み取りするためのグローバルプレフィックスを設定します (デフォルト: manifests/ )
name= : 使用するマニフェストの名前 (デフォルト: buildkit )

一貫したハッシュ化

複数の BuildKit デーモンインスタンスがあるが、クラスター全体でキャッシュを共有するためにレジストリを使用したくない場合は、コンシステントハッシュを使用したクライアント側の負荷分散を検討してください。

./examples/kubernetes/consistenthashを参照してください。

メタデータ

イメージダイジェストなどのビルドメタデータを出力するには、 --metadata-fileフラグを渡します。メタデータは、指定されたファイルに JSON オブジェクトとして書き込まれます。指定したファイルのディレクトリはすでに存在しており、書き込み可能である必要があります。

 buildctl build ... --metadata-file metadata.json

 jq「。」メタデータ.json

 { "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "containerimage.descriptor": {"annotations": { "config.digest": 2f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": " 2022-02-08T21:28:03Z"},"digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3","mediaType": "application/vnd.oci.image.manifest.v1+json": 506
  }, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"}

Systemd ソケットのアクティベーション

Systemd ベースのシステムでは、 buildkitd --addr fd://使用して Systemd ソケットのアクティベーションを介してデーモンと通信できます。 BuildKit および Systemd での Systemd ソケットのアクティベーションの使用例は、 ./examples/systemdにあります。

BuildKit を TCP サービスとして公開する

buildkitdデーモンは、TCP ソケットで gRPC API をリッスンできます。

デーモンとクライアント (mTLS) の両方に TLS 証明書を作成することを強くお勧めします。 mTLS なしで TCP を有効にすることは危険です。実行コンテナ (別名 Dockerfile RUNコンテナ) も BuildKit API を呼び出すことができるためです。

ビルドキット
   --addr tcp://0.0.0.0:1234
   --tlscacert /パス/to/ca.pem
   --tlscert /path/to/cert.pem
   --tlskey /path/to/key.pem

ビルドctl
   --addr tcp://example.com:1234
   --tlscacert /パス/to/ca.pem
   --tlscert /パス/to/clientcert.pem
   --tlskey /パス/to/clientkey.pem
   建てる ...

負荷分散

buildctl buildランダムに負荷分散されたbuildkitdデーモンに対して呼び出すことができます。

クライアント側の負荷分散のための一貫したハッシュも参照してください。

BuildKit のコンテナ化

BuildKit は、Docker コンテナ内でbuildkitdデーモンを実行し、リモートでアクセスすることによっても使用できます。

コンテナーイメージはmoby/buildkitとして提供されます。

moby/buildkit:latest : 最新の通常リリースからビルドされます
moby/buildkit:rootless : latestと同じですが、特権のないユーザーとして実行されます。 docs/rootless.mdを参照してください。
moby/buildkit:master : master ブランチからビルドされます
moby/buildkit:master-rootless : master と同じですが、特権のないユーザーとして実行されます。 docs/rootless.mdを参照してください。

コンテナ内でデーモンを実行するには:

 docker run -d --name buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd
buildctl build --help

ポッドマン

Podman コンテナーで実行されている BuildKit デーモンに接続するには、 docker-container:// podman-container:// :// を使用します。

 podman run -d --name buildkitd --privileged moby/buildkit:latest
buildctl --addr=podman-container://buildkitd build --frontend dockerfile.v0 --local context=。 --local dockerfile=。 --output type=oci |ポッドマン ロード foo

sudo必要ありません。

オタク

Nerdctl コンテナーで実行されている BuildKit デーモンに接続するには、 docker-container:// nerdctl-container:// :// を使用します。

 nerdctl run -d --name buildkitd --privileged moby/buildkit:latest
buildctl --addr=nerdctl-container://buildkitd build --frontend dockerfile.v0 --local context=。 --local dockerfile=。 --output type=oci | nerdctlロード

sudo必要ありません。

Kubernetes

Kubernetes のデプロイメントについては、 examples/kubernetesを参照してください。

デーモンレス

単一のコンテナーでクライアントと一時デーモンを実行するには (「デーモンレスモード」):

ドッカーラン
     -それ
     --rm
     --特権付き
     -v /path/to/dir:/tmp/work
     --entrypoint buildctl-daemonless.sh
     moby/ビルドキット:マスター
         建てる
         --フロントエンド dockerfile.v0
         --local context=/tmp/work
         --local dockerfile=/tmp/work

または

ドッカーラン
     -それ
     --rm
     --security-opt seccomp=制限なし
     --security-opt apparmor=制限なし
     -e BUILDKITD_FLAGS=--oci-worker-no-process-sandbox
     -v /path/to/dir:/tmp/work
     --entrypoint buildctl-daemonless.sh
     moby/buildkit:master-rootless
         建てる
          - フロントエンド
         dockerfile.v0
         --local context=/tmp/work
         --local dockerfile=/tmp/work

OpenTelemetry のサポート

BuildKit は、buildkitd gRPC API および buildctl コマンドの OpenTelemetry をサポートします。トレースをJaegerにキャプチャするには、 JAEGER_TRACE環境変数を収集アドレスに設定します。

 docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# JAEGER_TRACE がわかるように buildkitd と buildctl を再起動します# buildctl コマンドは http:/ にトレースされる必要があることがわかります/127.0.0.1:16686/

Windows では、Jaeger をコンテナーjaeger-all-in-one.exeの外で実行している場合は、環境変数setx -m JAEGER_TRACE "0.0.0.0:6831"を設定し、新しい端末でbuildkitd再起動すると、トレースは次のようになります。自動的に収集されます。

root権限なしでBuildKitを実行する

docs/rootless.mdを参照してください。

マルチプラットフォームイメージの構築

docs/multi-platform.mdを参照してください。

`buildctl`の構成

カラー出力コントロール

buildctl端末に情報を出力するために使用される色の変更をサポートしています。環境変数BUILDKIT_COLORS run=green:warning=yellow:error=red:cancel=255,165,0のような値に設定して、使用する色を設定できます。 NO_COLOR何かに設定すると、no-color.org で推奨されているように、カラー化された出力が無効になります。

解析エラーは報告されますが、無視されます。これにより、必要に応じてデフォルトのカラー値が使用されます。

事前定義された色のリスト。

ログ行数 (tty モードのアクティブなステップの場合)

BUILDKIT_TTY_LOG_LINES数値 (デフォルト: 6) に設定することで、tty モードでアクティブなステップに表示されるログ行の数を変更できます。

貢献する

BuildKit に貢献したいですか?素晴らしい！このプロジェクトへの貢献に関する情報は、CONTRIBUTING.md で見つけることができます。

拡大する

追加情報

バージョン 0.17.0
タイプその他のソースコード
更新時間 2024-11-05
サイズ
言語簡体字中国語

ビルドキット

ビルドキット

使用者

クイックスタート

Linuxのセットアップ

Windowsのセットアップ

macOS のセットアップ

ソースからビルドする

LLB を探索する

Dockerfile の探索

buildctlを使用して Dockerfile をビルドする

外部フロントエンドを使用して Dockerfile を構築する

出力

イメージ/レジストリ

ローカルディレクトリ

ドッカーのtarボール

OCI tarボール

コンテナードイメージストア

キャッシュ

ガベージコレクション

キャッシュのエクスポート

インライン (画像とキャッシュを一緒にプッシュ)

レジストリ (イメージとキャッシュを個別にプッシュ)

ローカルディレクトリ

GitHub アクション キャッシュ (実験的)

S3 キャッシュ (実験的)

Azure Blob Storage キャッシュ (実験的)

一貫したハッシュ化

メタデータ

Systemd ソケットのアクティベーション

BuildKit を TCP サービスとして公開する

負荷分散

BuildKit のコンテナ化

ポッドマン

オタク

Kubernetes

デーモンレス

OpenTelemetry のサポート

root権限なしでBuildKitを実行する

マルチプラットフォームイメージの構築

buildctlの構成

カラー出力コントロール

ログ行数 (tty モードのアクティブなステップの場合)

貢献する

`buildctl`を使用して Dockerfile をビルドする

GitHub アクションキャッシュ (実験的)

`buildctl`の構成