Ansible Roleの極致：疎結合で「壊れない」インフラを構築する設計思想
Ansibleを使い始めると、誰もが一度は「巨大な1枚岩のPlaybook」という地獄に突き当たる。実行のたびに祈るような気持ちで `ansible-playbook` を叩き、修正箇所を探すために数千行のYAMLをスクロールする……そんな時代は終わりにしよう。
真のSREは、インフラを「コード」としてではなく「疎結合なモジュール群」として管理する。今回は、チーム開発で破綻せず、数年後も平気でメンテナンスできる「Ansible Role」の極限設計術を伝授する。
—
1. ディレクトリ構造の「正解」：依存関係を排除せよ
多くのエンジニアが陥る罠は、Roleの中に「他のRoleの依存関係」をハードコーディングすることだ。これでは再利用性が死ぬ。以下の構造をテンプレートとして脳に刻め。
roles/
├── common/ # 全ホスト共通設定（NTP, User管理など）
│ ├── tasks/
│ │ └── main.yml # include_tasksで役割ごとに分割
│ ├── vars/
│ │ └── main.yml # 変更頻度の低いデフォルト値
│ └── templates/ # Jinja2テンプレート
├── web-server/ # 責務を1つに絞ったRole
│ ├── tasks/
│ ├── handlers/ # 再起動などのトリガーを集中管理
│ └── defaults/ # 外部から上書き可能な変数（最優先！）
【極限の知見】`defaults/main.yml` と `vars/main.yml` の使い分け
- `defaults/`: ユーザーがオーバーライドすべき設定値。
- `vars/`: ロジック上、絶対に変わってはいけない定数。
ここを混同すると、Roleを外部から呼び出した際に値の優先順位で事故が起きる。
—
2. 開発スピードを爆速にする「神」テクニック
必須のVSCodeプラグイン
- Ansible (Red Hat公式): Lint機能と補完が優秀。これがないとYAMLを書く時間が無駄になる。
- YAML (Red Hat): スキーマバリデーションに必須。
- GitLens: 誰がその設定を書き換えたか追跡できることが、冪等性の崩壊を防ぐ最大の防御線だ。
Ansible開発を加速する隠し設定
`ansible.cfg` はプロジェクトルートに置け。これを設定していないエンジニアは、現場で信頼を失う。
[defaults]
実行時間を可視化し、ボトルネックを瞬時に特定する
callback_whitelist = profile_tasks
接続エラー時のリトライを高速化
forks = 20
不要なFact収集をスキップして爆速実行
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_facts
—
3. 「壊れない」ための冪等性担保の鉄則
Ansibleは「あるべき姿」を記述する言語だ。`shell` や `command` モジュールを多用するのは、敗北を意味する。
YAML設計の黄金律：`changed_when` を使いこなす
標準モジュールがカバーできない処理を行う際は、必ず `changed_when` を定義して、無駄な変更ログが出るのを防げ。
- name: 設定ファイルが変更された場合のみ再起動を通知
shell: /usr/local/bin/check_config.sh
register: config_check
# 常にchangedにならないよう制御。成功しても変更なしとみなす
changed_when: config_check.rc != 0
notify: restart_service
—
4. チーム開発における「共有化の掟」
Roleを自作する前に `Ansible Galaxy` を見よ。だが、信頼できないRoleをそのまま使うな。
1. `requirements.yml` でバージョン固定:
`version: v1.2.3` のようにタグを指定せよ。ブランチ名（`master`など）を指定すると、ある日突然インフラが壊れる。
2. `molecule` によるテスト:
Roleのディレクトリで `molecule test` を叩いて、Dockerコンテナ上で冪等性と動作確認を自動化しろ。これを通していないコードを本番に投入するのは、目隠しで高速道路を走るのと同じだ。
—
結論：コードは「捨てる勇気」が重要
優れたインフラエンジニアは、コードを書くことよりも「どうすれば書かなくて済むか」を考える。
複雑なRoleを作ってしまったら、それは設計が間違っている証拠だ。Roleは「Webサーバー」「DBサーバー」「モニタリングエージェント」といった単位まで細分化し、Playbook側でそれらを組み合わせて「システム」を構成せよ。
今日から、あなたのAnsibleは「構築ツール」から「自動化されたインフラのドキュメント」へと進化する。
さあ、まずは `ansible-galaxy init` で、再利用可能な美しいモジュールを一つ作ることから始めよう。現場で震えるような高効率な自動化が、そこから始まる。