Documentation

17. ワークフロー

ワークフローを使うと、インベントリー、Playbook、またはパーミッションを共有または共有しない可能性のある一連の個別ジョブテンプレートを設定することができます。ただし、ワークフローには、ジョブテンプレートと同様の「管理者」および「実行」パーミッションがあります。ワークフローは、リリースプロセスの一部となっていたジョブの完全なセットを追跡するタスクを単一ユニットとして実行します。

注釈

ワークフローは Enterprise レベルのライセンスを持つユーザーのみが利用できます。

ジョブテンプレートは、ノードと呼ばれるグラフのような構造を使って相互にリンクされます。ジョブテンプレートノードはジョブテンプレートに関連付けられます。ジョブテンプレートは異なるワークフローの一部となることも、同じワークフローで複数回使用することもできます。グラフ構造のコピーは、ワークフローの起動時にワークフロージョブに保存されます。

ワークフローの実行時に、ジョブはノードのリンクされたテンプレートから生成されます。プロンプト方式 (prompt-driven) のフィールド (job_type、job_tags, skip_tags、制限、および関連付けられた認証情報およびインベントリー) を持つジョブテンプレートにリンクするノードにはそれらのフィールドが含まれる場合があり、それらは起動時にジョブに入れられます。各ワークフローノードに関連付けられるジョブテンプレートは、処理時に成否のシナリオに基づいて実行されます。ジョブが正常に完了すると他のジョブの実行がトリガーされ、ジョブが失敗すると別のジョブの実行がトリガーされる可能性があります。

ノードには、1 つの親および「Success (成功)」、「Failure (失敗)」または「Always (常時)」の状態にリンクされた子のみを設定できます。「Always (常時)」の場合、状態は「Success (成功)」でも「Failure (失敗)」でもありません。状態はワークフロージョブテンプレートのレベルではなく、ノードのレベルで適用されます。ワークフロージョブは、取り消されないか、エラーが生じない場合にのみ「Success (成功)」とマークされます。

以下が欠落しているワークフロージョブテンプレートを起動しようとする場合、ユーザーインターフェースから警告が通知されますが、プロセスは継続します。

  • ノードから削除されたジョブテンプレート
  • プロンプトが出されたフィールドが提供されますが、ジョブテンプレートは起動時にフィールドのプロンプトを出すように設定されません。

API から起動する場合、get コマンドを実行すると、警告の一覧が表示され、欠落しているコンポーネントが強調表示されます。ワークフロージョブテンプレートの基本的なワークフローは以下に示す通りです。

_images/workflow-diagram.png

いくつかのワークフローを同時に起動し、それらの起動時のスケジュールを設定することができます。ジョブテンプレートと同様に、ジョブの完了時など、ワークフローに通知を設定することができます。

17.1. 追加変数

ジョブテンプレートと同様に、ワークフローは Survey を使用して、extra_vars というワークフローの Playbook で使用される変数を指定します。Survey 変数はワークフロージョブテンプレートで定義される extra_vars defined と組み合わされ、ワークフロージョブ extra_vars に保存されます。ワークフロージョブの extra_vars は、ワークフロー内のジョブの生成時にジョブテンプレート変数に組み合わされます。

ワークフローは、3 つの追加変数を除き、ジョブテンプレートと同じ変数の順序の動作 (階層) を使用します。本書のジョブテンプレートの章の 追加変数 セクションの Ansible Tower 変数の順序の階層について参照してください。3 つの追加の変数には以下が含まれます。

_images/Architecture-Tower_Variable_Precedence_Hierarchy-Workflows.png

ワークフローの extra_vars のほかにも、ワークフローの一部として実行されるジョブは、ワークフローの親ジョブのアーティファクト辞書の変数を継承できます (また、ブランチの先祖のアップストリームと組み合わされます)。これらは、set_stats Ansible モジュールのバージョン 2.2.2 以降で定義できます。

Playbook で set_stats モジュールを使用すると、別のジョブでダウンストリームで使用できる結果を出す生成できます。たとえば、ユーザーに対し、統合の実行の成功または失敗について通知することができます。この例では、アーティファクトを渡すためにワークフローに組み合わせることのできる 2 つの Playbook を示します。

  • invoke_set_stats.yml: ワークフローの最初の Playbook
              - hosts: localhost
tasks:
  - name: "Artifact integration test results to the web"
    local_action: 'shell curl -F "file=@integration_results.txt" https://file.io'
    register: result

  - name: "Artifact URL of test results to Tower Workflows"
    set_stats:
      data:
        integration_results_url:  "{{ (result.stdout|from_json).link }}"
  • use_set_stats.yml: ワークフローの 2 番目の Playbook
      - hosts: localhost
tasks:
  - name: "Get test results from the web"
    uri:
      url: "{{ integration_results_url }}"
      return_content: true
    register: results


  - name: "Output test results"
    debug:
      msg: "{{ results.content }}"

set_stats モジュールはこのワークフローを以下のように処理します。

  1. 統合の結果の内容 (例: 以下の integration_results.txt) がまず web にアップロードされます。
the tests are passing!
  1. 次に invoke_set_stats Playbook により、set_stats が起動すると、アップロードされた integration_results.txt の URL が作成され、Ansible 変数「integration_results_url」に渡されます。
  2. ワークフローの 2 つ目の Playbook は、Ansible 追加変数「integration_results_url」を使用します。これは、uri モジュールを使用して web に対して呼び出しを実行し、直前のジョブテンプレートジョブでアップロードされたファイルの内容を取得します。次に、取得したファイルの内容を単純に出力します。
_images/wf-templates_set_stats.png

17.2. ワークフローの状態

ワークフロージョブには以下の状態が設定されます (「失敗」状態は含まれなし)。

  • 待機中
  • 実行中
  • 成功 (終了)
  • 取り消し
  • エラー

ワークフローのスキームでは、ジョブを取り消すとブランチが取り消され、ワークフロージョブを取り消すとワークフロー全体が取り消されます。ジョブテンプレートを削除してもジョブノードは削除されませんが、ユーザーインターフェースにそれが無効であることが示され、ワークフローに壊れたリンクが表示されます。次に、ワークフローの構造への影響なしの修正を求めるプロンプトが出されます。

17.3. ロールベースのアクセス制御

ワークフロージョブテンプレートを編集し、削除するには、管理者ロールが必要です。ワークフロージョブテンプレートを作成するには、組織管理者またはシステム管理者である必要になります。ただし、パーミッションのないジョブテンプレートが含まれるワークフロージョブテンプレートを実行することは可能です。プロジェクトと同様に、組織管理者は空のワークフローを作成してから、admin_role を管理者権限を持たないユーザーに割り当てると、それらのユーザーは追加のアクセスを委任したり、グラフを作成したりできます。ジョブテンプレートをワークフロージョブテンプレートに追加するには、ジョブテンプレートへの実行アクセスがなればなりません。

特定のユーザーに付与されるパーミッションの種類に応じて、複製コピーを作成したり、ワークフローを再起動する機能などの他のタスクを実行することもできます。通常は、再起動やコピーの作成を実行する前に (ジョブテンプレートなどの) ワークフローで使用されるすべてのリソースに対するパーミッションが必要になります。

このセクションで説明されているタスクを実行する方法についての詳細は、Ansible Tower Administration Guide を参照してください。