Documentation

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

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

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

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

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

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

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

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

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

_images/sourced-from-project-update-on-project-update.png

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

  • まず、同じプロジェクトから更新されるインベントリーやプロジェクトを使用するように、ジョブテンプレートを作成することができます。このような場合は、update_on_launch にプロジェクトを設定し、必要に応じてインベントリーの更新をトリガーします。

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

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

注釈

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

また、関連するジョブの実行中にプロジェクトの更新がブロックされません。大規模なプロジェクト (約 10 GB) がある場合は、/tmp のディスク容量が問題になる可能性があります。

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

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

  • source_project: 使用するプロジェクト

  • source_path: ディレクトリーまたはファイルを示すプロジェクト内の相対パス。これが空のままの場合は、" " はプロジェクトの root ディレクトリーを指す相対パスを表します。

  • source_vars: "file" タイプのインベントリーソースに設定されている場合には、実行時に環境変数に渡されます。

プロジェクトを更新すると、そのプロジェクトが使用されているインベントリーの更新が自動的に発生します。プロジェクトの更新は、インベントリーリソースの作成直後にスケジュールされます。関連ジョブの実行中は、インベントリー更新もプロジェクト更新もブロックされません。大規模なプロジェクト (約10 GB) がある場合は、/tmp のディスク領域が問題になる可能性があります。

Tower ユーザーインターフェースのインベントリーソースの作成ページに場所を指定できます。インベントリーソースの作成方法は、Ansible Tower User Guide の「インベントリー」セクションを参照してください。

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

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

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

関連するジョブの実行中にインベントリーの更新を実行できます。

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

Ansible Tower は、Ansible の ansible-inventory モジュールを使用してインベントリーファイルを処理し、Tower で必要な有効なインベントリー構文をすべてサポートします。