実行環境の作成および消費
Red Hat Ansible Automation Platform 用の一貫性のある再現可能な自動化実行環境を作成します。
概要
はじめに
Ansible Builder を使用して、Red Hat Ansible Automation Platform のニーズに合わせて一貫性のある再現可能な自動化実行環境を作成します。
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 自動化実行環境の概要
各ノードにパッケージをインストールして、ホストシステムにインストールされている他のソフトウェアと対話し、同期を維持する必要があるため、デフォルト以外の依存関係に依存する Ansible コンテンツを使用することは複雑になる可能性があります。
自動化実行環境は、このプロセスを単純化し、Ansible Builder で簡単に作成できます。
1.1. 自動化実行環境について
自動化実行環境は、Red Hat Ansible Automation Platform のすべての自動化が実行するコンテナーイメージです。自動化実行環境は、自動化の依存関係を通信するための共通の言語を作成し、自動化環境を構築して配布するための標準的な方法を提供します。
自動化実行環境には、以下が含まれます。
- Ansible 2.9 または Ansible Core 2.11-2.13
- Python 3.8-3.10
- Ansible Runner
- Ansible コンテンツコレクション
- コレクション、Python、またはシステムの依存関係
1.1.1. 自動化実行環境を使用する理由
自動化実行環境では、Red Hat Ansible Automation Platform はコントロールプレーンを実行プレーンから分離することで、分散アーキテクチャーに移行されました。コントロールプレーンから独立して自動化の実行を維持すると、開発サイクルが短縮され、環境間のスケーラビリティー、信頼性、および移植性が向上します。Red Hat Ansible Automation Platform には、Ansible コンテンツツールへのアクセスも含まれているため、自動化実行環境の構築と管理が容易になります。
自動化実行環境には、速度、移植性、柔軟性に加え、以下の利点があります。
- これにより、自動化が複数のプラットフォームで一貫して実行し、システムレベルの依存関係とコレクションベースのコンテンツを組み込むことができます。
- これにより、Red Hat Ansible Automation Platform の管理者は、さまざまなチームのニーズを満たす自動化環境を提供し、管理することができるようになります。
- これにより、自動化環境を構築して配布する標準的な方法を提供することで、自動化を簡単に拡張およびチーム間で共有できます。
- これにより、自動化チームは自動化環境自体の定義、構築、および更新を行うことができます。
- 自動化実行環境は、自動化の依存関係を通信するための共通の言語を提供します。
第2章 Ansible Builder の使用
Ansible Builder は、さまざまな Ansible Collections で定義されたメタデータを使用するか、ユーザーが作成したメタデータを使用して自動化実行環境を構築するプロセスを自動化するコマンドラインツールです。
2.1. Ansible Builder を使用する理由
Ansible Builder が開発される前に、Red Hat Ansible Automation Platform ユーザーは、必要なすべての依存関係がインストールされているカスタムの仮想環境またはコンテナーの作成時に、依存関係の問題およびエラーを実行することができました。
Ansible Builder を使用して、自動化実行環境に追加するコンテンツ (コレクション、要件、システムレベルパッケージなど) を指定するカスタマイズ可能な自動化実行環境定義ファイルを簡単に作成できるようになりました。これにより、ジョブの実行に必要な要件と依存関係をすべて満たすことができます。
2.2. Ansible Builder のインストール
Red Hat Subscription Management (RHSM) を使用して Ansible Builder をインストールし、Red Hat Ansible Automation Platform サブスクリプションをアタッチできます。Red Hat Ansible Automation Platform サブスクリプションを割り当てる と、ansible-builder
のインストールに必要なサブスクリプションのみのリソースにアクセスできます。サブスクリプションをアタッチすると、ansible-builder
に必要なリポジトリーが自動的に有効になります。
ansible-builder
をインストールする前に、有効なサブスクリプションがホストにアタッチされている必要があります。
手順
ターミナルで次のコマンドを実行して、Ansible Builder をインストールし、Ansible Automation Platform リポジトリーをアクティベートします。
# dnf install --enablerepo ansible-automation-platform-2.2-for-rhel-8-x86_64-rpms ansible-builder
2.3. 定義ファイルの構築
Ansible Builder をインストールしたら、自動化実行環境イメージを作成するために Ansible Builder が使用する定義ファイルを作成できます。自動化実行環境イメージを構築する高レベルのプロセスは、Ansible Builder が定義ファイルを読み取って検証してから、Containerfile
を作成し、最後に Containerfile
を Podman に渡して、自動化実行環境イメージを作成します。作成される定義ファイルは yaml
形式であり、異なるセクションが含まれます。定義ファイルの内容の詳細は、定義ファイルの内容の内訳 を参照してください。
以下は定義ファイルの例です。
例2.1 定義ファイル
version: 1 build_arg_defaults: 1 ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "-v" dependencies: 2 galaxy: requirements.yml python: requirements.txt system: bindep.txt additional_build_steps: 3 prepend: | RUN whoami RUN cat /etc/os-release append: - RUN echo This is a post-install command! - RUN ls -la /etc
これらの定義ファイルパラメーターの詳細は、定義ファイルの内容の内訳 を参照してください。
2.4. ビルドの実行およびコマンドの作成
前提条件
- 定義ファイルを作成している
手順
自動化実行環境イメージをビルドするには、以下を実行します。
$ ansible-builder build
Ansible Builder は、デフォルトでは execution-environment.yml
という名前の定義ファイルを探しますが、-f
フラグを使用して異なるファイルパスを引数として指定できます。
$ ansible-builder build -f definition-file-name.yml
definition-file-name は、定義ファイルの名前を指定します。
2.5. 定義ファイルの内容の内訳
自動化実行環境コンテナーイメージに含まれるコンテンツを指定するため、Ansible Builder で自動化実行環境を構築するには、定義ファイルが必要です。
次のセクションでは、定義ファイルの内容を説明します。
2.5.1. ビルド引数およびベースイメージ
定義ファイルの build_arg_defaults
セクションは、キーが Ansible Builder への引数のデフォルト値を指定できるディクショナリーです。build_arg_defaults
で使用できる値の一覧は、以下の表を参照してください。
Value | 説明 |
---|---|
| コレクションのインストールフェーズで、ユーザーは ansible-galaxy CLI に任意の引数を渡すことができます。たとえば、プレリリースコレクションのインストールを有効にする –pre フラグや、サーバーの SSL 証明書の検証を無効にする -c などです。 |
| 自動化実行環境の親イメージを指定し、既存のイメージに基づいて新しいイメージを構築できるようにします。これは通常、ee-minimal や ee-supported などのサポートされる実行環境ベースイメージですが、以前に作成した実行環境イメージをカスタマイズすることもできます。
デフォルトのイメージは |
|
Python の依存関係コレクションとコンパイルに使用される中間ビルダーイメージを指定します。対応する Python バージョンと
デフォルトのイメージは |
build_arg_defaults
で指定される値は Containerfile
にハードコーディングされるため、podman build
を手動で呼び出すとこの値が維持されます。
CLI --build-arg
フラグで同じ変数が指定されている場合は、CLI 値の優先順位が高くなります。
2.5.2. Ansible 設定ファイルパス
ansible_config
ディレクティブを使用すると、ansible.cfg
ファイルへのパスを指定して、ビルドの Collection インストールステージで、プライベートアカウントのトークンおよびその他の設定を自動化ハブサーバーに渡すことができます。設定ファイルパスは定義ファイルの場所を基準にし、生成されたコンテナービルドコンテキストにコピーされます。
ansible.cfg
ファイルは以下の例のような形式にする必要があります。
例2.2 ansible.cfg
ファイル
[galaxy] server_list = automation_hub [galaxy_server.automation_hub] url=https://cloud.redhat.com/api/automation-hub/ auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token token=my_ah_token
自動化ハブからコレクションをダウンロードする方法は、関連する Ansible ドキュメントページ を参照してください。
2.5.3. 依存関係
自動化実行環境イメージの問題を回避するには、Galaxy、Python、およびシステムのエントリーが有効な要件ファイルを参照していることを確認してください。
2.5.3.1. Galaxy
galaxy
エントリーは、ansible-galaxy collection install -r …
コマンドの有効な要件ファイルを参照します。
requirements.yml
エントリーは、自動化実行環境定義のディレクトリーからの相対パス、または絶対パスである可能性があります。
requirements.yml
ファイルの内容は以下のようになります。
例2.3 Galaxy の requirements.yml
ファイル
collections: - community.aws - kubernetes.core
2.5.3.2. Python
定義ファイルの python
エントリーは、pip install -r …
コマンドの有効な要件ファイルを参照します。
requirements.txt
エントリーは、Collection がすでに Python の依存関係としてリストされているように追加の Python 要件をインストールするファイルです。自動化実行環境定義のフォルダーのディレクトリーからの相対パス、または絶対パスとして記載されている可能性があります。requirements.txt
ファイルの内容は、pip freeze
コマンドの標準出力と同様に、以下の例のような形式にする必要があります。
例2.4 Python の requirements.txt
ファイル
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 python_version >= '2.7' collection community.vmware google-auth openshift>=0.6.2 requests-oauthlib openstacksdk>=0.13 ovirt-engine-sdk-python>=4.4.10
2.5.3.3. システム
定義の システム
エントリーは、bindep 要件ファイルを指定しています。このファイルは、コレクションに依存関係として含まれていないシステムレベルの依存関係をインストールします。自動化実行環境定義のフォルダーのディレクトリーからの相対パス、または絶対パスとして記載されている可能性があります。最低限、コレクションが、[platform:rpm]
に必要な要件を指定することが想定されます。
これは、libxml2
パッケージおよび subversion
パッケージをコンテナーに追加する bindep.txt
ファイルの例です。
例2.5 bindep.txt
ファイル
libxml2-devel [platform:rpm] subversion [platform:rpm]
複数のコレクションからのエントリーは、1 つのファイルに統合されます。これは bindep
により処理され、dnf
に渡されます。プロファイルのない要件や、ランタイム要件がイメージにインストールされません。
2.5.4. 追加のカスタムビルドの手順
prepend
コマンドと append
コマンドは、additional_build_steps
セクションで指定できます。これにより、メインのビルド手順が実行される前または後に実行する Containerfile
にコマンドが追加されます。
additional_build_steps
の構文は以下のいずれかである必要があります。
複数行の文字列
例2.6 複数行の文字列エントリー
prepend: | RUN whoami RUN cat /etc/os-release
リスト
例2.7 リストエントリー
append: - RUN echo This is a post-install command! - RUN ls -la /etc
2.6. 任意のビルドコマンド引数
-t
フラグは、自動化実行環境イメージに特定の名前でタグ付けします。たとえば、以下のコマンドは my_first_ee_image
という名前のイメージを構築します。
$ ansible-builder build -t my_first_ee_image
build
で -t
を使用しない場合は、ansible-execution-env`
というイメージが作成され、ローカルのコンテナーレジストリーに読み込まれます。
複数の定義ファイルがある場合は、-f
フラグで、使用する定義ファイルを指定できます。
$ ansible-builder build -f another-definition-file.yml -t another_ee_image
上記の例 では、Ansible Builder が、デフォルトの execution-environment.yml
の代わりに another-definition-file.yml
ファイルで提供される仕様を使用して、another_ee_image
という名前の自動実行環境イメージを構築します。
build コマンドで使用できるその他の仕様とフラグについては、ansible-builder build --help
と入力して、追加オプションのリストを表示してください。
2.7. Containerfile
定義ファイルが作成されると、Ansible Builder はこのファイルを読み取り、検証し、Containerfile
を作成し、最後に Containerfile
を Podman に渡してパッケージ化し、以下の手順を使用して自動化実行環境イメージを作成します。
- ベースイメージの取得
- ベースイメージの一時コピーでは、コレクションがダウンロードされ、宣言された Python およびシステム依存関係の一覧 (存在する場合) が後に収集されます。
- エフェメラルビルダーイメージでは、定義ファイルに記載されているすべての Python 依存関係の Python ホイールがダウンロードされ、(必要に応じて) ビルドされます。これには、定義ファイルに記載されているコレクションによって宣言されたすべての Python 依存関係が含まれます。
-
定義ファイルの additional_build_steps に対して
prepend
が実行します。 - 最終的な自動化実行環境イメージでは、定義ファイルに記載されているシステム依存関係がインストールされ、定義ファイルに記載されているコレクションが宣言したすべてのシステム依存関係が含まれます。
- 最終的な自動化実行環境イメージでは、ダウンロードしたコレクションがコピーされ、以前にフェッチされた Python 依存関係がインストールされます。
-
定義ファイルの additional_build_steps に対して
append
が実行します。
2.8. イメージの構築なしで Containerfile の作成
イメージをビルドせずに共有可能な Containerfile
を作成するには、以下を実行します。
$ ansible-builder create
第3章 自動化実行環境の公開
3.1. 既存の自動化実行環境イメージのカスタマイズ
Ansible コントローラーには、以下の 3 つのデフォルト実行環境が同梱されています。
-
Ansible 2.9
- Controller モジュール以外のコレクションがインストールされない -
Minimal
- Ansible Runner とともに最新の Ansible 2.13 リリースが含まれるが、コレクションや他の追加コンテンツは含まれない -
EE Supported
- 最小限のもの、および Red Hat がサポートするすべてのコレクションと依存関係
これらの環境は多くの自動化ユースケースに対応しますが、追加の項目を追加して、特定のニーズに合わせてこれらのコンテナーをカスタマイズできます。以下の手順では、kubernetes.core
コレクションを ee-minimal
デフォルトイメージに追加します。
手順
Podman を使用して
registry.redhat.io
にログインします。$ podman login -u="[username]" -p="[token/hash]" registry.redhat.io
必要な自動化実行環境のベースイメージをプルできることを確認します。
podman pull registry.redhat.io/ansible-automation-platform-22/ee-minimal-rhel8:latest
必要なベースイメージと新しい実行環境イメージに追加する追加のコンテンツを指定するように Ansible Builder ファイルを設定します。
たとえば、Kubernetes Core Collection を Galaxy から イメージに追加するには、以下のように
requirements.yml
ファイルを入力します。collections: - kubernetes.core
- 定義ファイルとそのコンテンツの詳細は、定義ファイルの内訳 セクションを参照してください。
実行環境定義ファイルで、
EE_BASE_IMAGE
フィールドに元のee-minimal
コンテナーの URL とタグを指定します。その場合、最終的なexecution-environment.yml
ファイルは以下のようになります。例3.1 カスタマイズされた
execution-environment.yml
ファイルversion: 1 build_arg_defaults: EE_BASE_IMAGE: 'registry.redhat.io/ansible-automation-platform-22/ee-minimal-rhel8:latest' dependencies: galaxy: requirements.yml
注記この例では、自動化ハブの認定コレクションではなく、コミュニティーバージョンの
kubernetes.core
を使用するため、ansible.cfg
ファイルを作成したり、定義ファイルで参照したりする必要はありません。以下のコマンドを使用して、新しい実行環境イメージを構築します。
$ ansible-builder build -t registry.redhat.io/[username]/new-ee
ここで、
[username]
はユーザー名を指定し、new-ee
は新しいコンテナーイメージの名前を指定します。
build
で -t
を使用しない場合は、ansible-execution-env
というイメージが作成され、ローカルのコンテナーレジストリーに読み込まれます。
podman images
コマンドを使用して、新しいコンテナーイメージが一覧に表示されていることを確認します。例3.2
new-ee
イメージを使用したpodman images
コマンドの出力REPOSITORY TAG IMAGE ID CREATED SIZE localhost/new-ee latest f5509587efbb 3 minutes ago 769 MB
コレクションがインストールされていることを確認します。
$ podman run registry.redhat.io/[username]/new-ee ansible-doc -l kubernetes.core
Automation Hub で使用するイメージにタグを付けます。
$ podman tag registry.redhat.io/[username]/new-ee [automation-hub-IP-address]/[username]/new-ee
Podman を使用して Automation Hub にログインします。
注記コンテナーをプッシュするには、Automation Hub の
admin
または適切なコンテナーリポジトリーのアクセス許可が必要です。詳細は、Red Hat Ansible Automation Platform ドキュメント の プライベート Automation Hub でのコンテナーの管理 を参照してください。$ podman login -u="[username]" -p="[token/hash]" [automation-hub-IP-address]
イメージを自動化ハブのコンテナーレジストリーにプッシュします。
$ podman push [automation-hub-IP-address]/[username]/new-ee
- 新しいイメージを自動化コントローラーインスタンスにプルします。
- Automation Controller に移動します。
- ナビゲーションバーから、Administration → Execution Environments の順にクリックします。
- Add をクリックします。
適切な情報を入力して Save をクリックし、新規イメージにプルします。
注記自動化ハブのインスタンスがパスワードまたはトークンで保護されている場合は、適切なコンテナーレジストリーの認証情報が設定されていることを確認してください。
第4章 プライベート自動化ハブコンテナーレジストリーへの入力
デフォルトでは、プライベート自動化ハブにはコンテナーイメージが含まれません。コンテナーレジストリーを設定するには、コンテナーイメージレジストリーにコンテナーイメージをプッシュする必要があります。本セクションの手順では、Red Hat Ecosystem Catalog (registry.redhat.io) からイメージをプルし、それらをタグ付けして、プライベート自動化コンテナーレジストリーにプッシュする方法を説明します。
4.1. 前提条件
- 新しいコンテナーを作成して、プライベート自動化ハブにプッシュするパーミッションがある。
4.2. 自動化ハブで使用するイメージの取得
コンテナーイメージをプライベート自動化ハブにプッシュする前に、まず既存のレジストリーからプルし、使用できるようにタグを付ける必要があります。以下の例では、Red Hat Ecosystem Catalog (registry.redhat.io) からイメージをプルする方法を説明します。
前提条件
registry.redhat.io からイメージをプルするパーミッションがある。
手順
registry.redhat.io 認証情報を使用して Podman にログインします。
$ podman login registry.redhat.io
- プロンプトにユーザー名およびパスワードを入力します。
コンテナーイメージをプルします。
$ podman pull registry.redhat.io/<container_image_name>:<tag>
検証
ローカルストレージ内のイメージを一覧表示します。
$ podman images
- 最近プルしたイメージが一覧に含まれていることを確認します。
- タグが正しいことを確認します。
関連情報
- イメージの登録および取得についての詳細は、Red Hat Ecosystem Catalog Help を参照してください。
4.3. 自動化ハブで使用するイメージのタグ付け
レジストリーからイメージをプルしたら、プライベート自動化ハブコンテナーレジストリーで使用するようにタグを付けます。
前提条件
- 外部レジストリーからコンテナーイメージをプルしている。
- 自動化ハブインスタンスの FQDN または IP アドレスがある。
手順
自動化ハブコンテナーリポジトリーを使用してローカルイメージにタグを付けます。
$ podman tag registry.redhat.io/<container_image_name>:<tag> <automation_hub_URL>/<container_image_name>
検証
ローカルストレージ内のイメージを一覧表示します。
$ podman images
- 自動化ハブの情報で最近タグ付けされたイメージが一覧に含まれていることを確認します。
4.4. プライベート自動化ハブへのコンテナーイメージのプッシュ
タグ付けされたコンテナーイメージをプライベート自動化ハブにプッシュして新規コンテナーを作成し、コンテナーレジストリーにデータを入力できます。
前提条件
- 新規コンテナーを作成するパーミッションがある。
- 自動化ハブインスタンスの FQDN または IP アドレスがある。
手順
自動化ハブの場所および認証情報を使用して Podman にログインします。
$ podman login -u=<username> -p=<password> <automation_hub_url>
コンテナーイメージを自動化ハブのコンテナーレジストリーにプッシュします。
$ podman push <automation_hub_url>/<container_image_name>
注記registry.redhat.io からの署名付きイメージが自動化ハブコンテナーレジストリーにプッシュされる場合は、
--remove-signatures
フラグが必要です。push
操作は、アップロード中にイメージレイヤーを再圧縮します。これは、再現性が保証されておらず、クライアントの実装に依存します。これにより、イメージレイヤーダイジェストが変更され、プッシュ操作が失敗し、Error: Copying this image requires changing layer representation, which is not possible (image is signed or the destination specifies a digest)
エラーが発生します。
検証
- ローカルの自動化ハブにログインします。
- Container Registry に移動します。
- コンテナーリポジトリー一覧でコンテナーを見つけます。
第5章 コンテナーリポジトリーの設定
コンテナーリポジトリーを設定して説明の追加、README の追加、リポジトリーにアクセスできるグループの追加、およびタグイメージの追加を行うことができます。
5.1. 前提条件
- リポジトリーを変更するパーミッションを持つプライベート Automation Hub にログインしている。
5.2. コンテナーリポジトリーへの README の追加
コンテナーリポジトリーに README を追加して、コンテナーを操作する方法をユーザーに提供します。自動化ハブコンテナーリポジトリーは、README を作成するためのマークダウンをサポートします。デフォルトでは、README は空になります。
前提条件
- コンテナーを変更するパーミッションがある。
手順
- Execution Environments に移動します。
- コンテナーリポジトリーを選択します。
- Detail タブで、Add をクリックします。
- Raw Markdown テキストフィールドに、Markdown で README テキストを入力します。
- 終了したら Save をクリックします。
README を追加したら、Edit をクリックし、ステップ 4 および 5 を繰り返すことで、いつでも編集できます。
5.3. コンテナーリポジトリーへのアクセスの提供
イメージを使用する必要のあるユーザーにコンテナーリポジトリーへのアクセスを提供します。グループを追加すると、グループがコンテナーリポジトリーに対して持つことができるパーミッションを変更できます。このオプションを使用して、グループが割り当てられている内容に応じてパーミッションを拡張または制限できます。
前提条件
- コンテナーの名前空間のパーミッションを変更している。
手順
- Execution Environments に移動します。
- コンテナーリポジトリーを選択します。
- ウィンドウの右上にある Edit をクリックします。
Groups with access で、アクセス権を付与するグループ (単数または複数) を選択します。
- (必要に応じて) グループ名でドロップダウンを使用して、特定のグループのパーミッションを追加または削除します。
- Save をクリックします。
5.4. コンテナーイメージのタグ付け
自動化ハブコンテナーリポジトリーに保存されているイメージにタグを付けて、名前を追加します。イメージにタグが追加されない場合、自動化ハブの名前はデフォルトで latest
に設定されます。
前提条件
- change image tags のパーミッションがある。
手順
- Execution Environments に移動します。
- コンテナーリポジトリーを選択します。
- Images タブをクリックします。
-
をクリックし、Manage tags をクリックします。
テキストフィールドに新しいタグを追加し、Add をクリックします。
- (必要に応じて) そのイメージのいずれのタグの x をクリックして、current tags を削除します。
- Save をクリックします。
検証
- Activity タブをクリックし、最新の変更を確認します。
第6章 コンテナーリポジトリーからのイメージのプル
自動化ハブコンテナーレジストリーからイメージを取得し、ローカルマシンにコピーを作成します。自動化ハブは、コンテナーリポジトリーの latest
イメージごとに、podman pull
コマンドを提供します。このコマンドを端末にコピーアンドペーストするか、podman pull
を使用してイメージタグに基づいてイメージをコピーすることができます。
6.1. 前提条件
- プライベートコンテナーリポジトリーを表示し、プルするパーミッションがある。
6.2. イメージのプル
自動化ハブコンテナーレジストリーからイメージをプルして、ローカルマシンにコピーできます。自動化ハブは、コンテナーリポジトリーの latest
イメージごとに、podman pull
コマンドを提供します。
手順
- Execution Environments に移動します。
- コンテナーリポジトリーを選択します。
- Pull this image エントリーで、Copy to clipboard をクリックします。
- 端末でコマンドを貼り付けます。
検証
-
podman images
を実行して、ローカルマシンにイメージを表示します。
6.3. 関連情報
- イメージをプルする際に使用するオプションについては、Podman ドキュメント を参照してください。
付録A 自動化実行環境の優先順位
プロジェクト更新は常にコントロールプレーンの自動化実行環境を使用しますが、ジョブは以下のように最初に利用可能な自動化実行環境を使用します。
-
ジョブを作成したテンプレート (ジョブテンプレートまたはインベントリーソース) で定義される
execution_environment
。 -
ジョブが使用するプロジェクトで定義される
default_environment
。 -
ジョブの組織で定義される
default_environment
。 -
ジョブが使用するインベントリーの組織で定義される
default_environment
。 -
現在の
DEFAULT_EXECUTION_ENVIRONMENT
設定 (api/v2/settings/jobs/
で設定可能)。 -
GLOBAL_JOB_EXECUTION_ENVIRONMENTS
設定からのイメージ。 - その他のグローバル実行環境。
複数の実行環境が基準 (6 および 7 に適用) に適合する場合は、最近作成された実行環境が使用されます。