14. 実行環境¶

自動化用に Python 仮想環境をビルドおよびデプロイできる機能は、Ansible 実行環境に置き換えられました。レガシーの仮想環境とは異なり、システムレベルの依存関係やコレクションベースのコンテンツを組み込むことができるコンテナーイメージがあります。各実行環境では、ジョブを実行するためのカスタマイズされたイメージを使用できます。また、各実行環境には、ジョブの実行時に必要なものだけが含まれ、それ以上のものは含まれていません。

14.1. 実行環境のビルド¶

デフォルト以外の依存関係 (カスタムの仮想環境) に依存する Ansible コンテンツの使用には注意が必要です。パッケージは各ノードにインストールされ、ホストシステムにインストールされている他のソフトウェアとうまく連携し、同期を保つ必要があります。以前は、ジョブはデフォルトで /var/lib/awx/venv/ansible の仮想環境内で実行されていました。これには、ansible-runner と、Ansible コントロールマシンで使用される特定のタイプの Ansible コンテンツの依存関係がプリロードされていました。

このプロセスを簡素化するために、Ansible として機能するコンテナーイメージをビルドできます`control nodes <https://docs.ansible.com/ansible/latest/network/getting_started/basic_concepts.html#control-node>`_。これらのコンテナーイメージは自動化 execution environments と呼ばれ、ansible-builder で作成してから、ansible-runner でこれらの画像を利用できます。

14.1.1. ansible-builder のインストール¶

イメージをビルドするには、podman または docker のいずれかを ansible-builder Python パッケージとともにインストールする必要があります。--container-runtime オプションは、使用する予定の Podman / Docker 実行可能ファイルに対応している必要があります。

PyPi からインストールする場合:

$ pip install ansible-builder

メインライン開発ブランチからインストールする場合:

$ pip install https://github.com/ansible/ansible-builder/archive/devel.zip

特定のタグまたはブランチからインストールする場合は、以下の例で <ref> を置き換えます。

$ pip install https://github.com/ansible/ansible-builder/archive/<ref>.zip

14.1.2. 実行環境のビルド¶

execution environment の作成に ansible-builder を使用します。

execution environment には以下が含まれると想定されます。

Ansible
Ansible Runner
Ansible コレクション
以下のPython および/またはシステムの依存関係
- コレクション内のモジュール/プラグイン
- ansible-base のコンテンツ
- カスタムのユーザーニーズ

新しい execution environment のビルドには、コレクション、Python 要件、システムレベルのパッケージなど、execution environment に含めるコンテンツを指定する定義 (.yml ファイル) が関わっています。execution environments への移行から生成された出力のコンテンツには、ファイルにパイプしたり、この定義ファイルに貼り付けたりできる必要なデータがいくつか含まれています。詳細は、従来の venvs を実行環境に移行を参照してください。仮想環境から移行しなかった場合は、実行環境の定義で概説されている必要なデータを使用して定義ファイルを作成できます。

コレクション開発者は、適切なメタデータを提供することにより、コンテンツの要件を宣言できます。詳細については、コレクションレベルのメタデータを参照してください。

14.1.3. ビルダーの実行¶

定義を作成したら、この手順を使用して execution environment を作成します。

ansible-builder build コマンドは、execution environment 定義を入力として受け取ります。execution environment イメージのビルドに必要なビルドコンテキストを出力し、そのイメージのビルドを続行します。イメージは他の場所のビルドコンテキストで再ビルドでき、同じ結果を生成します。デフォルトでは、現在のディレクトリーで execution-environment.yml という名前のファイルを検索します。

説明のために、以下のサンプル execution-environment.yml ファイルを開始点として使用します。

---
version: 1
dependencies:
  galaxy: requirements.yml

requirements.yml のコンテンツ

---
collections:
  - name: awx.awx

上記のファイルを使用して execution environment をビルドするには、以下を実行します。

$ ansible-builder build
...
STEP 7: COMMIT my-awx-ee
--> 09c930f5f6a
09c930f5f6ac329b7ddb321b144a029dbbfcc83bdfc77103968b7f6cdfc7bea2
Complete! The build context can be found at: context

すぐに使用できるコンテナーイメージの生成に加え、ビルドコンテキストが保持されます。これは、docker build または podman build などの選択したツールを使用して、別の時間や場所で再ビルドすることができます。

14.2. ジョブでの実行環境の使用¶

ジョブで execution environment を使用するには、いくつかのコンポーネントが必要です。

execution environment は、必ず ansible-builder を使用して作成しておく必要があります。詳細は実行環境のビルドを参照してください。execution environment が作成されると、これを使用してジョブを実行できます。automation controller ユーザーインターフェースを使用して、ジョブテンプレートで使用する execution environment を指定します。
execution environment をグローバルに使用できるようにするか、組織に関連付けるかによって、ジョブで execution environment を使用するには、適切なレベルの管理者権限が必要です。組織に関連付けられた Execution environments では、組織管理者がそれらの execution environments でジョブを実行できる必要があります。
認証情報が割り当てられた execution environment を使用するジョブまたはジョブテンプレートを実行する前に、認証情報にユーザー名、ホスト、およびパスワードが含まれていることを確認してください。

コントローラーユーザーインターフェイスの左側にあるナビゲーションバーから Execution Environments をクリックします。
追加ボタンを選択して execution environment を追加します。
以下のフィールドに該当する詳細を入力します。

Name: execution environment の名前を入力します (必須)。
Image: イメージ名を入力します (必須)。イメージ名には、正確な場所 (リポジトリー)、レジストリー、イメージ名、およびバージョンタグが quay.io/ansible/awx-ee:latestrepo/project/image-name:tag のサンプル形式で必要です。
Pull: オプションで、ジョブの実行時にプルのタイプを選択します。

Always pull container before running: コンテナーの最新のイメージファイルをプルします。

Only pull the image if not present before running: 指定されていない場合のみ最新のイメージをプルします。

Never pull container before running: コンテナーイメージの最新バージョンをプルしないでください。

Description: オプション。
Organization: オプションで、この execution environment を明確に使用するように組織を割り当てます。複数の組織にまたがって execution environment を使用できるようにするには、このフィールドを空白のままにします。
Registry credential: イメージに保護されたコンテナーレジストリーがある場合は、それにアクセスするための認証情報を提供します。

保存をクリックします。

新しく追加された execution environment は、ジョブテンプレートで使用できるようになりました。ジョブテンプレートに execution environment を追加するには、以下の例に示すようにジョブテンプレートの Execution Environment フィールドで指定します。ジョブテンプレートの設定の詳細については、『Automation Controller User Guide』の「ジョブテンプレート」を参照してください。

_images/job-template-with-example-ee-selected.png

execution environment をジョブテンプレートに追加すると、execution environment の Templates タブにそれらのテンプレートが一覧表示されていることを確認できます。

14.3. 実行環境のマウントオプション¶

execution environment を再構築して証明書を追加するのも 1 つの方法ですが、ホストから証明書を継承することで、より便利なソリューションが提供されます。VM ベースのインストールでは、ジョブ実行時にコントローラーが自動的にシステムトラストストアを execution environment にマウントします。

さらに、execution environment マウントオプションとマウントパスをジョブ設定ページの 分離されたジョブに公開するパス フィールドでカスタマイズすることができ、そこでは podman スタイルのボリュームマウント構文がサポートされています。詳細は、Podman documentation を参照してください。

execution environment のカスタマイズにより、execution environment のイメージに /etc/ssh/* のファイルが追加された場合、SSH エラーが発生することがあります。たとえば、/etc/ssh/ssh_config.d:/etc/ssh/ssh_config.d:O パスを公開すると、コンテナーはマウントできますが、所有権パーミッションは正しくマッピングされません。

このエラーが発生した場合、または古いバージョンのコントローラー (3.8.x など) からアップグレードした場合は、次の手順を実行します。

マウントされたボリュームのコンテナー所有権を root に変更します。
ジョブ設定ページの 分離されたジョブに公開するパス フィールドで、現在の例を用いて、以下のようにパスを公開します。

_images/settings-paths2expose-iso-jobs.png

注釈

:O オプションは、ディレクトリーに対してのみサポートされています。特にシステムパスを指定する場合は、できるだけ具体的に指定することを強くお勧めします。/etc や /usr を直接マウントすると、トラブルシューティングが困難になるほどの影響があります。

これにより、Podman に以下の例のようなコマンドを実行するように通知されます。このコマンドにより、設定がマウントされ、ssh コマンドが想定どおりに動作するようになります。

podman run -v /ssh_config:/etc/ssh/ssh_config.d/:O ...

OpenShift または Kubernetes コンテナー内の分離されたパスを HostPath として公開するには、以下の設定を想定してください。

_images/settings-paths2expose-iso-jobs-mount-containers.png

コンテナーグループのホストパスの公開 トグルを使用して有効にします。

Playbook が実行されると、結果として以下の例のような Pod 仕様が表示されます。volumeMounts と volumes セクションの詳細に注目してください。