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