Tower は Tower サーバーで直接保存された Playbook をサポートしますが、Playbook、ロール、および関連付けられた詳細をソースコントロールに保存することが最も適切な方法と言えます。これにより、インフラストラクチャーを自動化するルールを変更した日時や変更理由を示すための監査証跡を設定できます。さらに、Playbook をインフラストラクチャーやチームの他の部分と共有することが容易になります。
Ansible 文書 (http://docs.ansible.com/playbooks_best_practices.html) で Ansible のベストプラクティスを確認してください。複数のプロジェクトで使用する共通のルールセットを作成する場合に、このルールセットはソースコントロールのサブモジュール、または /opt などの共通のロケーションからアクセスできるようにする必要があります。プロジェクトがロールまたはコンテンツを他のプロジェクトからインポートすることは想定されていません。
注釈
Tower は vars_prompt の質問に対話的に対応できないので、Playbook では vars_prompt 機能を使用できません。vars_prompt を使用する必要がある場合は、Tower の Survey 機能を参照し、使用してください。
注釈
Tower では対話的に一時停止をキャンセルできないので、Playbook でタイムアウトなしに Ansible の pause 機能を使用しないでください。pause を使用する必要がある場合には、必ずタイムアウトを設定するようにしてください。
Tower で実行されるジョブは、現在の作業用ディレクトリーに Playbook ディレクトリーを使用します。ただし、ジョブはこれに依存せず、playbook_dir 変数を使用するようにコード化する必要があります。
クラウドプロバイダーまたはローカル CMDB であれ、インフラストラクチャー用に外部ソースが設定されている場合には、インベントリーの同期プロセスを定義し、動的インベントリーの Tower のサポート (クラウドインベントリーソースおよび custom inventory scripts を含む) を使用することが最も適切な方法になります。これにより、インベントリーの状態が常に最新の状態に保たれます。
注釈
インベントリーホスト変数の編集と追加は、--overwrite_vars が 設定されていない 限りインベントリー同期後も維持されます。
group_vars/ および host_vars/ を使用するのではなく、変数データをオブジェクトと共に Tower に維持する (インベントリーエディターを参照) ことが奨励されます。動的インベントリーソースを使用する場合、変数の上書き オプションが設定されていない場合に限り、Tower ではこれらの変数をデータベースと同期できます。
「コールバック」機能を使用して新規に起動するインスタンスが設定を要求できるようにする機能は、自動スケーリングのシナリオおよびプロビジョニング統合に非常に役立ちます。
ジョブテンプレートの「フォーク」を大きな値に設定し、実行の並行性を高めることを検討してください。Ansible のチューニングについての詳細は、「the Ansible blog 」を参照してください。
Jenkins などの継続的統合システムの場合に、Tower ジョブを生成するには、ジョブテンプレートに対して curl 要求を行う必要があります。ジョブテンプレートの認証情報では、特定のパスワードのプロンプトは必要になりません。設定と使用の説明については、`AWX CLI Ansible Tower documentation`_を参照してください。
LDAP ユーザーが Tower で認証されると、デフォルトでは、すべてのユーザー関連属性がログインのたびにデータベースで更新されます。一部の環境では、パフォーマンスの問題のためにこの操作をスキップできます。これを回避するには、AUTH_LDAP_ALWAYS_UPDATE_USER オプションを無効にします。設定と使用方法については、「Knowledge Base Article 5823061」を参照してください。新しいユーザーが引き続き作成され、最初のログイン時に属性がデータベースにプッシュされることに注意してください。
警告
このオプションを False に設定すると、LDAP ユーザーの属性への変更は Tower にプッシュされません。属性は、ユーザーが最初に作成されたときにのみ Tower にプッシュされます。