【AnsibleAutomationPlatform 】RPM版からコンテナ版へのマイグレーション

はじめに

今年リリースされたAAP2.6より、RPM版AAPからコンテナ版AAPへの移行パスが公開されました。
本記事は、ドキュメントの手順で移行を試した検証ログです。

基本ドキュメント通りに進めますが、一部ドキュメントで提示されている手順をスキップしている箇所があるため、あくまで一例としてご覧ください。

背景

現在、AAPをRHELにインストールする方式として、2種類存在します。

1. RHEL自身に直接パッケージを入れてインストールを行う通称RPM版
2. AAPのコンポーネントをコンテナ上に展開するコンテナ版

従来はRPM版が主流でしたが、今後はコンテナ版が主流になるようで、AAP2.7からはRPM版が削除されるとアナウンスされています。

コンテナ版が初めてGAとなったAAP2.5ではRPM版からコンテナ版への移行パスがTechnology previewだったため、新規で構築する必要がありました。
今年AAP2.6がリリースされたタイミングでRPM版からコンテナ版への移行パスがGAとなり、公式にサポートされる形になりました。

サポートされているアップグレードシナリオとしてはこちらのページを参照してください。

検証環境

環境としてはVMを3台使用しました。
基盤：Proxmox 8

VM名	OS	Hostname	CPU	RAM
AAP26-RPM	RHEL9.6	aap-server-rpm	2core	4GB
AAP26-GW	RHEL9.6	aap-gateway	2core	4GB
AAP26-CTR	RHEL9.6	aap-server	2core	16GB

使用したインストーラは以下の通りです。

バージョン	形式	ファイル名
AAP2.4	RPM	ansible-automation-platform-setup-2.4-13.tar.gz
AAP2.6	RPM	ansible-automation-platform-setup-2.6-1.tar.gz
AAP2.6	コンテナ	ansible-automation-platform-containerized-setup-2.6-1.tar.gz

移行シナリオ

今回の主題はRPM版からコンテナ版への移行ですが、個人的にAAP2.4 -> AAP2.6のアップデート込みで検証したかったため、以下の流れで検証を行います。

1. AAP2.4のインストール(RPM版)
2. AAP2.4からAAP2.6へのアップグレード(RPM版)
3. AAP2.6(RPM版)からAAP2.6(コンテナ版)への移行

※AAP2.6のコンテナ版はRHEL9以上のみ対応のため、AAP2.4がRHEL8などで動いている場合は、まずRHEL9以上への移行が必要になります。

1. AAP2.4のインストール(RPM版)

移行元となるAAP2.4を作成します。
今回は簡単な検証のみのためHubやEDAは入れない構成とします。
操作対象VM: AAP26-RPM

使用したインベントリファイル

inventory

[automationcontroller]
aap-server-rpm.internal ansible_connection=local ansible_become=true

[automationcontroller:vars]
peers=execution_nodes

[execution_nodes]

[automationhub]

[automationedacontroller]

[database]

[sso]

[all:vars]
admin_password='<pass>'

pg_host=''
pg_port=5432

pg_database='awx'
pg_username='awx'
pg_password='<pass>'
pg_sslmode='prefer'  # set to 'verify-full' for client-side enforced SSL

registry_url='registry.redhat.io'
registry_username='<user>'
registry_password='<pass>'

インストールコマンド

./setup.sh

PLAY RECAP *********************************************************************
aap-server-rpm.internal    : ok=362  changed=157  unreachable=0    failed=0    skippe                                               d=236  rescued=0    ignored=6
localhost                  : ok=0    changed=0    unreachable=0    failed=0    skippe                                               d=1    rescued=0    ignored=0

The setup process completed successfully.

AAP2.4の設定

デフォルト状態のまま移行しても成功したか分かりづらいため、設定を入れていきます。
新規ジョブテンプレートを作成

新規ユーザを追加

移行後はこれらの設定が存在するかどうかで、移行できているかを確認します。

2. AAP2.6へのアップグレード(RPM版)

操作対象VM: AAP26-RPM AAP26-GW
RPM版からコンテナ版に移行するには、移行元と移行先のバージョンを合わせる必要があるため、RPM版のAAP2.6にアップグレードします。

AAP2.5より登場したコンポーネントであるautomation gateway(以下ゲートウェイ)はコントローラーと別のホストである必要があるため、ゲートウェイ用にVMを用意します。

使用したインベントリファイル

inventory-growth

[automationgateway]
aap-gateway.internal ansible_user=<user> ansible_password=<pass> ansible_become=true

[automationcontroller]
aap-server-rpm.internal ansible_connection=local ansible_become=true

[automationcontroller:vars]
peers=execution_nodes

[execution_nodes]

[automationhub]

[automationedacontroller]

[database]
aap-server-rpm.internal ansible_connection=local ansible_become=true

[all:vars]
registry_username=<user>
registry_password=<pass>

redis_mode='standalone'

automationgateway_admin_password=<pass>
automationgateway_pg_host=aap-server-rpm.internal
automationgateway_pg_password=<pass>

admin_password=<pass>
pg_host=aap-server-rpm.internal
pg_password=<pass>

インストールコマンド
./setup.sh -i inventory-growth

PLAY RECAP *********************************************************************
aap-gateway.internal       : ok=182  changed=23   unreachable=0    failed=0    skipped=187  rescued=0    ignored=1
aap-server-rpm.internal    : ok=376  changed=77   unreachable=0    failed=0    skipped=288  rescued=0    ignored=1
localhost                  : ok=0    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

The setup process completed successfully.

弊環境で発生したエラー

原因は不明ですが（私の環境固有の問題かもしれませんが）、アップグレード中に特定のタスクで失敗するケースがありました。 該当タスクとしては、シークレットを作成する以下のタスクです。

TASK [ansible.automation_platform_installer.automationgateway : Generate service secret] ***

エラーログとしてはDBへ接続できない旨のログが表示されました。
接続できなかった原因としてはpostgresのサービスが停止していたためです。
postgresサービスを起動してから再度インストーラを流すと、インストールが完了しました。

設定確認 & 動作確認

2.4時代の設定が存在するか、またジョブが実行できるかを確認します。

設定があることを確認。

ジョブが実行できることも確認。

3. AAP2.6(RPM版)からAAP2.6(コンテナ版)への移行

操作対象VM: AAP26-CTR
いよいよ本題のRPM版からコンテナ版への移行を行います。
RPM版と違い、コンテナ版では1台のホストにすべてのコンポーネントを展開できるため、VMは1台だけ用意します。

移行元での準備

移行元ではpg_dumpによるデータベース出力とシークレット情報の取得を行います。

※ドキュメントには、環境が移行できる状態かを確認する手順や、バックアップの実施などが含まれていますが、本記事では移行に必要な手順だけ記載しています。
実際に作業される際はドキュメントを参照してください。

作業用ディレクトリを作成し、移動します。

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

DBの出力

pg_dumpでコンポーネントごとのDB情報を抜き出します。
今回は最小構成なのでコントローラーとゲートウェイのみです。

pg_dump -h aap-server-rpm.internal -U awx -d awx --clean --create -Fc -f controller/controller.pgc
pg_dump -h aap-server-rpm.internal -U automationgateway -d automationgateway --clean --create -Fc -f gateway/gateway.pgc

シークレットファイルの作成

既存環境のDB名や、シークレット情報を含んだシークレットファイルの作成します。

touch /tmp/backups/artifact/secrets.yml

シークレットファイルの中身としては、以下のような形です。(ドキュメントより)

secrets.yml

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_db_fields_encryption_key: <redacted>

それぞれの値を取得していきます。
controller_secret_keyはコントローラーが立っているホストで以下のファイルを確認します。

cat /etc/tower/SECRET_KEY

gateway_secret_keyはゲートウェイが立っているホストで以下のファイルを確認します。

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

DB名はpsqlでDBにアクセスすれば確認できます。

[holtit@aap-server-rpm artifact]$ psql -h aap-server-rpm.internal -U awx
Password for user awx:
psql (15.14)
Type "help" for help.

awx=> \l
                                                          List of databases
       Name        |       Owner       | Encoding |   Collate   |    Ctype    | ICU L
ocale | Locale Provider |   Access privileges
-------------------+-------------------+----------+-------------+-------------+------
------+-----------------+-----------------------
 automationgateway | automationgateway | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
      | libc            |
 awx               | awx               | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
      | libc            |
 postgres          | postgres          | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
      | libc            |
 template0         | postgres          | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
      | libc            | =c/postgres          +
                   |                   |          |             |             |
      |                 | postgres=CTc/postgres
 template1         | postgres          | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
      | libc            | =c/postgres          +
                   |                   |          |             |             |
      |                 | postgres=CTc/postgres
(5 rows)

コントローラーのDB名はawx、ゲートウェイのDB名はautomationgatewayであることが確認できました。

これらを記入すればsecrets.ymlは完成です。

secrets.yml

controller_pg_database: awx
controller_secret_key: <controller_secret_key>
gateway_pg_database: automationgateway
gateway_secret_key: <gateway_secret_key>

その他、カスタム設定やHub、EDA込みなら他にも必要な手順がありますが、今回は不要なのでスキップします。

ファイルの確認

各種ファイル作成後のディレクトリ構造としては以下の形となりました。

[holtit@aap-server-rpm artifact]$ ls -R
.:
controller  gateway  hub  secrets.yml

./controller:
controller.pgc  custom_configs

./controller/custom_configs:

./gateway:
gateway.pgc

./hub:

ファイルの転送

移行元の準備は完了したので、上記のディレクトリを移行先のサーバに転送します。
ドキュメントではtarballにまとめたり、チェックサムの確認など行っていますが、今回はディレクトリごと転送します。

scp -r /tmp/backups/artifact [e-mail]:~

移行先での作業

移行先での作業としては以下の流れとなります。

1. コンテナ版AAPをインストール
2. RPM版AAPのDBをリストア
3. 微調整

1. コンテナ版AAPをインストール

通常のコンテナ版インストールと同じようにインストールを行います。
インストール時には移行元で作成したシークレットファイルを使用します。
これにより、使用するDB名やシークレットを移行元環境と同じにすることができます。

ということで、使用したインベントリはこちらです。

[automationgateway]
aap-server.internal

[automationcontroller]
aap-server.internal

[automationhub]

[automationeda]

[database]
aap-server.internal

[all:vars]
ansible_connection=local

postgresql_admin_username=postgres
postgresql_admin_password=<pass>

registry_username=<user>
registry_password=<pass>

redis_mode=standalone

gateway_admin_password=<pass>
gateway_pg_host=aap-server.internal
gateway_pg_password=<pass>

controller_admin_password=<pass>
controller_pg_host=aap-server.internal
controller_pg_password=<pass>
controller_percent_memory_capacity=0.5

インストールコマンド

ansible-playbook -i inventory-growth ansible.containerized_installer.install -e @~/artifact/secrets.yml

シークレットファイルを変数ファイルとして読み込むため-e @~/artifact/secrets.ymlとします。
※移行元から持ってきたartifactディレクトリは、できる限りホームディレクトリに配置してください。後続の手順でもホームディレクトリに配置されていることが前提になっています。

PLAY RECAP **************************************************************************
aap-server.internal        : ok=408  changed=142  unreachable=0    failed=0    skipped=206  rescued=0    ignored=0
localhost                  : ok=20   changed=0    unreachable=0    failed=0    skipped=31   rescued=0    ignored=0

2. RPM版AAPのDBをリストア

リストア作業用にDB以外のコンテナを停止します。
今回はすべてのコンポーネントを同一VM上に展開しているため同一ホストで以下を実行します。

systemctl --user stop automation-controller-task automation-controller-web automation-controller-rsyslog
systemctl --user stop receptor
systemctl --user stop automation-gateway automation-gateway-proxy
systemctl --user stop redis-unix redis-tcp

次はDBのリストアを行います。
直接DBコンテナにアクセスするのではなく、操作用の一時コンテナを使用する方法がドキュメントに記載されています。
必要なファイルをマウントするコマンドが用意されているため、これを使用します。

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

操作用コンテナに入ったらpostgresへアクセスします。

psql -h aap-server.internal -U postgres

この時、念のためDB名を確認します。
確認するポイントとしてはゲートウェイのDB名です。
コンテナ版AAPがデフォルトで使用するゲートウェイ用DB名はgatewayです。
今回はRPM版と合わせるためにシークレットファイル内でDB名を指定しているため、automationgatewayとなっているはずです。

postgres=# \l
                                                    List of databases
       Name        |  Owner   | Encoding |  Collate   |   Ctype    | ICU Locale | Loc
ale Provider |   Access privileges
-------------------+----------+----------+------------+------------+------------+----
-------------+-----------------------
 automationgateway | gateway  | UTF8     | en_US.utf8 | en_US.utf8 |            | lib
c            |
 awx               | awx      | UTF8     | en_US.utf8 | en_US.utf8 |            | lib
c            |
 postgres          | postgres | UTF8     | en_US.utf8 | en_US.utf8 |            | lib
c            |
 template0         | postgres | UTF8     | en_US.utf8 | en_US.utf8 |            | lib
c            | =c/postgres          +
                   |          |          |            |            |            |
             | postgres=CTc/postgres
 template1         | postgres | UTF8     | en_US.utf8 | en_US.utf8 |            | lib
c            | =c/postgres          +
                   |          |          |            |            |            |
             | postgres=CTc/postgres
(5 rows)

リストアを行うための権限を付与します。

ALTER ROLE awx WITH CREATEDB;
ALTER ROLE gateway WITH CREATEDB;

postgresから抜け、ディレクトリを移動します。

\q
cd /var/lib/pgsql/backups/

移行元から持ってきたダンプファイルを使ってリストアを行います。

pg_restore --clean --create --no-owner -h aap-server.internal -U awx -d template1 controller/controller.pgc
pg_restore --clean --create --no-owner -h aap-server.internal -U gateway -d template1 gateway/gateway.pgc

何もエラー出力がなくプロンプトが返ってくればリストア完了です。

再度postgresに入り、付与した権限を消しておきます。

psql -h aap-server.internal -U postgres
ALTER ROLE awx WITH NOCREATEDB;
ALTER ROLE gateway WITH NOCREATEDB;

作業用コンテナから抜けて、停止していたコンテナ群を起動します。

systemctl --user start automation-controller-task automation-controller-web automation-controller-rsyslog
systemctl --user start receptor
systemctl --user start automation-gateway automation-gateway-proxy
systemctl --user start redis-unix redis-tcp

3. 微調整

以上の手順でDBのリストアまでは完了していますが、この段階ではAAPとして動作させることはできません。

このままだと、コントローラーとゲートウェイ間の通信ができないため、古い情報をDBから削除します。

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()
exit()
exit

この時点でAAPの再インストールを行います。
最初にインストールを行った時と同じインベントリ、シークレットファイルを使用してインストールを行います。

ansible-playbook -i inventory-growth ansible.containerized_installer.install -e @~/artifact/secrets.yml

PLAY RECAP **********************************************************************************************************************
aap-server.internal        : ok=385  changed=26   unreachable=0    failed=0    skipped=223  rescued=0    ignored=0
localhost                  : ok=20   changed=0    unreachable=0    failed=0    skipped=31   rescued=0    ignored=0

ノード間通信の確認

再インストールが完了したら、コンポーネント間が正しく通信できているかを確認します。

podman exec -it automation-controller-task bash
awx-manage list_instances

以下のような出力が返ってくればOKです。

[default capacity=56]
aap-server.internal capacity=56 node_type=hybrid version=4.7.4 heartbeat="2025-10-31 05:00:54"
[controlplane capacity=56]
aap-server.internal capacity=56 node_type=hybrid version=4.7.4 heartbeat="2025-10-31 05:00:54"

もしcapacityが0になっているノードがある場合、該当ノードを削除し正しいノードの再登録が必要になります。
私の環境では0になるノードが出てこなかったため、割愛します。

GUIでの動作確認

ここまでの手順で移行作業は完了したため、正常にAAPが動作しているかを確認します。

まずはAAP2.4時代に作成したジョブテンプレートとユーザが存在することを確認します。

続いてジョブが実行できるかも確認します。

ジョブテンプレートやユーザが存在していて、ジョブも実行できるため移行が成功していることが確認できました。

おわりに

RPM版AAPからコンテナ版AAPへの移行について試してみました。
EDAもHubもない簡単な構成ですが、移行させることができました。

(バックアップファイルに互換性ができてインストーラだけで完結するものかと思っていたので、想像より面倒だったのが本音です。)

参考