21. ジョブ¶

21.1.1. 詳細¶

詳細 ペインには、ジョブの基本的なステータスおよびその開始時間が表示されます。詳細 ペインの右上にあるアイコンからジョブの再起動 () または削除 () を実行できます。

詳細 ペインでは、ジョブ実行についての詳細が表示されます。

• ステータス: 以下のいずれかになります。

  • 保留中: インベントリーの同期は作成されていますが、まだキューに入れられていないか、または開始されていません。すべてのジョブ (インベントリーソースの同期に限らない) はシステムで実際に実行可能になるまで保留中の状態になります。インベントリーソースの同期が準備できる状態でない理由として、依存関係が現在実行中であるか (次の手順に進む前にすべての依存関係の実行が完了していなければならない)、または設定先で実行する容量が足りないなどが挙げられます。

  • 待機中: インベントリーの同期はキューに入れられており、実行を待機中です。

  • 実行中: インベントリーの同期が進行中です。

  • 成功: インベントリー同期ジョブが成功しました。

  • 失敗: インベントリーの同期ジョブが失敗しました。

• ライセンスエラー: インベントリーの同期 ジョブについてのみ表示されます。これが True の場合、インベントリーの同期でホストが追加されたために、Tower の管理ホストのライセンス数が制限を上回りました。

• ホスト制限エラー: ジョブのインベントリーが、システム管理者が定義したホストの上限を超えて組織に属していることを示しています。

• 開始: ジョブが Tower で開始された時点のタイムスタンプ。

• 完了日時: ジョブの完了時点のタイプスタンプ。

• 起動者: ジョブを開始したユーザーの名前。

• インベントリー: 関連付けられたインベントリーグループの名前。

• ソース: クラウドインベントリーのタイプ。

• 上書き: True の場合には、外部ソースに存在していたホストおよびグループは削除され、Tower インベントリーから削除されます。インベントリーソースで管理されていなかったホストおよびグループは、次に手動で作成されたグループにプロモートされるか、または手動で作成されたプロモーと先のグループがない場合には、インベントリーの「すべて」のデフォルトグループに置かれたままとなります。False の場合には、ローカルの子グループやグループが外部ソースで見つからない場合には、インベントリー更新プロセスからの影響は受けません。

• 変数の上書き: True の場合には、子グループおよびホストの変数はすべて削除され、外部ソースの変数に置き換えられます。False の場合には、マージが実行され、ローカル変数と外部ソースの変数が組み合わされます。

• 詳細: インベントリーソースの更新ジョブ用に Ansible が生成する出力のレベルを制御します。

• 環境: 使用される仮想環境。

• 実行ノード: ジョブの実行に使用されるノード。

• インスタンスグループ: このジョブで使用されるインスタンスグループの名前 (tower はデフォルトのインスタンスグループ)。

これらの項目をクリックすると、適切な場合には該当するジョブテンプレート、プロジェクトその他の Tower オブジェクトが表示されます。

21.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」を参照してください。

21.2.1. 詳細¶

詳細 ペインには、ジョブの基本的なステータスおよびその開始時間が表示されます。詳細 ペインの右上にあるアイコンからジョブの再起動 () または削除 () を実行できます。

詳細 ペイン: ジョブ実行についての詳細を提供します。

• 名前: 関連付けられたインベントリーグループの名前。

• ステータス: 以下のいずれかになります。

  • 保留中: SCM ジョブは作成されていますが、まだキューに入れられていないか、または開始されていません。すべてのジョブ (SCM ジョブに限らない) はシステムで実際に実行可能になるまで保留中の状態になります。SCM ジョブが準備できる状態でない理由として、依存関係が現在実行中であるか (次の手順に進む前にすべての依存関係の実行が完了していなければならない)、または設定先で実行する容量が足りないなどが挙げられます。

  • 待機中: SCM ジョブはキューに入れられており、実行を待機中です。

  • 実行中: SCM ジョブが進行中です。

  • 成功: 直前の SCM ジョブが成功しました。

  • 失敗: 直前の SCM ジョブが失敗しました。

• 開始: ジョブが Tower で開始された時点のタイムスタンプ。

• 完了日時: ジョブの完了時点のタイプスタンプ。

• 経過時間: ジョブに要した時間の合計。

• 起動タイプ: 手動 または スケジュール済み。

• プロジェクト: プロジェクトの名前。

これらの項目をクリックすると、適切な場合には該当するジョブテンプレート、プロジェクトその他の Tower オブジェクトが表示されます。

21.2.2. 標準出力¶

標準出力 ペインでは、SCM 更新の完全な実行結果が表示されます。ここでは、Ansible のコマンドラインで実行した時に表示される情報と同じ情報が表示され、これはでデバッグに役立ちます。標準出力ペインの右上隅にあるアイコンでは、出力をメインビューに切り替えたり ()、出力をダウンロードしたりできます ()。

21.3.1. 詳細¶

詳細 ペインには、ジョブの基本的なステータスおよびその開始時間が表示されます。詳細 ペインの右上にあるアイコンからジョブの再起動 () または削除 () を実行できます。

詳細 ペイン: ジョブ実行についての詳細を提供します。

• ステータス: 以下のいずれかになります。

  • 保留中: Playbook の実行は作成されていますが、まだキューに入れられていないか、または開始されていません。すべてのジョブ (Playbook の実行に限らない) はシステムで実際に実行可能になるまで保留中の状態になります。Playbook の実行が準備できる状態でない理由として、依存関係が現在実行中であるか (次の手順に進む前にすべての依存関係の実行が完了していなければならない)、または設定先で実行する容量が足りないなどが挙げられます。

  • 待機中: Playbook 実行はキューに入れられており、実行を待機中です。

  • 実行中: Playbook 実行が進行中です。

  • 成功: 直前の Playbook 実行が成功しました。

  • 失敗: 直前の Playbook 実行が失敗しました。

• テンプレート: ジョブが起動されるジョブテンプレートの名前。

• 開始: ジョブが Tower で開始された時点のタイムスタンプ。

• 完了日時: ジョブの完了時点のタイプスタンプ。

• 経過時間: ジョブに要した時間の合計。

• Launch By (起動:): このジョブを起動したユーザー、ジョブ、またはスケジュール済みのスキャンの名前。

• インベントリー: このジョブを実行するために選択されたインベントリー。

• マシンの認証情報: このジョブで使用される認証情報の名前。

• 詳細: ジョブテンプレートの作成時に設定される詳細レベル。

• 追加変数: ジョブテンプレートの作成時に渡される追加変数がここに表示されます。

これらの項目をクリックすると、適切な場合には該当するジョブテンプレート、プロジェクトその他の Tower オブジェクトが表示されます。

21.3.2. 標準出力ペイン¶

標準出力 ペインには、Ansible Playbook の完全な実行結果が表示されます。ここでは、Ansible のコマンドラインで実行した時に表示される情報と同じ情報が表示され、これはデバッグに役立ちます。イベントの概要、ホストのステータス、ホストのイベントを表示することができます。標準出力ペインの右上隅にあるアイコンでは、出力をメインビューに切り替えたり ()、出力をダウンロードしたりできます ()。

21.3.2.1. イベントの概要¶

イベントの概要では、この Playbook の一部として実行されたイベントの集計が表示されます。

• Play 数

• タスク数

• ホスト数

• ジョブテンプレートの実行経過時間

21.3.2.3. 検索¶

Tower 検索を使用して、特定ンおイベント、ホスト名、およびそれらのステータスを検索します。特定のステータスのホストのみをフィルターするには、以下の有効なステータスのいずれかを指定します。

• 変更済み: 実際に実行された Playbook タスク。Ansible タスクはべき等になるように作成される必要があるため、タスクはホストに何も実行せずに正常に終了させることができます。これらの場合に、タスクは Ok を返しますが、Changed (変更済み) は返しません。

• 失敗: 失敗したタスク。このホストについての追加の Playbook の実行は停止しました。

• OK: Playbook タスクは「Ok」を返しました。

• Unreachable (到達不可): ホストはネットワークからアクセスできないか、またはこれに関連した別の致命的なエラーが発生しました。

• Skipped (スキップ): ホストがターゲットの状態に到達するために変更が不要だったので、Playbook のタスクが省略されました。

• Rescued: Ansible 2.8 で導入されたこのオプションは、失敗したタスクを表示してから、レスキューセクションを実行します。

• Ignored: Ansible 2.8 で導入されたこのオプションは失敗したタスクを表示してから、ignore_errors: yes を設定します。

このステータスは、標準出力の各ペインの下部にある、ホストの概要フィールドと呼ばれる統計グループにも表示されます。

以下の例には、失敗したホストのみを含めた検索が表示されています。

Tower 検索の使用についての詳細は、検索 の章を参照してください。

21.3.2.4. 標準出力ビュー¶

標準出力ビューには、特定のジョブで発生するイベントすべてが表示されます。デフォルトでは、すべての行で全詳細が表示されるように展開されています。すべて折り畳む () を使用して、プレイおよびタスクのヘッダーのみを含むビューに切り替えます。標準出力のすべての行を表示するには、() ボタンをクリックします。

または、それぞれのプレイやタスクの横にある矢印アイコンをクリックすると、その詳細をすべて表示することができます。矢印をクリックして横向きから下向きに切り替えると、プレイまたはタスクに関連付けられている行が拡大されます。矢印をもう一度クリックして横向きの位置に戻すと、折りたたみ表示になり、行が非表示になります。

拡張/縮小モードで詳細を表示する際の留意点:

• 縮小表示されない行で、対応する行番号と開始時間を含む、表示されたそれぞれの行。

• プレイまたはタスクの完了後のプレイまたはタスクの開始時の拡張/縮小アイコン。

• 特定のプレイまたはタスクのクエリーを実行する場合、それは完了したプロセスの最後に縮小表示されます。

• エラーメッセージは、出力が大きすぎて表示できないことを示すエラーメッセージが表示される場合があります。これは、4000 を超えるイベントがある場合に生じます。エラーをバイパスするために、特定イベントについての検索およびフィルターを使用します。

• 標準出力 ビューのイベント行にカーソルを置くと、この行の上にツールのヒントが表示され、このタスクで影響を受けた合計ホスト数およびステータスの内訳についての詳細を表示するオプションが表示されます。

標準出力 ペインからイベントの行をクリックすると、ホストイベント ダイアログが別のウィンドウに表示されます。このウィンドウでは、特定のイベントの影響を受けるホストが表示されます。

v3.7.2 以前の Ansible Tower には 、Playbook の実行結果として記録できるイベントの最大数に制限がありました (約 20 億イベント)。3.7 へのアップグレードでは、Playbook の過去のすべての出力を、この制限が取り除かれた新しい拡張データ形式に徐々に移行する必要があります。この移行プロセスは段階的に行われ、インストールが完了するとバックグラウンドで自動的に実行されます。過去のジョブ出力が非常に大量にある (数十 GB、または数百 GB の出力) と、移行が完了するまでジョブの出力が欠落する可能性があります。最新のデータは出力上部に表示され、その後に古いイベントが表示されます。大規模ジョブを移行する場合は、通常の小規模なジョブがある場合に比べて時間がかかる場合があります。

21.3.2.5. ホストイベント¶

ホストイベント ダイアログでは、選択したイベントの影響を受けるホストに関する情報と、それに関連するプレイおよびタスクが表示されます。

• ホスト

• ステータス

• 固有 ID

• Created (作成) タイムスタンプ

• プレイ の名前

• タスク の名前

• 適用可能な場合、タスクの Ansible モジュール、およびモジュールのすべての 引数

• タスクの 標準出力

JSON 形式で結果を表示するには、JSON タブをクリックします。

21.4.1. 容量アルゴリズムに向けたリソースの判断¶

容量アルゴリズムは、システムで同時に実行可能なフォーク数を判断するために定義します。これにより、Ansible 自体が同時に通信するシステム数を制御します。Tower システムが実行するフォーク数が増えると通常、並行して作業が実行され、ジョブの実行速度がをより早くなります。代わりに、システムの負荷が増加し、全体的な作業速度が遅くなってしまう可能性があります。

Tower は、容量の判断時に、2 つのモードで稼働します。mem_capacity (デフォルト) では、システムでメモリーがなくならないようにする一方で、CPU をオーバーコミットできます。作業の多くが CPU に依存していない場合には、このモードを選択して、フォーク数を最大化します。

(mem - 2048) / mem_per_fork

(4096 - 2048) / 100 == ~20

cpus * fork_per_cpu

4 * 4 == 16

21.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 になります。

21.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 ユーザーインターフェースで容量を表示または編集するには、インスタンスグループの インスタンス タブを選択します。

21.5.1. ソースツリーのコピー動作¶

すべてのジョブ実行には、独自のプライベートデータディレクトリーがあります。このディレクトリーには、このジョブが実行されている指定された scm_branch のプロジェクトソースツリーのコピーが含まれています。ジョブは、プロジェクトフォルダーを自由に変更し、実行中にそれらの変更を自由に使用できます。このフォルダーは一時的なものであり、ジョブ実行の終了時にクリーンアップされます。

クリーニング がオンの場合、Tower は`git`_、Subversion、および Mercurial に関連した各 Ansible モジュール内の force パラメーターを使用して、リポジトリーのローカルコピーにある変更ファイルを破棄します。

21.5.2. プロジェクトのリビジョンの動作¶

一般に、プロジェクトの更新中、デフォルトブランチのリビジョン (プロジェクトの SCM ブランチ フィールドで指定) が更新時に保存され、そのプロジェクトを使用するジョブではそのリビジョンが使用されます。ジョブでデフォルト以外の SCM ブランチ (コミットハッシュ値またはタグではない) を使用した場合は、ジョブの開始前に最新のリビジョンがソースコントロールリモートから即時に取得されます。このリビジョンは、ジョブおよびそれぞれのプロジェクト更新の リビジョン フィールドに表示されます。

そのため、デフォルト以外のブランチではオフラインジョブを実行できません。タグを使用するか、ハッシュをコミットを使用して、ジョブが確実にソースコントロールからの静的バージョンを実行するようにします。プロジェクトの更新では、すべてのブランチのリビジョンは保存されず、プロジェクトのデフォルトブランチのみが保存されます。

** SCM ブランチ** フィールドは検証されないため、プロジェクトを更新して有効であることを確認する必要があります。このフィールドが指定されたり、要求されたりした場合には、ジョブテンプレートの Playbook フィールドは検証されず、 ジョブテンプレートを起動して、必要とされる Playbook が存在するかを確認する必要があります。

21.5.3. Git Refspec¶

SCM Refspec フィールドは、更新がリモートからダウンロードする必要がある追加の参照を指定します。以下に例を示します。

1. refs/*:refs/remotes/origin/*: リモートのリモートを含む、すべての参照を取得

2. refs/pull/*:refs/remotes/origin/pull/* (GitHub 専用): すべてのプル要求に対して、すべての参照を取得

3. refs/pull/62/head:refs/remotes/origin/pull/62/head: 対象の GitHub プル要求に対して、参照を取得

プロジェクトの規模が大きく、本書で紹介する 1 例目と 2 例目を使用する場合には、パフォーマンスへの影響を考慮する必要があります。

SCM Refspec パラメーターは、プロジェクトブランチの可用性に影響するものであり、他の場合には利用できない参照へのアクセスを許可できます。上記の例では、ユーザーは SCM ブランチ からのプル要求を指定できますが、これは SCM Refspec フィールドがなければ不可能です。

Ansible git モジュールはデフォルトで refs/heads/* を取得します。つまり、SCM Refspec が空の場合には、プロジェクトのブランチとタグ (およびその中のコミットハッシュ) を SCM ブランチとして使用できます。SCM Refspec フィールドで指定された値は、オーバーライドとして使用できる SCM ブランチ フィールドに影響します。プロジェクトの更新 (任意のタイプ) は、追加の git fetch コマンドを実行して、リモートからその refspec をプルします。

たとえば、1 番目または 2 番目の refspec の例でブランチの上書きを許可するプロジェクトを設定したとします -> ** SCMブランチ** を要求するジョブテンプレートでこれを使用します -> ジョブテンプレートを起動すると、新しいプル要求が作成された場合に、ブランチ pull/N/head が指定されます -> ジョブテンプレートは、指定された GitHub プル要求の参照に対して実行されます。

Ansible git モジュールの詳細は、https://docs.ansible.com/ansible/latest/modules/git_module.html を参照してください。