第8章 インスタンスとコンテナーグループ

ノードを定義する際には、以下の基準を使用します。

インベントリーファイルでは、グループ名を instance_group_* の形式で指定することでカスタムグループを定義できます。ここで * は API でのグループ名になります。インストールの完了後に、API でカスタムインスタンスグループを作成することもできます。

現在の動作では 、instance_group_* のメンバーは automationcontroller または execution_nodes グループに属していることが想定されています。

[automationcontroller]
126-addr.tatu.home ansible_host=192.168.111.126  node_type=control

[automationcontroller:vars]
peers=execution_nodes

[execution_nodes]

[instance_group_test]
110-addr.tatu.home ansible_host=192.168.111.110 receptor_listener_port=8928

インストーラーを実行すると、次のエラーが表示されます。

TASK [ansible.automation_platform_installer.check_config_static : Validate mesh topology] ***
fatal: [126-addr.tatu.home -> localhost]: FAILED! => {"msg": "The host '110-addr.tatu.home' is not present in either [automationcontroller] or [execution_nodes]"}

この問題を解決するには、ボックス 110-addr.tatu.home を execution_node グループに移動してください。

[automationcontroller]
126-addr.tatu.home ansible_host=192.168.111.126  node_type=control

[automationcontroller:vars]
peers=execution_nodes

[execution_nodes]
110-addr.tatu.home ansible_host=192.168.111.110 receptor_listener_port=8928

[instance_group_test]
110-addr.tatu.home

その結果、以下のようになります。

TASK [ansible.automation_platform_installer.check_config_static : Validate mesh topology] ***
ok: [126-addr.tatu.home -> localhost] => {"changed": false, "mesh": {"110-addr.tatu.home": {"node_type": "execution", "peers": [], "receptor_control_filename": "receptor.sock", "receptor_control_service_name": "control", "receptor_listener": true, "receptor_listener_port": 8928, "receptor_listener_protocol": "tcp", "receptor_log_level": "info"}, "126-addr.tatu.home": {"node_type": "control", "peers": ["110-addr.tatu.home"], "receptor_control_filename": "receptor.sock", "receptor_control_service_name": "control", "receptor_listener": false, "receptor_listener_port": 27199, "receptor_listener_protocol": "tcp", "receptor_log_level": "info"}}}

Automation Controller4.0 以前のバージョンからアップグレードすると、レガシーな instance_group_ メンバーに awx コードがインストールされている可能性があります。これにより、そのノードが オートメーションコントローラー グループに配置されます。

システム管理者として /api/v2/instance_groups に POST リクエストを送信することで、インスタンスグループを作成できます。

インスタンスグループを作成したら、以下を使用してインスタンスをインスタンスグループに関連付けることができます。

HTTP POST /api/v2/instance_groups/x/instances/ {'id': y}`

インスタンスグループに追加したインスタンスは、グループのワークキューをリッスンするように自動で再設定されます。詳細は、次のセクション インスタンスグループポリシー を参照してください。

ポリシーを定義することにより、オンラインになると自動的にインスタンスグループに参加するように Automation Controller インスタンスを設定できます。これらのポリシーは、新しいインスタンスがオンラインになるたびに評価されます。

インスタンスグループのポリシーは、インスタンスグループ 上の以下の 3 つのオプションフィールドによって制御されます。

Automation Controller ユーザーインターフェイス (UI) の インスタンスグループ リストビューには、インスタンスグループポリシーに基づいた各インスタンスグループの容量レベルの概要が表示されます。

ポリシーに関して以下の点を考慮してください。

インスタンスが特別で、特定のインスタンスグループだけに割り当てる必要があり、"percentage" または "minimum" のポリシーで他のグループに自動的に参加させない場合には、以下を行います。

これにより、インスタンスが percentage と minimum ポリシーに基づいて他のグループに自動的に追加されるのを防ぎます。当該インスタンスは、手動で割り当てたグループにのみ属します。

HTTP PATCH /api/v2/instance_groups/N/
{
"policy_instance_list": ["special-instance"]
}
HTTP PATCH /api/v2/instances/X/
{
"managed_by_policy": False
}

インスタンスグループに関連付けられたジョブを実行する場合は、次の動作に注意してください。

インスタンスグループをジョブテンプレート、インベントリー、または組織に関連付けた場合、そのジョブテンプレートから実行したジョブはデフォルトの動作の対象になりません。つまり、これら 3 つのリソースに関連付けられたインスタンスグループ内のすべてのインスタンスが容量不足の場合、容量が利用可能になるまでジョブが保留状態になります。

ジョブ送信先のインスタンスグループを決定する際の優先順位は、以下のとおりです。

インスタンスグループをジョブテンプレートに関連付け、すべてのインスタンスグループが容量に達している場合、ジョブはインベントリーで指定したインスタンスグループに送信され、次に組織で指定したインスタンスグループに送信されます。リソースが利用可能な場合、優先順位の高いグループから順にジョブを実行する必要があります。

Playbook で定義されているカスタムインスタンスグループなど、リソースにグローバル デフォルト グループを関連付けることも可能です。これを使用して、ジョブテンプレートまたはインベントリーで優先インスタンスグループを指定できます。一方で、容量が不足している場合には任意のインスタンスにジョブを送信できます。

ここでは、次の 2 つの例を示します。

このようにリソースを配置すると、柔軟性が得られます。また、インスタンスを 1 つだけ含むインスタンスグループを作成して、Automation Controller クラスター内の特定のホストに作業を割り振ることもできます。

外部ビジネスロジックにより、インスタンスグループに送信したジョブの同時実行性や、消費するフォークの最大数を制限する必要性が高まる場合があります。

従来のインスタンスおよびインスタンスグループの場合、2 つの組織が同じ基盤インスタンス上でジョブを実行できるようにしながら、各組織の同時実行ジョブの総数を制限することが推奨されます。これは、組織ごとにインスタンスグループを作成し、max_concurrent_jobs の値を割り当てることで実現できます。

Automation Controller グループの場合、Automation Controller は通常、OpenShift クラスターのリソース制限を認識しません。namespace の Pod 数に制限を設定することができます。自動スケーリングが設定されていない場合には、一度に特定の数の Pod をスケジュールするのに使用できるリソースのみに設定したりできます。この場合は、max_concurrent_jobs の値を調整できます。

利用可能な別のパラメーターは max_forks です。このパラメーターにより、インスタンスグループまたはコンテナーグループで消費される容量の上限をさらに柔軟に設定できます。このパラメーターは、さまざまなインベントリーサイズと "forks" 値を持つジョブが実行されている場合に使用できます。これにより、組織が同時に実行できるジョブの数を最大 10 個に制限し、一度に消費するフォークの数を最大 50 個に制限できます。

max_concurrent_jobs: 10
max_forks: 50

それぞれ 5 つのフォークを使用する 10 個のジョブを実行している場合、これらのジョブの 1 つがそのグループでの実行を終了する (または、容量のある別のグループでスケジュールされる) まで、11 番目のジョブは待機します。

2 つのジョブがそれぞれ 20 個のフォークで実行されている場合、task_impact が 11 以上の 3 番目のジョブは、これらのジョブのいずれかが終了するまで待機し、そのグループで実行されるか (または、容量のある別のグループにスケジュールされる) ことになります。

コンテナーグループの場合、すべてのジョブはジョブの forks 値に関係なく、同じリソース要求を持つ同じ pod_spec を使用して送信されるため、max_forks 値を使用することが有用です。デフォルトの pod_spec は 制限ではなく要求を設定するため、Pod はスロットリングや削除を受けることなく、要求された値を超えてバーストすることができます。max_forks の値 を設定することで、フォーク数が大きいジョブが多数同時にスケジュールされ、要求された値よりも多くのリソースを使用する複数の Pod によって OpenShift ノードが過剰にリソースを消費してしまうという状況を防ぐことができます。

インスタンスグループ内の同時実行ジョブとフォークの最大値を設定するには、Automation Controller ユーザーガイド の インスタンスグループの作成を 参照してください。

設定用 Playbook を再実行しても、インスタンスのプロビジョニングは解除されません。これは現在、インスタンスが意図的にオフラインにされたのか、障害が原因でオフラインになったのかをクラスターが識別できないためです。代わりに、Automation Controller インスタンスの全サービスをシャットダウンした後に、他のインスタンスからプロビジョニング解除ツールを実行します。

Automation Controller でインスタンスグループのプロビジョニングを解除しても、インスタンスグループは自動的にプロビジョニング解除されたり削除されたりしません (再プロビジョニングによって当該インスタンスグループが使用されなくなることはしばしばあります)。インスタンスグループは、引き続き API エンドポイントや統計監視に表示される可能性があります。次のコマンドを使用すると、これらのグループを削除できます。

awx-manage unregister_queue --queuename=<name>

インベントリーファイルのインスタンスグループからインスタンスのメンバーシップを削除し、設定用 Playbook を再実行しても、インスタンスがグループに再度追加されなくなるわけではありません。インスタンスがグループに再度追加されないようにするには、API を介してインスタンスを削除し、インベントリーファイルからも削除します。インベントリーファイルでのインスタンスグループの定義をやめることもできます。Automation Controller UI を通じてインスタンスグループのトポロジーを管理できます。UI でのインスタンスグループの管理に関する詳細は、Automation Controller ユーザーガイド の インスタンスグループの管理を 参照してください。