4.8 中継サーバ使用手順

以下の手順は、中継サーバの設定が終わっていることを想定しています。中継サーバの設定については「中継サーバの設定」を参照してください。

中継サーバを使用する際は、以下の手順①～⑥で設定をします。

①～③はシステム管理、④～⑥は自動化アプリケーション（AWX）で設定を行います。 ⑦ではワークフローのYAMLファイル記載内容について説明します。

①～③の操作を行うユーザーは、Primitiveロールの「automation_manager」が付与されている必要があります。また、④～⑥の操作を行うユーザーはAWXの組織が持つロールが付与されている必要があります。AWXのロールの詳細については、付録 「OSSのバージョンおよびエディション、参照先のマニュアル」のAWXのマニュアルを参照してください。また、組織の概要や組織の作成や各ロールの割り当てについては「組織の設定」「組織管理」を、ロールの割り当て全般については「ロール管理」、「Ops I上のロールとサポート機能の対応関係」を参照してください。

【システム管理】

①ノードグループを追加します。

ノードグループを追加すると、自動化アプリケーション（AWX）に自動的にノードグループID名のインスタンスグループが作成され、ジョブテンプレートとひもづけられます。ジョブはノードグループ内のいずれかのノードで実行されるため、ジョブ実行の負荷を複数のノードに分散させることができます。また、ジョブテンプレートに影響を与えずにノードの追加や入れ替えを実施することができます。
ノードグループ追加の詳細は「ノードグループ管理」を参照してください。

（図）ノードグループ画面
（図）ノードグループ画面 （図）ノードグループ画面


（図）インスタンスグループ画面
（図）インスタンスグループ画面 （図）インスタンスグループ画面


②IPブロックを追加します。

IPブロック追加については、「IPブロック管理」を参照してください。

③ノードとIPブロックをノードグループにひもづけます。

IPブロックが1つもひもづいていないノードグループで実行されたジョブは、すべてのIPアドレスにアクセスできます。ノードとIPブロックをノードグループにひもづける方法については、「ノードグループ管理」を参照してください。

【自動化アプリケーション（AWX）】

④～⑥では中継サーバを使用するため必要となるAWXの設定について説明します。AWXの標準的な設定については「自動化」を参照してください。

④認証情報に、中継サーバから接続する管理対象サーバ情報を登録します。

管理対象サーバの認証方法にあわせて設定を行ってください。その際、認証タイプは「マシン」を選択してください。また「Outpost」は予約語のため、名前として使用しないでください。設定方法の詳細は付録 「OSSのバージョンおよびエディション、参照先のマニュアル」の、AWXのマニュアルを参照してください。

（図）管理対象サーバ認証情報登録画面
（図）管理対象サーバ認証情報登録画面 （図）管理対象サーバ認証情報登録画面

⑤ジョブテンプレートを作成します。

ジョブテンプレートのインスタンスグループとして、①で自動生成されたインスタンスグループを選択します。その結果、ジョブテンプレートからノードグループがひもづけられます。

（図）ジョブテンプレート画面
（図）ジョブテンプレート画面 （図）ジョブテンプレート画面

（図）インスタンスグループ選択画面
（図）インスタンスグループ選択画面 （図）インスタンスグループ選択画面

⑥ジョブテンプレートの実行環境に「OpsI Outpost EE」を指定します。

「OpsI Outpost EE」はOps IのAWXにデフォルトで存在します。

（図）実行環境画面
（図）実行環境画面 （図）実行環境画面


【YAMLファイル記載内容】

⑦ワークフローのYAMLファイルに④で作成したジョブテンプレートを指定します。

ワークフローのYAMLファイルで、Task modelのactionとしてOps I提供部品の「awx.run_job_template」を設定し、inputに④で作成したジョブテンプレート名を定義します。 その結果、ワークフローからノードグループにひもづけられたジョブテンプレートを使用することができます。

ユーザーがカタログを起動すると、ワークフローでawx.run_job_templateを設定したステップでAWXのジョブテンプレートが実行され、コントロールプレーンにジョブが登録されます。中継サーバのエージェントがそのジョブを取得し、管理対象サーバに対しジョブを実行します。
ワークフローのYAMLファイルについては「Workflow」を参照してください。

（図）ジョブ実行の流れ
（図）ジョブ実行の流れ （図）ジョブ実行の流れ

【ジョブ数使用制限】

1つのノードで同時に実行できるジョブ数はハードウェアの構成により制限があり、例えば「RPMパッケージインストール前提条件」の最小構成の場合、最大12個になります。それ以上のジョブが同時に実行された場合、制限を超えるジョブは待機状態となり、実行中のいずれかのジョブが完了次第実行されます。ただし、最大待ち時間の5分以内に実行されない場合、待機しているジョブはエラーとなります。
ジョブ数使用制限以上のジョブを実行したい場合、ノードを分割し1つのノードあたりの使用制限を超えないよう対処が必要です。

【アウトポストの稼働監視】

エージェントが正常に稼働しているかを定期に確認することを推奨します。確認方法はOps Iの画面ステータス、または状態監視コマンドの実行により行います。また、プロセス監視も可能です。

  • Ops I画面ステータスでの確認：
    ノード詳細画面でステータスが「Not Ready」の場合、エージェントが停止状態と判断できます。ノード詳細画面については「ノード管理」を参照してください。

  • 状態監視コマンド「opsiopctl.sh status」での確認：
    エージェントではchiselとk3sのsystemdサービスが動作しており、「opsiopctl.sh status」の実行結果としてコマンドラインにそれぞれのサービスのステータスが出力され、停止状態の場合「inactive」と表示されます。また、ステータスの少なくとも1つが稼働状態「active」ではない場合「Outpost Agent is NotActive.」と出力され、コマンドの返り値として「1」が返却されます。
    また、「opsiopctl.sh status」を定期実行することでコマンドの返り値（0または1）を元に起動状態を確認することができます。 コマンドの詳細は 「RPMパッケージのコマンドスクリプト」の【アウトポストエージェントの状態監視：opsiopctl.sh status】を参照してください。

  • プロセス監視を行う場合： chiselとk3sのプロセス監視が可能です。プロセスの実行ファイルのPathは以下になります。

    • chisel：/opt/opsi/outpost/bin/chisel
    • k3s：/opt/opsi/outpost/bin/k3s