20. ジョブ¶
job (ジョブ) は、Ansible Playbook をホストのインベントリーに対して起動する Tower のインスタンスです。
ジョブリンクには、ジョブの一覧とそれらのステータスが表示 (正常に完了、失敗、またはアクティブ (実行中の) ジョブとして表示) されます。この画面から実行できるアクションには、特定のジョブの詳細および標準出力、ジョブの起動、またはジョブの削除が含まれます。
Ansible Tower 3.3 以降では、一覧ビューから最新のジョブを再起動できます。一部がすでに正常に実行された場合でも、指定したインベントリーのホストすべてで再実行可能です。こうすることで、再度これらのホストで Playbook を実行せずに、ジョブを再実行できるようになります。また、失敗したホストすべてでジョブを再実行することもできます。これにより、成功したホストを再度処理する必要がなくなるので、Ansible Tower ノードでの負荷を軽減できます。
再起動操作は、Playbook の実行の再起動にのみ適用され、システムジョブ、プロジェクト/インベントリーの更新、システムジョブ、ワークフロージョブなどには適用されません。
すべて を選択すると、全ホストが再起動されます。
失敗 を選択すると、失敗したホストおよび到達できないホストすべてが再起動されます。
再起動後には、そのまま同じページが表示されます。
Tower 検索機能を使用して各種の条件に基づいてジョブを検索します。Tower 検索についての詳細は、「 検索 」の章を参照してください。
どのタイプのジョブをクリックしても、そのジョブのジョブの詳細ビューに移動します。このビューは 2 つのセクションから構成されます。
詳細 ペイン: ジョブについての情報およびステータスを提供するペイン。
標準出力 ペイン: ジョブプロセスおよび出力を表示するペイン。
20.1. Job Details (ジョブの詳細): インベントリーの同期¶
20.1.1. 詳細¶
詳細 ペインには、ジョブの基本的なステータスおよびその開始時間が表示されます。詳細 ペインの右上にあるアイコンからジョブの再起動 (
) または削除 (
) を実行できます。
詳細 ペイン: ジョブ実行についての詳細を提供します。
名前: 関連付けられたインベントリーグループの名前。
ステータス: 以下のいずれかになります。
保留中: インベントリーの同期は作成されていますが、まだキューに入れられていないか、または開始されていません。すべてのジョブ (インベントリーソースの同期に限らない) はシステムで実際に実行可能になるまで保留中の状態になります。ジョブが保留にされる理由には、依存関係にある実行中のジョブの終了を待機する必要があることや、設定された場所にジョブの実行容量が十分にないことがあります。
待機中: インベントリーの同期はキューに入れられており、実行を待機中です。
実行中: インベントリーの同期が進行中です。
成功: インベントリー同期ジョブが成功しました。
失敗: インベントリーの同期ジョブが失敗しました。
説明: 失敗の理由についての説明です。
ライセンスエラー: インベントリーの同期 ジョブについてのみ表示されます。これが True の場合、インベントリーの同期でホストが追加されたために、Tower の管理ホストのライセンス数が制限を上回りました。
開始: ジョブが Tower で開始された時点のタイムスタンプ。
完了日時: ジョブの完了時点のタイプスタンプ。
経過時間: ジョブに要した時間の合計。
起動タイプ: 手動、スケジュール済み、または 依存関係
認証情報: このインベントリー同期で使用される認証情報。
ソース: クラウドインベントリーのタイプ。
上書き: True の場合、外部ソースに存在していたホストおよびグループは削除され、Tower インベントリーから削除されます。インベントリーソースで管理されていなかったホストおよびグループは、次に手動で作成されたグループにプロモートされるか、またはプロモート先となる手動で作成されたグループがない場合には、インベントリーの「すべて」のデフォルトグループに置かれます。False の場合、外部ソースに見つからないローカルの子ホストおよびグループはインベントリー更新プロセスの影響を受けません。
変数の上書き: True の場合には、子グループおよびホストの変数はすべて削除され、外部ソースの変数に置き換えられます。False の場合には、マージが実行され、ローカル変数と外部ソースの変数が組み合わされます。
これらの項目をクリックすると、適切な場合には該当するジョブテンプレート、プロジェクトその他の Tower オブジェクトが表示されます。
20.1.2. 標準出力¶
標準出力 ペインでは、インベントリー同期 Playbook の完全な実行結果が表示されます。ここでは、Ansible のコマンドラインで実行した時に表示される情報と同じ情報が表示され、これはデバッグの際に役立ちます。標準出力ペインの右上隅にあるアイコンでは、出力をメインビューに切り替えたり (
)、出力をダウンロードしたりできます (
)。
Ansible Tower 3.3 以降では、ANSIBLE_DISPLAY_ARGS_TO_STDOUT はデフォルトで、全 Playbook の実行に対して False に設定されます。これは、Ansible のデフォルトの動作と同じです。これにより、Tower はジョブ詳細インターフェースのタスクヘッダーにタスクの引数を表示しなくなり、標準出力に特定の機密情報のモジュールパラメーターを漏洩しなくなります。以前の動作を復元するには (セキュリティーの問題がありますが)、AWX_TASK_ENV 構成設定から ANSIBLE_DISPLAY_ARGS_TO_STDOUT を True に設定できます。詳細情報は、ANSIBLE_DISPLAY_ARGS_TO_STDOUT を参照してください。
20.2. Job Details (ジョブの詳細): SCM¶
20.2.1. 詳細¶
詳細 ペインには、ジョブの基本的なステータスおよびその開始時間が表示されます。詳細 ペインの右上にあるアイコンからジョブの再起動 () または削除 () を実行できます。
詳細 ペイン: ジョブ実行についての詳細を提供します。
名前: 関連付けられたインベントリーグループの名前。
ステータス: 以下のいずれかになります。
保留中: SCM ジョブは作成されていますが、まだキューに入れられていないか、または開始されていません。すべてのジョブ (SCM ジョブに限らない) はシステムで実際に実行可能になるまで保留中の状態になります。ジョブが保留にされる理由には、依存関係にある実行中のジョブの終了を待機する必要があることや、設定された場所にジョブの実行容量が十分にないことがあります。
待機中: SCM ジョブはキューに入れられており、実行を待機中です。
実行中: SCM ジョブが進行中です。
成功: 直前の SCM ジョブが成功しました。
失敗: 直前の SCM ジョブが失敗しました。
開始: ジョブが Tower で開始された時点のタイムスタンプ。
完了日時: ジョブの完了時点のタイプスタンプ。
経過時間: ジョブに要した時間の合計。
起動タイプ: 手動 または スケジュール済み。
プロジェクト: プロジェクトの名前。
これらの項目をクリックすると、適切な場合には該当するジョブテンプレート、プロジェクトその他の Tower オブジェクトが表示されます。
20.2.2. 標準出力¶
標準出力 ペインでは、SCM 更新の完全な実行結果が表示されます。ここでは、Ansible のコマンドラインで実行した時に表示される情報と同じ情報が表示され、これはでデバッグに役立ちます。標準出力ペインの右上隅にあるアイコンでは、出力をメインビューに切り替えたり ()、出力をダウンロードしたりできます ()。
20.3. Job Details (ジョブの詳細): Playbook の実行¶
Playbook 実行 ジョブのジョブの詳細ビューには、ジョブテンプレート ページからジョブを起動した後にもアクセスできます。
20.3.1. 詳細¶
詳細 ペインには、ジョブの基本的なステータスおよびその開始時間が表示されます。詳細 ペインの右上にあるアイコンからジョブの再起動 () または削除 () を実行できます。
詳細 ペイン: ジョブ実行についての詳細を提供します。
ステータス: 以下のいずれかになります。
保留中: Playbook 実行は作成されていますが、まだキューに入れられていないか、または開始されていません。すべてのジョブ (Playbook に限らない) はシステムで実際に実行可能になるまで保留中の状態になります。ジョブが保留にされる理由には、依存関係にある実行中のジョブの終了を待機する必要があることや、設定された場所にジョブの実行容量が十分にないことがあります。
待機中: Playbook 実行はキューに入れられており、実行を待機中です。
実行中: Playbook 実行が進行中です。
成功: 直前の Playbook 実行が成功しました。
失敗: 直前の Playbook 実行が失敗しました。
テンプレート: ジョブが起動されるジョブテンプレートの名前。
開始: ジョブが Tower で開始された時点のタイムスタンプ。
完了日時: ジョブの完了時点のタイプスタンプ。
経過時間: ジョブに要した時間の合計。
Launch By (起動:): このジョブを起動したユーザー、ジョブ、またはスケジュール済みのスキャンの名前。
インベントリー: このジョブを実行するために選択されたインベントリー。
マシンの認証情報: このジョブで使用される認証情報の名前。
詳細: ジョブテンプレートの作成時に設定される詳細レベル。
追加変数: ジョブテンプレートの作成時に渡される追加変数がここに表示されます。
これらの項目をクリックすると、適切な場合には該当するジョブテンプレート、プロジェクトその他の Tower オブジェクトが表示されます。
20.3.2. 標準出力ペイン¶
標準出力 ペインには、Ansible Playbook の完全な実行結果が表示されます。ここでは、Ansible のコマンドラインで実行した時に表示される情報と同じ情報が表示され、これはデバッグに役立ちます。イベントの概要、ホストのステータス、ホストのイベントを表示することができます。標準出力ペインの右上隅にあるアイコンでは、出力をメインビューに切り替えたり ()、出力をダウンロードしたりできます ()。
20.3.2.1. イベントの概要¶
イベントの概要では、この Playbook の一部として実行されたイベントの集計が表示されます。
Play 数
タスク数
ホスト数
ジョブテンプレートの実行経過時間
20.3.2.2. ホストのステータスバー¶
ホストのステータスバーは、標準出力 ペインの上部で実行されます。ホストステータスバーのセクションにカーソルを置くと、その特定のステータスに関連付けられたホスト数が表示されます。
20.3.2.3. 検索¶
Tower 検索を使用して、特定ンおイベント、ホスト名、およびそれらのステータスを検索します。特定のステータスのホストのみをフィルターするには、以下の有効なステータスのいずれかを指定します。
変更済み: 実際に実行された Playbook タスク。Ansible タスクはべき等になるように作成される必要があるため、タスクはホストに何も実行せずに正常に終了させることができます。これらの場合に、タスクは Ok を返しますが、Changed (変更済み) は返しません。
失敗: 失敗したタスク。このホストについての追加の Playbook の実行は停止しました。
OK: Playbook タスクは「Ok」を返しました。
Unreachable (到達不可): ホストはネットワークからアクセスできないか、またはこれに関連した別の致命的なエラーが発生しました。
Skipped (スキップ): ホストがターゲットの状態に到達するために変更が不要だったので、Playbook のタスクが省略されました。
以下の例には、失敗したホストのみを含めた検索が表示されています。
Tower 検索の使用についての詳細は、検索 の章を参照してください。
20.3.2.4. 標準出力ビュー¶
標準出力ビューには、特定のジョブで発生するイベントすべてが表示されます。デフォルトでは、すべての行で全詳細が表示されるように展開されています。すべて折り畳む (
) を使用して、プレイおよびタスクのヘッダーのみを含むビューに切り替えます。標準出力のすべての行を表示するには、(
) ボタンをクリックします。
または、それぞれのプレイやタスクの横にある矢印アイコンをクリックすると、その詳細をすべて表示することができます。矢印をクリックして横向きから下向きに切り替えると、プレイまたはタスクに関連付けられている行が拡大されます。矢印をもう一度クリックして横向きの位置に戻すと、折りたたみ表示になり、行が非表示になります。
拡張/縮小モードで詳細を表示する際の留意点:
縮小表示されない行で、対応する行番号と開始時間を含む、表示されたそれぞれの行。
プレイまたはタスクの完了後のプレイまたはタスクの開始時の拡張/縮小アイコン。
特定のプレイまたはタスクのクエリーを実行する場合、それは完了したプロセスの最後に縮小表示されます。
エラーメッセージは、出力が大きすぎて表示できないことを示すエラーメッセージが表示される場合があります。これは、4000 を超えるイベントがある場合に生じます。エラーをバイパスするために、特定イベントについての検索およびフィルターを使用します。
標準出力 ビューのイベント行にカーソルを置くと、この行の上にツールのヒントが表示され、このタスクで影響を受けた合計ホスト数およびステータスの内訳についての詳細を表示するオプションが表示されます。
標準出力 ペインからイベントの行をクリックすると、ホストイベント ダイアログが別のウィンドウに表示されます。このウィンドウでは、特定のイベントの影響を受けるホストが表示されます。
20.3.2.5. ホストイベント¶
ホストイベント ダイアログでは、選択したイベントの影響を受けるホストに関する情報と、それに関連するプレイおよびタスクが表示されます。
ホスト
ステータス
固有 ID
Created (作成) タイムスタンプ
プレイ の名前
タスク の名前
適用可能な場合、タスクの Ansible モジュール、およびモジュールのすべての 引数
タスクの 標準出力
JSON 形式で結果を表示するには、JSON タブをクリックします。
20.4. Ansible Tower の容量判断およびジョブの影響¶
Ansible Tower 容量システムは、インスタンスで利用可能なリソース量や、実行中のジョブのサイズ (影響 と呼ぶ) をもとに、インスタンスでいくつのジョブを実行可能か判断します。これを判断するのに使用するアルゴリズムは、2 つのアイテムだけをベースとします。
システムで利用可能なメモリー容量 (
mem_capacity)システムで利用可能な CPU 数 (
cpu_capacity)
容量は、インスタンスグループにも影響があります。グループはインスタンスで構成されるので、インスタンスを複数のグループに割り当てることができます。つまり、インスタンス 1 台への影響が、他のグループ全体の容量に影響を与える可能性があります。
インスタンスグループ (インスタンス自体ではなく) は、さまざまなレベルのジョブで使用するために割り当てることができます (「 クラスタリング 」参照)。タスクマネージャーはグラフを作成し、ジョブの実行先のグループや、起動の準備ができていないジョブに対してインスタンスグループの容量をコミットするかどうかを判断します。
最終的に、小規模な構成で、ジョブ実行に利用可能なインスタンスが 1 台しかない場合には、タスクマネージャーは、インスタンスが容量を超えていても、インスタンスでジョブが実行できるようにします。こうすることで、プロビジョニングが十分でないシステムでも、ジョブが停止しないようになります。
このように、容量および影響は、ジョブやインスタンス/インスタンスグループに対してゼロサムシステムではありません。
スライスされたジョブおよび容量への影響に関する情報は、「 ジョブスライスの実行動作 」を参照してください。
20.4.1. 容量アルゴリズムに向けたリソースの判断¶
容量アルゴリズムは、システムで同時に実行可能なフォーク数を判断するために定義します。これにより、Ansible 自体が同時に通信するシステム数を制御します。Tower システムが実行するフォーク数が増えると通常、並行して作業が実行され、ジョブの実行速度がをより早くなります。代わりに、システムの負荷が増加し、全体的な作業速度が遅くなってしまう可能性があります。
Tower は、容量の判断時に、2 つのモードで稼働します。mem_capacity (デフォルト) では、システムでメモリーがなくならないようにする一方で、CPU をオーバーコミットできます。作業の多くが CPU に依存していない場合には、このモードを選択して、フォーク数を最大化します。
20.4.1.1. メモリー対容量¶
mem_capacity は、フォークごとに必要なメモリー容量に対して、計算されます。Tower の内部コンポーネントのオーバーヘッドを考慮すると、これは、フォークごとに約 100 MB になります。Ansible ジョブで利用可能なメモリー容量を検討する場合には、容量アルゴリズムでは、他の Tower サービスの存在することを考慮し、メモリー 2 GB を確保します。これに関するアルゴリズムの公式は以下のようになります。
(mem - 2048) / mem_per_fork
以下に例を示します。
(4096 - 2048) / 100 == ~20
このように、メモリー 4GB のシステムは、フォーク 20 個分実行することができます。mem_per_fork の値は、Tower の設定値 (または環境変数) SYSTEM_TASK_FORKS_MEM (デフォルト値は 100) を設定して制御できます。
20.4.1.2. CPU 対容量¶
頻繁に、Ansible のワークロードが CPU に大きく依存する場合があります。このような場合には、同時の実行するワークロードを減らして、タスクの実行速度を高め、これらのジョブの平均完了時間を短縮することができる場合があります。
Tower の mem_capacity アルゴリズムでフォークごとに必要なメモリー容量を使用するように cpu_capacity アルゴリズムも、フォークごとに必要な CPU リソース数に着目します。このベースラインの値として、コアごとのフォーク数が 4 つとなります。CPU のアルゴリズムの公式は以下のとおりです。
cpus * fork_per_cpu
たとえば、4 つのコアが搭載されているシステムの場合:
4 * 4 == 16
fork_per_cpu の値は、Tower の設定値 (または環境変数) SYSTEM_TASK_FORKS_CPU (デフォルト値は 4) を設定して制御できます。
20.4.2. ジョブが影響を与える容量¶
容量を選択する場合に、各ジョブタイプがどのように容量に影響を与えるかを理解することが重要です。
Ansible とフォークの関係を理解すると便利です: https://www.ansible.com/blog/ansible-performance-tuning ("Know Your Forks" のセクションを参照)。
Ansible のデフォルトのフォーク値は 5 ですが、Tower では実際には 5 台未満のシステムに対して実行していることを認識しているので、実際の同時並行処理の値は 5 よりも少なくなります。
ジョブ実行時に、Ansible の親プロセスに対応するために、Tower はフォークの選択数に 1 つ追加します。そのため、フォークの値が 5 のシステム 5 台に対して、Playbook を実行する場合には、ジョブの影響に関する実際のフォーク値は 6 になります。
20.4.2.1. Tower でのジョブタイプの影響¶
ジョブとアドホックのジョブは、上記のモデル (フォーク + 1) を採用します。ジョブテンプレートでフォークの値を設定する場合は、ジョブの容量値は指定のフォーク最小値、使用するホスト数に 1を加えた数値になります。1 を加えることで、親 Ansible プロセスに対応します。
インスタンスの容量で、どのジョブを特定のインスタンスに割り当てるかを決定します。フォークの値が高く指定されている場合には、ジョブとアドホックコマンドは、より多くの容量を使用します。
他のジョブタイプへの影響は固定されています。
インベントリーの更新: 1
プロジェクトの更新: 1
システムジョブ: 5
ジョブテンプレートにフォークの値を設定しない場合には、ジョブは Ansible のデフォルトのフォーク値 4 を使用します。Ansible のデフォルト値はフォーク 5 ですが、ジョブのホストが 5 台未満の場合には、フォークの使用数は少なくなります。一般的に、フォークの値に、システムの機能より高い数値を設定すると、メモリーが足りなくなったり、CPU をオーバーコミットしたりする問題が発生する可能性があります。個別のシステムではそれほど容量がないにも拘わらず、Playbook でフォーク 1000 個を使用する場合には、システムのサイズが小さすぎたり、パフォーマンスやリソースの問題のリスクが発生したりします。
20.4.2.2. 適切な容量の選択¶
CPU バインドまたはメモリーバインドの容量制限から容量を選択するのは、実質的には、フォーク数の最小数または最大数を選択していることになります。上記の例では、CPU の容量でフォーク数を最大 16 個許容し、メモリー容量では 20 個許容できます。システムによっては、これらの差異は大きくなる可能性があり、多くの場合にこれらの 2 つの間でバランスを取っていくと良いでしょう。
インスタンスフィールド capacity_adjustment では、どちらをどの程度考慮するかを選択できます。これは、0.0 から 1.0 の値で表します。値を 1.0 に設定すると、最大値が使用されます。上記の例では、メモリー容量となるので、フォークの値を 20 が選択されます。値を 0.0 に設定すると、最小値が使用されます。また、0.5 は 2 つのアルゴリズムを 50/50 の割合で使用することになり、フォーク数は 18 になります。
16 + (20 - 16) * 0.5 == 18
Tower ユーザーインターフェースで容量を表示または編集するには、インスタンスグループの インスタンス タブを選択します。
