Docker Bake が Docker Desktop 4で一般公開されました。38!

Docker Bake with Docker Desktop 4の一般提供開始を発表できることを嬉しく思います。38!この強力なビルドオーケストレーションツールは、複雑なビルドの管理の手間を省き、あらゆる規模のチームにシンプルさ、柔軟性、パフォーマンスを提供します。

Docker Bakeとは?

Docker Bake は、Compose がランタイム環境の管理を簡素化するのと同様に、Docker ビルドを効率化するオーケストレーション ツールです。 Bake を使用すると、ビルドステージとデプロイ環境を宣言型ファイルで定義できるため、複雑なビルドの管理が容易になります。 また、BuildKit の並列化および最適化機能を活用して、ビルド時間を短縮します。

Dockerfileはイメージのビルドステップを定義するのに最適ですが、チームは多くの場合、複数のイメージをビルドし、テスト、リンティング、コード生成などのヘルパータスクを実行する必要があります。 従来、これは多数の docker build コマンドと独自のオプションや引数をジャグリングすることを意味し、退屈でエラーが発生しやすいプロセスでした。

Bake は、 ターゲットと呼ばれるすべてのオプションと画像の依存関係をカプセル化する宣言型ファイル形式を導入することで、ゲームを変えます。 さらに、Bake の並列化と重複排除機能により、より高速で効率的なビルドが保証されます。

なぜBakeを使用する必要があるのですか?

複雑なDockerビルド構成の課題:

• 無数のフラグと環境変数で満たされた長くて複雑なビルドコマンドの管理。
• 複数のイメージを構築するための面倒なワークフロー。
• 特定のターゲットまたは環境のビルドを宣言するのが難しい。
• 管理しやすくするためには、スクリプトまたは 3rdパーティツールが必要です

Docker Bake は、シンプルな宣言型アプローチで複雑なビルドをより適切に管理することで、これらの課題に取り組んでいます。

Docker Bake の主な利点

• シンプルさ: Docker ビルド コマンドとスクリプトの複雑なチェーンを 1 つの docker buildx bake コマンドに置き換えながら、理解と変更が容易な、バージョン管理された明確な構成ファイルを維持します。
• 柔軟性: HCL 構文とマトリックス ビルドを通じて高度なビルド ロジックを表現し、さまざまな環境や要件に適応する動的構成を可能にしながら、高度なユース ケース向けのカスタム機能をサポートします。
• 一貫性: バージョン管理されたファイルと継承パターンを通じて、チームと環境間で標準化されたビルド構成を維持し、環境固有のビルドの問題を排除し、構成のドリフトを減らします。
• パフォーマンス:独立したビルドを自動的に並列化し、コンテキスト重複排除とインテリジェントキャッシングにより冗長な操作を排除し、複雑なマルチイメージワークフローのビルド時間を大幅に短縮します。

図 1:すべてのフラグと環境変数を置き換える1つの簡単なDocker buildx bakeコマンド。

Docker Bake の使用例

1。 モノレポとイメージベーカリー

Docker Bake は、開発者が 1 つのソース リポジトリから複数の関連する Docker イメージを効率的に管理および構築するのに役立ちます。 さらに、共有構成と自動化された依存関係処理を活用して、組織の標準を適用できます。

• 開発効率: チームは、1 つのリポジトリ内の数十または数百のマイクロサービス間で一貫したビルド ロジックを維持できるため、構成のドリフトとメンテナンスのオーバーヘッドが削減されます。
• リソースの最適化: 共有ベースイメージとコンテキストは自動的に重複排除されるため、ビルド時間とストレージコストが大幅に削減されます。
• 標準化： 継承された構成を通じて組織の標準を適用し、すべてのサービスがセキュリティ、タグ付け、およびテストの要件に従っていることを確認します。
• 変更管理: ビルド構成の信頼できる唯一の情報源により、基本イメージの更新やセキュリティ パッチなど、組織全体の変更を簡単に実装できます。

2。 ユーザーを作成する

Docker Bake は、既存の docker-compose.yml ファイルとのシームレスな互換性を提供し、現在の設定を直接使用できます。 既存の Compose ユーザーは、最小限の労力で Bake の使用を開始できます。

• 段階的な採用: チームは、既存の作成ワークフローと知識を活用しながら、高度なビルド機能を段階的に採用できます。
• 開発の一貫性: ローカル開発 (compose 経由) と本番ビルド (Bake 経由) の両方に同じ設定を使用して、「自分のマシンで動作する」という問題を解消します。
• 強化された機能: マトリックス ビルドや HCL 式などの強力な機能にアクセスしながら、使い慣れた Compose 構文との互換性を維持します。
• CI/CD統合:Bakeの高度なビルド機能を追加しながら、Composeファイルをすでに理解している既存のCI/CDパイプラインとシームレスに統合します。

3。 複雑なビルド構成

開発者は、 Bake のターゲット、 グループ、 変数、 関数、 行列ターゲット 、その他多くのツールを使用して、プロジェクトやチーム全体のビルド構成を簡素化できます。

• クロスプラットフォームの互換性: マトリックスビルドを使用すると、チームは複数のアーキテクチャ、OSバージョン、依存関係の組み合わせにわたるビルドを1つの構成から効率的に管理できます。
• ダイナミックアダプテーション: HCL 式を使用すると、ビルドは複数の構成を維持することなく、さまざまな環境、git ブランチ、または CI 変数に適応できます。
• ビルドの最適化: カスタム関数を使用すると、バージョンの計算、タグの生成、Git 履歴に基づく条件付きビルドなどの高度なロジックが可能になります。
• 品質管理: 変数の検証と継承により、複雑なビルドシナリオ間で一貫した構成が保証され、エラーとメンテナンスの負担が軽減されます。
• スケール管理: グループとターゲットは、数十または数百の順列を持つ大規模なビルドシステムを整理するのに役立ち、それらを管理および保守可能にします。

4。 Docker ビルド クラウド

Bake に最適化されたビルドを基盤として、開発者はより効率的な Docker Build Cloud のパフォーマンスとより高速なビルドを実現できます。

• Docker Build Cloud のパフォーマンスの強化: クラウドインフラストラクチャ全体でマトリックスビルドを即座に並列化し、ビルドインフラストラクチャを管理することなく、1時間にわたるビルドパイプラインを数分に変えます。
• リソースの最適化: Build Cloud の分散キャッシングと重複排除を活用することで、帯域幅の使用量とビルド時間を大幅に削減できます。これは、リモート チームにとって特に価値があります。
• コスト管理: DBCでコストを節約 — Bakeの正確なターゲット定義により、構築する必要があるものだけにクラウドリソースを消費できます。
• 開発者エクスペリエンス: チームは、強力なローカルマシンを使用せずに複雑なマルチアーキテクチャビルドを実行できるため、ビルドパフォーマンスを維持しながら、任意のデバイスからの開発が可能になります。
• CI/CD の機能強化: リソースを大量に消費するビルドを CI ランナーから Build Cloud にオフロードすることで、CI のコストとキュー時間を削減しながら信頼性を向上させます。

Bake for GAの新機能

Docker Bake は数年前から実験的な機能であり、ユーザーからのフィードバックに基づいて改良および改善することができました。 そのため、 ターゲット と グループ、 変数、 HCL発現サポート、 継承 機能、 マトリックスターゲット、追加の contextsなど、ユーザーが愛する強力な成分セットがすでに存在しています。 この GA リリースにより、Bake は本番環境で使用できるようになり、より効率的で安全、かつ使いやすくするためにいくつかの機能強化が追加されました。

• 重複排除されたコンテキスト転送: 複数のターゲットが同じビルドコンテキストを共有する場合の冗長なファイル転送を排除することで、ビルドパイプラインを大幅に高速化します。
• エンタイトルメント: ビルド プロセス中にビルダーがアクセスできる機能とリソースをきめ細かく制御することで、セキュリティとリソース管理を強化します。
• コンポーザブル属性: チームが再利用可能な属性セットを定義できるようにすることで、構成管理を簡素化し、異なるターゲット間で組み合わせたり、一致させたり、オーバーライドしたりできるようにします。
• 変数の検証: 実際のビルドプロセスが始まる前に設定エラーをキャッチすることで、時間とリソースの浪費を防ぎます。

コンテキスト転送の重複排除

グループを使用してターゲットを同時にビルドすると、ビルドコンテキストはターゲットごとに個別にロードされます。 グループ内の複数のターゲットで同じコンテキストが使用されている場合、そのコンテキストは使用されるたびに 1 回転送されます。 これは、ビルド構成によっては、ビルド時間に大きな影響を与える可能性があります。

以前は、回避策として、コンテキスト ファイルを読み込む名前付きコンテキストを定義し、各ターゲットが名前付きコンテキストを参照する必要がありました。 しかし、Bake を使用すると、これは自動的に処理されます。

Bake は、同じコンテキストを共有するターゲットからのコンテキスト転送を自動的に重複排除できます。 グループを使用してターゲットを同時にビルドすると、ビルドコンテキストはターゲットごとに個別にロードされます。 グループ内の複数のターゲットで同じコンテキストが使用されている場合、そのコンテキストは使用されるたびに 1 回転送されます。 このより効率的なアプローチにより、ビルド時間が大幅に短縮されます。 

ビルド時間を短縮する方法については、 ドキュメントをご覧ください。 

エンタイトルメント

Bake には、Buildと連携して、特権操作へのアクセスを制御する権限が含まれるようになりました。 これにより、意図しない副作用やセキュリティリスクを防ぐことができます。 Bake が潜在的な問題 (特権アクセス要求や現在のディレクトリ外のファイルへのアクセス試行など) を検出した場合、明示的に許可されていない限り、ビルドは失敗します。

一貫性を保つために、Bake コマンドは、追加のエンタイトルメントへのアクセスを許可するための --allow=ENTITLEMENT flag をサポートするようになりました。 現在、Bake では次の権限がサポートされています。

• 同等のものを構築する
  • --allow network.host ― ホスト・ネットワーキングでの実行を許可します。
  • --security .insecure を許可します。 ― サンドボックスなしでの実行を許可します。 つまり、 —特権)
• ファイル システム: 作業ディレクトリの外部にあるファイルにアクセスする必要があるビルドに対して、ファイル システム アクセスを許可します。 これは影響します context, output, cache-from, cache-to, dockerfile, secret
  • --allow fs=<path|*> ― 作業ディレクトリの外部にあるファイルへの読み取りおよび書き込みアクセス権を付与します。
  • --allow fs.read=<path|*> ― 作業ディレクトリの外部にあるファイルへの読み取りアクセス権を付与します。
  • --allow fs.write=<path|*> ― 作業ディレクトリの外部にあるファイルへの書き込みアクセス権を付与します。
• ティッカー
  • --sshを許可する -SSHエージェントの公開を許可します。

コンポーズ可能な属性

以前は、いくつかの属性を CSV で定義する必要がありました (例: type=provenance,mode=min). これらは読みにくく、簡単に上書きすることはできませんでした。 次のものを構造化オブジェクトとして定義できるようになりました。

target "app" {
		attest = [
			{ type = "provenance", mode = "max" },
			{ type = "sbom", disabled = true}
		]

		cache-from = [
			{ type = "registry", ref = "user/app:cache" },
			{ type = "local", src = "path/to/cache"}
		]

		cache-to = [
			{ type = "local", dest = "path/to/cache" },
		]

		output = [
			{ type = "oci", dest = "../out.tar" },
			{ type = "local", dest="../out"}
		]

		secret = [
			{ id = "mysecret", src = "path/to/secret" },
			{ id = "mysecret2", env = "TOKEN" },
		]

		ssh = [
			{ id = "default" },
			{ id = "key", paths = ["path/to/key"] },
		]
}

そのため、属性はコンポーザブルになりました。 チームは、異なるターゲット間で属性を混在、一致、およびオーバーライドできるため、構成管理が簡素化されます。

 target "app-dev" {
    attest = [
			{ type = "provenance", mode = "min" },
			{ type = "sbom", disabled = true}
		]
  }

  target "app-prod" {
    inherits = ["app-dev"]

    attest = [
			{ type = "provenance", mode = "max" },
		]
  }

変数の検証

Bake は、開発者が設定エラーを早期に発見して解決できるように、 Terraform に似た変数の検証をサポートするようになりました。 Bake の GA は、次のユース ケースもサポートしています。

基本的な検証

変数の値が予期される型、値の範囲、またはその他の条件に準拠していることを確認するために、 validation ブロックを使用してカスタム検証ルールを定義できます。

variable "FOO" {
  validation {
    condition = FOO != ""
    error_message = "FOO is required."
  }
}

target "default" {
  args = {
    FOO = FOO
  }
}

複数の検証

複数の条件を評価するには、変数に複数の validation ブロックを定義します。 すべての条件が true である必要があります。

variable "FOO" {
  validation {
    condition = FOO != ""
    error_message = "FOO is required."
  }
  validation {
    condition = strlen(FOO) > 4
    error_message = "FOO must be longer than 4 characters."
  }
}

target "default" {
  args = {
    FOO = FOO
  }
}

他の変数への依存性

条件式で他の Bake 変数 を参照できるため、変数間の依存関係を強制する検証が可能になります。 これにより、従属変数が正しく設定されてから続行できます。

variable "FOO" {}
variable "BAR" {
  validation {
    condition = FOO != ""
    error_message = "BAR requires FOO to be set."
  }
}

target "default" {
  args = {
    BAR = BAR
  }
}

新しいベイクオプション

Bake 設定の更新に加えて、新しい –list オプションを追加しました。 以前は、プロジェクトに詳しくない場合や、サポートされているターゲットと変数のリマインダーが必要な場合は、ファイルを読む必要がありました。 これで、リストオプションを使用すると、それらのリストをすばやくクエリできます。 また、プログラムによるアクセスが必要な場合は、JSON形式のオプションもサポートしています。

対象を一覧表示

Bake 設定で使用可能なターゲットのリストをすばやく取得します。

• docker buildx bake --list targets
• docker buildx bake --list type = targets、format = json

変数のリスト

Bake 設定で使用可能な変数のリストを取得します。

• docker buildx bake --list 変数
• docker buildx bake --list type = variables 、 format = json

これらの改善は強力な機能セットに基づいて構築されており、Bakeは信頼性と将来性を兼ね備えています。

Docker Bake の使用を開始する

ビルドをシンプルにする準備はできましたか? Docker Desktop 4に更新します。今日38 、Bakeを使い始めてください。 宣言型構文と高度な機能を備えたDocker Bakeは、より速く、より効率的に、より少ない労力で構築できるように支援します。

ドキュメントを参照して、最初の Bake ファイルを作成する方法を学び、合理化されたビルドの利点を直接体験してください。

一緒に何か素晴らしいものを焼きましょう!