このセクションには、execution environments のセットアップとビルドに関連する参照情報が含まれています。
定義ファイルは、execution environment のイメージをビルドするために必要な .yml ファイルです。execution environment 定義スキーマの例は以下のとおりです。
---
version: 1
build_arg_defaults:
EE_BASE_IMAGE: 'quay.io/ansible/ansible-runner:stable-2.10-devel'
ansible_config: 'ansible.cfg'
dependencies:
galaxy: requirements.yml
python: requirements.txt
system: bindep.txt
additional_build_steps:
prepend: |
RUN whoami
RUN cat /etc/os-release
append:
- RUN echo This is a post-install command!
- RUN ls -la /etc
ビルド引数のデフォルト値は、default_build_args セクションの定義ファイルでディクショナリーとして指定できます。これは、--build-arg CLI フラグを使用する代わりとなります。
ansible-builder によって使用されるビルド引数は、以下のとおりです。
ANSIBLE_GALAXY_CLI_COLLECTION_OPTS により、ユーザーは –pre フラグを渡してプレリリースコレクションのインストールを有効化できます。
EE_BASE_IMAGE は、execution environment の親イメージを指定します。
EE_BUILDER_IMAGE は、タイプタスクのコンパイルに使用されるイメージを指定します。
default_build_args 内部に与えられた値は、Containerfile にハードコーディングされるため、podman build が手動で呼び出される場合は永続化します。
CLI --build-arg フラグで同じ変数が指定されている場合は、CLI 値の優先順位が高くなります。
ansible.cfg ファイルを使用して、プライベートアカウントのトークンとその他の設定を Automation Hub サーバーに渡す場合、ここに設定ファイルのパスを (文字列として) 一覧表示すると、ビルドの初期段階でビルド引数として含めることができます。
galaxy エントリーは、ansible-galaxy collection install -r ... コマンドの有効な要件ファイルを指しています。
エントリー requirements.yml は、execution environment 定義のフォルダーのディレクトリーからの相対パスであるか、または絶対パスである可能性があります。
Python エントリーは、pip install -r ... コマンドの有効な要件ファイルを指しています。
エントリー requirements.txt は、execution environment 定義のフォルダーのディレクトリーからの相対パスであるか、または絶対パスである可能性があります。
system エントリーは、bindep 要件ファイルを指します。これは bindep によって処理されてから dnf に渡されます。他のプラットフォームはまだサポートされていません。bindep の詳細については、OpenDev documentation を参照してください。
追加のコマンドは、メインビルド手順の前 (prepend) または後 (append) のいずれかで、additional_build_steps セクションで指定できます。構文は以下のいずれかである必要があります。
複数行の文字列 (上記の prepend セクションに例を示しています)
ディクショナリー (append を介して示すとおりです)
次のオプションは、ansible-builder build コマンドと使用できます。
フラグ |
説明 |
構文 |
|
ビルドされたイメージに適用されるタグ付きの名前をカスタマイズするには、以下を実行します。 |
|
|
|
|
|
現在の作業ディレクトリーに作成された |
|
|
Podman または Docker のビルド時の変数を使用するには、 |
|
カスタムベースイメージを使用するには、以下を実行します (以前に廃止された |
|
|
|
Podman のデフォルトの代わりに Docker を使用してイメージをビルドするには、以下を実行します。 |
|
|
詳細レベルをカスタマイズするには、以下を実行します。 |
|
test/data/pytz の例では、execution environment 定義に awx.awx のコレクションが必要です。ルックアッププラグイン awx.awx.tower_schedule_rrule が機能するには、PyPI pytz と別のライブラリーが必要です。test/data/pytz/execution-environment.yml ファイルが ansible-builder build コマンドに提供される場合は、イメージ内にコレクションがインストールされ、コレクション内の requirements.txt ファイルを読み取り、続いて pytz をイメージにインストールします。
生成されたイメージは、これらの変数をプライベートデータディレクトリー内の env/settings ファイル内に配置して、ansible-runner プロジェクト内で使用することができます。
---
container_image: image-name
process_isolation_executable: podman # or docker
process_isolation: true
awx.awx コレクションは、デフォルトの AWX execution environment に含まれるコンテンツのサブセットです。詳細については、awx-ee repository を参照してください。
execution environment の galaxy エントリー内のコレクションは、Python とシステム要件をイメージに提供します。
コレクションからの要件は、以下の方法で認識できます。
ファイル meta/execution-environment.yml は、Python および/または bindep 要件ファイルを参照します。
requirements.txt という名前のファイルは、コレクションのルートレベルにあります。
bindep.txt という名前のファイルは、コレクションのルートレベルにあります。
これらのファイルのいずれかがコレクションの build_ignore にある場合は、正しく動作しません。
コレクションメンテナーは、introspect コマンドを使用して、ansible-builder が想定する要件を認識していることを確認できます。いかに例を示します。
ansible-builder introspect --sanitize ~/.ansible/collections/
Python 要件ファイルは、他のファイルへの参照などの複雑な構文をサポートするために、requirements-parser ライブラリーを使用して 1 つのファイルに結合されます。
同じパッケージ名を与える別々のコレクションからのエントリーは、制約が結合された状態で同じエントリーに結合されます。
ansible-builder によって明確に 無視 されるパッケージ名がいくつかあります。コレクションがこれらのパッケージ名を一覧表示する場合、それらは結合されたファイルには含まれません。これらには、テストパッケージと Ansible 自体を提供するパッケージが含まれます。詳細な一覧は、ansible_builder.requirements モジュールの EXCLUDE_REQUIREMENTS を参照してください。
bindep 形式は、クロスプラットフォームの要件を指定する方法を提供します。コレクションが [platform:rpm] に必要な要件を指定することが、少なくとも想定されています。
複数のコレクションからのエントリーは、1 つのファイルに結合されます。プロファイルのない要件 (ランタイム要件) のみがイメージにインストールされます。互いに完全に重複している複数のコレクションからのエントリーは、結合されたファイルに統合される場合があります。