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

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

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

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

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

• 名前: ジョブの名前を入力します。

• 説明: 任意の説明を入力します (オプション)。

• ジョブタイプ:

  • 実行: 起動時に Playbook を実行し、選択されたホストで Ansible タスクを実行します。
  • チェック: Playbook の「ドライラン」を実行し、実際に変更せずに変更について報告します。チェックモードをサポートしないタスクはスキップされ、予想される変更については報告されません。
  • スキャン: システムトラッキング情報を収集します。特定インベントリーの「使用」パーミッションを持つユーザーには、スキャンジョブを作成するパーミッションがあります。デフォルト Playbook はユーザーが使用できるように作成されています。カスタム作成スキャン Playbook はスキャンモジュールを使用できます。スキャンジョブの作成についての詳細は、スキャンジョブテンプレート を参照してください。
  • 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時に実行またはチェックのジョブタイプを選択することを求めるプロンプトが出されます (スキャンジョブのタイプは起動時に変更することができません)。

  注釈

  ジョブタイプの詳細は、Ansible ドキュメントの Playbooks: Special Topics セクションを参照してください。

• インベントリー: このジョブテンプレートで使用するインベントリーを、現在ログインしている Tower ユーザーが利用できるインベントリーから選択します。

• 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時にこのジョブテンプレート実行に使用するインベントリーの選択を求めるプロンプトが出されます。

• プロジェクト: このジョブテンプレートで使用するプロジェクトを、現在ログインしている Tower ユーザーが利用できるプロジェクトから選択します。

• Playbook: このジョブテンプレートで起動する Playbook を、利用可能な Playbook から選択します。このメニューには、選択したプロジェクトのプロジェクトベースパスにある Playbook の名前が自動的に設定されます。たとえば、プロジェクトパスにある「jboss.yml」という名前の Playbook は「jboss」としてメニューに表示されます。

• マシンの認証情報: このジョブテンプレートで使用するマシンの認証情報を、現在ログインしている Tower ユーザーが使用できる認証情報から選択します。

• クラウド認証情報: このジョブテンプレートで使用する認証情報を、現在ログインしている Tower ユーザーが利用できる認証情報から選択します。詳細は、:ref:`ug_CloudCredentials`を参照してください。

• ネットワークの認証情報 このジョブテンプレートで使用するネットワークの認証情報を、現在ログインしている Tower ユーザーが使用できる認証情報から選択します。

• フォーク: Playbook の実行中に使用する並行または同時プロセスの数です。ゼロの値は、/etc/ansible/ansible.cfg で上書きが実行されない限り Ansible のデフォルト設定 (5 つの並行プロセス) を使用します。

• 制限:

  • Playbook が管理または影響を与えるホストの一覧をさらに制限するためのホストのパターンです。複数のパターンは、コロン (「:」) で区切ることができます。Core Ansible の場合のように「a:b」は「in group a or b」を、「a:b:&c」は「in a or b but must be in c」を、「a:!b」は「in a, and definitely not in b」を意味します。
  • 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時に制限を選択するようプロンプトが出されます。

  注釈

  詳細および例については、Ansible ドキュメントの Patterns を参照してください。

• 詳細: Playbook の実行時に Ansible が生成する出力レベルを制御します。詳細を「デフォルト」、「詳細」または「デバッグ」のいずれかに設定します。これは、「詳細」レポートビューにのみ表示されます。詳細ロギングには、すべてのコマンドの出力が含まれます。デバッグのロギングはきわめて詳細になり、特定のサポートインスタンスで役に立つ SSH 操作についての情報が含まれます。大半のユーザーは「デバッグ」モードの出力を確認する必要はありません。

警告

「詳細」の値が 5 の場合、Tower はジョブの実行時にブロックを実行し、これによりジョブが終了したことを示すレポートが遅延するため (レポートが作成されている場合でも)、ブラウザータブがロックアップする可能性があります。

• ジョブタグ:

  • Playbook タグのコンマ区切りの一覧を提供し、実行する Playbook の部分を指定します。
  • 詳細および例については、Ansible ドキュメントの Tags を参照してください。
  • 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時にジョブタグを選択するようプロンプトが出されます。

• スキップタグ:

  • Playbook タグのコンマ区切りの一覧を提供し、特定のタスクまたは実行する Playbook の一部をスキップします。
  • 詳細および例については、Ansible ドキュメントの Tags を参照してください。
  • 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時にジョブタグを選択するようプロンプトが出されます。

• オプション

  • 権限昇格の有効化: 有効にされている場合、Playbook を管理者として実行します。これは、--become オプションを ansible-playbook コマンドに渡すことに相当します。
  • プロビジョニングコールバックの許可: ホストが Tower API 経由で Tower に対してコールバックできるようにし、このジョブテンプレートからジョブを起動できるようにします。詳細は、プロビジョニングコールバック を参照してください。
  • 同時実行ジョブの有効化: キューにあるジョブが、相互に依存していない場合に同時に実行できるようにします。詳細は、ジョブの同時実行 を参照してください。

• ラベル: 「dev」または「test」などのこのジョブテンプレートを説明するオプションのラベルを指定します。ラベルを使用して Tower のディスプレイでのジョブテンプレートおよび完了したジョブの分類およびフィルターを実行します。

  • ラベルは、ジョブテンプレートに追加される際に作成されます。ラベルはジョブテンプレートで提供されるプロジェクトを使用する単一の組織に割り当てられます。組織のメンバーは、(管理者ロールなどの) 編集パーミッションがある場合にジョブテンプレートでラベルを作成できます。
  • ジョブテンプレートが保存されると、ラベルはジョブテンプレートの概要に表示されます。
  • ラベルの横にある「x」をクリックしてこれを削除します。ラベルが削除され、ジョブまたはジョブテンプレートの関連付けが解除されると、ラベルは組織ラベルの一覧から永久に削除されます。
  • ジョブは起動時にジョブテンプレートからラベルを継承します。ラベルがジョブテンプレートから削除される場合、ジョブからも削除されます。

• 追加変数:

  • 追加のコマンドライン変数を Playbook に渡します。これは、Ansible ドキュメントの Passing Variables on the Command Line に記載されている ansible-playbook の「-e」または「–extra-vars」コマンドラインパラメーターです。

  • YAML または JSON のいずれかを使用してキー/値のペアを指定します。これらの変数には、順序を示す最大値があり、他の場所で指定された他の変数を上書きします。値の例には、以下が含まれます。

    git_branch: production
    release_version: 1.5
    

  • 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時にコマンドライン変数を選択するようプロンプトが出されます。

  追加変数についての詳細は、:ref:`ug_jobtemplates_extravars`を参照してください。

3. ジョブテンプレートの詳細の設定が完了したら、**保存**を選択します。

テンプレートを保存してもジョブテンプレートのページを終了せず、追加の編集ができるように Job Template Details (ジョブテンプレートの詳細) ビューに留まります。保存したジョブの 詳細 タブからは、Survey の確認、編集、および追加を実行できます (ジョブタイプがスキャンでない場合)。

新規に作成されたテンプレートが画面下部のテンプレートの一覧に表示される際に、テンプレートが保存されていることを確認できます。

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

完了したジョブ タブには、このジョブテンプレートが実行された方法の詳細が記載されます。完了時に ID、名前、ジョブタイプが表示され、ジョブの再起動や削除を実行できます。ジョブ ID、名前、タイプまたはジョブが失敗したかどうかによって完了したジョブの一覧をフィルターできます。

13.3. パーミッションの使用¶

パーミッション をクリックすると、ユーザーおよびチームメンバーの関連付けられたパーミッションの確認、付与、編集および削除を実行できます。

ボタンをクリックし、このジョブテンプレートの新規のパーミッションを作成します。

この例では、2 ユーザーと 1 チームが選択されており、それぞれにこのジョブテンプレートのパーミッションが付与されています。

チームとユーザー間を切り換える必要はなく、パーミッションを同時にどちらにも割り当てることができることに注意してください。

13.4. 通知の使用¶

通知 をクリックすると、設定した通知の統合を簡単に確認できます。

ボタンをクリックして通知を作成します。

詳細は、通知 を参照してください。

13.5. Survey¶

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

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

多項選択式の質問を含む、多くのタイプの質問を尋ねるようにすることができます。

13.5.1. Survey の作成¶

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

1. ボタンをクリックして、**Survey の追加**ウィンドウを起動します。

画面上部にある ON/OFF トグルボタンを使用すると、この survey プロンプトをすぐに有効化または無効化できます。

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

• 名前: ユーザーに尋ねる質問
• 説明: (オプション) ユーザーに尋ねられる内容の説明。
• 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 (デフォルトの回答): 質問に対するデフォルトの回答。この値は、回答がユーザーによって提供されていない場合にインターフェースに事前に入力され、使用されます。
• 必須: この質問に対する回答がユーザーから求められているかどうかを示します。

3. 質問の情報を入力したら、 ボタンをクリックして質問を追加します。

定型化されたバージョンの Survey が「プレビュー」ペインに表示されます。いずれの質問についても、編集 ボタンをクリックして質問を編集できます。削除 ボタンをクリックすると質問を削除でき、グリッドアイコンをクリックおよびドラッグして質問の順序を変更できます。

4. 左ペインに戻り、質問を追加します。
5. 完了したら、保存 をクリックして Survey を保存します。

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

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

簡単になったデプロイメントによって毎回同じ方法で Playbook を実行できるため、一貫性が高まり、責任を委任することも可能になります。Ansible の専門家でないユーザーでも、他のユーザーが作成した Tower Playbook を実行できます。

ジョブテンプレートを起動するには、以下を実行します。

1. テンプレート ナビゲーションリンクまたはジョブテンプレートの詳細ビューからジョブテンプレートにアクセスし、下方にスクロールしてテンプレートの一覧からこれにアクセスします。

2. ボタンをクリックします。

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

• 設定された認証情報
• Ask に設定されたパスワードまたはパスフレーズ
• Survey (ジョブテンプレート用に設定されている場合)
• 追加変数 (ジョブテンプレートで必要な場合)

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

ジョブテンプレートおよび Survey に設定される追加変数と共に、Tower は以下の変数をジョブ環境に自動的に追加します。

• tower_job_id: このジョブ実行のジョブ ID
• tower_job_launch_type: ジョブが開始された方法を示す 手動、コールバック、または スケジュール済み のいずれか。
• tower_job_template_id: このジョブ実行が使用するジョブテンプレート ID
• tower_job_template_name: このジョブが使用するジョブテンプレート名
• tower_user_id: このジョブを開始した Tower ユーザーのユーザー ID。これはコールバックまたはスケジュール済みジョブでは利用できません。
• tower_user_name: このジョブを開始した Tower ユーザーのユーザー名。これはコールバックまたはスケジュール済みジョブでは利用できません。

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

13.7. スケジューリング¶

ジョブテンプレートの起動は ボタンでもスケジュールできます。このボタンをクリックすると、スケジュール ページが開きます。

このページには、選択された ジョブテンプレート で現在利用できるスケジュールの一覧が表示されます。スケジュールの一覧は、以下のいずれかで並び替え、検索できます。

• 名前: スケジュール名をクリックすると、スケジュールの編集 ダイアログが開きます。
• 初回実行日時: このタスクの最初にスケジュールされる実行
• 次回実行日時: このタスクの次回にスケジュールされる実行
• 最終実行日時: タスクに終了日時が設定されている場合、これはタスクの最後の実行になります。

スケジュール 画面の右上にあるボタンから以下のアクションを実行できます。

• アクティビティーストリームの表示
• 新規スケジュールの追加

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

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

1. テンプレート ナビゲーションリンクまたはジョブテンプレートの詳細ビューからコピーするジョブテンプレートにアクセスし、下方にスクロールしてテンプレートの一覧からこれにアクセスします。

2. ボタンをクリックします。

新規テンプレートが、コピーしたテンプレートの名前とタイムスタンプが設定された状態で開きます。

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

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

スキャンジョブは、ジョブが実行されているホストについての情報のみを収集する特殊なジョブテンプレートです。

この特殊なタイプのジョブテンプレートを作成するには、以下を実行します。

1. テンプレート をクリックします。

2. Click the button then select Job Template from the menu list, which launches the Create Job Template window.

3. 以下のフィールドの値を入力します (必須フィールドには赤のアスタリスクのマークが付きます):

• 名前: このインベントリーに適した名前を入力します。
• 説明: 任意の説明を入力します。
• ジョブタイプ: スキャン を選択します。

• インベントリー: このジョブで管理するホストが含まれるインベントリーを選択します。

• プロジェクト: このジョブに実行させる Playbook が含まれるプロジェクトを選択します。スキャンする特殊なプロジェクトがない限り、Tower に組み込まれているデフォルトのプロジェクトを使用します。

• Playbook: このジョブで実行する Playbook を選択します。スキャンする特殊なプロジェクトがない限り、Tower に組み込まれているデフォルトのプロジェクトを使用します。

• マシンの認証情報: リモートホストへのアクセス時にジョブで使用する認証情報を選択します。Ansible がリモートホストにログインするために必要なユーザー名および SSH キーまたはパスワードが含まれる認証情報を選択してください。

• クラウド認証情報: ジョブテンプレートでオプションのクラウド認証情報を選択すると、アクセス認証情報が実行中の Playbook に渡され、パラメーターを組み込まれているモジュールに手動で渡さなくてもクラウドへのプロビジョニングを実行できます。詳細は、クラウド認証情報の利用 を参照してください。

• ネットワークの認証情報 このジョブテンプレートで使用するネットワークの認証情報を、現在ログインしている Tower ユーザーが使用できる認証情報から選択します。

• フォーク: Playbook の実行中に使用する並列または同時プロセスの数です。

• 制限: Playbook が管理または影響を与えるホストの一覧をさらに制限するためのホストのパターンを指定します。

  • 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時に制限を選択するようプロンプトが出されます。

• 詳細: Playbook の実行時に Ansible が生成する出力レベルを制御します。

• ジョブタグ: プレイまたはタスクの特定の部分を実行するためのコンマで区切られたタグの一覧を指定します。

  • 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時にジョブタグを選択するようプロンプトが出されます。

• スキップタグ:

  • Playbook タグのコンマ区切りの一覧を提供し、特定のタスクまたは実行する Playbook の一部をスキップします。
  • 詳細および例については、Ansible ドキュメントの Tags を参照してください。
  • 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時にジョブタグを選択するようプロンプトが出されます。

• オプション:

  • 権限昇格の有効化: 有効にされている場合、Playbook を管理者として実行します。これは、--become オプションを ansible-playbook コマンドに渡すことに相当します。
  • プロビジョニングコールバックの許可: ホストが Tower API 経由で Tower に対してコールバックできるようにし、このジョブテンプレートからジョブを起動できるようにします。詳細は、プロビジョニングコールバック を参照してください。
  • 同時実行ジョブの有効化: キューにあるジョブが、相互に依存していない場合に同時に実行できるようにします。詳細は、ジョブの同時実行 を参照してください。

• ラベル: 「dev」または「test」などのこのジョブテンプレートを説明するオプションのラベルを指定します。ラベルを使用して Tower のディスプレイでのジョブテンプレートおよび完了したジョブの分類およびフィルターを実行します。

  • ラベルは、ジョブテンプレートに追加される際に作成されます。ラベルはジョブテンプレートで提供されるプロジェクトを使用する単一の組織に割り当てられます。組織のメンバーは、(管理者ロールなどの) 編集パーミッションがある場合にジョブテンプレートでラベルを作成できます。
  • ジョブテンプレートが保存されると、ラベルはジョブテンプレートの概要に表示されます。
  • ラベルの横にある「x」をクリックしてこれを削除します。ラベルが削除され、ジョブまたはジョブテンプレートの関連付けが解除されると、ラベルは組織ラベルの一覧から永久に削除されます。
  • ジョブは起動時にジョブテンプレートからラベルを継承します。ラベルがジョブテンプレートから削除される場合、ジョブからも削除されます。

• 追加変数:

  • 追加のコマンドライン変数を Playbook に渡します。これは、Ansible ドキュメントの Passing Variables on the Command Line に記載されている ansible-playbook の「-e」または「–extra-vars」コマンドラインパラメーターです。
  • YAML または JSON のいずれかを使用してキー/値のペアを指定します。これらの変数には、順序を示す最大値があり、他の場所で指定された他の変数を上書きします。
  • 起動プロンプト: これが選択されている場合、デフォルト値が指定されている場合でも、起動時にコマンドライン変数を選択するようプロンプトが出されます。

追加変数についての詳細は、:ref:`ug_jobtemplates_extravars`を参照してください。

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

---

- name: Get Ubuntu 15, 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
  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_file_paths: '/tmp/'
scan_use_checksum: true
scan_use_recursive: true

- 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"
   }
 ]

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

クラウド認証情報は、それぞれのクラウドインベントリーの同期時に使用されます。クラウド認証情報はジョブテンプレートに関連付け、Playbook で使用できるようにランタイム環境に組み込むこともできます。クラウド認証情報の使用は、Ansible Tower バージョン 2.4.0 で導入されました。

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: centosTemplate
    cluster: MainCluster
    resource_pool: "/Resources"
    vm_extra_config:
      folder: MyFolder

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

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

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

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

コールバックには、URL のある外部ホストが設定を要求できないようにするためにホスト設定キーも必要です。 ボタンをクリックしてこのコールバックの固有のホストキーを作成するか、または独自のキーを入力します。ホストキーは複数のホストで再利用でき、このジョブテンプレートは多数のホストに対して適用できます。設定を要求できるホストを制御する必要がある場合、キーはいつでも変更できます。

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

http://<Tower server name>/api/v1/job_templates/1/callback/

同じ URL の ‘1’ は Tower のジョブテンプレート ID です。

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

root@localhost:~$ curl --data "host_config_key=5a8ec154832b780b9bdef1061764ae5a" \
                    http://<Tower server name>/api/v1/job_templates/1/callback/

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

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

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

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

Request server configuration from Ansible Tower.

OPTIONS:
   -h      Show this message
   -s      Tower server (e.g. https://tower.example.com) (required)
   -k      Allow insecure SSL connections and transfers
   -c      Host config key (required)
   -t      Job template ID (required)
   -e      Extra variables
   -s      Number of seconds between retries (default: 60)

このスクリプトには、コマンドを再試行する方法を認識する点でインテリジェンスがあります。単純な curl 要求に対し、コールバックを使用するためのより堅牢な方法になります。記載がある通り、スクリプトの再試行は 1 分に 1 回の頻度で最長 10 分間行われます。

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

cron ジョブからの request_tower_configuration.sh スクリプトの実行についての推奨を行う一方、cron の間隔については 30 分ごとが推奨されます。繰り返される設定は Tower のスケジュールで簡単に処理できるため、ほとんどのユーザーによるコールバックの主な使用方法は、オンライン時の最新の設定にブートストラップされるベースイメージを有効にする方法です。これを実行するには、初回の起動時に実行するのがより適切です。初回起動時のスクリプトは、通常は自己削除を実行する単純な 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": "5a8ec154832b780b9bdef1061764ae5a", "extra_vars": "{\"foo\": \"bar\"}"}' \
                 http://<Tower server name>/api/v1/job_templates/1/callback

13.12. 追加変数¶

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

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

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

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

Ansible Tower 変数の順序の階層 (最後に一覧表示された win)