5 クラスタ化デプロイメントへのOracle Linux Automation Managerのインストール
この章では、Oracle Linux Automation Managerマルチホスト・デプロイメントでホストを準備する方法について説明します。ホストを準備する際には、Oracle Linux Automation Managerソフトウェア・パッケージをインストールし、Oracle Linux Automation Managerサービス・メッシュの一部として構成する必要があります。コントロール・プレーン・ノードと実行プレーン・ノードを構成および起動する前に、サービス・メッシュ・ノードを構成して起動します。
コントロール・プレーン・サービス・メッシュの構成と起動
/etc/receptor/receptor.conf
ファイルを編集します。このファイルには、次の要素が含まれています:
- ノードID: ノードIDは、ホストのIPアドレスまたはホスト名である必要があります。
- log-level: 使用可能なオプションは、Error、Warning、InfoおよびDebugです。ログ・レベル・オプションは、ログの冗長性を高めます。Errorでは最も少ない情報が生成され、Debugでは最も多くの情報が生成されます。
- tcp-listener port: これは、他のノードで構成された着信TCPピア接続をノードがリスニングするポートです。たとえば、ノードIDがポート27199をリスニングするコントロール・ノードを表している場合、このコントロール・ノードへの接続を確立しようとする他のすべてのノードは、
/etc/receptor/receptor.conf
ファイルのtcp-peer要素でポート27199を指定する必要があります。 - control-service: クラスタ内のすべてのノードは、ステータスを報告し、作業を開始および監視するコントロール・サービスを実行します。
- work-command: この要素は、ノードで実行できる作業のタイプを定義します。コントロール・プレーン・ノードの場合、作業のタイプは常にLocalです。この要素が実行するコマンドは、Ansible Runnerツールです。これは、AnsibleおよびAnsibleプレイブック・タスクを実行するための抽象化レイヤーを提供し、ステータスおよびイベント・データを他のシステムに送信するように構成できます。Ansible Runnerの詳細は、https://ansible-runner.readthedocs.io/en/stable/を参照してください。
コントロール・プレーン・ノードとして使用する各ホストで、次を実行します:
-
レセプタのデフォルト構成をすべて削除し、
/etc/receptor/receptor.conf
を編集して、次のコントロール・プレーン固有の構成情報を追加します:--- - node: id: <IP address or host name> - log-level: info - tcp-listener: port: <port_number> - control-service: service: control filename: /var/run/receptor/receptor.sock - work-command: worktype: local command: /var/lib/ol-automation-manager/venv/awx/bin/ansible-runner params: worker allowruntimeparams: true verifysignature: false
前述の例では、IP address or hostnameはノードのIPアドレスまたはホスト名、port_numberはこのノードがリスニングするポート番号です。たとえば、control1-192.0.121.28のように、ノード名とノードのIPアドレスを指定して設定できます。また、ポート27199でリスニングするtcp-listenerリストを構成できます。コントロール・プレーン・ノードでは、worktypeパラメータは
local
である必要があります。 - Oracle Linux Automation Managerメッシュ・サービスを起動します。
sudo systemctl start receptor-awx
- サービス・メッシュを確認します。詳細は、「クラスタ・ノードのサービス・メッシュ・ステータスの表示」を参照してください。
ノート:
プロセスのこの段階では、サービス・メッシュ・ノード間のピア関係はまだ確立されていません。ステータス情報は、サービス・メッシュを実行している個々のサーバーについてのみ存在します。
実行プレーン・サービス・メッシュの構成と起動
/etc/receptor/receptor.conf
ファイルを編集します。このファイルには、次の要素が含まれています:
- ノードID: ノードIDは、ホストのIPアドレスまたはホスト名である必要があります。
- log-level: 使用可能なオプションは、Error、Warning、InfoおよびDebugです。ログ・レベル・オプションは、ログの冗長性を高めます。Errorでは最も少ない情報が生成され、Debugでは最も多くの情報が生成されます。
- tcp-listener port: これは、他のノードで構成された着信TCPピア接続をノードがリスニングするポートです。たとえば、ノードIDがポート27199をリスニングする実行ノードを表している場合、この実行ノードへの接続を確立しようとする他のすべてのノードは、
/etc/receptor/receptor.conf
ファイルのtcp-peer要素でポート27199を指定する必要があります。 - tcp-peer: この要素には、接続先のホストのホスト名とポート番号を含める必要があります。たとえば、この実行ノードが冗長性を確保するために複数のコントロール・プレーン・ノードに接続する必要がある場合、実行ノードが接続するコントロール・プレーン・ノードごとにtcp-peer要素を追加する必要があります。addressフィールドには、コントロール・プレーン・ノードのホスト名またはIPアドレスと、それに続くポート番号を入力します。redial要素が有効になっている場合、接続が失敗した場合にホストへの接続を定期的に再確立しようとします。
また、サービス・メッシュ・トポロジの要件に基づいて、他の実行ノードまたはホップ・ノードのホスト名とポート番号を含めるようにtcp-peer要素を構成することもできます。
- control-service: クラスタ内のすべてのノードは、ステータスを報告し、作業を開始および監視するコントロール・サービスを実行します。
- work-command: この要素は、ノードで実行できる作業のタイプを定義します。実行プレーン・ノードの場合、work typeは
ansible-runner
です。この要素が実行するコマンドは、Ansible Runnerツールです。これは、AnsibleおよびAnsibleプレイブック・タスクを実行するための抽象化レイヤーを提供し、ステータスおよびイベント・データを他のシステムに送信するように構成できます。Ansible Runnerの詳細は、https://ansible-runner.readthedocs.io/en/stable/を参照してください。
実行プレーン・ノードとして使用する各ホストで、次を実行します:
-
レセプタのデフォルト構成をすべて削除し、
/etc/receptor/receptor.conf
を編集して、次の実行プレーン固有の構成情報を追加します:--- - node: id: <IP address or hostname> - log-level: debug - tcp-listener: port: <port_number> - tcp-peer: address: <hostname or IP address>:<target_port_number> redial: true - tcp-peer: address: <hostname or IP address>:<target_port_number> redial: true - control-service: service: control filename: /var/run/receptor/receptor.sock - work-command: worktype: ansible-runner command: /var/lib/ol-automation-manager/venv/awx/bin/ansible-runner params: worker allowruntimeparams: true verifysignature: false
前述の例では次のようになります。
- IP address or hostnameはノードのIPアドレスまたはホスト名です。
- port_numberは、このノードがリスニングしているポート番号です。
- target_portは、このノードが接続するように構成するピア・ノードのポート番号です。
- hostname or IP addressは、接続先の実行ノード、コントロール・ノードまたはホップ・ノードのホスト名またはIPアドレスです。
- worktypeパラメータは、実行プレーン・ノードでは
ansible-runner
である必要があります。
実行環境が複数のコントロール・ノード、実行ノードまたはホップ・ノードに関連付けられている場合は、実行ホストが関連付けられているインスタンスに対して
- tcp-peer:
で他のノードを入力します。 - Oracle Linux Automation Managerメッシュ・サービスを起動します。
sudo systemctl start receptor-awx
- サービス・メッシュを確認します。詳細は、「クラスタ・ノードのサービス・メッシュ・ステータスの表示」を参照してください。
ノート:
プロセスのこの段階では、サービス・メッシュ・ノード間のピア関係はまだ確立されていません。ステータス情報は、サービス・メッシュを実行している個々のサーバーについてのみ存在します。
ホップ・ノードの構成と起動
/etc/receptor/receptor.conf
ファイルを編集します。このファイルには、次の要素が含まれています:
- ノードID: ノードIDは、ホストのIPアドレスまたはホスト名である必要があります。
- log-level: 使用可能なオプションは、Error、Warning、InfoおよびDebugです。ログ・レベル・オプションは、ログの冗長性を高めます。Errorでは最も少ない情報が生成され、Debugでは最も多くの情報が生成されます。
- tcp-listener port: これは、他のノードで構成された着信TCPピア接続をノードがリスニングするポートです。たとえば、ノードIDがポート27199をリスニングする実行ノードを表している場合、この実行ノードへの接続を確立しようとする他のすべてのノードは、
/etc/receptor/receptor.conf
ファイルのtcp-peer要素でポート27199を指定する必要があります。 - tcp-peer: この要素には、接続先のホストのホスト名とポート番号を含める必要があります。たとえば、コントロール・ノードと実行ノード間の中間ノードとしてコントロール・ノードに接続するようにホップ・ノードを構成できます。addressフィールドには、コントロール・プレーン・ノードのホスト名またはIPアドレスと、それに続くポート番号を入力します。redial要素が有効になっている場合、接続が失敗した場合にホストへの接続を定期的に再確立しようとします。
- control-service: クラスタ内のすべてのノードは、ステータスを報告し、作業を開始および監視するコントロール・サービスを実行します。
- work-command: この要素は、ノードで実行できる作業のタイプを定義します。ホップ・ノードはプレイブックを実行しません。ただし、デフォルトのフィールドを構成する必要があります。ホップ・ノードのwork typeは常に
ansible-runner
です。
ホップ・ノードとして使用する各ホストで、次を実行します:
-
レセプタのデフォルト構成をすべて削除し、
/etc/receptor/receptor.conf
を編集して、次のホップ・ノード固有の構成情報を追加します:--- - node: id: <node IP address or hostname> - log-level: debug - tcp-listener: port: <port_number> - tcp-peer: address: <control hostname or IP address>:<target_port_number> redial: true - tcp-peer: address: <control hostname or IP address>:<target_port_number> redial: true - control-service: service: control filename: /var/run/receptor/receptor.sock - work-command: worktype: ansible-runner command: /var/lib/ol-automation-manager/venv/awx/bin/ansible-runner params: worker allowruntimeparams: true verifysignature: false
前述の例では次のようになります。
- node IP address or hostnameはノードのIPアドレスまたはホスト名です。
- port_numberは、このノードがリスニングしているポート番号です。
- target_portは、このノードが接続するように構成するピア・ノードのポート番号です。
- control hostname or IP addressは、ホップ・ノードが接続しているコントロール・ノードのホスト名またはIPアドレスです。
ホップ・ノードが複数のコントロール・ノードに関連付けられている場合は、ホップ・ノードが関連付けられているインスタンスごとに
- tcp-peer:
で他のノードを入力します。 - Oracle Linux Automation Managerメッシュ・サービスを起動します。
sudo systemctl start receptor-awx
- サービス・メッシュを確認します。詳細は、「クラスタ・ノードのサービス・メッシュ・ステータスの表示」を参照してください。
ノート:
プロセスのこの段階では、サービス・メッシュ・ノード間のピア関係はまだ確立されていません。ステータス情報は、サービス・メッシュを実行している個々のサーバーについてのみ存在します。
コントロール・ノード、実行ノードおよびホップ・ノードの構成
コントロール・プレーン・ノード、実行プレーン・ノード、ホップ・ノードを構成するには、1つのコントロール・プレーン・ホストで、すべてのOracle Linux Automation Managerインスタンスに適用される次のステップを実行します:
- 次のコマンドを実行します。
sudo su -l awx -s /bin/bash
-
次を実行します:
-
コントロール・ノード・タイプとして選択するホストごとに、次のコマンドを繰り返し実行します。コマンドを実行するたびに、IPアドレスまたはホスト名を変更します:
awx-manage provision_instance --hostname=<control hostname or IP address> --node_type=control
前述の例では、control hostname or IP addressは、Oracle Linux Automation Managerを実行しているシステムのホスト名またはIPアドレスです。このホスト名またはIPアドレスは、
/etc/receptor/receptor.conf
ファイルのノードIDを構成したときに使用したホスト名またはIPアドレスと一致している必要があります(「コントロール・プレーン・サービス・メッシュの構成と起動」を参照)。ホスト名を使用する場合は、ホストが解決可能である必要があります。 -
実行ノード・タイプとして選択するホストごとに、次のコマンドを繰り返し実行します。コマンドを実行するたびに、IPアドレスまたはホスト名を変更します:
awx-manage provision_instance --hostname=<execution hostname or IP address> --node_type=execution
前述の例では、execution hostname or IP addressは、Oracle Linux Automation Managerを実行しているシステムのホスト名またはIPアドレスです。このホスト名またはIPアドレスは、
ファイルのノードIDを構成したときに使用したホスト名またはIPアドレスと一致している必要があります(「実行プレーン・サービス・メッシュの構成と起動」を参照)。ホスト名を使用する場合は、ホストが解決可能である必要があります。/etc/receptor/receptor.conf
-
ホップ・ノード・タイプとして選択するホストごとに、次のコマンドを繰り返し実行します。コマンドを実行するたびに、IPアドレスまたはホスト名を変更します:
awx-manage provision_instance --hostname=<hop hostname or IP address> --node_type=hop
前述の例では、hop hostname or IP addressはOracle Linux Automation Managerを実行しているシステムのホスト名またはIPアドレスです。このホスト名またはIPアドレスは、
ファイルのノードIDを構成したときに使用したホスト名またはIPアドレスと一致している必要があります(「ホップ・ノードの構成と起動」を参照)。ホスト名を使用する場合は、ホストが解決可能である必要があります。/etc/receptor/receptor.conf
-
- 次のコマンドを実行して、デフォルトの実行環境を登録します:
- コントロール・プレーン実行環境
- OLAM EE: (2.3)
awx-manage register_default_execution_environments
-
次のコマンドを実行して、コントロール・プレーン・インスタンス・グループ(コマンドでキューとして指定)を作成し、コントロール・プレーン・ホストに関連付けます。クラスタ内の各コントロール・プレーン・ホストに対して、同じキュー名でコマンドを繰り返します:
awx-manage register_queue --queuename=controlplane --hostnames=<control hostname or IP address>
-
次のコマンドを実行して、インスタンス・グループを作成し、実行プレーン・ホストに関連付けます。クラスタ内の各実行プレーン・ホストに対して、同じキュー名でコマンドを繰り返します:
awx-manage register_queue --queuename=execution --hostnames=<execution hostname or IP address>
- 次のコマンドを実行してコントロール・ノードと実行ノードのレセプタ・アドレス・レコードを追加します。
awx-manage add_receptor_address --instance=<execution hostname, control hostname, or IP address> --address=<execution hostname, control hostname, or IP address> --port=27199 --canonical
-
awx-manage list_instances
コマンドを実行して、登録した各ホストが適切なインスタンス・グループで使用可能であることを確認します。たとえば、次は、コントロール・プレーン・インスタンス・グループと実行インスタンス・グループで実行されている2つのコントロール・プレーン・ノードと3つの実行プレーン・ノードのIPアドレスを示しています。これらのノードはまだ実行されていないため、使用可能な容量やハートビート情報は表示されません。awx-manage list_instances [controlplane capacity=0] 192.0.119.192 capacity=0 node_type=control version=? 192.0.124.44 capacity=0 node_type=control version=? [execution capacity=0] 192.0.114.137 capacity=0 node_type=execution version=ansible-runner-??? 192.0.117.98 capacity=0 node_type=execution version=ansible-runner-??? 192.0.125.241 capacity=0 node_type=execution version=ansible-runner-??? [ungrouped capacity=0] 192.0.123.77 node_type=hop version=ansible-runner-???
- 次のコマンドを実行して、クラスタ内の各ノード間のOracle Linux Automation Managerサービス・メッシュのピア関係を登録します:
awx-manage register_peers <execution or hop hostname or IP address> --peers <execution, hop, or control hostname or IP address>
このコマンドは、ピア関係を必要とするノード・ペアごとに実行する必要があります。たとえば、「サービス・メッシュ・トポロジの例」で説明されている例では、ピア関係を確立するために、各実行ノードに対してコマンドを2回実行しています。これにより、各実行ノードは異なるコントロール・ノードに接続されます。これにより、コントロール・ノードの1つに障害が発生した場合でも、各実行ノードには常にバックアップ・コントロール・ノードが確保されます。
他の可能なトポロジとして、分離された実行ノードがホップ・ノードにピアリングし、ホップ・ノードがコントロール・ノードにピアリングする必要があるトポロジもあります。この場合、コマンドを1回実行して実行ノードをホップ・ノードにピアリングし、もう一度実行してホップ・ノードをコントロール・ノードにピアリングする必要があります。
-
awxシェル環境を終了します。
exit
- コントロール・プレーン・ホストと実行プレーン・ホストごとに、
/etc/tower/conf.d/filename.py
にカスタム設定ファイルを作成し、次の内容を含めます:DEFAULT_EXECUTION_QUEUE_NAME = 'execution' DEFAULT_CONTROL_PLANE_QUEUE_NAME = 'controlplane'
コントロール・ノード、実行ノードおよびホップ・ノードの起動
コントロール・ノード、実行ノードおよびホップ・ノードを起動するには、次を実行します:
-
各ノードでサービスを起動します:
sudo systemctl enable --now ol-automation-manager.service
-
1つのコントロール・プレーン・ノードで、次のコマンドを実行して、次のようなデータを事前にリロードします:
- デモ・プロジェクト
- デフォルトのGalaxy資格証明
- デモ組織
- デモ・インベントリ
- デモ・ジョブ・テンプレート
- その他
sudo su -l awx -s /bin/bash awx-manage create_preload_data
ノート:
事前にロードされたデータは、すべてのクラスタ・ノードが接続するデータベースに保持されるため、このコマンドは1回のみ実行する必要があります。 -
awx-manage list_instances
コマンドを実行して、コントロール・プレーン・ノードと実行プレーン・ノードが現在実行中であることを確認し、使用可能な容量とハートビート情報を表示します。たとえば、次では、すべてのコントロール・プレーン・インスタンスと実行プレーン・インスタンスが実行中であり、使用可能な容量とアクティブなハートビート情報が表示されています。awx-manage list_instances [controlplane capacity=270] 192.0.119.192 capacity=135 node_type=control version=24.6.1 heartbeat="2022-09-22 14:38:29" 192.0.124.44 capacity=135 node_type=control version=24.6.1 heartbeat="2022-09-22 14:39:09" [execution capacity=405] 192.0.114.137 capacity=135 node_type=execution version=24.6.1 heartbeat="2022-09-22 14:40:07" 192.0.117.98 capacity=135 node_type=execution version=24.6.1 heartbeat="2022-09-22 14:40:35" 192.0.125.241 capacity=135 node_type=execution version=24.6.1 heartbeat="2022-09-22 14:40:55" [ungrouped capacity=0] 192.0.123.77 node_type=hop heartbeat="2024-09-20 13:26:44"
-
awxシェル環境を終了します。
exit
TLS検証と署名付き作業リクエストの構成
クラスタ内のサービス・メッシュ通信を、TLS検証とクラスタ・ノード間で送信される署名付き作業リクエストによって保護することをお薦めします。TLS検証はサービス・メッシュ・ネットワーク内の安全な通信を確保し、署名付き作業リクエストは安全なジョブ実行を確保します。
- クラスタ内の各ホスト(各実行ノード、ホップ・ノードおよびコントロール・プレーン・ノード)で、TLS設定用のファイルを作成します。たとえば、
/etc/tower/conf.d/tls.py
です。 - 署名付き作業を有効にするには、
/etc/tower/conf.d/tls.py
に次のテキストを追加します:RECEPTOR_NO_SIG = False
- カスタム設定ファイルの所有権と権限を設定します:
sudo chown awx:awx /etc/tower/conf.d/tls.py sudo chmod 0640 /etc/tower/conf.d/tls.py
- コントロール・ノードの1つから、
/etc/tower
フォルダで次を実行します:sudo mkdir -p certs sudo receptor --cert-init commonname="test CA" bits=2048 outcert=certs/ca.crt outkey=certs/ca.key
- クラスタ内の各ノードで次を実行します:
node_id
フィールドにIPアドレスを使用している場合は、次のコマンドを実行してcertsフォルダを作成し、TLS証明書を生成します:node=<node_id>; sudo receptor --cert-makereq bits=2048 commonname="$node test cert" ipaddress=$node nodeid=$node outreq=certs/$node.csr outkey=certs/$node.key node=<node_id>; sudo receptor --cert-signreq req=certs/$node.csr cacert=certs/ca.crt cakey=certs/ca.key outcert=certs/$node.crt
前述の例では、node_idは、キーを作成するノードのIPアドレスです。これは、実行ノード、ホップ・ノードまたはコントロール・プレーン・ノードの
/etc/receptor/receptor.conf
ファイルで設定されています。node_id
フィールドにホスト名を使用している場合は、次のコマンドを実行してcertsフォルダを作成し、TLS証明書を生成します:node=<node_id>; sudo receptor --cert-makereq bits=2048 commonname="$node test cert" dnsname=$node nodeid=$node outreq=certs/$node.csr outkey=certs/$node.key node=<node_id>; sudo receptor --cert-signreq req=certs/$node.csr cacert=certs/ca.crt cakey=certs/ca.key outcert=certs/$node.crt
前述の例では、node_idは、キーを作成するノードのホスト名です。これは、実行ノード、ホップ・ノード、またはコントロール・プレーン・ノードの
/etc/receptor/receptor.conf
ファイルで設定されています。
- 2番目のコマンドの後、
yes
と入力して証明書への署名を確認します。たとえば、次は、2つのホストを持つクラスタの証明書を生成します:node=192.0.250.40; sudo receptor --cert-makereq bits=2048 commonname="$node test cert" ipaddress=192.0.250.40 nodeid=$node outreq=certs/$node.csr outkey=certs/$node.key node=192.0.250.40; sudo receptor --cert-signreq req=certs/$node.csr cacert=certs/ca.crt cakey=certs/ca.key outcert=certs/$node.crt Requested certificate: Subject: CN=192.0.250.40 test cert Encryption Algorithm: RSA (2048 bits) Signature Algorithm: SHA256-RSA Names: IP Address: 192.0.250.40 Receptor Node ID: 192.0.250.40 Sign certificate (yes/no)? yes node=192.0.251.206; sudo receptor --cert-makereq bits=2048 commonname="$node test cert" ipaddress=192.0.251.206 nodeid=$node outreq=certs/$node.csr outkey=certs/$node.key node=192.0.251.206; sudo receptor --cert-signreq req=certs/$node.csr cacert=certs/ca.crt cakey=certs/ca.key outcert=certs/$node.crt Requested certificate: Subject: CN=192.0.251.206 test cert Encryption Algorithm: RSA (2048 bits) Signature Algorithm: SHA256-RSA Names: IP Address: 192.0.251.206 Receptor Node ID: 192.0.251.206 Sign certificate (yes/no)? yes
/etc/tower/certs
フォルダから、次のコマンドを実行して、作業リクエストの署名と検証用の証明書を生成します:sudo openssl genrsa -out signworkprivate.pem 2048 sudo openssl rsa -in signworkprivate.pem -pubout -out signworkpublic.pem
/etc/tower/
フォルダから、次のコマンドを実行して、certsフォルダの所有権とフォルダ内のすべてのファイルを変更します:sudo chown -R awx:awx certs
/etc/tower/certs
フォルダに必要なファイルがすべて揃っていることを確認します。たとえば、次は4ノード・クラスタ用に生成されたキー情報を示します。ls -al total 68 drwxr-xr-x. 2 awx awx 4096 Sep 12 18:26 . drwxr-xr-x. 4 awx awx 132 Sep 12 16:49 .. -rw-------. 1 awx awx 1180 Sep 12 18:19 192.0.113.178.crt -rw-------. 1 awx awx 1001 Sep 12 18:19 192.0.113.178.csr -rw-------. 1 awx awx 1679 Sep 12 18:19 192.0.113.178.key -rw-------. 1 awx awx 1176 Sep 12 18:20 192.0.121.28.crt -rw-------. 1 awx awx 1001 Sep 12 18:20 192.0.121.28.csr -rw-------. 1 awx awx 1675 Sep 12 18:20 192.0.121.28.key -rw-------. 1 awx awx 1180 Sep 12 18:20 192.0.126.172.crt -rw-------. 1 awx awx 1001 Sep 12 18:19 192.0.126.172.csr -rw-------. 1 awx awx 1679 Sep 12 18:19 192.0.126.172.key -rw-------. 1 awx awx 1176 Sep 12 18:19 192.0.127.70.crt -rw-------. 1 awx awx 1001 Sep 12 18:19 192.0.127.70.csr -rw-------. 1 awx awx 1675 Sep 12 18:19 192.0.127.70.key -rw-------. 1 awx awx 1107 Sep 12 16:54 ca.crt -rw-------. 1 awx awx 1679 Sep 12 16:54 ca.key -rw-------. 1 awx awx 1675 Sep 12 18:26 signworkprivate.pem -rw-r--r--. 1 awx awx 451 Sep 12 18:26 signworkpublic.pem
- クラスタ内の各ノードの
/etc/tower
フォルダにcertsフォルダを作成し、certsフォルダの所有権とグループをawx:awx
に変更します:sudo mkdir -p certs sudo chown -R awx:awx certs
- ca.crt、ノード固有の.crt、csr、キー・ファイル、signworkprivate.pemおよびsignworkpublic.pemファイルをクラスタ内の各ノードにコピーします。
- コントロール・プレーン・ノードごとに、
/etc/receptor/receptor.conf
ファイルに次の行を追加します:--- - node: id: <IP address or host name> - log-level: debug # Add the tls: control that specifies the tls-server name for the listener - tcp-listener: port: 27199 tls: controller # Add the TLS server configuration - tls-server: name: controller cert: /etc/tower/certs/<IP address or host name>.crt key: /etc/tower/certs/<IP address or host name>.key requireclientcert: true clientcas: /etc/tower/certs/ca.crt - control-service: service: control filename: /var/run/receptor/receptor.sock # Add the work-signing and work-verification elements - work-signing: privatekey: /etc/tower/certs/signworkprivate.pem tokenexpiration: 30m - work-verification: publickey: /etc/tower/certs/signworkpublic.pem # Set verifysignature to true. - work-command: worktype: local command: /var/lib/ol-automation-manager/venv/awx/bin/ansible-runner params: worker allowruntimeparams: true verifysignature: true
前述の例では、IP address or host nameは、コントロール・プレーン・ホストのホスト名またはIPアドレスです。ホスト名を使用する場合は、ホスト名が解決可能である必要があります。
- 実行プレーン・ノードごとに、
/etc/receptor/receptor.conf
ファイルに次の行を追加します:--- - node: id: <execution IP address or host name> - log-level: debug - tcp-listener: port: 27199 # Add tls: client that specifies the tls-client name. - tcp-peer: address: <hostname or IP address>:27199 redial: true tls: client - tcp-peer: address: <hostname or IP address>:27199 redial: true tls: client # Add the tls-client element. - tls-client: name: client rootcas: /etc/tower/certs/ca.crt insecureskipverify: false cert: /etc/tower/certs/<execution IP address or host name>.crt key: /etc/tower/certs/<execution IP address or host name>.key - control-service: service: control filename: /var/run/receptor/receptor.sock # Add the work-verification element. - work-verification: publickey: /etc/tower/certs/signworkpublic.pem # Set verifysignature to true. - work-command: worktype: ansible-runner command: /var/lib/ol-automation-manager/venv/awx/bin/ansible-runner params: worker allowruntimeparams: true verifysignature: true
前述の例では次のようになります。
- execution IP address or host nameは、ノードのIPアドレスまたはホスト名です
- hostname or IP addressは、ピアリングする実行ノード、コントロール・ノード、またはホップ・ノードのホスト名またはIPアドレスです。
- (必要に応じて)ホップ・ノードごとに、
/etc/receptor/receptor.conf
ファイルに次の行を追加します:--- - node: id: <node IP address or hostname> - log-level: debug # Add the tls: control that specifies the tls-server name for the listener - tcp-listener: port: 27199 tls: controller # Add tls: client that specifies the tls-client name. - tcp-peer: address: <control hostname or IP address>:27199 redial: true tls: client # Add the tls-client element. - tls-client: name: client rootcas: /etc/tower/certs/ca.crt insecureskipverify: false cert: /etc/tower/certs/<node IP address or hostname>.crt key: /etc/tower/certs/<node IP address or hostname>.key - work-verification: publickey: /etc/tower/certs/signworkpublic.pem # Add the work-signing and work-verification elements - work-signing: privatekey: /etc/tower/certs/signworkprivate.pem tokenexpiration: 30m # Add the TLS server configuration - tls-server: name: controller cert: /etc/tower/certs/<node IP address or hostname>.crt key: /etc/tower/certs/<node IP address or hostname>.key requireclientcert: true clientcas: /etc/tower/certs/ca.crt - control-service: service: control filename: /var/run/receptor/receptor.sock # Set verifysignature to true. - work-command: worktype: local command: /var/lib/ol-automation-manager/venv/awx/bin/ansible-runner params: worker allowruntimeparams: true verifysignature: true
前述の例では次のようになります。
- node IP address or host nameは、ノードのIPアドレスまたはホスト名です
- control hostname or IP addressは、ピアリングするコントロール・プレーン・ホストのホスト名またはIPアドレスです。
- 各ノードで、サービス・メッシュとOracle Linux Automation Managerを再起動します。
sudo systemctl daemon-reload sudo systemctl restart receptor-awx sudo systemctl restart ol-automation-manager
- サービス・メッシュを確認します。詳細は、「サービス・メッシュの表示」を参照してください。