2.5. 定義ファイルの内容の内訳
自動化実行環境コンテナーイメージに含まれるコンテンツを指定するため、Ansible Builder で自動化実行環境を構築するには、定義ファイルが必要です。
次のセクションでは、定義ファイルの内容を説明します。
2.5.1. ビルド引数およびベースイメージ
定義ファイルの build_arg_defaults セクションは、キーが Ansible Builder への引数のデフォルト値を指定できるディクショナリーです。build_arg_defaults で使用できる値の一覧は、以下の表を参照してください。
| 値 | 説明 |
|---|---|
|
| コレクションのインストールフェーズで、ユーザーは ansible-galaxy CLI に任意の引数を渡すことができます。たとえば、プレリリースコレクションのインストールを有効にする –pre フラグや、サーバーの SSL 証明書の検証を無効にする -c などです。 |
|
| 使用すると、–no-deps などのフラグをロールのインストールに渡すことができます。 |
build_arg_defaults で指定される値は Containerfile にハードコーディングされるため、podman build を手動で呼び出すとこの値が維持されます。
CLI --build-arg フラグで同じ変数が指定されている場合は、CLI 値の優先順位が高くなります。
最終イメージにインストールする必要がある依存関係は、定義ファイルの依存関係セクションに含めることができます。
自動化実行環境イメージに関する問題を回避するには、Galaxy、Python、およびシステムのエントリーが有効な要件ファイルを指していること、またはそれぞれのファイルタイプに対して有効なコンテンツであることを確認してください。
2.5.1.1. Galaxy
galaxy エントリーには、有効な要件ファイルへの参照か、ansible-galaxy collection install -r … コマンドのインラインコンテンツを含めます。
requirements.yml エントリーは、自動化実行環境定義のフォルダーのディレクトリーからの相対パスか、絶対パスにすることができます。
内容は次のようになります。
例2.2 Galaxy エントリー
collections: - community.aws - kubernetes.core
2.5.1.2. Python
定義ファイル内の Python エントリーは、有効な要件ファイル、または pip install -r … コマンドの PEP508 形式の Python 要件のインラインリストを参照します。
requirements.txt エントリーは、Collection がすでに Python の依存関係としてリストされているように追加の Python 要件をインストールするファイルです。自動化実行環境定義のフォルダーのディレクトリーからの相対パス、または絶対パスとして記載されている可能性があります。requirements.txt ファイルの内容は、pip freeze コマンドの標準出力と同様に、以下の例のような形式にする必要があります。
例2.3 Python エントリー
boto>=2.49.0 botocore>=1.12.249 pytz python-dateutil>=2.7.0 awxkit packaging requests>=2.4.2 xmltodict azure-cli-core==2.11.1 openshift>=0.6.2 requests-oauthlib openstacksdk>=0.13 ovirt-engine-sdk-python>=4.4.10
2.5.1.3. システム
定義内の system エントリーは、bindep 要件ファイルまたは bindep エントリーのインラインリストを指します。これらは、コレクションに依存関係としてすでに含まれているものの範囲外にあるシステムレベルの依存関係をインストールします。自動化実行環境定義のフォルダーのディレクトリーからの相対パスまたは絶対パスとしてリスト表示できます。少なくとも、コレクションでは [platform:rpm] に必要な要件を指定する必要があります。
これは、libxml2 パッケージおよび subversion パッケージをコンテナーに追加する bindep.txt ファイルの例です。
例2.4 System エントリー
libxml2-devel [platform:rpm] subversion [platform:rpm]
複数のコレクションからのエントリーは、1 つのファイルに統合されます。これは bindep により処理され、dnf に渡されます。プロファイルのない要件や、ランタイム要件がイメージにインストールされません。
2.5.2. イメージ
定義ファイルの イメージ セクションでは、ベースイメージを識別します。署名付きコンテナーイメージの検証は、podman コンテナーランタイムでサポートされています。
イメージ で使用できる値のリストについては、次の表を参照してください。
| 値 | 説明 |
|---|---|
|
| 自動化実行環境の親イメージを指定し、既存のイメージに基づいて新しいイメージをビルドできるようにします。これは通常、ee-minimal または ee-supported などのサポートされる実行環境ベースイメージですが、作成済みでさらにカスタマイズしたい実行環境イメージでも問題ありません。
コンテナーイメージが使用するには
デフォルトのイメージは |
CLI --build-arg フラグで同じ変数が指定されている場合は、CLI 値の優先順位が高くなります。
2.5.3. 追加のビルドファイル
定義ファイルの additional_build_steps セクションに外部ファイルを参照またはコピーすることで、任意の外部ファイルをビルドコンテキストディレクトリーに追加できます。形式はディクショナリー値のリストで、各リスト項目に src および dest のキーと値を含めます。
各リスト項目は、次の必須キーを含むディクショナリーである必要があります。
src-
ビルドコンテキストディレクトリーにコピーするソースファイルを指定します。これは、絶対パス (
/home/user/.ansible.cfgなど) か、実行環境ファイルへの相対パスにすることができます。相対パスは、1 つ以上のファイルに一致する glob 式にすることができます (files/*.cfgなど)。
絶対パスには正規表現を含めることはできません。src がディレクトリーの場合、そのディレクトリーの内容全体が dest にコピーされます。
dest-
ソースファイル (例:
files/configs) が含まれるビルドコンテキストディレクトリーの_buildサブディレクトリーの下にあるサブディレクトリーパスを指定します。この値を絶対パスにしたり、パス内に..を含めたりすることはできません。このディレクトリーが存在しない場合は、Ansible Builder によって作成されます。
2.5.4. 追加のカスタムビルドの手順
定義ファイルの additional_build_steps セクションで、任意のビルドフェーズのカスタムビルドコマンドを指定できます。これにより、ビルドフェーズをきめ細かく制御できるようになります。
prepend_ および append_ コマンドを使用して、メインのビルドステップの実行前または実行後に実行されるディレクティブを Containerfile に追加します。コマンドは、ランタイムシステムに必要なルールに準拠する必要があります。
added_build_steps で使用できる値のリストは、次の表を参照してください。
| 値 | 説明 |
|---|---|
|
| ベースイメージをビルドする前にコマンドを挿入できます。 |
|
| ベースイメージをビルドした後にコマンドを挿入できます。 |
|
| galaxy イメージをビルドする前に挿入できます。 |
|
| galaxy イメージをビルドした後に挿入できます。 |
|
| Python ビルダーイメージをビルドする前に、コマンドを挿入できます。 |
|
| Python ビルダーイメージをビルドした後に、コマンドを挿入できます。 |
|
| 最終イメージをビルドする前に挿入できます。 |
|
| 最終イメージをビルドした後に挿入できます。 |
added_build_steps の構文は、複数行の文字列とリストの両方をサポートします。以下の例を参照してください。
例2.5 複数行の文字列エントリー
prepend_final: | RUN whoami RUN cat /etc/os-release
例2.6 リストエントリー
append_final: - RUN echo This is a post-install command! - RUN ls -la /etc
2.5.5. 関連情報
- 一般的なシナリオの定義ファイルの例については、Ansible Builder ドキュメント の COMMON SCENARIOS セクションを参照してください。
