DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Ansible ファクトキャッシュ設定の包括ガイド

jsonfile または Redis で Ansible ファクトキャッシュを設定し、タイムアウトを設定し、古いキャッシュデータをクリアし、繰り返されるファクト収集のオーバーヘッドを回避します。

Ansible ファクトキャッシュ設定の包括ガイド

Ansible ファクトキャッシュは、プレイブックが実行のたびに同じホストファクトの収集に時間を費やしすぎる場合に役立ちます。数百のホストを管理する場合、setup モジュールの呼び出しが繰り返されると、実際の作業が始まる前に SSH のオーバーヘッドが顕著に増加する可能性があります。

ファクトキャッシュは、正常に実行された後に収集したファクトを保存し、キャッシュが有効な間はそれらを再利用します。その結果、多少古いファクトでも許容できるワークフローでは、プレイブックの起動が高速化されます。

Ansible ファクトとパフォーマンスへの影響を理解する

Ansible は、明示的、またはデフォルトの gather_facts: true 動作を通じて、setup モジュールでファクトを収集します。ファクトには、OS ファミリー、カーネル、IP アドレス、マウント、CPU、メモリ、Python インタプリタ情報などの詳細が含まれます。

パフォーマンスの向上は、キャッシュされたデータが新しい場合に、リモート収集を繰り返さないことで得られます。これは、レポート、テンプレート、および分単位で変更されないファクトに依存する条件付きロジックに役立ちます。

ファクトキャッシュの設定方法

Ansible は ansible.cfg でファクトキャッシュを設定します。実用的な選択肢として、ローカル JSON ファイルと Redis の 2 つがあります。正確なプラグイン名が重要です。

1. JSON ファイルキャッシュ (ローカルストレージ)

JSON ファイルキャッシュは、制御マシンにファクトを保存します。シンプルで、外部サービスは必要ありません。

ansible.cfg での JSON キャッシュの設定

jsonfile キャッシュプラグインを使用します:

[defaults]
fact_caching = jsonfile
fact_caching_connection = /path/to/ansible_facts_cache
fact_caching_timeout = 600

fact_caching_connection は、Ansible がキャッシュファイルを書き込むディレクトリです。事前に作成し、Ansible を実行するユーザーが書き込み可能であることを確認してください:

mkdir -p /path/to/ansible_facts_cache

fact_caching_timeout は秒単位で測定されます。タイムアウト後、プレイでファクトが必要になると、Ansible は新しいファクトを再度収集します。

2. Redis キャッシュ (共有、高性能ストレージ)

Redis は、複数の制御ノード、ユーザー、または CI ジョブが同じファクトキャッシュを共有する必要がある場合に適しています。

Redis キャッシュの前提条件

到達可能な Redis サーバーと、Ansible が使用する Python 環境で利用可能な Python Redis クライアントが必要です:

python -m pip install redis

ansible.cfg での Redis キャッシュの設定

Redis 接続文字列を使用します:

[defaults]
fact_caching = redis
fact_caching_connection = 127.0.0.1:6379/0
fact_caching_timeout = 3600

/0 は Redis データベース 0 を選択します。他のアプリケーションも Redis を使用する場合は、専用のデータベースまたは Redis インスタンスを使用し、Redis エンドポイントを他のインフラストラクチャサービスと同様に保護してください。

キャッシュをプレイブックに統合する

キャッシュは、プレイがファクトを収集するときに設定されます:

- name: ファクトを収集して使用する
  hosts: webservers
  gather_facts: true
  tasks:
    - name: OS ファミリーを表示
      debug:
        msg: "OS ファミリーは {{ ansible_os_family }} です"

ファクトキャッシュが有効な場合、Ansible はキャッシュされたファクトが有効な間はそれを再利用できます。ファクトがないか期限切れで、gather_facts: true の場合、Ansible は再度ファクトを収集します。

gather_facts: false を設定すると、Ansible はそのプレイのファクト収集を実行しません。キャッシュされたファクトは、すでにキャッシュされている場合、ホスト変数を介して利用可能な場合がありますが、重要なロジックでは盲目的に依存しないでください。キャッシュがないと、変数が未定義になる可能性があります。

安全なパターンは、スケジュールされたプレイまたは初期のプレイでファクトを収集し、その後、古さが許容されるレポートやオーケストレーションのプレイブックでキャッシュされたファクトを使用することです。

ファクトキャッシュの管理

ホストファクトが変更され、タイムアウトを待ちたくない場合は、キャッシュをクリアします。

JSON キャッシュのクリア

設定されたキャッシュディレクトリ内のファイルを削除します:

rm -rf /path/to/ansible_facts_cache/*

Redis キャッシュのクリア

Redis データベースが Ansible ファクト専用の場合は、そのデータベースをフラッシュできます:

redis-cli -n 0 FLUSHDB

FLUSHDB は、選択された Redis データベース内のすべてのキーを削除します。共有データベースで実行する場合は、すべてのキーを削除しても安全であることを確認してください。

ベストプラクティス

  • 単一の制御マシンとシンプルなローカルワークフローには jsonfile を使用します。
  • 複数のランナーが同じキャッシュを必要とする場合は Redis を使用します。
  • 急速に変化するインフラストラクチャではタイムアウトを短く、安定したフリートでは長く設定します。
  • 他のユーザーが読み取れる場所に機密性の高いカスタムファクトをキャッシュしないでください。
  • ansible --version で Ansible が使用している設定ファイルを確認します。
  • 大規模なフリートでキャッシュを有効にする前に、1 つのインベントリグループでテストします。

実践的なポイント

繰り返されるファクト収集が測定可能なコストであり、プレイブックがキャッシュされたデータを許容できる場合は、Ansible ファクトキャッシュを有効にします。jsonfile から始め、キャッシュの共有が実際のワークフローの問題を解決する場合にのみ Redis に移行し、ホストファクトの変更頻度に合わせてタイムアウトを設定します。