20.12. プロビジョニングコールバック
プロビジョニングコールバックは、automation controller の機能で、ユーザーが automation controller コンソールからホストを管理するジョブを起動するのを待たずに、ホストが自身に対して実行する Playbook を開始できるようにします。
プロビジョニングコールバックは、呼び出し側ホストで Playbook を実行するためにのみ使用され、クラウドバースティングを目的としています。クラウドバースティングは、コンピューティング需要の急増時にパブリッククラウドに「バースト」することで、プライベートクラウドがパブリッククラウドリソースにアクセスできるようにするクラウドコンピューティング設定です。
例
別のホストに対してジョブを実行しないように、認証キーの送信などの設定用にクライアントからサーバーへの通信が必要な新しいインスタンス。これにより、次のものが自動的に設定されます。
- 別のシステム (AWS 自動スケーリング、キックスタートやプレシードなどの OS プロビジョニングシステムなど) によってプロビジョニングされた後のシステム。
- Automation controller API を直接呼び出さずに、プログラムでジョブを起動します。
起動したジョブテンプレートは、プロビジョニングを要求しているホストに対してのみ実行されます。
通常、firstboot タイプのスクリプトまたは cron で、アクセスします。
20.12.1. プロビジョニングコールバックの有効化
手順
コールバックを有効にするには、ジョブテンプレートの Provisioning Callbacks チェックボックスをオンにします。これにより、ジョブテンプレートの プロビジョニングコールバック URL が表示されます。
注記automation controller のプロビジョニングコールバック機能を動的インベントリーと共に使用しようとする場合、Update on Launch がジョブテンプレートでインベントリーグループに対して設定されている必要があります。
URL を持つ外部ホストが設定を要求できないように、コールバックにはホスト設定キーも必要です。ホスト設定キーのカスタム値を指定します。ホストキーを複数のホスト間で再利用して、このジョブテンプレートを複数のホストに適用できます。設定要求が可能なホストを制御する場合は、このキーをいつでも変更できます。
REST を使用して手動でコールバックするには以下を実行します。
手順
UI で、https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback/ の形式のコールバック URL を確認します。
- このサンプル URL の "7" は、automation controller のジョブテンプレート ID です。
ホストからのリクエストが POST であることを確認してください。以下は、
curlを使用した例です (すべて 1 行にあります)。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/- コールバックを成功させるには、要求元のホストがインベントリーに定義されていることを確認してください。
トラブルシューティング
Automation controller が、定義されたインベントリーのいずれかで名前または IP アドレスでホストを見つけることができない場合、リクエストは拒否されます。この方法でジョブテンプレートを実行する場合は、それ自体に対して Playbook の実行を開始するホストがインベントリーに存在することを確認してください。ホストがインベントリーにない場合、ジョブテンプレートは失敗し、No Hosts Matched のタイプエラーメッセージが表示されます。
ホストがインベントリーに存在せず、インベントリーグループに対して Update on Launch が設定されている場合、Automation controller はコールバックを実行する前にクラウドベースのインベントリーソースを更新しようとします。
検証
リクエストが成功すると、Jobs タブにエントリーが表示され、そこで結果と履歴を確認できます。REST を使用してコールバックにアクセスできますが、コールバックを使用する推奨方法は、Automation controller に同梱されているサンプルスクリプトの 1 つを使用することです。
-
/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 分間再試行します。
これはスクリプトの例です。200 以外のエラーコードは再試行が必要な一時的なエラーではない可能性があるため、障害シナリオの検出時に、より動的な動作が必要な場合は、このスクリプトを編集します。
Automation controller の動的インベントリーでコールバックを使用できます。たとえば、サポートされているクラウドプロバイダーの 1 つからクラウドインベントリーを取得する場合などです。このような場合は、Update On Launch の設定とともに、クラウドの API エンドポイントのハンマリングを回避するために、インベントリーソースのインベントリーキャッシュタイムアウトを必ず設定してください。request_tower_configuration.sh スクリプトは 1 分に 1 回、最大 10 分間ポーリングするため、インベントリー (インベントリーソース自体で設定) のキャッシュ無効化にかける推奨の時間値は 1 ~ 2 分になります。
cron ジョブから request_tower_configuration.sh スクリプトを実行することは推奨できませんが、推奨される cron 間隔は 30 分です。多くのユーザーは主に、オンラインになったタイミングで最新の設定にブートストラップされたベースイメージを有効にするという使用をしているので、繰り返しの設定は、automation controller をスケジューリングすることで処理できます。最初の起動時に実行するのがベストプラクティスです。最初の起動スクリプトは、init スクリプトで通常、自身でそのまま削除するため、request_tower_configuration.sh スクリプトのコピーを呼び出す init スクリプトを設定して、自動スケーリングイメージに変換します。
20.12.2. 追加変数をプロビジョニングコールバックに渡す方法
通常のジョブテンプレートと同じ方法で、プロビジョニングコールバックで extra_vars を渡すことができます。extra_vars を渡すには、送信されるデータは、アプリケーションまたは JSON のコンテンツタイプとして POST のボディーに含める必要があります。
手順
次のいずれかの方法を使用して、追加の変数を渡します。
独自の
extra_varsを追加する場合は、例として次の JSON 形式を使用します。'{"extra_vars": {"variable1":"value1","variable2":"value2",...}}'curlを使用して追加の変数をジョブテンプレート呼び出しに渡します。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
詳細は、Automation Controller 管理ガイド の Curl を使用したジョブの起動 を参照してください。
