Documentation

4. インベントリーファイルのインポート

Ansible Tower 3.2 では、1 からインベントリーファイルを作成するのではなく、ソースコントロールからインベントリーファイルを選択できる機能が導入されました。この機能は、コンテンツのブラウザーを編集するのではなく、コンテンツをソースコントロールから取得する以外は、カスタムのインベントリースクリプトと同じです。つまり、このファイルは編集不可で、group_vars および host_vars ファイルまたはこのファイルに関連付けられているディレクトリーなど、インベントリーがソースで更新されるので、プロジェクト内のインベントリーも同様に更新されます。SCM タイプは、インベントリーファイルもスクリプトも両方消費し、両方に含まれるインベントリーファイルやカスタムタイプで重複がある場合には複数スクリプトが実行されます。

注釈

以下の機能は、Ansible バージョン 2.4 以降と互換性があります。Ansible バージョン 2.2 および 2.3 では、インベントリーの更新はサポートされなくなりました。

注釈

Ansible バージョン 2.8 以降でインベントリーを更新すると、ソースタイプによってインベントリープラグインを使用する場合があります。これらは、以前と新しいコンテンツ両方を返すようにオプションを有効化して実行されます (例: hostvars、ホスト名、グループ)。詳細は、『Ansible Tower User Guide』の「 Inventory Plugins 」セクションを参照してください。

4.1. カスタムの動的インベントリースクリプト

バージョン管理に保存されているカスタムの動的インベントリースクリプトは、インポートして、実行することができます。この機能により、Tower にコピーアンドペーストし、ソースコントロールから直接プルしてから実行する必要なく、インベントリースクリプトへの変更がより簡単に加えられるようになりました。スクリプトは、作業の実行に必要な認証情報を処理するために記述する必要があるので、スクリプトに必要な Python ライブラリーをインストールする必要があります (これは、カスタムの動的インベントリースクリプトと同じ要件です)。また、ユーザー定義のインベントリーソーススクリプトと SCM ソースは Playbook に関する Ansible virtualenv の要件に準拠する必要があるため、これはどちらにも当てはまります。

SCM インベントリーソース自体を編集する場合は、環境変数を指定することができます。スクリプトによってはこれで十分ですが、この方法では、クラウドプロバイダーやインベントリーへのアクセスを可能にする機密情報が安全に保存されません。

より良い方法として、使用予定のインベントリースクリプトの新規認証タイプを作成してください。認証タイプでは、入力する情報に必要なタイプをすべて指定する必要があります。このタイプの認証情報を作成する場合には、シークレットは暗号化形式で保存されます。インベントリーソースにその認証情報を適用する場合、スクリプトは、環境変数やファイルなどの入力データにアクセスできます。

詳細は、「 Credential types 」を参照してください。

4.1.1. プロジェクトの変更の更新

インベントリーソースに静的なコンテンツが含まれる場合には、ソースのプロジェクトの SHA-1 が変更されるたびに自動的にコンテンツを更新するほうが望ましい場合があります。これは、Update on Project Change (プロジェクトの変更時に更新) にインベントリーソースを設定してください。

このボックスがチェックされると、インベントリーソースが起動時に更新できなくなります。設定によっては起動時に更新する必要があるので、起動時の更新は重要です。たとえば、ジョブテンプレートの実行前に、インベントリーが順番に更新されるように参照するプロジェクトを設定する場合には、ジョブテンプレートが実行するインベントリーが更新された形式になるようにします。ただし、他に 2 種類の方法があります。

  • まず、同じプロジェクトから更新されるインベントリーやプロジェクトを使用するように、ジョブテンプレートを作成することができます。このような場合は、update_on_launch にプロジェクトを設定し、必要に応じてインベントリーの更新をトリガーします。
  • インベントリーソースのプロジェクトとは別の Playbook のプロジェクトを使用する必要がある場合には、ワークフローにそのプロジェクトを配置することができ、プロジェクトの更新に成功したらジョブテンプレートを実行できるようになります。

こうすることで、インベントリーの更新が完了するまでプロジェクトは完了の状態にならないので、インベントリーの更新が時間どおりに (ジョブテンプレートが起動する前にインベントリーの変更が行われるという意味です) 行われるようになります。

注釈

インベントリーの更新に失敗しても、プロジェクトは失敗とマークされません。また、プロジェクトの更新すべてが適切なインベントリーの更新をトリガーするわけではありません。プロジェクトの改訂が変更されず、インベントリーが編集されていない場合には、インベントリーの更新は実行されません。

4.2. SCM インベントリーソースのフィールド

使用するソースのフィールドは以下のとおりです。

  • source_project: 使用するプロジェクト
  • source_path: ディレクトリーまたはファイルを示すプロジェクト内の相対パス。これが空のままの場合は、" " はプロジェクトの root ディレクトリーを指す相対パスを表します。
  • source_vars: “file” タイプのインベントリーソースに設定されている場合には、実行時に環境変数に渡されます。

プロジェクトの更新は自動的に使用先のインベントリーの更新をトリガーします。インベントリーソースの作成直後にプロジェクトの更新がスケジュールされます。

Tower ユーザーインターフェースのインベントリーソースの作成ページから場所を手動で指定することができます。

インベントリーソースの作成に関する説明は『 Ansible Tower User Guide 』の「ug_inventories」を参照してください。

この一覧は、プロジェクトが更新されたら最新の SCM 情報にリフレッシュする必要があります。インベントリーソースが SCM インベントリーソースとしてプロジェクトを使用しない場合には、インベントリーの一覧は更新時にはリフレッシュされません。

Ansible Tower 3.5 から、インベントリーに SCM ソースが含まれる場合に、インベントリー更新のジョブ詳細ページに、プロジェクト更新のステータスインジケーターと、プロジェクト名が表示されます。ステータスインジケーターは、プロジェクト更新ジョブにリンクされ、プロジェクト名はプロジェクトにリンクされます。

_images/jobs-details-scm-sourced-inventories.png

4.2.1. サポートされるファイルの構文

Ansible Tower は、Tower が必要とする有効なインベントリー構文すべてをサポートする Ansible 2.4 以降の ansible-inventory モジュールを使用します。

コマンドラインで設定できるようにするには、awx-manage inventory_import コマンドで --method のオプションを使用することができます。ファイルからインベントリーを更新するには、Ansible バージョン 2.4 以前の ansible-inventory コマンドのバックポートバージョンが使用されます。

Ansible 2.4 以降のバージョンでは、正式に配布されている ansible-inventory のコマンドを使用して、インベントリーファイルが処理されます。