機械翻訳について

5 クラスタ化されたデプロイメントへのOracle Linux Automation Managerのインストール

この章では、Oracle Linux Automation Managerマルチ・ホスト・デプロイメントでホストを準備する方法について説明します。 ホストを準備する場合は、Oracle Linux Automation Managerソフトウェア・パッケージをインストールし、Oracle Linux Automation Managerサービス・メッシュの一部として構成する必要があります。 コントロール・プレーンおよび実行プレーン・ノードを構成および開始する前に、サービス・メッシュ・ノードを構成して起動します。

コントロール・プレーン・サービス・メッシュの構成および起動

クラスタのコントロール・プレーンで各ノードを構成するには、/etc/receptor/receptor.confファイルを編集します。 このファイルには、次の要素が含まれています:

• node ID: ノードIDはホストのIPアドレスまたはホスト名である必要があります。
• log-level: 使用可能なオプションは次のとおりです: エラー、警告、情報およびデバッグ。 ログ・レベル・オプションを使用すると、エラーによって生成される情報が最小になり、デバッグによって生成される情報が最大になるように、冗長性が向上します。
• tcp-listenerポート: これは、ノードがほかのノードで構成された受信TCPピア接続を待機するポートです。 たとえば、ノードIDがポート27199でリスニングする制御ノードを表す場合、この制御ノードへの接続を確立する他のすべてのノードは、/etc/receptor/receptor.conf ファイルで構成するtcp-peer要素でポート27199を指定する必要があります。
• control-service: クラスタ内のすべてのノードは、ステータスを報告し、作業を開始およびモニターする制御サービスを実行します。
• work-command: この要素は、ノードで実行できる作業のタイプを定義します。 コントロール・プレーン・ノードの場合、作業タイプは常にローカルです。 実行するコマンドは、AnsibleおよびAnsibleプレイブック・タスクを実行するための抽象レイヤーを提供するAnsibleランナー・ツールであり、他のシステムにステータスおよびイベント・データを送信するように構成できます。 Ansible Runnerの詳細は、https://ansible-runner.readthedocs.io/en/stable/を参照してください。

コントロール・プレーン・ノードとして使用する各ホストで、次の手順を実行します:

1. Receptorのデフォルト構成を削除し、次の構成コントロール・プレーン固有の情報が含まれるように/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アドレスまたはホスト名」はノードのIPアドレスまたはホスト名で、port_numberはこのノードがリスニングしているポート番号です。 たとえば、ノード名とノードのIPアドレスを指定するcontrol1-192.0.121.28のようなものを使用できます。 また、ポート27199でtcp-listenerリスト・リスニングを構成することもできます。 コントロール・プレーン・ノードのworktypeパラメータはlocalである必要があります。

2. Oracle Linux Automation Managerメッシュ・サービスを起動します。

   sudo systemctl start receptor-awx

3. サービス・メッシュを確認します。 詳細については、「クラスタ・ノードのサービス・メッシュ・ステータスの表示」を参照してください。

   ノート:

   プロセスのこの時点で、サービス・メッシュ・ノード間のピア関係はまだ確立されていません。 ステータス情報は、サービス・メッシュを実行している個々のサーバーに対してのみ存在します。

実行プレーン・サービス・メッシュの構成および起動

クラスタの実行プレーンで各ノードを構成するには、/etc/receptor/receptor.confファイルを編集します。 このファイルには、次の要素が含まれています:

• node ID: ノードIDはホストのIPアドレスまたはホスト名である必要があります。
• log-level: 使用可能なオプションは次のとおりです: エラー、警告、情報およびデバッグ。 ログ・レベル・オプションを使用すると、エラーによって生成される情報が最小になり、デバッグによって生成される情報が最大になるように、冗長性が向上します。
• tcp-listenerポート: これは、ノードがほかのノードで構成された受信TCPピア接続を待機するポートです。 たとえば、ノードIDがポート27199でリスニングする実行ノードを表す場合、この実行ノードへの接続を確立する他のすべてのノードは、/etc/receptor/receptor.conf ファイルで構成するtcp-peer要素でポート27199を指定する必要があります。
• tcp-peerポート: この要素には、接続先のホストのホスト名とポート番号を含める必要があります。 たとえば、冗長性を提供するためにこの実行ノードを複数のコントロール・プレーン・ノードに接続する必要がある場合は、実行ノードが接続する各コントロール・プレーン・ノードにtcp-peer要素を追加する必要があります。 アドレス・フィールドに、コントロール・プレーン・ノードのホスト名またはIPアドレスを入力し、続けてポート番号を入力します。 有効になっている場合、redial要素は、接続に失敗した場合にホストへの接続を定期的に再確立しようとします。

  サービス・メッシュ・トポロジの要件に基づいて、他の実行ノードまたはホップ・ノードのホスト名およびポート番号を含めるようにtcp-peer要素を構成することもできます。

• control-service: クラスタ内のすべてのノードは、ステータスを報告し、作業を開始およびモニターする制御サービスを実行します。
• work-command: この要素は、ノードで実行できる作業のタイプを定義します。 実行プレーン・ノードの場合、作業タイプは常にansible-runnerです。 実行するコマンドは、AnsibleおよびAnsibleプレイブック・タスクを実行するための抽象レイヤーを提供するAnsibleランナー・ツールであり、他のシステムにステータスおよびイベント・データを送信するように構成できます。 Ansible Runnerの詳細は、https://ansible-runner.readthedocs.io/en/stable/を参照してください。

実行プレーン・ノードとして使用する各ホストで、次の手順を実行します:

1. Receptorのデフォルト構成をすべて削除し、/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アドレスまたはホスト名」は、ノードのIPアドレスまたはホスト名です。
   • port_numberは、このノードがリスニングしているポート番号です。
   • target_portは、このノードが接続するように構成しているピア・ノードのポート番号です。
   • 「ホスト名またはIPアドレス」は、接続している実行、制御またはホップ・ノードのホスト名またはIPアドレスです。
   • 実行プレーン・ノードでは、worktypeパラメータはansible-runnerである必要があります。

   実行環境が複数の制御、実行またはホップ・ノードに関連付けられている場合は、実行ホストが関連付けられているインスタンスに対して追加の- tcp-peer:ノードを入力します。

2. Oracle Linux Automation Managerメッシュ・サービスを起動します。

   sudo systemctl start receptor-awx

3. サービス・メッシュを確認します。 詳細については、「クラスタ・ノードのサービス・メッシュ・ステータスの表示」を参照してください。

   ノート:

   プロセスのこの時点で、サービス・メッシュ・ノード間のピア関係はまだ確立されていません。 ステータス情報は、サービス・メッシュを実行している個々のサーバーに対してのみ存在します。

ホップ・ノードの構成と起動

クラスタ内の各ホップ・ノードを構成するには、/etc/receptor/receptor.confファイルを編集します。 このファイルには、次の要素が含まれています:

• node ID: ノードIDはホストのIPアドレスまたはホスト名である必要があります。
• log-level: 使用可能なオプションは次のとおりです: エラー、警告、情報およびデバッグ。 ログ・レベル・オプションを使用すると、エラーによって生成される情報が最小になり、デバッグによって生成される情報が最大になるように、冗長性が向上します。
• tcp-listenerポート: これは、ノードがほかのノードで構成された受信TCPピア接続を待機するポートです。 たとえば、ノードIDがポート27199でリスニングする実行ノードを表す場合、この実行ノードへの接続を確立する他のすべてのノードは、/etc/receptor/receptor.conf ファイルで構成するtcp-peer要素でポート27199を指定する必要があります。
• tcp-peerポート: この要素には、接続先のホストのホスト名とポート番号を含める必要があります。 たとえば、制御ノードと実行ノードの間の中間ノードとして制御ノードに接続するようにホップ・ノードを構成できます。 アドレス・フィールドに、コントロール・プレーン・ノードのホスト名またはIPアドレスを入力し、続けてポート番号を入力します。 有効になっている場合、redial要素は、接続に失敗した場合にホストへの接続を定期的に再確立しようとします。
• control-service: クラスタ内のすべてのノードは、ステータスを報告し、作業を開始およびモニターする制御サービスを実行します。
• work-command: この要素は、ノードで実行できる作業のタイプを定義します。 ホップ・ノードはプレイブックを実行しません。 ただし、デフォルト・フィールドを構成する必要があります。 ホップ・ノードの作業タイプは、常にansible-runnerです。

ホップ・ノードとして使用する各ホストで、次の手順を実行します:

1. Receptorのデフォルト構成をすべて削除し、/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: local
       command: /var/lib/ol-automation-manager/venv/awx/bin/ansible-runner
       params: worker
       allowruntimeparams: true
       verifysignature: false

   この例では、次のようになります。

   • 「ノードIPアドレスまたはホスト名」は、ノードのIPアドレスまたはホスト名です。
   • port_numberは、このノードがリスニングしているポート番号です。
   • target_portは、このノードが接続するように構成しているピア・ノードのポート番号です。
   • 「制御ホスト名またはIPアドレス」は、ホップ・ノードが接続している制御ノードのホスト名またはIPアドレスです。

   ホップ・ノードが複数の制御ノードに関連付けられている場合は、ホップ・ノードが関連付けられているインスタンスごとに、追加の- tcp-peer:ノードを入力します。

2. Oracle Linux Automation Managerメッシュ・サービスを起動します。

   sudo systemctl start receptor-awx

3. サービス・メッシュを確認します。 詳細については、「クラスタ・ノードのサービス・メッシュ・ステータスの表示」を参照してください。

   ノート:

   プロセスのこの時点で、サービス・メッシュ・ノード間のピア関係はまだ確立されていません。 ステータス情報は、サービス・メッシュを実行している個々のサーバーに対してのみ存在します。

制御ノード、実行ノードおよびホップ・ノードの構成

コントロール・プレーン、実行プレーンおよびホップ・ノードを構成するには、1つのコントロール・プレーン・ホストで、すべてのOracle Linux Automation Managerインスタンスに適用される次のステップを実行します:

1. 次のコマンドを実行します。

   sudo su -l awx -s /bin/bash
   

2. 次を実行します。

   • 制御ノード・タイプとして指定するホストごとに次のコマンドを繰り返し、コマンドを実行するたびにIPアドレスまたはホスト名を変更します:

     awx-manage provision_instance --hostname=<control hostname or IP address> --node_type=control

     前の例では、「制御ホスト名またはIPアドレス」は、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

     前の例では、「実行ホスト名またはIPアドレス」は、Oracle Linux Automation Managerを実行しているシステムのホスト名またはIPアドレスです。 ホスト名またはIPアドレスの選択は、/etc/receptor/receptor.conf ファイル・ノードIDを構成したときに使用したホスト名またはIPアドレスと一致する必要があります(「実行プレーン・サービス・メッシュの構成および起動」を参照)。 ホスト名を使用する場合は、ホストが解決可能である必要があります。

   • ホップ・ノード・タイプとして指定するホストごとに、次のコマンドを繰り返し、コマンドを実行するたびにIPアドレスまたはホスト名を変更します:

     awx-manage provision_instance --hostname=<hop hostname or IP address> --node_type=hop

     前の例では、「ホップ・ホスト名またはIPアドレス」は、Oracle Linux Automation Managerを実行しているシステムのホスト名またはIPアドレスです。 ホスト名またはIPアドレスの選択は、/etc/receptor/receptor.conf ファイル・ノードIDを構成したときに使用したホスト名またはIPアドレスと一致する必要があります(「ホップ・ノードの構成と起動」を参照)。 ホスト名を使用する場合は、ホストが解決可能である必要があります。

3. 次のコマンドを実行して、デフォルトの実行環境を登録します:
   • コントロール・プレーン実行環境
   • OLAM EE: (最新)

   awx-manage register_default_execution_environments

4. 次のコマンドを実行して、コントロール・プレーン・インスタンス・グループ(コマンドでキューとして指定)を作成し、それをコントロール・プレーン・ホストに関連付けます。 クラスタ内のコントロール・プレーン・ホストごとに、同じキュー名を指定してコマンドを繰り返します:

   awx-manage register_queue --queuename=controlplane --hostnames=<control hostname or IP address>

5. 次のコマンドを実行して、インスタンス・グループを作成し、実行プレーン・ホストに関連付けます。 クラスタ内の実行プレーン・ホストごとに、同じキュー名を指定してコマンドを繰り返します:

   awx-manage register_queue --queuename=execution --hostnames=<execution hostname or IP address>

6. 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-???

   ノート:

   ホップ・ノードはどのインスタンス・グループにも関連付けられていないため、このリストには表示されません。
7. 次のコマンドを実行して、クラスタ内の各ノード間の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つに障害が発生した場合に、各実行ノードに常にバックアップ制御ノードが存在することが保証されます。

   分離された実行ノードがホップ・ノードとピア接続する必要があり、ホップ・ノードが制御ノードとピア接続する必要があるトポロジなど、追加のトポロジが可能です。 この場合、コマンドは一度実行して実行ノードをホップ・ノードとピアリングし、ホップ・ノードを制御ノードとピアリングする必要があります。

8. awxシェル環境を終了します。

   exit

9. 制御および実行プレーン・ホストごとに、次を使用して/etc/tower/settings.pyファイルを編集します:

   DEFAULT_EXECUTION_QUEUE_NAME = 'execution'
   DEFAULT_CONTROL_PLANE_QUEUE_NAME = 'controlplane'

制御ノード、実行ノードおよびホップ・ノードの起動

制御ノード、実行ノード、およびホップ・ノードを起動するには、次の手順を実行します:

1. 各ノードでサービスを起動します:

   sudo systemctl enable --now ol-automation-manager.service

2. 1つのコントロール・プレーン・ノードで、次のコマンドを実行して、次のようなデータをプリロードします:

   • デモ・プロジェクト
   • デフォルトのギャラクシ資格証明
   • デモ組織
   • デモ・インベントリ
   • デモ・ジョブ・テンプレート
   • その他

   sudo su -l awx -s /bin/bash
   awx-manage create_preload_data 

   ノート:

   事前ロードされたデータは、すべてのクラスタ・ノードが接続するデータベースに保持されるため、このコマンドは1回のみ実行する必要があります。
3. awx-manage list_instancesコマンドを実行して、コントロールおよび実行プレーン・ノードが実行されていることを確認し、使用可能な容量を表示し、ハートビート情報を表示します。 たとえば、次の例は、実行されているすべてのコントロール・プレーン・インスタンスと実行プレーン・インスタンス、使用可能な容量およびアクティブなハートビート情報を示しています。

   awx-manage list_instances
   [controlplane capacity=270]
   	192.0.119.192 capacity=135 node_type=control version=19.5.1 heartbeat="2022-09-22 14:38:29"
   	192.0.124.44 capacity=135 node_type=control version=19.5.1 heartbeat="2022-09-22 14:39:09"
   
   [execution capacity=405]
   	192.0.114.137 capacity=135 node_type=execution version=19.5.1 heartbeat="2022-09-22 14:40:07"
   	192.0.117.98 capacity=135 node_type=execution version=19.5.1 heartbeat="2022-09-22 14:40:35"
   	192.0.125.241 capacity=135 node_type=execution version=19.5.1 heartbeat="2022-09-22 14:40:55"

   ノート:

   ホップ・ノードはどのインスタンス・グループにも関連付けられていないため、このリストには表示されません。
4. awxシェル環境を終了します。

   exit

TLS検証および署名済作業リクエストの構成

Oracleでは、クラスタ・ノード間で送信されるTLS検証および署名済作業リクエストを使用して、クラスタ内のサービス・メッシュ通信を保護することをお薦めします。 TLS検証により、サービス・メッシュ・ネットワークでのセキュアな通信が保証され、署名された作業リクエストによってセキュアなジョブ実行が保証されます。

次の手順では、既存のOracle Linux Automation ManagerクラスタのTLSを有効にします。 この手順を実行する前に、次のタスクを完了してください:

• ホストの設定
• コントロール・プレーン・サービス・メッシュの構成および起動
• 実行プレーン・サービス・メッシュの構成および起動
• ホップ・ノードの構成と起動
• 制御ノード、実行ノードおよびホップ・ノードの構成
• 制御ノード、実行ノードおよびホップ・ノードの起動

TLS検証および署名済作業リクエストを構成するには、次を実行します:

1. クラスタ内の各ホスト(各実行、ホップおよびコントロール・プレーン・ノード)で、署名済作業リクエストを有効にするには、/etc/tower/settings.pyファイルに次のテキストを追加します。

   RECEPTOR_NO_SIG = False

2. いずれかのコントロール・ノードの/etc/towerフォルダで、次の手順を実行します:
   • node_idフィールドのIPアドレスを使用している場合は、次のコマンドを実行してcertsフォルダを作成し、TLS証明書を生成します:

     sudo mkdir -p certs
     sudo receptor --cert-init commonname="test CA" bits=2048 outcert=certs/ca.crt outkey=certs/ca.key
     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は、実行、ホップまたはコントロール・プレーン・ノードの/etc/receptor/receptor.confファイルで設定したキーを作成するノードのIPアドレスです。

   • node_idフィールドのホスト名を使用している場合は、次のコマンドを実行してcertsフォルダを作成し、TLS証明書を生成します:

     sudo mkdir -p certs
     sudo receptor --cert-init commonname="test CA" bits=2048 outcert=certs/ca.crt outkey=certs/ca.key
     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ファイルで設定したキーを作成するノードのホスト名です。

3. 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
                                           

4. /etc/tower/certsフォルダから次のコマンドを実行して、作業リクエストの署名および検証用の証明書を生成します:

   sudo openssl genrsa -out signworkprivate.pem 2048
   sudo openssl rsa -in signworkprivate.pem -pubout -out signworkpublic.pem

5. cd /etc/tower/フォルダから次のコマンドを実行して、certsフォルダの所有権およびフォルダ内のすべてのファイルを変更します:

   sudo chown -R awx:awx certs

6. /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

7. クラスタの各ノードで、/etc/towerフォルダにcertsフォルダを作成し、certsフォルダの所有権およびグループをawx:awxに変更します :

   sudo mkdir -p certs
   sudo chown -R awx:awx certs

8. ca.crt、ノード固有の.crt、csrおよびキー・ファイルおよびsignworkprivate.pemおよびsignworkpublic.pemファイルをクラスタ内の各ノードにコピーします。
9. コントロール・プレーン・ノードごとに、/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アドレスまたはホスト名」はコントロール・プレーン・ホストのホスト名またはIPアドレスです。 ホスト名を使用する場合は、ホストが解決可能である必要があります。

10. 実行プレーン・ノードごとに、/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

    この例では、次のようになります。

    • 「実行IPアドレスまたはホスト名」は、ノードのIPアドレスまたはホスト名です
    • 「ホスト名またはIPアドレス」は、ピアリングする実行、制御またはホップ・ノードのホスト名またはIPアドレスです。
11. (必要に応じて)ホップ・ノードごとに、/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

    この例では、次のようになります。

    • 「ノードIPアドレスまたはホスト名」は、ノードのIPアドレスまたはホスト名です
    • 「制御ホスト名またはIPアドレス」は、ピアリングするコントロール・プレーン・ホストのホスト名またはIPアドレスです。
12. 各ノードで、サービス・メッシュおよびOracle Linux Automation Managerを再起動します。

    sudo systemctl restart receptor-awx
    sudo systemctl restart ol-automation-manager

13. サービス・メッシュを確認します。 詳細は、「サービス・メッシュの表示」を参照してください。