はじめに
Ansible Automation Platform (AAP) 2.6 Containerized 環境へ Execution Node を追加した際のトラブルシューティング記録です。
AAP Self-managed Containerized 版の導入手順については、以下の記事で解説しています。
今回は既存の Automation Controller 環境に対して Execution Node を追加し、Receptor Mesh を構成しようとしました。
しかし、インストーラー実行中に以下のエラーが発生し、原因の特定にかなり時間を要しました。
Host aap-test-contrl.cloud.ibm.com is not a registered instance.
当初はインベントリや Receptor の設定ミスを疑いましたが、最終的な原因はインベントリではなく、仮想マシン複製に伴う OS の machine-id 重複でした。
本記事では、事象の発生から原因調査、対処手順、そして無事に Execution Node が追加されるまでの流れを時系列でまとめます。
- まとめ画像
環境
- Ansible Automation Platform 2.6.12
- Containerized Installation
- Controller × 1
- Execution Node × 1
- RHEL 9.6 (ppc64le)
- IBM Power S1022
構成イメージ
Controller 1台、Execution Node 1台のシンプルな Receptor Mesh 構成です。
+------------------------+
| Automation Controller |
| (Hybrid Node) |
+------------+-----------+
|
| Receptor Mesh
|
+------------+-----------+
| Execution Node |
+------------------------+
Execution Node には Controller のような Web UI や API、PostgreSQL などのコンテナ群は配置されず、Receptor コンテナのみが稼働します。
事前準備
Execution Node 側で Controller と同様に事前準備を実施します。
- 必要な RHEL モジュール導入
- AAP インストール用ユーザー作成
- Podman 導入
- Controller Node から Execution Node への SSH 接続設定
詳細は Red Hat 公式ドキュメントを参照してください。
1. SSH 接続設定（authorized_keys 登録）
Execution Node 側へ公開鍵を登録します。
$ vi /home/ansible/.ssh/authorized_keys
Controller から Execution Node へ SSH ログインできることを確認します。
$ ssh -i id_rsa_exec1 ansible@xx.xx.xx.xx
2. /etc/hosts による名前解決設定
DNS を利用しない検証環境のため、Controller と Execution Node の双方で /etc/hosts に名前解決設定を行いました。
$ cat /etc/hosts
xx.xx.xx.xx aap-test-contrl.cloud.ibm.com
yy.yy.yy.yy aap-exec1.cloud.ibm.com
双方から ping で名前解決・疎通を確認します。
$ ping aap-test-contrl.cloud.ibm.com
$ ping aap-exec1.cloud.ibm.com
3. インベントリ疎通確認
Ansible コマンドで全対象ノードへの疎通を確認します。
$ ansible all -i inventory_mcp_2 -m ping
aap-exec1.cloud.ibm.com | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
aap-test-contrl.cloud.ibm.com | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
両ノードとも正常に応答しました。
Receptor Mesh のインベントリ設定
Containerized Installer で Execution Node を追加する場合、インベントリに execution_nodes グループを追加し、ピアリング対象となる receptor_peers を設定します。
また、Controller 単体構成で利用していた ansible_connection=local はコメントアウトします。リモートホスト（Execution Node）へ SSH 接続してプロビジョニングを実行する必要があるためです。
インベントリ差分
[ansible@aap-test-contrl install]$ diff inventory_mcp_1 inventory_mcp_2
22a23,26
> [execution_nodes]
> aap-exec1.cloud.ibm.com receptor_type=execution receptor_peers='["aap-test-contrl.cloud.ibm.com"]'
>
>
29c33
< ansible_connection=local
---
> #ansible_connection=local
参考：単体構成時の初期インベントリ（inventory_mcp_1）
# -----------------------------------------------------
# ホストグループ定義
# -----------------------------------------------------
[automationgateway]
aap-test-contrl.cloud.ibm.com
[automationcontroller]
aap-test-contrl.cloud.ibm.com
[automationhub]
aap-test-contrl.cloud.ibm.com
[automationeda]
aap-test-contrl.cloud.ibm.com
[database]
aap-test-contrl.cloud.ibm.com
[ansiblemcp]
aap-test-contrl.cloud.ibm.com
# -----------------------------------------------------
# 共通変数 [all:vars]
# -----------------------------------------------------
[all:vars]
# Ansible
ansible_connection=local
# Model Context Protocol 設定
mcp_allow_write_operations=true
# --- postgresql認証設定 ---
postgresql_admin_username=postgres
postgresql_admin_password=xxxxx
# --- レジストリ認証設定 ---
registry_username='test'
registry_password='test'
# --- インストール形式 (Bundle版) ---
bundle_install=true
bundle_dir='{{ lookup("ansible.builtin.env", "PWD") }}/bundle'
# Redis設定
redis_mode=standalone
# --- AAP Gateway 設定 ---
gateway_admin_password=xxxxx
gateway_pg_host="aap-test-contrl.cloud.ibm.com"
gateway_pg_password=xxxxx
# --- AAP Controller 設定 ---
controller_admin_password=xxxxx
controller_pg_host="aap-test-contrl.cloud.ibm.com"
controller_pg_password=xxxxx
controller_percent_memory_capacity=0.5
# --- AAP Automation Hub 設定 ---
hub_admin_password=xxxxx
hub_pg_host="aap-test-contrl.cloud.ibm.com"
hub_pg_password=xxxxx
hub_seed_collections=false
# --- AAP EDA Controller 設定 ---
eda_admin_password=xxxxx
eda_pg_host="aap-test-contrl.cloud.ibm.com"
eda_pg_password=xxxxx
発生したエラー
Execution Node を定義したインベントリ（inventory_mcp_2）を指定してインストーラーを実行しました。
$ ansible-playbook -i inventory_mcp_2 ansible.containerized_installer.install
しかし、タスクの途中で以下のエラーが発生して停止してしまいました。
Host aap-test-contrl.cloud.ibm.com is not a registered instance.
当初は以下の原因を疑いました。
- インベントリの記述ミス（グループ名や変数定義）
- Receptor Mesh のピア設定ミス（
receptor_peersの指定方法） - SSH 接続や権限の問題
- DNS / hosts の名前解決の問題
しかし、接続や設定を見直しても誤りは見当たりません。
原因調査
1. DB 上のインスタンス情報を確認
Controller 単体構成時の PostgreSQL データベース（main_instance テーブル）を確認したところ、以下のように Controller が hybrid ノードとして登録されていました。
$ podman exec -it postgresql psql -U awx awx \
-c "select id,uuid,hostname,node_type from main_instance;"
id | uuid | hostname | node_type
----+--------------------------------------+-------------------------------+-----------
1 | 59103087-bb8c-5859-b219-2b42866ee17f | aap-test-contrl.cloud.ibm.com | hybrid
(1 row)
ところが、Execution Node 追加の Playbook を流した直後に同じテーブルを確認すると、状態が一変していました。
$ podman exec -it postgresql psql -U awx awx \
-c "select id,uuid,hostname,node_type from main_instance;"
id | uuid | hostname | node_type
----+--------------------------------------+-------------------------------+-----------
1 | 59103087-bb8c-5859-b219-2b42866ee17f | aap-exec1.cloud.ibm.com | execution
(1 row)
レコードが 2 行に増えるのではなく、UUID（59103087-...）と ID（1）はそのままに、hostname と node_type が Execution Node の情報で上書きされていました。
これにより、Controller 自身のインスタンスレコードが DB 上から消失してしまい、後続タスクで Controller を探した際に Host aap-test-contrl.cloud.ibm.com is not a registered instance. が発生していたことが判明しました。
2. machine-id の確認
AAP がホストを識別・UUID 生成するキーとして、OS の /etc/machine-id が関わっていると推測し、両ホストの値を確認しました。
- Controller Node:
$ cat /etc/machine-id
b2a2fd3cfe354ad794b59adca520cbe9
- Execution Node:
$ cat /etc/machine-id
b2a2fd3cfe354ad794b59adca520cbe9
Ansible の Fact 収集でも確認してみます。
$ ansible -i inventory_mcp_2 all -m setup -a 'filter=ansible_machine_id'
aap-exec1.cloud.ibm.com | SUCCESS => {
"ansible_facts": {
"ansible_machine_id": "b2a2fd3cfe354ad794b59adca520cbe9",
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false
}
aap-test-contrl.cloud.ibm.com | SUCCESS => {
"ansible_facts": {
"ansible_machine_id": "b2a2fd3cfe354ad794b59adca520cbe9",
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false
}
両ノードの machine-id が完全に一致していました。
今回の環境では、同一の VM テンプレート（イメージ）から Controller と Execution Node をクローンして作成しており、OS 展開後に machine-id の再生成を行っていなかったことが原因でした。
3. machine-id 重複による影響のメカニズム
Controller 稼働中 (UUID: 59103087-...)
↓
Execution Node 追加インストーラー実行
↓
machine-id が Controller と同一のため「同一ノードの更新」と判定
↓
既存の Instance レコード (id=1) を Execution Node 情報で上書き
↓
DB から Controller のホスト情報が消失
↓
「Host aap-test-contrl.cloud.ibm.com is not a registered instance.」で失敗
エラーメッセージからは Receptor やインベントリの記述不整合に見えますが、根本原因は OS レベルでの識別子重複 でした。
対処：machine-id の再生成
Execution Node 側で既存の machine-id を退避し、systemd-machine-id-setup コマンドで新しい ID を再生成します。
[ansible@aap-exec1 ~]$ sudo mv /etc/machine-id /etc/machine-id_bk
[ansible@aap-exec1 ~]$ sudo systemd-machine-id-setup
Initializing machine ID from random generator.
[ansible@aap-exec1 ~]$ cat /etc/machine-id
70d1c04103aa4a2aa2e4093784a2257d
Ansible 経由で、Controller と Execution Node の machine-id が別々の値になったことを確認します。
$ ansible -i inventory_mcp_2 all -m setup -a 'filter=ansible_machine_id'
aap-test-contrl.cloud.ibm.com | SUCCESS => {
"ansible_facts": {
"ansible_machine_id": "b2a2fd3cfe354ad794b59adca520cbe9",
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false
}
aap-exec1.cloud.ibm.com | SUCCESS => {
"ansible_facts": {
"ansible_machine_id": "70d1c04103aa4a2aa2e4093784a2257d",
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false
}
これで各ホストが一意の識別子を持つ状態になりました。
再実行と結果確認
1. インストーラーの再実行
machine-id の解消後、再度インストーラーを実行します。
$ ansible-playbook -i inventory_mcp_2 ansible.containerized_installer.install
~ 省略 ~
TASK [Delete the ansible base shared secret] *******************************************************************************************************************************************************************************
ok: [aap-test-contrl.cloud.ibm.com]
PLAY RECAP *****************************************************************************************************************************************************************************************************************
aap-exec1.cloud.ibm.com : ok=105 changed=15 unreachable=0 failed=0 skipped=94 rescued=0 ignored=0
aap-test-contrl.cloud.ibm.com : ok=654 changed=40 unreachable=0 failed=0 skipped=309 rescued=0 ignored=0
localhost : ok=40 changed=0 unreachable=0 failed=0 skipped=62 rescued=0 ignored=0
エラーなく正常に完了しました。
2. コンテナ稼働状態の確認
-
Controller Node
Controller 側では各種 AAP コンテナ群が稼働しています。
$ podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
928b26b235cb registry.redhat.io/rhel9/postgresql-15:latest run-postgresql About an hour ago Up About an hour 5432/tcp postgresql
98c671e4ef6d registry.redhat.io/rhel9/redis-6:latest run-redis About an hour ago Up About an hour 6379/tcp redis-unix
12d3259c58db registry.redhat.io/rhel9/redis-6:latest run-redis About an hour ago Up 17 minutes 6379/tcp redis-tcp
c8a92fe10fab registry.redhat.io/ansible-automation-platform-26/receptor-rhel9:latest /usr/bin/receptor... About an hour ago Up 28 minutes receptor
19a436313af3 registry.redhat.io/ansible-automation-platform-26/controller-rhel9:latest /usr/bin/launch_a... About an hour ago Up About an hour 8052/tcp automation-controller-rsyslog
fc4b7123dcdf registry.redhat.io/ansible-automation-platform-26/controller-rhel9:latest /usr/bin/launch_a... About an hour ago Up About an hour 8052/tcp automation-controller-task
2d2b4cb57977 registry.redhat.io/ansible-automation-platform-26/controller-rhel9:latest /usr/bin/launch_a... About an hour ago Up About an hour 8052/tcp automation-controller-web
1fbdaa4da0b3 registry.redhat.io/ansible-automation-platform-26/eda-controller-rhel9:latest gunicorn --bind 1... About an hour ago Up About an hour automation-eda-api
54c3fa4147bc registry.redhat.io/ansible-automation-platform-26/eda-controller-rhel9:latest daphne --bind 127... About an hour ago Up About an hour automation-eda-daphne
6b5a05821050 registry.redhat.io/ansible-automation-platform-26/eda-controller-ui-rhel9:latest /bin/sh -c nginx ... About an hour ago Up About an hour 8080/tcp, 8443/tcp automation-eda-web
5fd6d42c66f9 registry.redhat.io/ansible-automation-platform-26/eda-controller-rhel9:latest aap-eda-manage rq... About an hour ago Up About an hour automation-eda-worker-1
762aef1a2995 registry.redhat.io/ansible-automation-platform-26/eda-controller-rhel9:latest aap-eda-manage rq... About an hour ago Up About an hour automation-eda-worker-2
695954f3920c registry.redhat.io/ansible-automation-platform-26/eda-controller-rhel9:latest aap-eda-manage rq... About an hour ago Up About an hour automation-eda-activation-worker-1
961e8cea1431 registry.redhat.io/ansible-automation-platform-26/eda-controller-rhel9:latest aap-eda-manage rq... About an hour ago Up About an hour automation-eda-activation-worker-2
97110214af0b registry.redhat.io/ansible-automation-platform-26/eda-controller-rhel9:latest aap-eda-manage sc... About an hour ago Up About an hour automation-eda-scheduler
ad234aad4183 registry.redhat.io/ansible-automation-platform-26/hub-rhel9:latest pulpcore-api --na... About an hour ago Up 54 minutes automation-hub-api
fdf3646c96e6 registry.redhat.io/ansible-automation-platform-26/hub-rhel9:latest pulpcore-content ... 57 minutes ago Up 54 minutes automation-hub-content
c922a9d2b8a5 registry.redhat.io/ansible-automation-platform-26/hub-web-rhel9:latest /bin/sh -c nginx ... 57 minutes ago Up 54 minutes 8080/tcp, 8443/tcp automation-hub-web
237646f1275c registry.redhat.io/ansible-automation-platform-26/hub-rhel9:latest pulpcore-worker 56 minutes ago Up 54 minutes automation-hub-worker-1
913f37f1f82e registry.redhat.io/ansible-automation-platform-26/hub-rhel9:latest pulpcore-worker 56 minutes ago Up 54 minutes automation-hub-worker-2
f965dcd496e0 registry.redhat.io/ansible-automation-platform-tech-preview/mcp-server-rhel9:latest /entrypoint.sh 54 minutes ago Up 52 minutes 8080/tcp, 8086/tcp ansiblemcp
7314ed21ebcb registry.redhat.io/ansible-automation-platform-26/gateway-proxy-rhel9:latest /usr/bin/envoy --... 16 minutes ago Up 16 minutes automation-gateway-proxy
03c9058642dc registry.redhat.io/ansible-automation-platform-26/gateway-rhel9:latest /usr/bin/supervis... 16 minutes ago Up 16 minutes automation-gateway
-
Execution Node
Execution Node では意図通り Receptor コンテナのみが稼働しています。
$ podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
608f36f58bdb registry.redhat.io/ansible-automation-platform-26/receptor-rhel9:latest /usr/bin/receptor... 29 minutes ago Up 15 minutes receptor
3. AAP GUI Topology View の確認
AAP Web UI の Administration → Instances を確認すると、以下の通り両ノードが正しく認識されています。
-
aap-test-contrl.cloud.ibm.com(hybrid) -
aap-exec1.cloud.ibm.com(execution)
Controller から Execution Node への Receptor Mesh リンクが構成され、正常に追加されたことが確認できました。
まとめ
AAP 2.6 Containerized 環境への Execution Node 追加自体は、インベントリに execution_nodes を追記してインストーラーを実行するだけのシンプルな操作です。
しかし今回のように、VM 複製による machine-id の重複があると、データベース上でインスタンス情報が上書きされ、一見して原因が分かりづらいエラー（Host ... is not a registered instance.）を引き起こします。
特に以下のような手順でノードを用意した場合は注意が必要です。
- 仮想マシンテンプレートからのクローン
- PowerVC / クラウドイメージからの複製
- LPAR クローン
- バックアップイメージからの復元
ノード追加前に以下のコマンドで machine-id の一意性を確認しておくことを強くお勧めします。
# 全ノードの machine-id 一括確認
$ ansible all -m setup -a 'filter=ansible_machine_id'
# 重複していた場合の再生成手順（対象ノード上で実行）
$ sudo mv /etc/machine-id /etc/machine-id_bk
$ sudo systemd-machine-id-setup
もし同様のインスタンス未登録エラーに遭遇した際は、インベントリだけでなく OS の machine-id を疑ってみてください。
参照ドキュメント
- Add execution nodes (Red Hat Documentation)
- How to Add Execution Node(s) to existing Ansible Automation Platform (Red Hat Customer Portal)
- Configure the inventory file
- Design patterns for mesh