第5章 仮想環境の実行環境への移行


Ansible Automation Platform 2 には、自動化コントロールプレーンと実行プレーンを完全に分離する、再考されたアーキテクチャーが付属しています。この新機能を使用すると、globe 全体で自動化を簡単にスケーリングでき、単一のデータセンターで自動化の実行にバインドされずに、できるだけソースに近いように自動化を実行できます。Ansible Automation Platform 1.2 と比較して、より動的、スケーラビリティー、回復性があり、柔軟性があります。

自動化実行環境の導入により、これらのコンテナーイメージは、Ansible Core、Ansible Content Collections、Python 依存関係、Red Hat Enterprise Linux UBI 8、および追加のパッケージ依存関係などの主要コンポーネントを含め、パッケージ化して実行するために必要なすべての自動化を可能にします。

この章では、Ansible Automation Platform 1.2 クラスター内のカスタム Python 仮想環境を、ユーザーが構築した自動化実行環境に移行することに焦点を当てます。

この 1 回限りの作業により、最新の Ansible Automation Platform 2 機能と、より少ない長期メンテナンスで複数のプラットフォームにわたって一貫した自動化を実行する機能を活用するための扉が開かれます。

警告

ユーザーが構築した実行環境にアクセスするには、それらが Private Automation Hub またはコンテナーレジストリー内でホストされている必要があります。Private Automation Hub のインストール方法の詳細については Ansible Automation Platform 2.1 リファレンスアーキテクチャーのデプロイ を参照してください。

5.1. 仮想環境から実行環境への移行の自動化

Ansible コマンドを実行するだけでプロセスを自動化する補助的な Ansible Playbook を含めることで、簡素化しています。

すべてを行うには、以下の手動のプロセスを実行します。

  1. Ansible Automation Platform 1.2 環境にカスタム Python 仮想環境を備える
  2. Python 仮想環境のカスタムリストを取得するための awx-manage コマンドラインユーティリティーを使用する
  3. 各 Python 仮想環境で awx-manage export_custom_venv コマンドを実行して、インストールされている Python パッケージのリストを取得する
  4. awx-manage custom_venv_associations コマンドを使用して Python 仮想環境の関連付けを確認する
  5. ansible-builder ツールを使用して上記の情報をフィルタリングして実行環境を作成する

自動プロセスは、以下で構成されます。

  1. Ansible Automation Platform 1.2 環境にある各カスタム Python 仮想環境からパッケージの一覧を取得する
  2. 前のステップのパッケージリストを Ansible-2.9 のパッケージリストと比較する。[1] ベースの Ansible-2.9 実行環境に存在しないパッケージを見つける
  3. Ansible-2.9 実行環境をベースとして使用し、前のステップのリストから不足している依存関係を含む新しいカスタム実行環境を作成する

シナリオがどのように実行されるかを確認するには、以下の例を試してみます。

既存の Ansible Automation Platform 1.2 には、custom-venv1 および custom-venv2 という ラベルの付いた 2 つのカスタム Python 仮想環境があります。

redhat_cop.ee_utilities コレクション にパッケージ化されたロール virtualenv_migrate を使用して、Ansible Tower ノードへの ssh アクセスを介して Ansible Automation Platform 1.2 環境に対して実行し、(Ansible 2.9 実行環境) と比較する現在のベース実行環境の一部ではないパッケージとそのバージョンを抽出します。

注記

redhat_cop.ee_utilities コレクションはコミュニティープロジェクトで、Red Hat では正式にサポートされていません。

それぞれの環境の Playbook およびインベントリーファイルのサンプルを以下に示します。

playbook.yml

---
- name: Review custom virtualenvs and pull requirements
  hosts: enva_tower
  become: true
  tasks:
    - name: Include venv role
      include_role:
        name: redhat_cop.ee_utilities.virtualenv_migrate

Inventory

[tower]
ansibletower.example.com
ansible_ssh_private_key_file=/path/to/example.pem


[all:vars]
###############################################################################
# Required configuration variables for migration from venv -> EE              #
###############################################################################

# The default URL location to the execution environment (Default Ansible 2.9)
# If you want to use the newest Ansible base, change to: ee-minimal-rhel8:latest
venv_migrate_default_ee_url="registry.redhat.io/ansible-automation-platform-21/ee-29-rhel8:latest"

# User credential for access to venv_migrate_default_ee_url
registry_username='myusername'

注記
  • ssh に必要なユーザーをもとに ansible_user=<ANSIBLE_USER> を Ansible Tower ノードに追加します。
  • この参照環境は、暗号化された認証情報を利用しており、プレーンテキストのパスワードは含まれていません。付録C 暗号化された credentials.yml ファイルの作成 の詳細は、ansible-vault を使用してレジストリーの認証情報を暗号化する方法を参照してください。暗号化された credentials.yml ファイルは、registry_passwordを指定するために使用されます。
警告

このロールには、podman コマンドを実行するために sudo 権限が必要です。

Ansible Playbook のサンプル出力は、各カスタム Python 仮想環境に必要な追加パッケージのリストを示しています。この場合、custom-venv1 Python 仮想環境には、Ansible 2.9 実行環境にすでに含まれているものに加えて、次のパッケージが必要であることがわかります。

  • certifi
  • charset-normalizer
  • enum34
  • future
  • solidfire-sdk-python

custom-venv2 Python 仮想環境には、標準の Ansible-2.9 実行環境に含まれるものに加えて、zabbix-api のみが必要でした。

注記

Ansible 2.9 実行環境は、ほとんどの Ansible Automation Platform 1.2 環境が Ansible 2.9 を使用しているため、カスタム Python 仮想環境との比較に使用されます。こうすることで、後方互換性があるので移行が容易になります。

TASK [redhat_cop.tower_utilities.virtualenv_migrate : diff | Show the packages that are extra from default EEs in custom venvs.] ******************************************************************************
ok: [3.228.23.40 -> localhost] => {
    "msg": [
        {
            "/opt/my-envs/custom-venv1/": [
                "certifi",
                "charset-normalizer",
                "enum34",
                "future",
                "solidfire-sdk-python"
            ]
        },
        {
            "/opt/my-envs/custom-venv2/": [
                "zabbix-api"
            ]
        }
    ]
}

カスタム Python 仮想環境ごとにパッケージがキャプチャーされると、Ansible Playbook は、ローカルユーザー環境での実行環境の作成を自動化する redhat_cop.ee_utilities コレクション の一部である ee_builder ロールを使用します。

提供された Ansible Playbook を実行する前に、ローカルホストマシンに ansible-builder をインストールします。Playbook の実行により、カスタム Python 仮想環境と提供されたベース実行環境の間のパッケージの差異をもとに、ローカルマシン上に実行環境が作成されます。

$ podman images

REPOSITORY                           TAG                IMAGE ID
localhost/custom-venv2               latest             c017418d1919
localhost/custom-venv1               latest             7cbe3b49974d
localhost/custom-venv                latest             9d5d809f38b0

5.1.1. Private Automation Hub へのプッシュ

ローカル実行環境が整ったら、次の方法でそれらを Private Automation Hub にプッシュできます。

注記

この参照アーキテクチャーでは、自動化実行環境の名前をカスタム Python 仮想環境の名前のままにし、簡素化しています。名前に変更が必要な場合は、実行環境を Private Automation Hub または選択したコンテナーレジストリーにプッシュする前に podman tag コマンドを使用します。

$ podman login [automation-hub-url]
# Enter the username and password to access Private Automation Hub.
$ podman tag [image-id] [automation-hub-url]/[container image name]
$ podman push [automation-hub-url]/[container image name]
ヒント

詳細は、Private Automation Hub でのコンテナーの管理 を参照してください。

この作業が完了したら、コントローラーユーザーインターフェース内に Private Automation Hub のレジストリー認証情報を作成して、実行環境を Automation Controller に同期します。

Automation controller 内でレジストリー認証情報を作成するには、次のようにします。

  1. Resources→Credentials を選択します。
  2. Credentials 内で青い Add ボタンを選択します。
  3. Create New Credentials ウィンドウで、以下を実行します。

    1. Name を指定します(例: My private automation hub credentials)。
    2. Credential Type でドロップダウンを選択し、Container Registry を選択します。
    3. Type Details で以下を実行します。

      1. 認証 URL (例: pah.example.com) を指定します。
      2. Username フィールドに Private Automation Hub のユーザー名を入力します
      3. パスワードまたは トークン フィールドに Private Automation Hub のパスワードまたはトークンを入力します。
      4. Private Automation Hub 環境が SSL に対応している場合は、Verify SSL を選択します。
  4. Save をクリックします。

Automation controller 内で実行環境を使用できるようにするには、Private Automation Hub からイメージをプルする新しい実行環境を作成します。

Automation Controller 内で以下を実行します。

  1. Administration →Execution Environments を選択します。
  2. Execution Environments 内で、青色の Add ボタンを選択します
  3. Create new execution environment ウィンドウで、以下を実行します。

    1. Name (例: my execution environment) を指定します。
    2. 実行環境のイメージの場所 (例: repo/project/image-name:tag) を指定します。
    3. Registry credential の虫眼鏡を選択します。

      1. Private Automation Hub 認証情報など、Private Automation Hub の認証情報のラジオボタンをクリックします。

Automation controller 内で実行環境が使用可能になったため、既存のジョブテンプレートまたは新しく作成されたジョブテンプレートに対して使用できます。

ヒント

後方互換性を確保する必要がないユーザーが構築する実行環境を新たに作成する場合には、ee-minimal の実行環境を、基盤の実行環境として使用し、新しいイメージを構築することを推奨します。



[1] この参照アーキテクチャーは、Ansible Automation Platform 1.2 の実行プレーン環境とよく似た環境を作成するためにansible-2.9 実行環境を使用しています。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る