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

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

インベントリーファイルでカスタムグループを定義するには、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 Controller 4.0 以前のバージョンからアップグレードした後は、レガシーの instance_group_ メンバーに awx コードがインストールされている可能性があります。これにより、ノードが automationcontroller グループに配置されます。

インスタンスグループは、システム管理者として /api/v2/instance_groups に POST 要求を出すことで作成できます。

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

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

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

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

インスタンスグループポリシーは、Instance Group の次の 3 つの任意フィールドにより制御されます。

Automation Controller ユーザーインターフェイス (UI) の Instance Groups リストビューには、インスタンスグループポリシーをもとにした各インスタンスグループのキャパシティーレベルの概要が表示されます。

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

インスタンスが特別で、特定のインスタンスグループだけに割り当てる必要があり、"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 で定義されたカスタムインスタンスグループなどのリソースに、グローバルの default グループを関連付けることもできます。これを使用して、ジョブテンプレートまたはインベントリーで優先インスタンスグループを指定できます。一方で、容量が不足している場合には任意のインスタンスにジョブを送信できます。

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

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

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

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

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

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

max_concurrent_jobs: 10
max_forks: 50

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

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

コンテナーグループの場合、ジョブの "forks" 値に関係なく、すべてのジョブが同じリソース要求で同じ pod_spec を使用して送信されるため、max_forks 値を使用すると便利です。デフォルトの pod_spec は、制限ではなく要求を設定します。そのため、Pod はスロットリングが適用されたりリープされたりすることなく、要求した値を超えて「バースト」できます。max_forks 値を設定することで、フォーク値の大きい多数のジョブが同時にスケジュールされ、OpenShift ノードが、要求した値よりも多くのリソースを使用して複数の Pod でオーバーサブスクライブされるという状況を防ぐことができます。

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

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

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

awx-manage unregister_queue --queuename=<name>

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