Documentation

13. ジョブテンプレート

job template (ジョブテンプレート) は、Ansible ジョブを実行するためのパラメーターの定義およびパラメーターセットです。ジョブテンプレートは同じジョブを何度も実行する場合に便利です。ジョブテンプレートは Ansible playbook コンテンツの再利用およびチーム間のコラボレーションを促進します。REST API はジョブの直接の実行を可能にしますが、Tower ではまずジョブテンプレートを作成することが求められます。

このメニューでは、現在利用可能なジョブテンプレートの一覧が表示されます。ジョブテンプレートの一覧は 名前 または 説明 で並べ替え、検索できます。テンプレート タブから、ユーザーはジョブテンプレートを起動し、スケジュールし、変更し、削除できます。

Job templates - home with example job template

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

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

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

Job templates - create new job template

  1. 以下のフィールドに該当する詳細を入力します。
  • 名前: ジョブの名前を入力します。

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

  • ジョブタイプ:

    • 実行: 起動時に 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」をクリックしてこれを削除します。ラベルが削除され、ジョブまたはジョブテンプレートの関連付けが解除されると、ラベルは組織ラベルの一覧から永久に削除されます。
    • ジョブは起動時にジョブテンプレートからラベルを継承します。ラベルがジョブテンプレートから削除される場合、ジョブからも削除されます。
_images/job-template-create-labels.png _images/job-template-saved-labels.png
  • 追加変数:

    • 追加のコマンドライン変数を 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`を参照してください。

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

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

_images/job-templates-job-template-saved.png

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

_images/job-template-saved-labels.png

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

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

_images/job-template-completed-jobs-view.png

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

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

_images/job-template-completed-permissions-view.png

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

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

_images/job-template-assign-permissions-view.png

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

13.4. 通知の使用

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

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

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

_images/job-template-completed-notifications-view.png

13.5. Survey

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

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

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

注釈

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

13.5.1. Survey の作成

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

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

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

  1. 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 (デフォルトの回答): 質問に対するデフォルトの回答。この値は、回答がユーザーによって提供されていない場合にインターフェースに事前に入力され、使用されます。
  • 必須: この質問に対する回答がユーザーから求められているかどうかを示します。
  1. 質問の情報を入力したら、add ボタンをクリックして質問を追加します。

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

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

job-template-completed-survey

13.5.2. オプションの Survey の質問

Survey の質問に対する 必須 の設定は、対話するユーザーにとって回答がオプションかどうかを決定します。

背後では、オプションの Survey 変数は入力されていない場合でも Playbook の ``extra_vars``に渡されることがあります。

  • テキスト以外の変数 (入力タイプ) がオプションとマークされ、入力されていない場合、Survey の extra_var は Playbook に渡されません。
  • テキスト入力またはテキスト領域の入力がオプションとしてマークされ、入力されていない場合で、最小の length > 0``が設定されている場合、Survey  の``extra_var は Playbook に渡されません。
  • テキスト入力またはテキスト領域の入力がオプションとしてマークされ、入力されていない場合で、最小の length === 0``が設定されている場合、Survey  の``extra_var は、値が空のストリング ( “” ) に設定された状態で Playbook に渡されます。

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

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

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

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

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

Job Templates

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

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

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

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

job-launch-with-prompt-job-tags

job-launch-with-prompt-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. スケジューリング

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

Job Templates - schedule launch

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

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

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

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

13.7.1. ジョブテンプレートのスケジュール

新規スケジュールを作成するには、以下を実行します。

  1. スケジュール画面で、add ボタンをクリックします。
  2. 以下のフィールドに該当する詳細を入力します。
  • 名前
  • 開始日
  • 開始時間
  • ローカルタイムゾーン: 入力した開始時間はこのタイムゾーンの時間になります。
  • 繰り返しの頻度: 更新頻度の変更に合わせて適切なオプションが表示されます。

注釈

ジョブは UTC でスケジュールされます。ジョブが 1 日の特定の時間に繰り返し実行される場合には、夏時間 (DST) へ/からの切り替えがあると、ローカルタイムゾーンに合わせてこれらのジョブのスケジュールは移動します。

以下のスケジュールの説明には、スケジュールの具体的な内容と選択されたローカルタイムゾーンのスケジュール済みのオカレンスの一覧が表示されます。

Job Template - schedule add

  1. スケジュールの詳細が正しければ、**保存**をクリックします。

スケジュールが保存されると、関連付けられたジョブテンプレートについてのスケジュールの一覧が表示されます。

ON/OFF トグルボタンを使用すると、このスケジュールをすぐに有効化または無効化できます。

スケジュールの他のアクションはアクション列で選択できます。

  • スケジュールの編集
  • スケジュールの削除

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

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

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

Job Templates

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

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

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

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

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

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

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

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

  1. 以下のフィールドの値を入力します (必須フィールドには赤のアスタリスクのマークが付きます):
  • 名前: このインベントリーに適した名前を入力します。
  • 説明: 任意の説明を入力します。
  • ジョブタイプ: スキャン を選択します。

注釈

起動時に「scan」タイプ に/からジョブタイプを変更することはできません。ask_job_type_on_launch オプションは、起動時に「実行」と「チェック」の切り替えのみを可能にします。

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

注釈

起動時に新規インベントリーをスキャンジョブに割り当てることはできません。スキャンジョブは固定したインベントリーに関連付ける必要があります。

  • プロジェクト: このジョブに実行させる 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」をクリックしてこれを削除します。ラベルが削除され、ジョブまたはジョブテンプレートの関連付けが解除されると、ラベルは組織ラベルの一覧から永久に削除されます。
    • ジョブは起動時にジョブテンプレートからラベルを継承します。ラベルがジョブテンプレートから削除される場合、ジョブからも削除されます。
_images/job-template-create-labels.png _images/job-template-saved-labels.png
  • 追加変数:

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

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

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

13.9.1. スキャンジョブテンプレート用にサポートされるオペレーティングシステム

以下のオペレーティングシステムはスキャンジョブ用にサポートされています。

  • Red Hat Enterprise Linux 5, 6, & 7
  • CentOS 5, 6, & 7
  • Ubuntu 12.04, 14.04, 16.04
  • OEL 6 & 7
  • SLES 11 & 12
  • Debian 6 & 7
  • Fedora 22, 23, 24
  • Amazon Linux 2016.03
  • Windows Server 2008 以降

一部のオペレーティングシステムには、python を実行したり、スキャンモジュールが依存する python パッケージにアクセスしたりするために初期設定が必要になる場合があります。

13.9.1.1. スキャン前の設定

以下は、スキャンジョブを実行できるように特定のディストリビューションを設定する Playbook の例です。

Bootstrap Ubuntu (16.04)

---

- 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

Bootstrap Fedora (23, 24)

---

- 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

CentOS 5 または Red Hat Enterprise Linux 5 では、simplejson パッケージのインストールが必要になる場合があります。

13.9.2. スキャンジョブテンプレートの起動

Inventories Scan Job - saved

右側のボタンを使用してスキャンジョブの 起動スケジュール編集削除、または コピー を実行できます。

launch ボタンをクリックします。このジョブテンプレートに設定されている必要な認証情報、パスワード、パスフレーズなどを入力します。

「ジョブ」ページには、Playbook が実行したすべてのタスクおよびイベントの詳細が表示されます。

Inventories Scan Job - job page

13.9.3. スキャンジョブテンプレートのスケジュール

スキャンジョブをスケジュールするには、以下を実行します。

  1. スキャンジョブのスケジュールにアクセスするには、schedule ボタンをクリックします (テンプレート ナビゲーションリンクから最も簡単にアクセスできます)。

Inventories Scan Job - schedule home

  1. add ボタンをクリックしてスケジュールを追加します。
  2. 以下のフィールドに該当する詳細を入力します。
  • 名前
  • 開始日
  • 開始時間
  • ローカルタイムゾーン: 入力した開始時間はこのタイムゾーンの時間になります。
  • 繰り返しの頻度: 更新頻度の変更に合わせて適切なオプションが表示されます。

注釈

ジョブは UTC でスケジュールされます。ジョブが 1 日の特定の時間に繰り返し実行される場合には、夏時間 (DST) へ/からの切り替えがあると、ローカルタイムゾーンに合わせてこれらのジョブのスケジュールは移動します。

以下のスケジュールの説明には、スケジュールの具体的な内容と選択されたローカルタイムゾーンのスケジュール済みのオカレンスの一覧が表示されます。

Inventories Scan Job - schedule add

  1. スケジュールの詳細が正しければ、**保存**をクリックします。

スケジュールが保存されると、関連付けられたジョブテンプレートについてのスケジュールの一覧が表示されます。

Inventories Scan Job - schedule saved

ON/OFF トグルボタンを使用すると、このスケジュールをすぐに有効化または無効化できます。

スケジュールの他のアクションはアクション列で選択できます。

  • スケジュールの編集
  • スケジュールの削除

13.9.4. カスタムスキャンジョブテンプレート

カスタムスキャンジョブは、カスタマイズされたファクトモジュールと共にカスタムスキャン Playbook を使用する通常のスキャンジョブテンプレートです。追加の Ansible ファクトモジュールは、カスタムスキャン Playbook で簡単に組み込むことができます。

13.9.4.1. ファクトスキャン Playbook

Tower にバンドルされたデフォルトのスキャンジョブ 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 に設定することは同じです。

13.9.4.2. カスタムファクトスキャン

カスタムファクトスキャンの Playbook は上記のファクトスキャン Playbook の例と似ています。例として、カスタム scan_foo Ansible ファクトモジュールのみを使用する Playbook は以下のようになります。

scan_custom.yml:

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

scan_foo.py:

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

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

main()

カスタムファクトモジュールを使用するには、それがスキャンジョブテンプレートで使用される Ansible プロジェクトの /library/ サブディレクトリーにあることを確認します。このファクトスキャンモジュールは非常に単純で、ハードコーディングされたファクトのセットを返します。

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

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

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

13.10.1. OpenStack

以下のサンプル Playbook は nova_compute Ansible OpenStack クラウドモジュールを起動し、認証情報によって分かりやすいタスクを実行し、とくに auth_urlユーザー名パスワード、および project_name などの情報を要求します。これらのフィールドは、クラウド認証情報の内容に基づいて Tower で作成された YAML ファイルをポイントする環境変数 OS_CLIENT_CONFIG_FILE を使って Playbook で利用できるようにされます。このサンプル Playbook は YAML ファイルを Ansible 変数スペースに読み込みます。

OS_CLIENT_CONFIG_FILE の例:

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

Playbook の例:

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

13.10.2. Amazon Web Services

Amazon Web Services クラウド認証情報は Playbook の実行時に以下の環境変数として公開されます (ジョブテンプレートで、設定に必要なクラウド認証情報を選択します):

  • AWS_ACCESS_KEY
  • AWS_SECRET_KEY

すべての AWS モジュールは、aws_access_key または aws_secret_key モジュールオプションを設定せずに Tower で実行される場合にこれらの認証情報を暗黙的に使用します。

13.10.3. Rackspace

Rackspace クラウド認証情報は Playbook 実行時に以下の環境変数として公開されます (ジョブテンプレートで、設定に必要なクラウド認証情報を選択します):

  • RAX_USERNAME
  • RAX_API_KEY

すべての Rackspace モジュールは、username または api_key モジュールオプションを設定せずに Tower で実行される場合にこれらの認証情報を暗黙的に使用します。

13.10.4. Google

Google クラウド認証情報は Playbook の実行時に以下の環境変数として公開されます (ジョブテンプレートで、設定に必要なクラウド認証情報を選択します):

  • GCE_EMAIL
  • GCE_PROJECT
  • GCE_PEM_FILE_PATH

すべての Google モジュールは、service_account_emailproject_id、または pem_file モジュールオプションを設定せずに Tower で実行される場合にこれらの認証情報を暗黙的に使用します。

13.10.5. Azure

Azure クラウド認証情報は Playbook の実行時に以下の環境変数として公開されます (ジョブテンプレートで、設定に必要なクラウド認証情報を選択します):

  • AZURE_SUBSCRIPTION_ID
  • AZURE_CERT_PATH

すべての Azure モジュールは、subscription_id または management_cert_path モジュールオプションを設定せずに Tower で実行される場合にこれらの認証情報を暗黙的に使用します。

13.10.6. VMware

VMware クラウド認証情報は Playbook の実行時に以下の環境変数として公開されます (ジョブテンプレートで、設定に必要なクラウド認証情報を選択します):

  • VMWARE_USER
  • VMWARE_PASSWORD
  • VMWARE_HOST

以下のサンプル Playbook はこれらの認証情報の使用方法を示しています。

- 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 が表示されます。

注釈

Tower のプロビジョニングコールバック機能を動的インベントリーと共に使用しようとする場合、「起動時の更新」はジョブテンプレートでインベントリーグループに対して設定されている必要があります。

_images/provisioning-callbacks-config.png

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

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 を実行するホストはインベントリーになければなりません。ホストがインベントリーにない場合、ジョブテンプレートは「一致するホストがありません」というタイプのエラーメッセージを出して失敗します。

注釈

ホストがインベントリーになく、起動時の更新 がインベントリーグループに設定されている場合、Tower はコールバックの実行前にクラウドベースのインベントリーソースの更新を試行します。

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

コールバックは 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 分間行われます。

注釈

これはスクリプトのサンプルであることに注意してください。200 エラーコード以外のエラーコードは再試行を要求する一時的なエラーであるため、失敗シナリオを検出する際により動的な動作が必要な場合にこのスクリプトを編集する必要があります。

クラウドインベントリーをサポートされているクラウドプロバイダーのいずれかからプルする場合のように、コールバックを 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 スクリプトを設定し、それを自動スケーリングイメージに入れます。

13.11.1. 追加変数をプロビジョニングコールバックに渡す

通常のジョブテンプレートで extra_vars を渡せるように、それらをプロビジョニングコールバックに渡すこともできます。extra_vars を渡すには、送信されたデータはアプリケーション/json として (コンテンツタイプとして) POST 要求の本体の一部にする必要があります。独自の extra_vars が渡されるように追加する際に、例として以下の JSON 形式を使用します。

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

(Ansible Tower バージョン 2.2.0 で追加されています。)

また以下の例に示されているように、curl を使用してジョブテンプレートの呼び出しに追加の変数を渡すこともできます。

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

詳細は、Launching Jobs with Curl を参照してください。

13.12. 追加変数

注釈

追加の厳密な extra_vars 検証が Ansible Tower 3.0.0 で追加されました。ジョブ起動 API に渡される``extra_vars`` は、以下が True の場合のみ受け入れられます。

  • それらは有効な survey の変数に対応するものである。
  • ask_variables_on_launch は True に設定されている。

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

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

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

注釈

Ansible Tower バージョン 2.4 より、ジョブテンプレートの追加変数および Survey 変数の動作が変更されました。以前のバージョンでは、Survey を使用して設定される変数はジョブテンプレートで指定される追加変数をオーバーライドしました。2.4 以降では、ジョブテンプレートの追加変数辞書は Survey 変数にマージされています。これにより、2.4 へのアップグレード時に動作の変更が生じる可能性があります。

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

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

_images/Architecture-Tower_Variable_Precedence_Hierarchy.png

13.12.1. ジョブテンプレートの再起動

Ansible Tower バージョン 2.4 の別の変更により、ジョブの launch_type 設定が導入されました。ジョブを手動で再起動せずに、再起動は launch_typerelaunch に設定して表示されます。再起動の動作は、extra_vars継承しない 点で、起動の動作とは異なります。

ジョブを再起動しても継承ロジックが実行される訳でありません。再起動されるジョブについて計算されたものと同じ extra_vars を使用します。

たとえば、extra_vars を指定せずにジョブテンプレートを起動するとします。これにより、j1 というジョブが作成されます。次に、そのジョブテンプレートを編集し、一部の extra_vars を追加 ("{ "hello": "world" }" の追加など) を実行するとします。

j1 を再起動すると j2 が作成されますが、継承するロジックがなく、j1 には extra_vars がないため、j2 には extra_vars が指定されません。

この例では、j1 の作成後に追加した``extra_vars`` でジョブテンプレートを起動した場合、作成されるジョブの再起動 (j3) には extra_vars が含まれます。j3 を再起動すると j4 が作成され、これにも extra_vars が含まれます。