Ansible Inventoryの深淵：静的記述からの脱却と、クラウドネイティブな自動化の極意
「まだ手動でIPアドレスを書き換えているのか？」
もし君が、AWSやGCP上のインスタンスが増減するたびに`hosts`ファイルを編集しているなら、今すぐその手を止めてほしい。Ansibleは単なる構成管理ツールではない。インフラの「現在地」をリアルタイムで把握し、あるべき姿へと収束させるためのエンジンだ。
今日は、Ansible Inventoryをマスターし、泥臭い手動管理から解放されるための「プロの作法」を伝授する。
—
1. 静的インベントリを「運用に耐えうる」状態にする
まず、静的インベントリ（INI形式は捨て、YAML一択だ）を設計する際の鉄則は、「ホスト名ではなく、役割（Role）でグルーピングする」ことだ。
推奨構成: `inventory/production.yml`
all:
children:
webservers:
hosts:
web-01:
ansible_host: 10.0.1.10
web-02:
ansible_host: 10.0.1.11
vars:
nginx_port: 80
dbservers:
hosts:
db-01:
ansible_host: 10.0.2.10
vars:
ansible_user: ec2-user
ansible_ssh_private_key_file: ~/.ssh/id_rsa
ポイント: `ansible_host`を直接記述しつつ、変数をグループ単位で括る。これにより、将来的に動的インベントリへ移行する際の構造的負債を最小化できる。
—
2. 動的インベントリ（Dynamic Inventory）こそがSREの真髄
クラウド環境において、IPアドレスは「使い捨て」である。AWSの `aws_ec2` プラグインを使えば、環境内のインスタンスをタグベースで自動抽出できる。
`inventory/aws_ec2.yml` (神設定)
plugin: aws_ec2
regions:
- ap-northeast-1
filters:
# ‘Environment: production’ タグを持つインスタンスだけを対象にする
tag:Environment:
- production
keyed_groups:
# タグから自動的にグループを生成する (例: Role: web -> webグループに所属)
- key: tags.Role
prefix: ”
separator: ”
compose:
# Ansibleの接続先をプライベートIPに強制する
ansible_host: private_ip_address
この設定ファイルを置くだけで、`ansible-inventory –graph` を叩けば、クラウド上の全リソースが自動的にツリー表示される。もうIPリストと睨めっこする必要はない。
—
3. 現場で震える！生産性を爆上げする「プロの武装」
① VS Code神プラグイン
- Ansible (Red Hat公式): 構文チェックとドキュメント参照が爆速化する。
- YAML (Red Hat): スキーマバリデーションが強力。インデントミスで深夜に泣くことがなくなる。
② チーム開発で絶対守るべきルール：`ansible.cfg` の共有
プロジェクトルートに必ず `ansible.cfg` を置き、挙動を統一せよ。これを怠ると「僕の環境では動く」という悲劇が繰り返される。
[defaults]
inventory = inventory/aws_ec2.yml
remote_tmp = /tmp/.ansible/tmp
パフォーマンスの要：SSHパイプラインを有効化
pipelining = True
冪等性の確認を厳格に
retry_files_enabled = False
ログ出力の最適化
stdout_callback = yaml
③ 隠れたキーボードショートカット (VS Code)
- `Ctrl + Shift + P` -> `Ansible: Run Ansible Lint`: ファイル保存時に自動実行するよう設定すれば、コード品質が物理的に担保される。
—
4. 現場で役立つ「極限の知見」：冪等性の担保
動的インベントリを使う際、最も注意すべきは「意図しない対象への操作」だ。これを防ぐには、必ず `limit` オプションを習慣化すること。
間違いを許容しない実行コマンド
ansible-playbook site.yml -i inventory/aws_ec2.yml –limit “tag_Role_web” –check
なぜこれが必要か？
クラウドは動的だ。もし誰かがテスト環境に同じタグを付けてしまったら、プロダクションの設定がテスト環境に反映される可能性がある。`–check` モードでの事前確認と `limit` による範囲限定は、SREの生存本能だ。
—
最後に：なぜここまでやるのか
我々インフラエンジニアの仕事は、サーバーを「叩く」ことではなく、システムを「あるべき状態」に維持し続けることだ。
インベントリファイルを自動化し、インフラをコードとして扱い、環境の差分を排除する。これができれば、君のチームは障害対応に追われる時間を減らし、より高次元なアーキテクチャ設計に集中できるはずだ。
「ツールに使われるな、ツールを使い倒せ」。
今日から君のインベントリは、単なるテキストファイルではなく、クラウドを制御する「脳」になる。さあ、コードを書いて世界を自動化しよう。