翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Image Builder のレシピの管理
EC2 Image Builder レシピは、カスタマイズされたマシンイメージを作成するための設計図です。レシピは 3 つの主要な要素を指定します。
-
ベースイメージ – イメージの開始点 (AMI、コンテナイメージ、またはインポートされた VM)。
-
コンポーネント – イメージをカスタマイズするビルドステップとテストステップ。コンポーネントはオプションです。この設計では、テストとディストリビューション専用のワークフローがサポートされています。
-
設定 – ストレージボリューム、インスタンス設定、作業ディレクトリ、およびその他のビルドタイムパラメータ。
Image Builder は、次の 2 種類のレシピをサポートしています。
-
イメージレシピは、Amazon EC2 インスタンスの起動に使用できる Amazon マシンイメージ (AMIs) を生成します。
-
コンテナレシピは、Amazon ECR リポジトリに保存されているDockerコンテナイメージを生成します。
レシピはイミュータブルです。レシピを作成後に変更または置換することはできません。コンポーネントやその他の設定を更新するには、新しいレシピまたはレシピバージョンを作成する必要があります。Image Builder は以前のバージョンをすべて保持します。これにより、各出力を生成した正確なレシピまでイメージリネージをトレースできます。既存のレシピにはいつでもタグを適用できます。の Image Builder コマンドを使用したリソースのタグ付けの詳細については AWS CLI、このガイドのリソースにタグを付ける「」セクションを参照してください。
ヒント
Amazon マネージドコンポーネントをレシピで使用することも、独自のカスタムコンポーネントを開発することもできます。詳細については、「Image Builder イメージ用のカスタムコンポーネントの開発」を参照してください。出力 AMIs を作成するイメージレシピでは、 AWS Marketplace イメージ製品とコンポーネントを使用することもできます。 AWS Marketplace 製品との統合の詳細については、「」を参照してくださいAWS Marketplace Image Builder での統合。
このセクションのトピックを使用して、既存のレシピの一覧表示、詳細の表示、新しいレシピバージョンの作成など、EC2 Image Builder レシピを管理します。
内容
イメージレシピとコンテナレシピの比較
次の表は、イメージレシピとコンテナレシピの機能を比較したものです。
| 機能 | イメージのレシピ | コンテナレシピ |
|---|---|---|
| Output | AMI | Docker Amazon ECR のコンテナイメージ |
| ベースイメージソース | AMI ID、Image Builder イメージ ARN、SSM パラメータ、 AWS Marketplace 製品 | Docker Hub イメージ、Amazon ECR イメージ、Amazon マネージドイメージ、Image Builder イメージ ARN |
| Dockerfile | 該当しない | 必須 (コンテキスト変数を含むテンプレート) |
| ターゲットリポジトリ | 該当しない | Amazon ECR (必須) |
| ストレージ設定 | 出力 AMI のブロックデバイスマッピング | ビルドインスタンスのブロックデバイスマッピング |
| ユーザーデータ | サポート (デフォルトの cloud-init を上書き) | レシピレベルではサポートされていません |
| Systems Manager エージェントコントロール | 設定可能 (ビルド後にアンインストール) | 設定不可 |
| AWS Marketplace コンポーネント | サポート | サポートされていません |
| プラットフォームオーバーライド | 該当なし (AMI から検出) | Amazon ECR およびDocker Hubイメージで使用可能 |
レシピのバージョニング
すべてのレシピは、<major>.<minor>.<patch> 形式のセマンティックバージョニングを使用します。各バージョンノードは、0～1,073,741,823 (2^30 - 1) の値を受け入れます。
ワイルドカード (x) を 1 つの位置で使用して、自動バージョン増分を有効にできます。ワイルドカードバージョンでレシピを作成すると、Image Builder はその位置で次に使用可能な数値xで を置き換えます。
| パターン | 動作 | シーケンスの例 |
|---|---|---|
1.0.x |
パッチ番号をインクリメントする | 1.0.1、1.0.2、1.0.3、... |
1.x.0 |
マイナーナンバーをインクリメントする | 1.1.0、1.2.0、1.3.0、... |
x.0.0 |
メジャー番号をインクリメントする | 1.0.0、2.0.0、3.0.0、... |
ワイルドカードバージョンには、次のルールが適用されます。
-
バージョン文字列ごとに許可される
xワイルドカードは 1 つだけです。 -
ワイルドカードは任意の 1 つの位置 (メジャー、マイナー、またはパッチ) に表示できます。
-
残りの位置の数値は、明示的な整数である必要があります。
ヒント
CI/CD オートメーションでワイルドカードバージョンを使用すると、レシピバージョンを手動で追跡して増分する必要がなくなります。同じワイルドカードでレシピを作成するたびに、Image Builder は次に使用可能なバージョンを解決します。たとえば、常に を使用するレシピは、、1.0.1、 1.0.2などに1.0.x解決されます。Image Builder リソースのセマンティックバージョニングの詳細については、Image Builder でのセマンティックバージョニングを参照してください。
レシピの制約と制限
レシピを作成する前に、次の制約事項を確認してください。
| 制約 | 制限 | 注意事項 |
|---|---|---|
| レシピあたりのコンポーネント | 20 (デフォルト) | ビルドコンポーネントとテストコンポーネントの両方が含まれます。を通じて引き上げをリクエストできます AWS サポート。 |
| 最大レシピサイズ | 25 KB | パラメータ値を含む、すべてのコンポーネント設定の累積サイズ。 |
| 出力イメージあたりの製品コード | 9 | ベースイメージと AWS Marketplace コンポーネントから組み合わせます。 |
| コンポーネントの一意性 | レシピごとに 1 つ | 同じコンポーネント (バージョンに関係なく) は 1 回しか表示できません。 |
| バージョンノードの最大数 | 1,073,741,823 | ノードごと (メジャー、マイナー、またはパッチ）。 |
| レシピ名 | 変更できません | 名前は作成後に修正されます。別の名前の新しいレシピを作成します。 |
コンポーネントは、次の互換性要件を満たしている必要があります。
-
コンポーネントはレシピのプラットフォーム (Linux、Windows、macOS) と一致する必要があります。
-
OS バージョンのメタデータが利用可能な場合、コンポーネントは親イメージの OS バージョンをサポートしている必要があります。
-
DEPRECATEDまたはDISABLEDステータスのコンポーネントを新しいレシピに追加することはできません。 -
CIS 強化コンポーネントには、CIS が公開した親イメージが必要です。
リソースをクリーンアップする
予期しない料金が発生しないように、このガイドの例で作成したリソースとパイプラインは必ずクリーンアップしてください。Image Builder でのリソースの削除については、「未使用または古くなった Image Builder リソースの削除」を参照してください。
