Ansible Automation Platform の移行

手順

1. 現在の RPM デプロイメントのトポロジー全体をドキュメント化します。

   1. すべてのサーバー、ノード、およびそれらのロール (コントロールノード、実行ノード、データベースサーバーなど) を詳細に描写します。
   2. デプロイメント内の各サーバーのホスト名、IP アドレス、および機能を記録します。
   3. コンポーネント間のネットワーク設定をドキュメント化します。

2. Ansible Automation Platform のバージョン情報:

   1. 現在デプロイされている Ansible Automation Platform の正確なバージョン (X.Y) を記録します。

3. 各コンポーネントの特定のバージョンをドキュメント化します。

   1. Automation Controller のバージョン
   2. Automation Hub のバージョン
   3. プラットフォームゲートウェイのバージョン

4. データベースの設定:

   1. 各コンポーネントのデータベース名
   2. データベースのユーザーとロール
   3. 接続パラメーターと認証方法
   4. カスタムの PostgreSQL 設定または最適化

手順

1. PostgreSQL データベースのバージョンが PostgreSQL バージョン 15 であることを確認します。

   データベースサーバーに接続し、postgres ユーザーとして次のコマンドを実行すると、現在の PostgreSQL バージョンを確認できます。

   $ psql -c 'SELECT version();'

   重要

   移行プロセスを正常に実行するには、PostgreSQL バージョン 15 が厳密に要求されます。PostgreSQL 13 以前を実行している場合は、移行を続行する前にバージョン 15 にアップグレードしてください。

   Ansible Automation Platform によって管理されるデータベースを使用している場合は、インストールプログラムを再実行して PostgreSQL バージョンをアップグレードしてください。お客様提供の (外部) データベースを使用している場合は、データベース管理者またはサービスプロバイダーに連絡してバージョンを確認し、必要に応じてアップグレードの準備をしてください。

2. 移行元環境の完全なバックアップを作成します。

   $ ./setup.sh -e 'backup_dest=/path/to/backup_dir/' -b

3. 各コンポーネントグループの 1 つのノードから接続設定を取得します。

   コマンドごとに、ホストにアクセスして root ユーザーになります。

   • Automation Controller ノードにアクセスして、次のコマンドを実行します。

     # awx-manage print_settings | grep '^DATABASES'

   • Automation Hub ノードにアクセスして、次のコマンドを実行します。

     # grep '^DATABASES' /etc/pulp/settings.py

   • プラットフォームゲートウェイノードにアクセスして、次のコマンドを実行します。

     # aap-gateway-manage print_settings | grep '^DATABASES'

4. 手動で作成したアーティファクトをプラットフォームゲートウェイノードに一時的に配置します。

   # mkdir -p /tmp/backups/artifact/{controller,gateway,hub}

   # mkdir -p /tmp/backups/artifact/controller/custom_configs

   # touch /tmp/backups/artifact/secrets.yml

   # cd /tmp/backups/artifact/

5. データベースのサイズを検証し、ファイルシステムに pg_dump 用の十分な領域があることを確認します。

   データベースサーバーに接続し、postgres ユーザーとして次のコマンドを実行すると、データベースのサイズを確認できます。

   $ psql -c '\l+'

   次のステップを実行する前に、必要に応じてファイルシステムのサイズを調整するか、外部ファイルシステムをマウントします。

   注記

   これらのコマンドは、すべてのターゲットファイルを /tmp ファイルシステムに送信します。実際の環境のニーズに合わせてコマンドを調整します。

6. プラットフォームゲートウェイノードで、すべてのコンポーネントのデータベースダンプを実行し、作成したアーティファクト内に保存します。

   # psql -h <pg_hostname> -U <component_pg_user> -d <database_name> -t -c 'SHOW server_version;' # ensure connectivity to the database

   # pg_dump -h <pg_hostname> -U <component_pg_user> -d <component_pg_name> --clean --create -Fc -f <component>/<component>.pgc

   # ls -ld <component>/<component>.pgc

   # echo "<component>_pg_database: <database_name>" >> secrets.yml ## Add the database name for the component to the secrets file

7. 各コンポーネントグループの 1 つのノードから RPM 環境のシークレットをエクスポートします。

   以下の各ステップでは、root ユーザーを使用してコマンドを実行します。

   • Automation Controller ノードにアクセスし、シークレットキーを収集して、secrets.yml ファイルの controller_secret_key 値に追加します。

     # cat /etc/tower/SECRET_KEY

   • Automation Hub ノードにアクセスし、シークレットキーを収集して、secrets.yml ファイルの hub_secret_key 値に追加します。

     # grep '^SECRET_KEY' /etc/pulp/settings.py | awk -F'=' '{ print $2 }'

   • Automation Hub ノードにアクセスし、database_fields.symmetric.key 値を収集して、secrets.yml ファイルの hub_db_fields_encryption_key 値に追加します。

     # cat /etc/pulp/certs/database_fields.symmetric.key

   • プラットフォームゲートウェイノードにアクセスし、シークレットキーを収集して、secrets.yml ファイルの gateway_secret_key 値に追加します。

     # cat /etc/ansible-automation-platform/gateway/SECRET_KEY

8. Automation Controller のカスタム設定をエクスポートします。

   /etc/tower/conf.d にカスタム設定が存在する場合は、それを /tmp/backups/artifact/controller/custom_configs にコピーします。

   インストールプログラムによって管理され、カスタムとはみなされない Automation Controller 上の設定ファイル:

   • /etc/tower/conf.d/postgres.py
   • /etc/tower/conf.d/channels.py
   • /etc/tower/conf.d/caching.py
   • /etc/tower/conf.d/cluster_host_id.py

9. アーティファクトをパッケージ化します。

   # cd /tmp/backups/artifact/

   # [ -f sha256sum.txt ] && rm -f sha256sum.txt; find . -type f -name "*.pgc" -exec sha256sum {} \; >> sha256sum.txt

   # cat sha256sum.txt

   # cd ..

   # tar cf artifact.tar artifact

   # sha256sum artifact.tar > artifact.tar.sha256

   # sha256sum --check artifact.tar.sha256

   # tar tvf artifact.tar

   tar tvf artifact.tar の出力例:

   drwxr-xr-x ansible/ansible     0 2025-05-08 16:48 artifact/
   drwxr-xr-x ansible/ansible     0 2025-05-08 16:33 artifact/controller/
   -rw-r--r-- ansible/ansible 732615 2025-05-08 16:26 artifact/controller/controller.pgc
   drwxr-xr-x ansible/ansible      0 2025-05-08 16:33 artifact/controller/custom_configs/
   drwxr-xr-x ansible/ansible      0 2025-05-08 16:11 artifact/gateway/
   -rw-r--r-- ansible/ansible 231155 2025-05-08 16:28 artifact/gateway/gateway.pgc
   drwxr-xr-x ansible/ansible      0 2025-05-08 16:26 artifact/hub/
   -rw-r--r-- ansible/ansible 29252002 2025-05-08 16:26 artifact/hub/hub.pgc
   -rw-r--r-- ansible/ansible      614 2025-05-08 16:24 artifact/secrets.yml
   -rw-r--r-- ansible/ansible      338 2025-05-08 16:48 artifact/sha256sum.txt

10. artifact.tar と artifact.tar.sha256 をローカルマシンにダウンロードするか、scp コマンドを使用してターゲットノードに転送します。

手順

1. 現在のコンテナー化バージョンのデプロイメントの完全なトポロジーをドキュメント化します。

   1. すべてのサーバー、ノード、およびそれらのロール (コントロールノード、実行ノード、データベースサーバーなど) を詳細に描写します。
   2. デプロイメント内の各サーバーのホスト名、IP アドレス、および機能を記録します。
   3. コンポーネント間のネットワーク設定をドキュメント化します。

2. Ansible Automation Platform のバージョン情報:

   1. 現在デプロイされている Ansible Automation Platform の正確なバージョン (X.Y) を記録します。

3. 各コンポーネントの特定のバージョンをドキュメント化します。

   1. Automation Controller のバージョン
   2. Automation Hub のバージョン
   3. プラットフォームゲートウェイのバージョン

4. データベースの設定:

   1. 各コンポーネントのデータベース名
   2. データベースのユーザーとロール
   3. 接続パラメーターと認証方法
   4. カスタムの PostgreSQL 設定または最適化
5. すべてのカスタムの構成と設定を特定します。
6. コンテナーのリソース割り当てとボリュームをドキュメント化します。

手順

1. PostgreSQL データベースのバージョンが PostgreSQL バージョン 15 であることを確認します。

   データベースサーバーに接続し、postgres ユーザーとして次のコマンドを実行すると、現在の PostgreSQL バージョンを確認できます。

   $ podman exec -it postgresql bash -c 'psql -c "SELECT version();"'

   重要

   移行プロセスを正常に実行するには、PostgreSQL バージョン 15 が厳密に要求されます。PostgreSQL 13 以前を実行している場合は、移行を続行する前にバージョン 15 にアップグレードしてください。

   Ansible Automation Platform によって管理されるデータベースを使用している場合は、インストールプログラムを再実行して PostgreSQL バージョンをアップグレードしてください。お客様提供の (外部) データベースを使用している場合は、データベース管理者またはサービスプロバイダーに連絡してバージョンを確認し、必要に応じてアップグレードの準備をしてください。

2. 移行元環境の完全なバックアップを作成します。

   $ ansible-playbook -i <path_to_inventory> ansible.containerized_installer.backup

3. 各コンポーネントグループの 1 つのノードから接続設定を取得します。

   • Automation Controller ノードにアクセスして、次のコマンドを実行します。

     $ podman exec -it automation-controller-task bash -c 'awx-manage print_settings | grep '^DATABASES'

   • Automation Hub ノードにアクセスして、次のコマンドを実行します。

     $ podman exec -it automation-hub-api bash -c "pulpcore-manager diffsettings | grep '^DATABASES'"

   • プラットフォームゲートウェイノードにアクセスして、次のコマンドを実行します。

     $ podman exec -it automation-gateway bash -c "aap-gateway-manage print_settings | grep '^DATABASES'"

4. データベースのサイズを検証し、ファイルシステムに pg_dump 用の十分な領域があることを確認します。

   データベースサーバーに接続し、postgres ユーザーとして次のコマンドを実行すると、データベースのサイズを確認できます。

   $ podman exec -it postgresql bash -c 'psql -c "\l+"'

   次のステップを実行する前に、必要に応じてファイルシステムのサイズを調整するか、外部ファイルシステムをマウントします。

   注記

   これらのコマンドは、すべてのターゲットファイルを /tmp ファイルシステムに送信します。実際の環境のニーズに合わせてコマンドを調整します。

5. 手動で作成したアーティファクトをプラットフォームゲートウェイノードに一時的に配置します。

   # mkdir -p /tmp/backups/artifact/{controller,gateway,hub}

   # mkdir -p /tmp/backups/artifact/controller/custom_configs

   # touch /tmp/backups/artifact/secrets.yml

   # cd /tmp/backups/artifact/

6. プラットフォームゲートウェイノードで、すべてのコンポーネントのデータベースダンプを実行し、先ほど作成したアーティファクト内に保存します。

   psql コマンドと pg_restore コマンドを実行するには、一時コンテナーを作成し、その中でコマンドを実行する必要があります。このコマンドはデータベースノードから実行する必要があります。

   $ podman run -it --rm --name postgresql_restore_temp --network host --volume ~/aap/tls/extracted:/etc/pki/ca-trust/extracted:z --volume ~/aap/postgresql/server.crt:/var/lib/pgsql/server.crt:ro,z --volume ~/aap/postgresql/server.key:/var/lib/pgsql/server.key:ro,z --volume /tmp/backups/artifact:/var/lib/pgsql/backups:ro,z registry.redhat.io/rhel8/postgresql-15:latest bash

   注記

   このコマンドは、イメージが registry.redhat.io/rhel8/postgresql-15:latest であることを前提としています。イメージが見つからない場合は、podman images ls を使用して、ユーザーが使用できるイメージを確認してください。

   上記のコマンドを実行すると、postgresql_restore_temp という名前のコンテナー内でシェルが開き、アーティファクトが /var/lib/pgsql/backups にマウントされます。また、正しい証明書を解決できるように、PostgreSQL 証明書がマウントされます。

   bash-4.4$ cd /var/lib/pgsql/backups
   bash-4.4$ psql -h <pg_hostname> -U <component_pg_user> -d <database_name> -t -c 'SHOW server_version;' # ensure connectivity to db
   bash-4.4$ pg_dump -h <pg_hostname> -U <component_pg_user> -d <component_pg_name> --clean --create -Fc -f <component>/<component>.pgc
   bash-4.4$ ls -ld <component>/<component>.pgc
   bash-4.4$ echo "<component>_pg_database: <database_name>" >> secrets.yml ## Add the DB name for the component to the secrets file

   このデータを収集したら、この一時コンテナーを終了します。

7. 各コンポーネントグループの 1 つのノードから、コンテナー環境のシークレットをエクスポートします。

   以下の各ステップでは、root ユーザーを使用してコマンドを実行します。

   1. Automation Controller ノードにアクセスし、シークレットキーを収集して、secrets.yaml ファイルの controller_secret_key 値に追加します。

      $ podman secret inspect --showsecret --format "{{.SecretData}}" controller_secret_key

   2. Automation Hub ノードにアクセスし、シークレットキーを収集して、secrets.yaml ファイルの hub_secret_key 値に追加します。

      $ podman secret inspect --showsecret --format "{{.SecretData}}" hub_secret_key

   3. Automation Hub ノードにアクセスし、database_fields.symmetric.key 値を収集して、secrets.yaml ファイルの hub_db_fields_encryption_key 値に追加します。

      $ podman secret inspect --showsecret --format "{{.SecretData}}" hub_database_fields

   4. プラットフォームゲートウェイノードにアクセスし、シークレットキーを収集して、secrets.yaml ファイルの gateway_secret_key 値に追加します。

      $ podman secret inspect --showsecret --format "{{.SecretData}}" gateway_secret_key

8. Automation Controller のカスタム設定をエクスポートします。

   コンテナー化されたインストール環境のインベントリーに extra_settings が存在する場合は、それを新しいファイルにコピーし、/tmp/backups/artifact/controller/custom_configs に保存します。

9. アーティファクトをパッケージ化します。

   # cd /tmp/backups/artifact/
   # [ -f sha256sum.txt ] && rm -f sha256sum.txt; find . -type f -name "*.pgc" -exec sha256sum {} \; >> sha256sum.txt
   # cat sha256sum.txt
   # cd ..
   # tar cf artifact.tar artifact
   # sha256sum artifact.tar > artifact.tar.sha256
   # sha256sum --check artifact.tar.sha256
   # tar tvf artifact.tar

   tar tvf artifact.tar の出力例:

   drwxr-xr-x ansible/ansible     0 2025-05-08 16:48 artifact/
   drwxr-xr-x ansible/ansible     0 2025-05-08 16:33 artifact/controller/
   -rw-r--r-- ansible/ansible 732615 2025-05-08 16:26 artifact/controller/controller.pgc
   drwxr-xr-x ansible/ansible      0 2025-05-08 16:33 artifact/controller/custom_configs/
   drwxr-xr-x ansible/ansible      0 2025-05-08 16:11 artifact/gateway/
   -rw-r--r-- ansible/ansible 231155 2025-05-08 16:28 artifact/gateway/gateway.pgc
   drwxr-xr-x ansible/ansible      0 2025-05-08 16:26 artifact/hub/
   -rw-r--r-- ansible/ansible 29252002 2025-05-08 16:26 artifact/hub/hub.pgc
   -rw-r--r-- ansible/ansible      614 2025-05-08 16:24 artifact/secrets.yml
   -rw-r--r-- ansible/ansible      338 2025-05-08 16:48 artifact/sha256sum.txt

10. artifact.tar と artifact.tar.sha256 をローカルマシンにダウンロードするか、scp コマンドを使用してターゲットノードに転送します。

手順

1. ファイルシステムのホームフォルダーのサイズを検証し、アーティファクトを転送するのに十分な領域があることを確認します。
2. scp または任意のファイル転送方法を使用して、作業するノードにアーティファクトを転送します。プラットフォームゲートウェイノードはほとんどのシステムにアクセスできるため、このノードから作業することを推奨します。ただし、PostgreSQL のダンプにより、アクセスの制限やファイルシステムの領域に制限がある場合は、代わりにデータベースノードから作業してください。
3. Ansible Automation Platform ダウンロードページ からコンテナー化された Ansible Automation Platform の最新バージョンをダウンロードします。
4. アーティファクトのチェックサムを検証します。

5. コンテナーを実行しているユーザーのホームフォルダーにアーティファクトを抽出します。

   $ cd ~

   $ sha256sum-check artifact.tar.sha256

   $ tar xf artifact.tar

   $ cd artifact

   $ sha256sum-check sha256sum.txt

6. コンテナー化バージョンのデプロイメント用のインベントリーファイルを生成します。

   移行元環境と同じトポロジーになるようにインベントリーファイルを設定します。アーティファクトの secrets.yml ファイルからコンポーネントデータベース名と secret_key 値を設定します。

   これは、以下の 2 つの方法で実行できます。

   • インベントリーファイルに追加の変数を設定します。

   • インストールプログラムを実行するときに、secrets.yml ファイルを追加の変数ファイルとして使用します。

     1. 方法 1: インベントリーファイル内の追加の変数

        $ egrep 'pg_database|_key' inventory
        controller_pg_database=<redacted>
        controller_secret_key=<redacted>
        gateway_pg_database=<redacted>
        gateway_secret_key=<redacted>
        hub_pg_database=<redacted>
        hub_secret_key=<redacted>
        __hub_database_fields=<redacted>

        注記

        __hub_database_fields 値は、シークレット内の hub_db_fields_encryption_key 値から取得されます。

     2. 方法 2: 追加の変数ファイル

        $ ansible-playbook -i inventory ansible.containerized_installer.install -e @~/artifact/secrets.yml -e "__hub_database_fields='{{ hub_db_fields_encryption_key }}'"

7. 移行先のコンテナー環境をインストールして設定します。
8. PostgreSQL データベースのバージョンが 15 であることを確認します。

9. 初期のコンテナー環境のバックアップを作成します。

   $ ansible-playbook -i <path_to_inventory> ansible.containerized_installer.backup

10. 新規インストールが正しく機能することを確認します。

手順

1. データベースを除くコンテナー化されたサービスを停止します。

   1. すべてのノードで、Performance Co-Pilot が設定されている場合は、次のコマンドを実行します。

      $ systemctl --user stop pcp

   2. Automation Controller ノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user stop automation-controller-task automation-controller-web automation-controller-rsyslog
      $ systemctl --user stop receptor

   3. Automation Hub ノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user stop automation-hub-api automation-hub-content automation-hub-web automation-hub-worker-1 automation-hub-worker-2

   4. Event-Driven Ansible ノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user stop automation-eda-scheduler automation-eda-daphne automation-eda-web automation-eda-api automation-eda-worker-1 automation-eda-worker-2 automation-eda-activation-worker-1 automation-eda-activation-worker-2

   5. プラットフォームゲートウェイノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user stop automation-gateway automation-gateway-proxy

   6. スタンドアロン Redis を使用する場合はプラットフォームゲートウェイノードにアクセスし、クラスター Redis を使用する場合はインベントリーファイル内の Redis グループの全ノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user stop redis-unix redis-tcp

      注記

      エンタープライズデプロイメントでは、コンポーネントは別々のノードで実行されます。各コンポーネントのノードでコマンドを実行してください。

2. データベースダンプをコンテナー環境にインポートします。

   1. Ansible Automation Platform によって管理されるデータベースを使用している場合は、psql コマンドと pg_restore コマンドを実行するために、一時コンテナーを作成する必要があります。このコマンドはデータベースノードから実行します。

      $ podman run -it --rm --name postgresql_restore_temp --network host --volume ~/aap/tls/extracted:/etc/pki/ca-trust/extracted:z --volume ~/aap/postgresql/server.crt:/var/lib/pgsql/server.crt:ro,z --volume ~/aap/postgresql/server.key:/var/lib/pgsql/server.key:ro,z --volume ~/artifact:/var/lib/pgsql/backups:ro,z registry.redhat.io/rhel8/postgresql-15:latest bash

      注記

      上記のコマンドを実行すると、postgresql_restore_temp という名前のコンテナー内でシェルが開き、アーティファクトが /var/lib/pgsql/backups にマウントされます。また、正しい証明書を解決できるように、PostgreSQL 証明書がマウントされます。

      このコマンドは、イメージ registry.redhat.io/rhel8/postgresql-15:latest が利用可能であることを前提としています。イメージが見つからない場合は、podman images ls を使用して、ユーザーが使用できるイメージを確認してください。

      また、アーティファクトが現在のユーザーのホームフォルダーにあることも前提としています。アーティファクトが他の場所にある場合は、~/artifact を必要なパスに変更してください。

   2. お客様提供の (外部) データベースを使用している場合は、psql コマンドと pg_restore コマンドがインストールされ、データベースにアクセスできる任意のノードからこれらのコマンドを実行できます。不明な場合は、データベース管理者に問い合わせてください。

   3. コンテナー内からデータベースにアクセスし、ユーザーに CREATEDB ロールがあることを確認します。

      bash-4.4$ psql -h <pg_hostname> -U postgres
      postgres=# \l
                Name           |     Owner     | Encoding |   Collate   |    Ctype    | ICU Locale | Locale Provider |   Access privileg
      es
      -------------------------+---------------+----------+-------------+-------------+------------+-----------------+------------------
      -----
       automationedacontroller | eda           | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            |
       automationhub           | automationhub | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            |
       awx                     | awx           | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            |
       gateway                 | gateway       | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            |
      ...

   4. コンポーネント名ごとに、CREATEDB ロールを Owner に追加します。以下に例を示します。

      postgres=# ALTER ROLE awx WITH CREATEDB;
      postgres=# \q

      awx は、データベース所有者に置き換えます。

   5. CREATEDB を追加したら、アーティファクトがマウントされているパスにアクセスし、pg_restore コマンドを実行します。

      bash$ cd /var/lib/pgsql/backups
      bash$ pg_restore --clean --create --no-owner -h <pg_hostname> -U <component_pg_user> -d template1 <component>/<component>.pgc

   6. 復元後、ユーザーから権限を削除します。以下に例を示します。

      postgres=# ALTER ROLE awx WITH NOCREATEDB;
      postgres=# \q

      awx は、ロールを持つ各ユーザーに置き換えます。

3. データベースを除くコンテナー化されたサービスを起動します。

   注記

   エンタープライズデプロイメントでは、コンポーネントは別々のノードで実行されます。各コンポーネントのノードでコマンドを実行してください。

   1. すべてのノードで、Performance Co-Pilot が設定されている場合は、次のコマンドを実行します。

      $ systemctl --user start pcp

   2. Automation Controller ノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user start automation-controller-task automation-controller-web automation-controller-rsyslog
      $ systemctl --user start receptor

   3. Automation Hub ノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user start automation-hub-api automation-hub-content automation-hub-web automation-hub-worker-1 automation-hub-worker-2

   4. Event-Driven Ansible ノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user start automation-eda-scheduler automation-eda-daphne automation-eda-web automation-eda-api automation-eda-worker-1 automation-eda-worker-2  automation-eda-activation-worker-1 automation-eda-activation-worker-2

   5. プラットフォームゲートウェイノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user start automation-gateway automation-gateway-proxy

   6. スタンドアロン Redis を使用する場合はプラットフォームゲートウェイノードにアクセスし、クラスター Redis を使用する場合はインベントリー内の Redis グループの全ノードにアクセスして、次のコマンドを実行します。

      $ systemctl --user start redis-unix redis-tcp

手順

1. プラットフォームゲートウェイ設定のプロビジョニングを解除します。

   • プラットフォームゲートウェイ設定のプロビジョニング解除を行うには、automation-gateway コンテナーを実行しているホストに、4.2.6 と同じルートレスユーザーとして SSH 接続し、以下のコマンドを実行して、プラットフォームゲートウェイのプロキシー設定を削除します。

     $ podman exec -it automation-gateway bash
     $ aap-gateway-manage migrate
     $ aap-gateway-manage shell_plus
     >>> HTTPPort.objects.all().delete(); ServiceNode.objects.all().delete(); ServiceCluster.objects.all().delete()

2. カスタムの構成と設定を移行します。

   • インベントリーファイルを編集し、component_extra_settings を使用して各コンポーネントに関連する extra_settings を適用します。

3. 各コンポーネントの Resource Server Secret Key を更新します。

   1. 各コンポーネントの現在の Resource Secret 値を収集します。

      $ podman exec -it automation-gateway bash -c 'aap-gateway-manage shell_plus --quiet -c "[print(cl.name, key.secret) for cl in ServiceCluster.objects.all() for key in cl.service_keys.all()]"'

   2. 現在のシークレット値を検証します。

      $ for secret_name in eda_resource_server hub_resource_server controller_resource_server
      do
      echo $secret_name
      podman secret inspect $secret_name --showsecret | grep SecretData
      done

   3. シークレット値が現在の値と一致しない場合は、既存のシークレットを削除して再作成し、新しい値で更新します。

      1. シークレットを削除します。

         $ podman secret rm <SECRET_NAME>

      2. シークレットを再作成します。

         $ echo "secret_value" | podman secret create <SECRET_NAME> -

         上記のコマンドの <SECRET_NAME> プレースホルダーを、各コンポーネントの適切なシークレット名に置き換えます: eda_resource_server (Event-Driven Ansible)、hub_resource_server (Automation Hub)、controller_resource_server (Automation Controller)。

4. インストールと同じインベントリーを使用して、移行先環境でインストールプログラムを再実行します。

5. 自動化実行のインスタンスを検証します。

   1. ルートレスユーザーとして、automation-controller-task コンテナーを提供するホストに SSH で接続し、次のコマンドを実行して、ソースアーティファクトから孤立したインスタンスを検証して削除します。

      $ podman exec -it automation-controller-task bash

      $ awx-manage list_instances

   2. このクラスターの一部ではなくなったノードを探します。ヘルスチェックに失敗したために capacity が 0 になったノードが良い目印となります。

      [ungrouped capacity=0]
      	[DISABLED] node1.example.org capacity=0 node_type=hybrid version=X.Y.Z heartbeat="..."
      	[DISABLED] node2.example.org capacity=0 node_type=execution version=ansible-runner-X.Y.Z heartbeat="..."

   3. awx-manage を使用してこれらのノードを削除し、aap-controller-task インスタンスのみを残します。

      awx-manage deprovision_instance --host=node1.example.org
      awx-manage deprovision_instance --host=node2.example.org

6. Pulp の孤立した Automation Hub コンテンツのリンクを修復します。

   • Automation Hub アドレスに直接アクセスできる任意のホストから次のコマンドを実行します。

     $ curl -d '{\"verify_checksums\": true }' -X POST -k https://<gateway url>/api/galaxy/pulp/api/v3/repair/ -u <gateway_admin_user>:<gateway_admin_password>

7. インスタンスグループの設定を調整します。

   1. Automation Execution → Infrastructure → Instance Groups に移動します。
   2. Instance Group を選択し、Instances タブを選択します。
   3. 必要に応じてインスタンスの関連付けと関連付けの解除を実行します。

8. 決定環境と認証情報を調整します。

   1. Automation Decisions → Decision Environments に移動します。
   2. この新しい環境に関連しない、またはアクセスできなくなったレジストリー URL を参照する各決定環境を編集します。たとえば、Automation Hub 決定環境は、移行先の Automation Hub 環境に合わせて変更が必要になる場合があります。
   3. このような決定環境に関連付けられている各認証情報を選択し、そのアドレスが新しい環境に合致したものであることを確認します。

9. 実行環境と認証情報を調整します。

   1. Automation Execution → Infrastructure → Execution Environments に移動します。
   2. 各実行環境イメージを確認し、そのアドレスを新しい環境に照らして検証します。
   3. Automation Execution → Infrastructure → Credentials に移動します。
   4. 各認証情報を編集し、すべての環境固有の情報が新しい環境に合致したものであることを確認します。
10. インスタンスグループを使用した RBAC ルールなど、移行後のさらなるカスタマイズや設定を検証します。

手順

1. 移行されたすべてのコンポーネントが正しく機能することを確認します。

   1. プラットフォームゲートウェイ: https://<gateway_hostname>/ から Ansible Automation Platform URL にアクセスし、ダッシュボードが正しく読み込まれることを確認します。プラットフォームゲートウェイサービスが実行されており、Automation Controller に接続されていることを確認します。
   2. Automation Controller: Automation Execution で、プロジェクト、インベントリー、およびジョブテンプレートが存在し、設定されていることを確認します。
   3. Automation Hub: Automation Content で、コレクション、名前空間、およびそれらのコンテンツが表示されることを確認します。
   4. Event-Driven Ansible (該当する場合): Automation Execution Decisions で、ルール監査、ルールブックアクティベーション、およびプロジェクトにアクセスできることを確認します。

   5. 各コンポーネントについて、ログを確認して起動エラーや警告がないことを確認します。

      podman logs <container_name>

2. ワークフローと自動化プロセスをテストします。

   1. ジョブテンプレートの実行: さまざまな認証情報タイプに依存するジョブテンプレートを含む、いくつかの主要なジョブテンプレートを実行します。
   2. ワークフローテンプレートのテスト: ワークフローテンプレートを実行して、ワークフローノードが正しい順序で実行され、ワークフローが正常に完了することを確認します。
   3. 実行環境の検証: ジョブが適切な実行環境で実行され、必要な依存関係にアクセスできることを確認します。
   4. ジョブのアーティファクトの確認: ジョブのアーティファクトが適切に保存され、アクセス可能であることを確認します。
   5. ジョブのスケジュールの検証: スケジュールしたジョブをテストして、予定時刻に実行されることを確認します。

3. ユーザーのアクセスと権限を検証します。

   1. ユーザー認証: さまざまなユーザーアカウントでログイン機能をテストし、認証が正しく機能することを確認します。
   2. ロールベースアクセス制御: ユーザーが組織、プロジェクト、インベントリー、ジョブテンプレートに対する適切な権限を持っていることを確認します。
   3. チームメンバーシップ: チームメンバーシップとチームベースの権限がそのまま維持されていることを確認します。
   4. API アクセス: API トークンをテストし、API アクセスが適切に機能していることを確認します。
   5. SSO 統合 (該当する場合): シングルサインオン認証が正しく機能していることを確認します。

4. コンテンツの同期と利用可能性を確認します。

   1. コレクションの同期: リモートからコレクションを同期できることを確認します。
   2. コレクションのアップロード: コレクションをアップロードできることを確認します。
   3. コレクションリポジトリー: Automation Hub がコレクションを利用可能にし、実行環境でそれらを使用できることを確認します。
   4. プロジェクトの同期: プロジェクトがソース管理リポジトリーのコンテンツを同期できることを確認します。
   5. 外部コンテンツソース: Automation Hub と Ansible Galaxy (設定されている場合) からの同期をテストします。
   6. 実行環境の可用性: 必要なすべての実行環境が存在し、実行ノードがそれらにアクセスできることを確認します。
   7. コンテンツの依存関係: ジョブを実行するときに、システムがコンテンツの依存関係を正しく解決することを確認します。

手順

1. Ansible Automation Platform をデプロイするために Ansible Automation Platform Operator を設定します。
2. データベース設定 (内部または外部) をセットアップします。
3. Redis 設定 (内部または外部) をセットアップします。
4. Ansible Automation Platform Operator を使用して Ansible Automation Platform をインストールします。
5. 初期の OpenShift Container Platform デプロイメントのバックアップを作成します。
6. 新規インストールが正しく機能することを確認します。

手順

1. Ansible Automation Platform コンポーネントをスケールダウンします。

   1. まず、idle_aap を使用して Ansible Automation Platform のデプロイメントをスケールダウンします。

      oc patch ansibleautomationplatform aap --type merge -p '{"spec":{"idle_aap":true}}'

   2. コンポーネント Pod が停止するまで待機します。稼働し続けるのは 6 つの Operator Pod のみです。

      NAME                                                                  READY   STATUS      RESTARTS   AGE
      pod/aap-controller-migration-4.6.13-5swc6                             0/1     Completed   0          160m
      pod/aap-gateway-operator-controller-manager-6b75c95458-4zrxv          2/2     Running     0          26h
      pod/ansible-lightspeed-operator-controller-manager-b674c55b8-qncjp    2/2     Running     0          45h
      pod/automation-controller-operator-controller-manager-6b79d48d4cchn   2/2     Running     0          45h
      pod/automation-hub-operator-controller-manager-5cd674c984-5njfj       2/2     Running     0          45h
      pod/eda-server-operator-controller-manager-645f4db5-d2flt             2/2     Running     0          45h
      pod/resource-operator-controller-manager-86b8f7bb54-cvz6d             2/2     Running     0          45h

   3. Ansible Automation Platform Gateway Operator と Ansible Automation Platform Controller Operator をスケールダウンします。

      oc scale --replicas=0 deployment aap-gateway-operator-controller-manager automation-controller-operator-controller-manager

      出力例:

      deployment.apps/aap-gateway-operator-controller-manager scaled
      deployment.apps/automation-controller-operator-controller-manager scaled

2. アイドル状態の Postgres StatefulSet をスケールアップします。

   oc scale --replicas=1 statefulset.apps/aap-postgres-15

3. データベースの復元用に一時的な環境を準備します。

   1. 適切な設定とサイズで一時的な永続ボリューム要求 (PVC) を作成します。

      aap-temp-pvc.yaml

      ---
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: aap-temp-pvc
        namespace: aap
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 200Gi

      oc create -f aap-temp-pvc.yaml

   2. 一時的なデプロイメントに使用する既存の PostgreSQL イメージを取得します。

      echo $(oc get pod/aap-postgres-15-0 -o jsonpath="{.spec.containers[].image}")

   3. マウントされた一時的な PVC を使用して一時的な PostgreSQL デプロイメントを作成します。

      aap-temp-postgres.yaml

      ---
      kind: Deployment
      apiVersion: apps/v1
      metadata:
        name: aap-temp-postgres
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: aap-temp-postgres
        template:
          metadata:
            labels:
              app: aap-temp-postgres
          spec:
            containers:
              - name: aap-temp-postgres
                image: <postgres image from previous step>
                command:
                  - /bin/sh
                  - '-c'
                  - sleep infinity
                imagePullPolicy: Always
                securityContext:
                  runAsNonRoot: true
                  allowPrivilegeEscalation: false
                volumeMounts:
                  - name: aap-temp-pvc
                    mountPath: /tmp/aap-temp-pvc
            volumes:
              - name: aap-temp-pvc
                persistentVolumeClaim:
                  claimName: aap-temp-pvc

      oc create -f aap-temp-postgres.yaml

4. エクスポートアーティファクトを一時的な PostgreSQL Pod にコピーします。

   1. まず、Pod 名を取得し、それを環境変数として設定します。

      export AAP_TEMP_POSTGRES=$(oc get pods --no-headers -o custom-columns="metadata.name" | grep aap-temp-postgres)

   2. 環境変数をテストします。

      echo $AAP_TEMP_POSTGRES

      出力例:

      aap-temp-postgres-7b6c57f87f-s2ldp

   3. アーティファクトとチェックサムを PVC にコピーします。

      oc cp artifact.tar $AAP_TEMP_POSTGRES:/tmp/aap-temp-pvc/
      oc cp artifact.tar.sha256 $AAP_TEMP_POSTGRES:/tmp/aap-temp-pvc/

5. 一時的な PostgreSQL Pod を使用して、データベースを Ansible Automation Platform の PostgreSQL に復元します。

   1. まず、3 つのデータベースすべての PostgreSQL パスワードと PostgreSQL 管理者パスワードを取得します。

      echo "" && for secret in aap-controller-postgres-configuration aap-hub-postgres-configuration aap-gateway-postgres-configuration
      do
      echo $secret
      echo "PASSWORD: `oc get secrets $secret -o jsonpath="{.data['password']}" | base64 -d`"
      echo "USER: `oc get secrets $secret -o jsonpath="{.data['username']}" | base64 -d`"
      echo "DATABASE: `oc get secrets $secret -o jsonpath="{.data['database']}" | base64 -d`"
      echo ""
      done && echo "POSTGRES ADMIN PASSWORD: `oc get secrets aap-gateway-postgres-configuration -o jsonpath="{.data['postgres_admin_password']}" | base64 -d`"

   2. 一時的な PostgreSQL デプロイメントに入り、コピーしたアーティファクトを含むマウントされた PVC にディレクトリーを変更します。

      oc exec -it deployment.apps/aap-temp-postgres -- /bin/bash

   3. Pod 内で、ディレクトリーを /tmp/aap-temp-pvc に変更し、その内容をリスト表示します。

      cd /tmp/aap-temp-pvc && ls -l

      出力例:

      total 2240
      -rw-r--r--. 1 1000900000 1000900000 2273280 Jun 13 17:41 artifact.tar
      -rw-r--r--. 1 1000900000 1000900000      79 Jun 13 17:42 artifact.tar.sha256
      drwxrws---. 2 root       1000900000   16384 Jun 13 17:40 lost+found

   4. アーカイブを検証します。

      sha256sum --check artifact.tar.sha256

      出力例:

      artifact.tar: OK

   5. アーティファクトを抽出し、その内容を確認します。

      tar xf artifact.tar && cd artifact && sha256sum --check sha256sum.txt

      出力例:

       ./controller/controller.pgc: OK
       ./gateway/gateway.pgc: OK
       ./hub/hub.pgc: OK

   6. Automation Controller のデータベースを削除します。

      dropdb -h aap-postgres-15 automationcontroller

   7. CREATEDB ロールを使用してユーザーを一時的に変更します。

      postgres=# ALTER USER automationcontroller WITH CREATEDB;

   8. データベースを作成します。

      createdb -h aap-postgres-15 -U automationcontroller automationcontroller

   9. 一時的なユーザー権限を元に戻します。

      postgres=# ALTER USER automationcontroller NOCREATEDB;

   10. Automation Controller のデータベースを復元します。

       pg_restore --clean --create --no-owner -h aap-postgres-15 -U automationcontroller -d automationcontroller controller/controller.pgc

   11. Automation Hub のデータベースを復元します。

       pg_restore --clean --create --no-owner -h aap-postgres-15 -U automationhub -d automationhub hub/hub.pgc

   12. プラットフォームゲートウェイのデータベースを復元します。

       pg_restore --clean --create --no-owner -h aap-postgres-15 -U gateway -d gateway gateway/gateway.pgc

   13. Pod を終了します。

       exit

6. データベースフィールドの暗号化シークレットを置き換え、一時リソースをクリーンアップします。

   1. データベースフィールドの暗号化シークレットを置き換えます。

      oc set data secret/aap-controller-secret-key secret_key="<unencoded controller_secret_key value from secrets.yml>"

      oc set data secret/aap-db-fields-encryption-secret secret_key="<unencoded gateway_secret_key value from secrets.yml>"

      oc set data secret/aap-hub-db-fields-encryption database_fields.symmetric.key="<unencoded hub_db_fields_encryption_key value from secrets.yml>"

   2. 一時的な PostgreSQL と PVC をクリーンアップします。

      oc delete -f aap-temp-postgres.yaml

      oc delete -f aap-temp-pvc.yaml

7. Ansible Automation Platform コンポーネントをスケールアップして元の状態に戻します。

   1. プラットフォームゲートウェイと Automation Controller Operator をスケールアップし、プラットフォームゲートウェイ Operator のリコンシリエーションループが完了するまで待機します。

      PostgreSQL の StatefulSet がアイドル状態に戻ります。

      oc scale --replicas=1 deployment aap-gateway-operator-controller-manager automation-controller-operator-controller-manager

      出力例:

      deployment.apps/aap-gateway-operator-controller-manager scaled
      deployment.apps/automation-controller-operator-controller-manager scaled

      oc logs -f $(oc get pods  --no-headers -o custom-columns=":metadata.name" | grep aap-gateway-operator)

   2. リコンシリエーションが停止するまで待ちます。

      出力例:

      META: ending play
      {"level":"info","ts":"2025-06-12T15:41:29Z","logger":"runner","msg":"Ansible-runner exited successfully","job":"5672263053238024330","name":"aap","namespace":"aap"}
      
      ----- Ansible Task Status Event StdOut (aap.ansible.com/v1alpha1, Kind=AnsibleAutomationPlatform, aap/aap) -----
      
      
      PLAY RECAP *********************************************************************
      localhost                  : ok=45   changed=0    unreachable=0    failed=0    skipped=63   rescued=0    ignored=0

   3. idle_aap を使用して Ansible Automation Platform をスケールアップして元に戻します。

      oc patch ansibleautomationplatform aap --type=merge -p '{"spec":{"idle_aap":false}}'

      出力例:

      ansibleautomationplatform.aap.ansible.com/aap patched

8. aap-gateway Pod が実行されるまで待って、古いサービスエンドポイントをクリーンアップします。

   出力例:

   pod/aap-gateway-6c989b846c-47b91 2/2 Running 0 45s

   for i in HTTPPort Route ServiceNode; do; oc exec -it deployment.apps/aap-gateway -- aap-gateway-manage shell -c 'from aap_gateway_api.models import '$i';print('$i'.objects.all().delete())'; done

   出力例:

   (23, {'aap_gateway_api.ServiceAPIRoute': 4, 'aap_gateway_api.AdditionalRoute': 7, 'aap_gateway_api.Route': 11, 'aap_gateway_api.HTTPPort': 1})
   (0, {})
   (4, {'aap_gateway_api.ServiceNode': 4})

9. awx-manage を実行してインスタンスのプロビジョニングを解除します。

   1. Automation Controller Pod を取得します。

      export AAP_CONTROLLER_POD=$(oc get pods --no-headers -o custom-columns=":metadata.name" | grep aap-controller-task)

   2. 環境変数をテストします。

      echo $AAP_CONTROLLER_POD

      出力例:

      aap-controller-task-759b6d9759-r59q9

   3. Automation Controller Pod に入ります。

      oc exec -it $AAP_CONTROLLER_POD -- /bin/bash
      awx-manage list_instances

      出力例:

      bash-4.4$
      [controlplane capacity=642 policy=100%]
      	aap-controller-task-759b6d9759-r59q9 capacity=642 node_type=control version=4.6.15 heartbeat="2025-06-12 21:39:48"
      	node1.example.org capacity=0 node_type=hybrid version=4.6.13 heartbeat="2025-05-30 17:22:11"
      
      [default capacity=0 policy=100%]
      	node1.example.org capacity=0 node_type=hybrid version=4.6.13 heartbeat="2025-05-30 17:22:11"
      	node2.example.org capacity=0 node_type=execution version=ansible-runner-2.4.1 heartbeat="2025-05-30 17:22:08"

   4. awx-manage を使用して古いノードを削除し、aap-controller-task のみを残します。

      awx-manage deprovision_instance --host=node1.example.org
      awx-manage deprovision_instance --host=node2.example.org

10. curl コマンドを実行して、Automation Hub ファイルシステムのデータを修復します。

    curl -d '{\"verify_checksums\": true }' -X POST -k https://<aap url>/api/galaxy/pulp/api/v3/repair/ -u <admin_user>:<restored_admin_password>

手順

1. Django SECRET_KEY シークレットをソースプラットフォームに合わせて変更します。
2. プラットフォームゲートウェイのサービスノードをプロビジョニング解除し、再設定します。
3. プラットフォームゲートウェイのノードとサービスの登録ロジックを再実行します。
4. コンテナー固有の設定を OpenShift Container Platform に適した形式に変換します。
5. コンテナーリソースの割り当てを、OpenShift Container Platform のリソースに合わせて調整します。

手順

1. 移行したすべてのコンポーネントが機能していることを確認します。
2. ワークフローと自動化プロセスをテストします。
3. ユーザーのアクセスと権限を検証します。
4. コンテンツの同期と利用可能性を確認します。
5. OpenShift Container Platform 固有の機能との統合をテストします。

手順

1. Red Hat カスタマーポータルで サポートチケット を送信し、Managed Ansible Automation Platform への移行をリクエストします。

   サポートチケットには次の内容を含める必要があります。

   • 移行元のインストール環境のタイプ (RPM、コンテナー化、OpenShift)
   • Managed Ansible Automation Platform の URL またはデプロイメント名
   • 移行元のバージョン (インストーラーまたは Operator バージョン)
2. Ansible Site Reliability Engineering (SRE) チームが、サポートチケットで、作成される移行アーティファクトを処理用のセキュアなストレージにアップロードする方法に関する手順を案内します。
3. Ansible SRE チームが、特定のターゲットインスタンスに移行アーティファクトをインポートし、サポートチケットを通じてお客様に通知します。
4. Ansible SRE チームが移行の成功をお客様に通知します。

手順

1. ローカル管理者アカウントを使用して Managed Ansible Automation Platform インスタンスにログインし、データがインポートされたことを確認します。

2. ソースデプロイメントの設定に基づいて、次のアクションを実行します。

   1. 新しい URL を反映するように、シングルサインオン (SSO) オーセンティケーターとマッピングを再設定します。

   2. 新しい URL を反映するように Private Automation Hub コンテンツを更新します。

      1. 次のコマンドを実行して、Automation Hub リポジトリーを更新します。

         curl -d '{\"verify_checksums\": true }' -X POST -k https://<platform url>/api/galaxy/pulp/api/v3/repair/ -u <admin_user>:<admin_password>

      2. Automation Hub で設定されているすべてのリポジトリーで同期を実行します。
      3. 移行元の Automation Hub から移行先の Automation Hub にカスタムの実行環境をプッシュします。
   3. 自動化メッシュを再設定します。
3. 移行後、カスタム証明書、カスタムドメイン、プライベートエンドポイント経由の接続の設定など、標準の Site Reliability Engineering (SRE) タスクをサポートチケットを通じてリクエストできます。