実行環境の作成および消費
Ansible Builder で実行環境を作成および使用する
概要
はじめに
Ansible Builder を使用して、Red Hat Ansible Automation Platform のニーズに合わせて一貫性のある再現可能な自動化実行環境を作成します。
Red Hat ドキュメントへのフィードバック (英語のみ)
このドキュメントの改善に関するご意見がある場合や、エラーを発見した場合は、https://access.redhat.com から Technical Support チームに連絡してください。
第1章 自動化実行環境の概要
各ノードにパッケージをインストールして、ホストシステムにインストールされている他のソフトウェアと対話し、同期を維持する必要があるため、デフォルト以外の依存関係に依存する Ansible コンテンツを使用することは複雑になる可能性があります。
自動化実行環境は、このプロセスを単純化し、Ansible Builder で簡単に作成できます。
1.1. 自動化実行環境について
Red Hat Ansible Automation Platform のすべての自動化は、自動化実行環境と呼ばれるコンテナーイメージ上で実行されます。自動化実行環境は、自動化の依存関係を通信するための共通の言語を作成し、自動化環境を構築して配布するための標準的な方法を提供します。
自動化実行環境には、以下が含まれている必要があります。
- Ansible Core 2.15 以降
- Python 3.8-3.11
- Ansible Runner
- Ansible コンテンツコレクションとその依存関係
- システムの依存関係
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 を使用すると、Ansible Core、Python、Collection、サードパーティーの Python 要件、システムレベルのパッケージなどの自動化実行環境に含むコンテンツを指定する、カスタマイズ可能な自動化実行環境定義ファイルを簡単に作成できるようになりました。これにより、ジョブの実行に必要な要件と依存関係をすべて満たすことができます。
2.2. Ansible Builder のインストール
前提条件
- Podman コンテナーランタイムがインストールされている。
-
ホストに有効なサブスクリプションがアタッチされている。これにより、
ansible-builder
のインストールに必要なサブスクリプションのみのリソースにアクセスでき、ansible-builder
に必要なリポジトリーが自動的に有効化されるようになります。詳細は、Red Hat Ansible Automation Platform サブスクリプションのアタッチ を参照してください。
手順
ターミナルで次のコマンドを実行して、Ansible Automation Platform リポジトリーをアクティブ化します。
# dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms ansible-builder
2.3. 定義ファイルの構築
Ansible Builder をインストールした後、Ansible Builder が自動化実行環境イメージを作成するために使用する定義ファイルを作成できます。Ansible Builder は、定義ファイルを読み取って検証してから Containerfile
を作成し、最後にその Containerfile
を Podman に渡して自動化実行環境イメージを作成します。続いて Podman は、自動化実行環境イメージをパッケージ化して作成します。作成する定義ファイルは yaml
形式であり、さまざまなセクションが含まれている必要があります。指定されていない場合のデフォルトの定義ファイル名は、execution-environment.yml
です。定義ファイルの各部分の詳細は、定義ファイルの内容の内訳 を参照してください。
以下はバージョン 3 の定義ファイルの例です。各定義ファイルでは、使用する Ansible Builder 機能セットのメジャーバージョン番号を指定する必要があります。指定しない場合、Ansible Builder はデフォルトでバージョン 1 になり、ほとんどの新機能と定義キーワードが使用できなくなります。
例2.1 定義ファイルの例
version: 3 build_arg_defaults: 1 ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: '--pre' dependencies: 2 galaxy: requirements.yml python: - six - psutil system: bindep.txt images: 3 base_image: name: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel9:latest # Custom package manager path for the RHEL based images options: 4 package_manager_path: /usr/bin/microdnf additional_build_steps: 5 prepend_base: - RUN echo This is a prepend base command! prepend_galaxy: # Environment variables used for Galaxy client configurations - ENV ANSIBLE_GALAXY_SERVER_LIST=automation_hub - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_URL=https://console.redhat.com/api/automation-hub/content/xxxxxxx-synclist/ - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_AUTH_URL=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token # define a custom build arg env passthru - we still also have to pass # `--build-arg ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN` to get it to pick it up from the env - ARG ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN prepend_final: | RUN whoami RUN cat /etc/os-release append_final: - RUN echo This is a post-install command! - RUN ls -la /etc
関連情報
- 定義ファイルの内容の詳細は、定義ファイルの内容の内訳 を参照してください。
- Ansible Builder バージョン 2 と 3 の違いの詳細は、Ansible 3 Porting Guide を参照してください。
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
で使用できる値の一覧は、以下の表を参照してください。
値 | 説明 |
---|---|
| コレクションのインストールフェーズで、ユーザーは 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 セクションを参照してください。
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
とコンテナービルドコンテキストを作成し、オプションでこれらを Podman に渡して自動化実行環境イメージをビルドします。コンテナーのビルドは、base
、galaxy
、builder
、および final
といういくつかの異なるステージで行われます。イメージのビルド手順 (および、additional_build_steps
で定義された対応するカスタムの prepend_
および append_
手順) は次のとおりです。
-
base
ビルドステージでは、指定されたベースイメージが、Python、pip
、ansible-core
、ansible-runner
など、他のビルドステージで必要なコンポーネントを使用して (オプションで) カスタマイズされます。次に、生成されたイメージが検証され、必要なコンポーネントが利用可能であることが確認されます (コンポーネントはベースイメージにすでに存在している可能性があるため)。結果として得られるカスタマイズされたbase
イメージの一時的なコピーは、他のすべてのビルドステージのベースとして使用されます。 -
galaxy
ビルドステージでは、定義ファイルで指定されたコレクションがダウンロードされ、final
ビルドステージでのインストールのために保存されます。コレクションによって宣言された Python とシステムの依存関係も (存在する場合)、今後の分析のために収集されます。 -
builder
ビルドステージでは、コレクションによって宣言された Python の依存関係が、定義ファイルにリストされている依存関係とマージされます。この最後の Python 依存関係セットは、Python ホイールとしてダウンロードおよびビルドされ、final
ビルドステージでのインストールのために保存されます。 -
final
ビルドステージでは、以前にダウンロードしたコレクションが、システムパッケージおよびコレクションによって依存関係として宣言された、または定義ファイルにリストされていた、以前にビルドされた Python パッケージとともにインストールされます。
2.8. イメージをビルドせずに Containerfile を作成する
セキュリティー上の理由から、サンドボックス環境でビルドした共有コンテナーイメージを使用する必要がある場合は、共有可能な Containerfile
を作成できます。
$ ansible-builder create
第3章 一般的な自動化実行環境のシナリオ
一般的な設定シナリオに対応するには、次の定義ファイルの例を使用します。
3.1. Automation Hub CA 証明書の更新
この例を使用して、デフォルトの定義ファイルをカスタマイズして CA 証明書を additional-build-files
セクションに含め、そのファイルを適切なディレクトリーに移動します。最後にコマンドを実行して CA 証明書の動的設定を更新し、システムがこの CA 証明書を信頼できるようにします。
前提条件
-
カスタム CA 証明書 (例:
rootCA.crt
)。
prepend_base
を使用して CA 証明書をカスタマイズすると、その結果作成される CA 設定が、他のすべてのビルドステージと最終イメージに表示されます。他のすべてのビルドステージは、ベースイメージから継承されるためです。
additional_build_files: # copy the CA public key into the build context, we will copy and use it in the base image later - src: files/rootCA.crt dest: configs additional_build_steps: prepend_base: # copy a custom CA cert into the base image and recompute the trust database # because this is in "base", all stages will inherit (including the final EE) - COPY _build/configs/rootCA.crt /usr/share/pki/ca-trust-source/anchors - RUN update-ca-trust options: package_manager_path: /usr/bin/microdnf # downstream images use non-standard package manager [galaxy] server_list = automation_hub
3.2. 自動化実行環境を構築する際に Automation Hub 認証の詳細を使用する
以下の例を使用して、デフォルトの定義ファイルをカスタマイズし、Automation Hub 認証の詳細を、最終的な自動化実行環境イメージで公開することなく、自動化実行環境ビルドに渡します。
前提条件
-
Automation Hub API トークンを作成 し、セキュアな場所 (たとえば
token.txt
という名前のファイル) に保存している。 - Automation Hub API トークンが入力されるビルド引数を定義している。
export ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN=$(cat <token.txt>)
additional_build_steps: prepend_galaxy: # define a custom build arg env passthru- we still also have to pass # `--build-arg ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN` to get it to pick it up from the host env - ARG ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN - ENV ANSIBLE_GALAXY_SERVER_LIST=automation_hub - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_URL=https://console.redhat.com/api/automation-hub/content/<yourhuburl>-synclist/ - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_AUTH_URL=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
3.3. 関連情報
- 自動化実行環境の定義ファイルの各部分については、定義ファイルの内容の内訳 を参照してください。
- その他の一般的なシナリオ用の定義ファイルの例は、Ansible Builder Documentation の 一般的なシナリオのセクション を参照してください。
第4章 自動化実行環境の公開
4.1. 既存の自動化実行環境イメージのカスタマイズ
Ansible Controller には、以下のデフォルトの実行環境が含まれます。
-
最小限
- 最新の Ansible-core 2.15 リリースと Ansible Runner が含まれますが、コレクションやその他のコンテンツは含まれません。 -
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-24/ee-minimal-rhel8:latest
必要なベースイメージと新しい実行環境イメージに追加する追加のコンテンツを指定するように Ansible Builder ファイルを設定します。
たとえば、Galaxy の Kubernetes Core Collection をイメージに追加するには、Galaxy エントリーを使用します。
collections: - kubernetes.core
- 定義ファイルとその内容の詳細は、定義ファイルの内訳 セクションを参照してください。
実行環境定義ファイルで、
EE_BASE_IMAGE
フィールドに元のee-minimal
コンテナーの URL とタグを指定します。その場合、最終的なexecution-environment.yml
ファイルは以下のようになります。例4.1 カスタマイズされた
execution-environment.yml
ファイルversion: 3 images: base_image: 'registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel9:latest' dependencies: galaxy: collections: - kubernetes.core
注記この例では、自動化ハブの認定コレクションではなく、コミュニティーバージョンの
kubernetes.core
を使用するため、ansible.cfg
ファイルを作成したり、定義ファイルで参照したりする必要はありません。以下のコマンドを使用して、新しい実行環境イメージをビルドします。
$ ansible-builder build -t [username]/new-ee
ここで、
[username]
はユーザー名を指定し、new-ee
は新しいコンテナーイメージの名前を指定します。注記build
で-t
を使用しない場合は、ansible-execution-env
というイメージが作成され、ローカルのコンテナーレジストリーに読み込まれます。podman images
コマンドを使用して、新しいコンテナーイメージが一覧に表示されていることを確認します。例4.2
new-ee
イメージを使用したpodman images
コマンドの出力REPOSITORY TAG IMAGE ID CREATED SIZE localhost/new-ee latest f5509587efbb 3 minutes ago 769 MB
コレクションがインストールされていることを確認します。
$ podman run [username]/new-ee ansible-doc -l kubernetes.core
Automation Hub で使用するイメージにタグを付けます。
$ podman tag [username]/new-ee [automation-hub-IP-address]/[username]/new-ee
Podman を使用して Automation Hub にログインします。
注記コンテナーをプッシュするには、Automation Hub の
admin
または適切なコンテナーリポジトリーのアクセス許可が必要です。詳細は、Automation Hub でのコンテンツの管理 の Private Automation Hub でのコンテナーの管理 セクションを参照してください。$ podman login -u="[username]" -p="[token/hash]" [automation-hub-IP-address]
イメージを自動化ハブのコンテナーレジストリーにプッシュします。
$ podman push [automation-hub-IP-address]/[username]/new-ee
新しいイメージを自動化コントローラーインスタンスにプルします。
- Automation Controller に移動します。
- ナビゲーションパネルから、 → を選択します。
- をクリックします。
適切な情報を入力して
をクリックし、新規イメージにプルします。注記自動化ハブのインスタンスがパスワードまたはトークンで保護されている場合は、適切なコンテナーレジストリーの認証情報が設定されていることを確認してください。
4.2. 関連情報 (または次の手順)
一般的なシナリオに基づいて実行環境をカスタマイズする方法の詳細は、Ansible Builder ドキュメント の次のトピックを参照してください。
第5章 Private Automation Hub コンテナーレジストリーへの入力
デフォルトでは、Private Automation Hub にはコンテナーイメージが含まれていません。コンテナーレジストリーを設定するには、コンテナーイメージレジストリーにコンテナーイメージをプッシュする必要があります。
Private Automation Hub コンテナーレジストリーを設定するには、特定のワークフローに従う必要があります。
- Red Hat Ecosystem Catalog (registry.redhat.io) からイメージをプルします。
- イメージにタグを付けます。
- Private Automation Hub コンテナーレジストリーにプッシュします。
2025 年 4 月 1 日 の時点で、quay.io
は 3 つのエンドポイントを別に追加しています。そのため、お客様はファイアウォールシステムリスト内の許可リストとブロックリストを調整して、次のエンドポイントを含める必要があります。
-
cdn04.quay.io
-
cdn05.quay.io
-
cdn06.quay.io
コンテナーイメージのプルに関する問題を回避するには、次のホスト名への送信 TCP 接続 (ポート 80 および 443) を許可する必要があります。
-
cdn.quay.io
-
cdn01.quay.io
-
cdn02.quay.io
-
cdn03.quay.io
-
cdn04.quay.io
-
cdn05.quay.io
-
cdn06.quay.io
registry.redhat.io
または registry.access.redhat.com
への送信接続を特に有効にするすべてのファイアウォール設定にこの変更を加えます。
ファイアウォールルールを設定するときは、IP アドレスの代わりにホスト名を使用します。
この変更を加えた後も、引き続き registry.redhat.io
または registry.access.redhat.com
からイメージをプルできます。Red Hat コンテナーイメージのプルを続行するために、quay.io
にログインする必要も、quay.io
レジストリーと直接やりとりする必要もありません。
詳細は、Firewall changes for container image pulls 2024/2025 を参照してください。
Table 6.4 に記載されている ネットワークポートとプロトコル を確認します。実行環境 (EE)) を確認してください。コンテナーイメージをプルする際の問題を回避するのに役立ちます。
5.1. Automation Hub で使用するイメージのプル
コンテナーイメージを Private Automation Hub にプッシュする前に、まず既存のレジストリーからプルし、使用できるようにタグを付ける必要があります。次の例では、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 を参照してください。
5.2. Automation Hub で使用するイメージのタグ付け
レジストリーからイメージをプルしたら、Private Automation Hub コンテナーレジストリーで使用するようにタグを付けます。
前提条件
- 外部レジストリーからコンテナーイメージをプルしている。
- Automation Hub インスタンスの FQDN または IP アドレスがある。
手順
Automation Hub コンテナーリポジトリーを使用してローカルイメージにタグを付けます。
$ podman tag registry.redhat.io/<container_image_name>:<tag> <automation_hub_hostname>/<container_image_name>
検証
ローカルストレージ内のイメージをリスト表示します。
$ podman images
- Automation Hub の情報で最近タグ付けされたイメージが一覧に含まれていることを確認します。
5.3. Private Automation Hub へのコンテナーイメージのプッシュ
タグ付けされたコンテナーイメージを Private Automation Hub にプッシュして、新しいコンテナーを作成し、コンテナーレジストリーに追加できます。
前提条件
- 新規コンテナーを作成する権限がある。
- Automation Hub インスタンスの FQDN または IP アドレスがある。
手順
Automation Hub の場所および認証情報を使用して Podman にログインします。
$ podman login -u=<username> -p=<password> <automation_hub_url>
コンテナーイメージを Automation Hub のコンテナーレジストリーにプッシュします。
$ podman push <automation_hub_url>/<container_image_name>
トラブルシューティング
push
操作は、アップロード中にイメージレイヤーを再圧縮します。この操作は、再現性が保証されておらず、クライアントの実装に依存します。これにより、イメージレイヤーダイジェストが変更され、プッシュ操作が失敗し、Error: Copying this image requires changing layer representation, which is not possible (image is signed or the destination specifies a digest)
エラーが発生します。
検証
- Automation Hub にログインします。
- に移動します。
- コンテナーリポジトリーリストでコンテナーを見つけます。
第6章 コンテナーリポジトリーの設定
コンテナーリポジトリーを設定する際には、説明の追加、README の追加、リポジトリーにアクセスできるグループの追加、およびイメージのタグ付けを行う必要があります。
6.1. コンテナーレジストリーを設定するための前提条件
- Private Automation Hub にログインしている。
- リポジトリーを変更する権限が必要です。
6.2. コンテナーリポジトリーへの README の追加
コンテナーリポジトリーに README を追加して、コンテナーを操作する方法をユーザーに提供します。Automation Hub コンテナーリポジトリーは、README を作成するためのマークダウンをサポートします。デフォルトでは、README は空です。
前提条件
- コンテナーを変更する権限がある。
手順
- Automation Hub にログインします。
- ナビゲーションパネルから、 → を選択します。
- コンテナーリポジトリーを選択します。
- Detail タブで、 をクリックします。
- Raw Markdown テキストフィールドに、Markdown で README テキストを入力します。
- 完了したら、 をクリックします。
README を追加したら、
をクリックし、ステップ 4 および 5 を繰り返すことで、いつでも編集できます。6.3. コンテナーリポジトリーへのアクセスの提供
イメージを操作する必要があるユーザーにコンテナーリポジトリーへのアクセスを提供します。グループを追加すると、グループがコンテナーリポジトリーに対して持つことができる権限を変更できます。このオプションを使用して、グループが割り当てられている内容に応じて権限を拡張または制限できます。
前提条件
- コンテナーの名前空間の権限を変更している。
手順
- Automation Hub にログインします。
- ナビゲーションパネルから、 → を選択します。
- コンテナーリポジトリーを選択します。
- Access タブで、 をクリックします。
- アクセスを許可するグループを選択し、 をクリックします。
- この実行環境に追加するロールを選択し、 をクリックします。
- をクリックします。
6.4. コンテナーイメージのタグ付け
Automation Hub コンテナーリポジトリーに保存されているイメージにタグを付けて、名前を追加します。イメージにタグが追加されない場合、Automation Hub の名前はデフォルトで latest
に設定されます。
前提条件
- change image tags の権限がある。
手順
- ナビゲーションパネルから、 → を選択します。
- コンテナーリポジトリーを選択します。
- Images タブをクリックします。
- ⋮ をクリックし、 をクリックします。 アイコン
- テキストフィールドに新しいタグを追加し、 をクリックします。
- (必要に応じて) そのイメージのいずれのタグの current tags を削除します。 をクリックして、
- をクリックします。
検証
- Activity タブをクリックし、最新の変更を確認します。
6.5. Automation Controller での認証情報の作成
パスワードまたはトークンで保護されたレジストリーからコンテナーイメージをプルするには、Automation Controller で認証情報を作成する必要があります。
Ansible Automation Platform の以前のバージョンでは、実行環境イメージを格納するためにレジストリーをデプロイする必要がありました。Ansible Automation Platform 2.0 以降のシステムは、コンテナーレジストリーがすでに稼働していると想定して動作します。実行環境イメージを格納するには、選択したコンテナーレジストリーについてのみ認証情報を追加します。
手順
- Automation Controller に移動します。
- ナビゲーションパネルから → を選択します。
- をクリックして、新規の認証情報を作成します。
- 承認用の 名前、説明、および 組織 を入力します。
- 認証情報のタイプ を選択します。
- 認証用 URL を入力します。これはコンテナーレジストリーのアドレスです。
- コンテナーレジストリーへのログインに必要な ユーザー名 と パスワードまたはトークン を入力します。
- オプション: SSL 検証を有効にするには、Verify SSL を選択します。
- をクリックします。
第7章 コンテナーリポジトリーからのイメージのプル
Automation Hub コンテナーレジストリーからイメージを取得し、ローカルマシンにコピーを作成します。Automation Hub は、コンテナーリポジトリーの latest
イメージごとに、podman pull
コマンドを提供します。このコマンドを端末にコピーアンドペーストするか、podman pull
を使用してイメージタグに基づいてイメージをコピーすることができます。
7.1. イメージのプル
Automation Hub コンテナーレジストリーからイメージをプルして、ローカルマシンにコピーできます。
前提条件
- プライベートコンテナーリポジトリーを表示およびプルする権限がある。
手順
- パスワードまたはトークンで保護されたレジストリーからコンテナーイメージをプルする必要がある場合は、イメージをプルする前に Automation Controller で認証情報を作成 する必要があります。
- ナビゲーションパネルから、 → を選択します。
- コンテナーリポジトリーを選択します。
- Pull this image エントリーで、 をクリックします。
- 端末でコマンドを貼り付けます。
検証
-
podman images
を実行して、ローカルマシンにイメージを表示します。
7.2. コンテナーリポジトリーからのイメージの同期
Automation Hub コンテナーレジストリーからイメージをプルして、イメージをローカルマシンに同期できます。リモートコンテナーレジストリーからイメージを同期するには、まずリモートレジストリーを設定する必要があります。
前提条件
プライベートコンテナーリポジトリーを表示およびプルする権限がある。
手順
- ナビゲーションパネルから、 → を選択します。
- https://registry.redhat.io をレジストリーに追加します。
認証に必要な認証情報を追加します。
注記コンテナーレジストリーの中には、流量制御を積極的に行っているものもあります。Advanced Options で流量制御を設定します。
- ナビゲーションパネルから、 → を選択します。
- ページヘッダーの をクリックします。
取得元のレジストリーを選択します。Name フィールドには、ローカルレジストリーに表示されるイメージの名前が表示されます。
注記Upstream name フィールドは、リモートサーバー上のイメージの名前です。たとえば、アップストリーム名が "alpine" に設定され、Name フィールドが "local/alpine" の場合、alpine イメージがリモートからダウンロードされ、"local/alpine" に名前が変更されます。
- 追加または除外するタグのリストを設定します。イメージに多数のタグがあると、イメージの同期に時間がかかり、大量のディスク容量が使用されます。
関連情報
- レジストリーのリストについては、Red Hat コンテナーレジストリーの認証 を参照してください。
- イメージをプルする際に使用するオプションは、What is Podman? ドキュメントを参照してください。
パート I. オープンソースライセンス
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity.For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.
"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship.For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner.For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.
2. Grant of Copyright License.Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
3. Grant of Patent License.Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
4. Redistribution.You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
- You must give any other recipients of the Work or Derivative Works a copy of this License; and
- You must cause any modified files to carry prominent notices stating that You changed the files; and
- You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
- If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear.The contents of the NOTICE file are for informational purposes only and do not modify the License.You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
5. Submission of Contributions.Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions.Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.
6. Trademarks.This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty.Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
8. Limitation of Liability.In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability.While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License.However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
付録A 自動化実行環境の優先順位
プロジェクト更新は常にコントロールプレーンの自動化実行環境を使用しますが、ジョブは以下のように最初に利用可能な自動化実行環境を使用します。
-
ジョブを作成したテンプレート (ジョブテンプレートまたはインベントリーソース) で定義される
execution_environment
。 -
ジョブが使用するプロジェクトで定義される
default_environment
。 -
ジョブの組織で定義される
default_environment
。 -
ジョブが使用するインベントリーの組織で定義される
default_environment
。 -
現在の
DEFAULT_EXECUTION_ENVIRONMENT
設定 (api/v2/settings/system/
で設定可能)。 -
GLOBAL_JOB_EXECUTION_ENVIRONMENTS
設定からのイメージ。 - その他のグローバル実行環境。
複数の実行環境が基準 (6 および 7 に適用) に適合する場合は、最近作成された実行環境が使用されます。