20. ジョブテンプレート¶

20.1. ジョブテンプレートの作成¶

新規ジョブテンプレートを作成するには、以下を実行します。

1. 追加 ボタンをクリックしてから、メニュー一覧で ジョブテンプレート を選択します。

2. 以下のフィールドに該当する詳細を入力します。

Job Template default credentials must be replaced
with one of the same type. Please select a credential
for the following types in order to proceed: Machine.

3. オプション: 必要に応じて、このテンプレートを起動するためのオプションを指定します。

• 権限昇格: オンにすると、この Playbook を管理者として実行できます。これは、--become オプションを ansible-playbook コマンドに渡すことに相当します。

• プロビジョニングコールバック: オンにすると、ホストが REST API 経由で automation controller に対してコールバックできるようになり、このジョブテンプレートからジョブを起動できるようになります。詳細は、プロビジョニングコールバック を参照してください。

• Webhook の有効化: ジョブテンプレートを起動するために使用される定義済みの SCM システム Web サービスとのインターフェース機能を有効にします。現在サポートされている SCM システムは GitHub と GitLab です。

Webhook を有効にすると、他のフィールドが表示され、以下の追加情報の入力を求められます。

• Webhook サービス: Webhook からリッスンするサービスを選択します

• Webhook URL: POST 要求を送信する Webhook サービスの URL が自動的に入力されます。

• Webhook Key: automation controller に送信されたペイロードへの署名に Webhook サービスが使用するために生成された共有シークレット。automation controller がこのサービスから Webhook を受け入れるには、Webhook サービスでこの設定が行われている必要があります。

• Webhook の認証情報: オプションで、ステータス更新を Webhook サービスに送り返すために使用する認証情報として GitHub または GitLab のパーソナルアクセストークン (PAT) を指定します。選択するには認証情報が存在する必要があります。作成するには、「認証情報タイプ」を参照してください。

Webhook の設定に関する追加情報は、「Webhook の使用」を参照してください。

• 同時実行ジョブ: オンにすると、キューにあるジョブが、相互に依存していない場合に同時に実行できるようになります。ジョブスライスを同時に実行する場合には、このボックスにチェックを入れてください。詳細は、automation controller の容量判断およびジョブの影響 を参照してください。

• ファクトストレージの有効化: オンにすると、automation controller は、ジョブの実行に関連するインベントリーですべてのホストについての収集されたファクトを保存します。

• Prevent Instance Group Fallback: Check this option to allow only the instance groups listed in the Instance Groups field above to execute the job. If unchecked, all available instances in the execution pool will be used based on the hierarchy described in ジョブ実行場所の制御. Click the icon for more information.

4. ジョブテンプレートの詳細の設定が完了したら、保存 をクリックします。

テンプレートを保存しても、ジョブテンプレートページは終了しませんが、ジョブテンプレートの詳細タブが表示されます。テンプレートを保存したら、起動 をクリックしてジョブを起動するか、編集 をクリックして、パーミッション、通知、完了済みジョブの表示、survey の追加など、テンプレートの属性を追加または変更できます (ジョブタイプがスキャンでない場合)。起動する前に、まずテンプレートを保存する必要があります。そうしないと、起動 ボタンはグレイアウトしたままになります。

新規に作成されたテンプレートがテンプレートリストビューに表示されると、テンプレートが保存されていることを確認できます。

20.2. パーミッションの追加¶

1. アクセス タブで 追加 ボタンをクリックします。

2. 追加するユーザーまたはチームを選択し、**次へ**をクリックします。

3. リストから 1 つまたは複数のユーザーを選択します。これには、メンバーとして追加するユーザーの隣にあるチェックボックスをクリックして、次へ をクリックします。

この例では、追加するユーザーが 2 つ選択されています。

4. 選択したユーザーやチームに割り当てるロールを選択します。役割の一覧は、下にスクロールして確認してください。リソースによって利用できるオプションが異なります。

5. 保存 ボタンをクリックすると、選択したユーザーまたはチームにロールが適用され、メンバーとして追加されます。

ユーザー/チームの追加ウィンドウが閉じ、各ユーザーやチームに割り当てられた更新済みのロールが表示されます。

特定ユーザーのロールを削除するには、そのリソースの横にある「関連付けの解除」(x) ボタンをクリックします。

これにより確認ダイアログが起動し、関連付けの解除を確定するように求められます。

20.3. 通知の使用¶

通知 タブをクリックすると、設定した通知の統合と、実行されている場合はそのステータスを確認できます。

トグルを使用して、特定のテンプレートで使用する通知を有効または無効にします。詳細については、「通知の有効化と無効化」を参照してください。

通知が設定されていない場合は、追加 ボタンをクリックして新規通知を作成します。さまざまな通知タイプや拡張メッセージングの設定に関する補足情報は、通知タイプ を参照してください。

20.4. 完了したジョブの表示¶

完了したジョブ タブでは、実行済みのジョブテンプレートの一覧が表示されます。展開 をクリックして、ステータス ID、名前、ジョブタイプ、開始時間と完了時間、ジョブを開始したユーザー、使用したテンプレート、インベントリー、プロジェクトおよび認証情報など、各ジョブの詳細を表示します。これらの条件を使用して完了したジョブの一覧をフィルタリングできます。

このリストに表示スライスされたジョブは適宜、実行したスライスジョブ数でラベルが付けられます。

20.5. スケジューリング¶

スケジュール タブから特定のジョブテンプレートのスケジュールにアクセスします。

20.6. Survey¶

「実行」または「チェック」のジョブタイプを選択すると、ジョブテンプレートの作成または編集画面で Survey を設定できます。Survey は、「Prompt for Extra Variables (追加変数のプロンプト)」と同様に Playbook の追加変数を設定しますが、ユーザーが使いやすい質問と回答を使ってこれを実行します。また、Survey ではユーザー入力を検証することもできます。Survey ボタンをクリックして Survey を作成します。

Survey のユースケースは多岐に及びます。一例として、開発者に「push to stage」ボタンを付与する操作が必要な場合、これは Ansible の高度な知識がなくても実行できます。起動時に、このタスクは「What tag should we release?」などといった質問への回答を求めるプロンプトを出す可能性があります。

多項選択式の質問など、多種の質問を尋ねることができます。

20.6.1. Survey の作成¶

Survey を作成するには、以下を実行します。

1. テンプレートで Survey タブをクリックして、追加 ボタンをクリックします。

2. Survey には複数の質問を含めることができます。それぞれの質問について、以下の情報を入力します。

• Question: The question to ask the user

• 説明: (オプション) ユーザーに尋ねられる内容の説明。

• Answer Variable Name (回答の変数名): ユーザーの応答の保存に使用する Ansible 変数名。これは Playbook で使用される変数です。変数名にはスペースを含めることができません。

• 回答タイプ: 以下の質問のタイプから選択します。

  • テキスト: 単一行のテキスト。この回答の最小および最大の長さ (文字数) を設定できます。

  • Textarea (テキスト領域): 複数行のテキストフィールド。この回答の最小および最大の長さ (文字数) を設定できます。

  • パスワード: 応答は、実際のパスワードが処理される場合と同様に機密情報として処理されます。この回答の最小および最大の長さ (文字数) を設定できます。

  • Multiple Choice (single select) (複数の選択 (単一選択)): 1 度に 1 つのみを選択できるオプションの一覧。複数の選択オプション ボックスに 1 行に 1 つのオプションを入力します。

  • Multiple Choice (multiple select)(複数の選択 (複数選択)): 1 度に任意の数のオプションを選択できるオプションの一覧。複数の選択オプション ボックスに 1 行に 1 つのオプションを入力します。

  • Integer (整数): 整数。この回答の最小および最大の長さ (文字数) を設定できます。

  • Float (浮動): 10 進数。この回答の最小および最大の長さ (文字数) を設定できます。

• 必須: この質問に対する回答がユーザーから求められているかどうかを示します。

• 最小長 と 最大長: 回答が特定の長さである必要があるかどうかを指定します。

• Default answer: The default answer to the question. This value is pre-filled in the interface and is used if the answer is not provided by the user.

3. 質問情報を入力したら、保存 をクリックして質問を追加します。

Survey 一覧に Survey の質問が表示されます。いずれの質問も、 をクリックして編集したり、各質問の横にあるチェックボックスをオンにしてから 削除 をクリックして削除したり、画面上部の切り替えボタンを使用して Survey プロンプトを有効または無効にしたりできます。

Survey の質問が複数ある場合は、順序の編集 ボタンを使用し、グリッドアイコンをクリックアンドドラッグして質問の順序を並べ替えることができます。

4. さらに質問を追加するには、追加 ボタンをクリックして質問を追加します。

20.7. ジョブテンプレートの起動¶

automation controller の大きな利点として、Ansible Playbook のプッシュボタンによるデプロイメントが挙げられます。テンプレートを簡単に定義し、通常はコマンドラインで ansible-playbook に渡すすべてのパラメーター (Playbook だけでなく、インベントリー、認証情報、追加変数、およびコマンドラインで指定できるすべてのオプションおよび設定など) を保存できます。

デプロイメントが簡単になり、Playbook が毎回同じ方法で実行されるため一貫性が確保され、責任を委譲することも可能になります。Ansible に精通していないユーザーであっても、他のユーザーが作成した Playbook を実行できます。

以下のいずれかの方法でジョブテンプレートを起動します。

• 左のナビゲーションバーの テンプレート メニューからジョブテンプレートリストにアクセスするか、ジョブテンプレートの詳細ビューで一番下までスクロールして、 テンプレートの一覧からボタンにアクセスします。

• 起動するジョブテンプレートのジョブテンプレートの詳細ビューで、起動 をクリックします。

ジョブを実行するには、追加の情報が必要になる場合があります。以下のデータは起動時に必要になることがあります。

• 設定された認証情報

• Prompt on Launch オプションが任意のパラメーターに対して選択されている

• Ask に設定されたパスワードまたはパスフレーズ

• Survey (ジョブテンプレート用に設定されている場合)

• 追加変数 (ジョブテンプレートで必要な場合)

以下は、ジョブタグのプロンプトを出し、「Survey」で作成された Survey サンプルを実行するジョブの起動例です。

ジョブテンプレートと survey で設定された追加の変数とともに、automation controller 次の変数をジョブ環境に自動的に追加します。また、awx_ * 変数はシステムによって定義され、オーバーライドできません。awx_job_template_name のようなジョブコンテキストに関する変数は、extra_vars に設定されている場合は影響を受けません。

• awx_job_id: このジョブ実行のジョブ ID

• awx_job_launch_type: ジョブの起動方法を示す説明:

  • 手動: ジョブがユーザーにより手動で開始されました。

  • 再起動: ジョブは再起動機能を使用して開始されました。

  • コールバック: ジョブはホストのコールバックを使用して開始されました。

  • スケジュール済み: ジョブはスケジュールから開始されました。

  • 依存関係: ジョブは別のジョブの依存関係として開始されました。

  • ワークフロー: ジョブはワークフローのジョブから開始されました。

  • 同期: ジョブはプロジェクトの同期により開始されました。

  • scm: ジョブはインベントリーの SCM 同期として作成されました。

• awx_job_template_id: このジョブ実行が使用するジョブテンプレート ID

• awx_job_template_name: このジョブが使用するジョブテンプレート名

• awx_execution_node: The Execution Node name that launched this job

• awx_project_revision: この特定のジョブが使用するソースツリーのリビジョン ID (ジョブのフィールド scm_revision とも同じです)

• awx_project_scm_branch: ジョブテンプレートが使用するプロジェクトに設定されたデフォルトのプロジェクト SCM ブランチ

• awx_job_scm_branch SCM ブランチがジョブによって上書きされると、その値はここに表示されます。

• awx_user_email: このジョブを開始したコントローラーユーザーのメール。これはコールバックまたはスケジュール済みジョブでは利用できません。

• awx_user_first_name: このジョブを開始したコントローラーユーザーの名。これはコールバックまたはスケジュール済みジョブでは利用できません。

• awx_user_id: このジョブを開始したコントローラーユーザーの ID。これはコールバックまたはスケジュール済みジョブでは利用できません。

• awx_user_last_name: このジョブを開始したコントローラーユーザーの姓。これはコールバックまたはスケジュール済みジョブでは利用できません。

• awx_user_name: このジョブを開始したコントローラーユーザーのユーザー名。これはコールバックまたはスケジュール済みジョブでは利用できません。

• awx_schedule_id: このジョブを起動したスケジュールの ID (該当する場合)。

• awx_schedule_name: このジョブを起動したスケジュール名 (該当する場合)。

• awx_workflow_job_id: このジョブを起動したワークフロージョブの ID (該当する場合)。

• awx_workflow_job_name: このジョブを起動したワークフロージョブ名 (該当する場合)。これは、ワークフロージョブテンプレートとも同じである点に注意してください。

• awx_inventory_id: 該当する場合、このジョブが使用するインベントリーの ID。

• awx_inventory_name: 該当する場合、このジョブが使用するインベントリーの名前。

変数はすべて awx_job_id など、プリフィックスが「awx」であることが前提です。

起動時に、automation controller は Web ブラウザーを ジョブ タブにあるこのジョブの「ジョブステータス」ページに自動的にリダイレクトします。

スライスジョブが実行中の場合は、ジョブリストはワークフローとジョブスライス以外に、個別の詳細が確認できるリンクを表示します。

20.8. ジョブテンプレートのコピー¶

ジョブテンプレートのコピーを選択した場合、関連付けられたスケジュール、通知、またはパーミッションのコピーは 実行されません。スケジュールおよび通知は、ジョブテンプレートのコピーを作成するユーザーまたは管理者によって再作成される必要があります。ジョブテンプレートをコピーするユーザーには管理者権限が付与されますが、パーミッションはジョブテンプレートには割り当てられたり (コピーされたり) しません。

1. 左のナビゲーションバーの テンプレート メニューからジョブテンプレートの一覧にアクセスするか、ジョブテンプレートの詳細ビューで一番下までスクロールして、テンプレートのリストからアクセスします。

2. コピーするテンプレートに関連付けられた ボタンをクリックします。

コピー元のテンプレート名とタイムスタンプが付いた新しいテンプレートがテンプレートのリストに表示されます。

3. クリックして新しいテンプレートを開き、編集 をクリックします。

4. 名前 フィールドの内容を新規の名前に置き換え、他のフィールドのエントリーを指定または変更してこのページを完了します。

5. 完了したら 保存 をクリックします。

20.9. スキャンジョブテンプレート¶

スキャンジョブは automation controller 3.2 以降ではサポートされなくなりました。このシステムトラッキング機能は、履歴データとしてファクトをキャプチャーし、保存する方法として使用されてきました。ファクトはファクトのキャッシュによりコントローラーに保存されるようになりました。詳細は、ファクトのキャッシング を参照してください。

automation controller 3.2 よりも前のバージョンのシステムにジョブテンプレートのスキャンジョブがある場合、それらはタイプの実行 (通常のジョブテンプレートと同様) に変換されており、それらの関連リソース (インベントリー、認証情報など) を保持しています。関連プロジェクトのないジョブテンプレートのスキャンジョブにはデフォルトで特殊な Playbook が割り当てられるか、またはユーザーは独自のスキャン Playbook でプロジェクトを指定することができます。https://github.com/ansible/tower-fact-modules をポイントするプロジェクトが各組織に作成され、ジョブテンプレートは Playbook に設定されていました (https://github.com/ansible/tower-fact-modules/blob/master/scan_facts.yml.)。

20.9.1. ファクトスキャン Playbook¶

スキャンジョブ Playbook scan_facts.yml には、3 つの fact scan modules パッケージ、サービスおよびファイルの呼び出し機能が Ansible の標準的なファクト収集機能と共に含まれます。scan_facts.yml Playbook ファイルは以下のようになります。

- hosts: all
  vars:
    scan_use_checksum: false
    scan_use_recursive: false
  tasks:
    - scan_packages:
    - scan_services:
    - scan_files:
        paths: '{{ scan_file_paths }}'
        get_checksum: '{{ scan_use_checksum }}'
        recursive: '{{ scan_use_recursive }}'
      when: scan_file_paths is defined

scan_files ファクトモジュールは、スキャンジョブテンプレートの extra_vars で渡されるパラメーターを受け入れる唯一のモジュールです。

scan_file_paths: '/tmp/'
scan_use_checksum: true
scan_use_recursive: true

• scan_file_paths パラメーターには複数の設定を含まれる場合があります (/tmp/ または /var/log など)。

• scan_use_checksum および scan_use_recursive パラメーターは false に設定したり、省略したりすることもできます。設定の省略と、False の設定は同じです。

スキャンジョブテンプレートは become を有効にし、become が使用される可能性のある認証情報を使用するはずです。オプションメニューの 権限昇格の有効化 にチェックを付けて become を有効にすることができます。

---

- name: Get Ubuntu 16, and on ready
 hosts: all
 sudo: yes
 gather_facts: no

 tasks:

 - name: install python-simplejson
   raw: sudo apt-get -y update
   raw: sudo apt-get -y install python-simplejson
   raw: sudo apt-get install python-apt

---

- name: Get Fedora ready
 hosts: all
 sudo: yes
 gather_facts: no

 tasks:

 - name: install python-simplejson
   raw: sudo dnf -y update
   raw: sudo dnf -y install python-simplejson
   raw: sudo dnf -y install rpm-python

- hosts: all
  gather_facts: false
  tasks:
    - scan_foo:

def main():
    module = AnsibleModule(
        argument_spec = dict())

    foo = [
      {
        "hello": "world"
      },
      {
        "foo": "bar"
      }
    ]
    results = dict(ansible_facts=dict(foo=foo))
    module.exit_json(**results)

main()

[
   {
     "hello": "world"
   },
   {
     "foo": "bar"
   }
 ]

20.10. ファクトのキャッシング¶

自動コントローラーは Ansible ファクトキャッシュプラグイン経由でホストごとにファクトを保存し、取得します。この動作はジョブテンプレート別に設定されます。ファクトのキャッシングはデフォルトでオフにされていますが、これを有効にしてジョブの実行に関連するインベントリーに含まれる全ホストに対するファクト要求に対応させることができます。これにより、ホストのファクトのインベントリー全体にアクセスを有する状態で、--limit でジョブテンプレートを使用できます。プラグインがホストごとに施行するグローバルタイムアウト設定は、Jobs 設定メニューから (秒単位で) 指定できます。

ファクトキャッシュを使用する (use_fact_cache=True) ジョブの起動時に、コントローラーはそのジョブに関連付けられたインベントリー内の各ホストに関連付けられている ansible_facts をすべて保存します。automation controller に同梱される Ansible Fact Cache プラグインは、ファクトキャッシュが有効になっているジョブでのみ有効になります (use_fact_cache=True)。

ファクトキャッシュが有効な (use_fact_cache=True) ジョブの実行が終了すると、コントローラーはインベントリーのホストのレコードをすべて収集します。現在のホスト別に保存されているファクトよりも更新時間が 新しい レコードがデータベースで更新されます。

新規の、および変更されたファクトはコントローラーのロギング機能によってログに記録されます。とりわけ system_tracking 名前空間またはロガーに対して実行されます。ログのペイロードには以下のフィールドが含まれます。

• host_name

• inventory_id

• ansible_facts

ansible_facts はコントローラーインベントリー inventory_id に含まれる host_name の Ansible ファクトすべてのディレクトリーです。

20.10.1. ファクトキャッシングの利点¶

ファクトのキャッシングにより、ファクトの収集を実行する場合よりも大幅の時間を節約できます。数千のホストおよびフォークに対して実行されるジョブに Playbook がある場合に、それらのホスト全体でファクトを収集するだけで 10 分程度の時間がかかってしまう可能性があります。一方、ジョブを定期的に実行する場合に最初の実行時にそれらのファクトがキャッシュされると、次回実行時にはそれらがデータベースからプルされるようになります。これにより、スマートインベントリーなどの大規模なインベントリーに対するジョブの実行時間が大幅に削減されます。

注釈

Do not modify the ansible.cfg file to apply fact caching. Custom fact caching could conflict with the controller's fact caching feature. It is recommended to use the fact caching module that comes with automation controller.

キャッシュされたファクトのジョブでの使用は、「ジョブテンプレート」ウィンドウの オプション フィールドでこれを有効にして選択できます。

ファクトを削除するには、Ansible clear_facts meta task を実行する必要があります。以下は、Ansible clear_facts meta task を使用する Playbook の例となります。

- hosts: all
  gather_facts: false
  tasks:
    - name: Clear gathered facts from all currently targeted hosts
      meta: clear_facts

ファクトキャッシングの API エンドポイントについては、以下を参照してください。

http://<controller server name>/api/v2/hosts/x/ansible_facts

20.11. クラウド認証情報の利用¶

クラウド認証情報は、それぞれのクラウドインベントリーの同期時に使用されます。クラウド認証情報をジョブテンプレートに関連付け、Playbook で使用できるようにランタイム環境に組み込むこともできます。現在サポートされているクラウド認証情報は次のとおりです。

clouds:
  devstack:
    auth:
      auth_url: http://devstack.yoursite.com:5000/v2.0/
      username: admin
      password: your_password_here
      project_name: demo

- hosts: all
  gather_facts: false
  vars:
    config_file: "{{ lookup('env', 'OS_CLIENT_CONFIG_FILE') }}"
    nova_tenant_name: demo
    nova_image_name: "cirros-0.3.2-x86_64-uec"
    nova_instance_name: autobot
    nova_instance_state: 'present'
    nova_flavor_name: m1.nano

    nova_group:
      group_name: antarctica
      instance_name: deceptacon
      instance_count: 3
  tasks:
    - debug: msg="{{ config_file }}"
    - stat: path="{{ config_file }}"
      register: st
    - include_vars: "{{ config_file }}"
      when: st.stat.exists and st.stat.isreg

    - name: "Print out clouds variable"
      debug: msg="{{ clouds|default('No clouds found') }}"

    - name: "Setting nova instance state to: {{ nova_instance_state }}"
      local_action:
        module: nova_compute
        login_username: "{{ clouds.devstack.auth.username }}"
        login_password: "{{ clouds.devstack.auth.password }}"

- vsphere_guest:
    vcenter_hostname: "{{ lookup('env', 'VMWARE_HOST') }}"
    username: "{{ lookup('env', 'VMWARE_USER') }}"
    password: "{{ lookup('env', 'VMWARE_PASSWORD') }}"
    guest: newvm001
    from_template: yes
    template_src: linuxTemplate
    cluster: MainCluster
    resource_pool: "/Resources"
    vm_extra_config:
      folder: MyFolder

20.12. プロビジョニングコールバック¶

プロビジョニングコールバックは、ユーザーがジョブを起動して自動コントローラーコンソールからホストを管理するのを待機するのではなく、ホストが独自に Playbook 実行を開始できるようにする自動コントローラーの機能です。プロビジョニングコールバックは、呼び出し側のホストで Playbook を実行する場合に のみ 使用されることに注意してください。プロビジョニングコールバックは、クラウド拡張 (cloud bursting) に対応するもので ((承認キーの送信など) 設定のためにクライアントとサーバー間の通信が必要な新規インスタンスを想定)、別のホストに対してジョブを実行するためのものではありません。これは、別のシステムでプロビジョニングされた後のシステムの自動設定 (AWS 自動スケーリング、またはキックスタートまたは peseed などの OS プロビジョニングシステムなど)、または自動コントローラー API を直接起動しないジョブのプログラムによる起動を可能にします。起動するジョブテンプレートはプロビジョニングを要求するホストに対してのみ実行されます。

これは firstboot タイプのスクリプトまたは cron からアクセスされることが多くあります。

コールバックを有効にするには、ジョブテンプレートで Provisioning Callbacks チェックボックスにチェックを付けます。これにより、このジョブテンプレートの プロビジョニングコールバック URL が表示されます。

コールバックには、URL のある外部ホストが設定を要求できないようにするためにホスト設定キーも必要です。ホスト設定キーにカスタムの値を指定してください。ホストキーは複数のホストで再利用でき、このジョブテンプレートは多数のホストに対して適用できます。設定を要求できるホストを制御する必要がある場合、キーはいつでも変更できます。

REST 経由で手動のコールバックを実行するには、以下の形式のコールバック URL を UI で確認します。

https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback/

このサンプル URL の '7' は、自動コントローラーのジョブテンプレート ID です。

ホストからの要求は POST である必要があります。以下は、curl を使用した例になります (すべて単一行にあります)。

curl -k -f -i -H 'Content-Type:application/json' -XPOST -d '{"host_config_key": "redhat"}' \
                  https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback/

コールバックが正常に実行されるには、要求側のホストをインベントリーに定義する必要があります。自動コントローラーが定義済みのインベントリーで名前または IP アドレスによるホストの検索ができない場合、要求は拒否されます。このようにジョブテンプレートを実行する場合、独自に実行される Playbook を実行するホストはインベントリーになければなりません。ホストがインベントリーにない場合、ジョブテンプレートは「一致するホストがありません」というタイプのエラーメッセージを出して失敗します。

要求が成功した場合は、「ジョブ」タブにエントリーが作成されます。ここで結果および履歴を確認できます。

コールバックは REST でアクセスできますが、コールバックの推奨される使用方法として、/usr/share/awx/request_tower_configuration.sh (Linux/UNIX) または /usr/share/awx/request_tower_configuration.ps1 (Windows) など、自動コントローラーに同梱されるサンプルのスクリプトのいずれかを使用できます。使用方法については、以下のように -h フラグを渡すと、ファイルのソースコードに表示されます。

./request_tower_configuration.sh -h
Usage: ./request_tower_configuration.sh <options>

Request server configuration from Ansible Tower.

OPTIONS:
 -h      Show this message
 -s      Controller server (e.g. https://ac.example.com) (required)
 -k      Allow insecure SSL connections and transfers
 -c      Host config key (required)
 -t      Job template ID (required)
 -e      Extra variables

このスクリプトにはインテリジェンスがあり、コマンドを再試行する方法を認識します。したがって、このスクリプトは単純な curl 要求に比べて、より強力にコールバックを使用できます。記載されているように、スクリプトの再試行は 1 分に 1 回の頻度で最長 10 分間行われます。

クラウドインベントリーをサポートされているクラウドプロバイダーのいずれかからプルする場合のように、コールバックを自動コントローラーの動的インベントリーと共に使用する可能性が高くなります。これらの場合には、起動時の更新 の設定と共に、クラウドの API エンドポイントのハンマリングを防ぐために、インベントリーソースのインベントリーのキャッシュタイムアウトを設定します。request_tower_configuration.sh スクリプトは 1 分に 1 回の頻度で最小 10 分間ポーリングを行うため、インベントリーの推奨されるキャッシュ無効化の時間 (インベントリーソース自体に設定される) は 1 分または 2 分間になります。

cron ジョブから request_tower_configuration.sh スクリプトを実行することを推奨していますが、推奨の cron の間隔は約 30 分ごとです。設定が繰り返される場合には自動コントローラーのスケジュールで簡単に処理できるため、オンライン時の最新設定にブートストラップされるベースイメージを有効化するときに、多くのユーザーは主にコールバック機能を使用します。これを実行するには、初回の起動時に実行するのがより適切です。初回起動時のスクリプトは、通常は自己削除を実行する単純な init スクリプトであるため、request_tower_configuration.sh スクリプトのコピーを呼び出す init スクリプトを設定し、それを自動スケーリングイメージに入れます。

'{"extra_vars": {"variable1":"value1","variable2":"value2",...}}'

root@localhost:~$ curl -f -H 'Content-Type: application/json' -XPOST \
                 -d '{"host_config_key": "redhat", "extra_vars": "{\"foo\": \"bar\"}"}' \
                 https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback

20.13. 追加変数¶

Survey 変数を渡す際に、それらはコントローラー内の追加変数 (extra_vars) として渡されます。これは、(Survey で実行するように) 追加変数をジョブテンプレートに渡すと、インベントリーおよびプロジェクトから渡される他の変数が上書きされる可能性があるために注意が必要です。

たとえば、インベントリーの定義された変数が debug = true であるとします。この変数 debug = true がジョブテンプレート Survey で上書きされる可能性はあります。

渡す必要のある変数が上書きされないようにするには、この変数を Survey で再定義して組み込むことができます。追加変数はインベントリー、グループおよびホストのレベルで定義できることに注意してください。

ALLOW_JINJA_IN_EXTRA_VARS パラメーターを指定する場合は、Automation Controller Administration Guide の Controller Tips and Tricks セクションで、コントローラー UI のジョブ設定画面でこれを設定します。

以下は、YAML および JSON 形式の extra_vars を簡素化した例です。

YAML 形式の設定:

launch_to_orbit: true
satellites:
  - sputnik
  - explorer
  - satcom

JSON 形式の設定:

{
  "launch_to_orbit": true,
  "satellites": ["sputnik", "explorer", "satcom"]
}

以下の表では、Ansible の変数の順序との比較で、automation controller の変数の順序の動作 (階層) を示しています。

自動コントローラー変数の順序の階層 (最後に一覧表示された win)