Tower は Tower サーバーで直接保存された Playbook をサポートしますが、Playbook、ロール、および関連付けられた詳細をソースコントロールに保存することが最も適切な方法と言えます。これにより、インフラストラクチャーを自動化するルールを変更した日時や変更理由を示すための監査証跡を設定できます。さらに、Playbook をインフラストラクチャーやチームの他の部分と共有することが容易になります。
Ansible 文書 (http://docs.ansible.com/playbooks_best_practices.html) で Ansible のベストプラクティスを確認してください。複数のプロジェクトで使用する共通のルールセットを作成する場合、それらはソースコントロールのサブモジュール、または /opt などの共通のロケーションからアクセスできるようにする必要があります。プロジェクトがロールまたはコンテンツを他のプロジェクトからインポートすることは想定されてされていません。
注釈
Tower は vars_prompt の質問を対話的に許可しないため、Playbook では Ansible の vars_prompt 機能を使用できません。vars_prompt を使用する必要がある場合は、Tower の「 Survey 」機能の説明を参照し、使用してください。
注釈
Tower では対話的に一時停止をキャンセルできないので、Playbook でタイムアウトなしに Ansible の pause 機能を使用しないでください。pause を使用する必要がある場合には、必ずタイムアウトを設定するようにしてください。
注釈
Tower のインベントリー処理方法と互換性がないので、Playbook で Ansible の meta: refresh_inventory 機能は使用しないでください。Playbook がインベントリーを更新すると、ジョブを開始したインベントリーの最初に戻ってしまいます。代わりに、別のインベントリー更新手順を行うワークフローを使用してください。
Tower で実行されるジョブは現在の作業用ディレクトリーとして Playbook ディレクトリーを使用します。ただし、ジョブはこれに依存せず、playbook_dir 変数を使用するようコード化する必要があります。
クラウドプロバイダーまたはローカル CMDB であれ、インフラストラクチャー用に外部ソースが設定されている場合には、インベントリーの同期プロセスを定義し、動的インベントリーの Tower のサポート (クラウドインベントリーソースおよび カスタムインベントリースクリプト を含む) を使用することが最も適切な方法になります。これにより、インベントリーの状態が常に最新の状態に保たれます。
注釈
Ansible Tower 2.4.0 リリースでは、--overwrite_vars が 設定されていない場合に、インベントリーホスト変数への編集や追加がインベントリー同期後も永続化するようになりました。インベントリーの同期を以前と同じように動作させるには、--overwrite と --overwrite_vars の両方を設定する必要があります。
group_vars/ および host_vars/ を使用するのではなく、変数データをオブジェクトと共に Tower に維持する (インベントリーエディターを参照) ことが奨励されます。動的インベントリーソースを使用する場合、変数の上書き オプションが設定されていない場合に限り、Tower ではこれらの変数をデータベースと同期できます。
「コールバック」機能を使用して新規に起動するインスタンスが設定を要求できるようにする機能は、自動スケーリングのシナリオおよびプロビジョニング統合に非常に役立ちます。
ジョブテンプレートの「フォーク」を大きな値に設定し、実行の並行性を高めることを検討してください。Ansible のチューニングについての詳細は、「 Ansible ブログ 」を参照してください。
Jenkins などの継続的統合システムの場合、Tower ジョブを生成するには、ジョブテンプレートに対して curl 要求をするか、または Tower CLI ツールを使用する必要があります。ジョブテンプレートの認証情報では、特定のパスワードのプロンプトは必要になりません。API を使用したジョブ生成については、Tower API ガイド で扱われています。