Chefの通知（notifies/subscribes）を制する者がインフラの「冪等性」を制する
Chefの `notifies` と `subscribes`。これらを単なる「イベントトリガー」だと思っているなら、大規模なインフラ環境では確実に痛い目を見る。
Chefは「収束（Convergence）」を目指すツールだ。リソースの状態をあるべき姿（Desired State）に近づけるプロセスにおいて、リソース間の依存関係をどう制御するか。この設計思想を理解しないまま書かれたレシピは、実行するたびに結果が変わる「不安定な脆弱性」を孕むことになる。
今日は、現場でエンジニアが最も頭を抱える「実行順序の罠」と、それを完全に支配するための極限の知見を授ける。
—
1. 収束フェーズの深淵：Immediate vs Delayed
Chefには主に2つの実行タイミングが存在する。これを誤ると、設定ファイルが書き換わる前にサービスが再起動されるといった「順序の不整合」が起きる。
- `:immediate`（即時実行）
リソースが更新された「その瞬間」に通知先を実行する。依存関係が極めて強い場合（例：設定ファイルの更新直後に即座に設定を読み込ませたい場合）に使う。
- `:delayed`（遅延実行 – デフォルト）
ChefのChef Client実行の「最後に」まとめて実行する。これがなぜ重要か？ 複数リソースの更新によって、同じサービスを何度も再起動（Restart）する無駄を防ぐためだ。
現場での黄金律
「特別な理由がない限り、`:delayed` を使え」。
即時実行を多用すると、実行順序の予測が困難になり、Chefの冪等性が崩壊する。「設定ファイルが3つ書き換わったから、最後に1回だけサービスをリロードする」という挙動こそが、Chefを洗練されたツールたらしめる。
—
2. 現場で使える「通知」の実践設計
以下は、NGなコードと、現場で採用すべき堅牢なコードの対比だ。
悪い例：混乱を招く依存関係
設定ファイルを更新
template ‘/etc/nginx/nginx.conf’ do
notifies :restart, ‘service[nginx]’, :immediate # 危険：即時実行しすぎると順序制御が崩壊する
end
良い例：冪等性を担保する設計
テンプレートのリソース定義
template ‘/etc/nginx/nginx.conf’ do
source ‘nginx.conf.erb’
# デフォルト（delayed）を活用し、複数更新を統合する
notifies :reload, ‘service[nginx]’, :delayed
end
サービスのリソース定義はシンプルに保つ
service ‘nginx’ do
action [:enable, :start]
end
—
3. 生産性を極限まで高める「テックリードの装備」
Chef開発を日常的に行うなら、ツール選定で妥協してはいけない。
必須の神プラグイン & 開発環境
1. `vscode-chef`: VS Code用。リソースのシンタックスハイライト、補完が強力。
2. `RuboCop` + `chef/cookstyle`: これなしでCIを通すのは論外だ。コミュニティのベストプラクティスに強制的に従わせることで、コードレビューのコストをゼロにする。
3. `Test Kitchen` + `Kitchen-Terraform`: ローカル環境で仮想マシンを立ち上げ、冪等性を検証する。`kitchen converge` を打つ回数を最小化する設計が、開発スピードの鍵だ。
チーム開発の「設定共有ルール」
`.chef/config.rb` を各々でいじらせるな。
チームで `Policyfile.rb` を導入せよ。従来の `Berkshelf` はもう古い。`Policyfile` は、レシピのバージョン、属性値、実行順序を1つの「ロックファイル」に固定する。これにより、「自分の環境では動く」という地獄から解放される。
Policyfile.rb の神構成例
name ‘web_server_policy’
default_source :supermarket
依存関係を厳格に固定
cookbook ‘nginx’, ‘~> 12.0.0’
cookbook ‘my_app’, path: ‘./cookbooks/my_app’
ノード属性をコードで管理し、JSONファイルの散逸を防ぐ
default[‘nginx’][‘version’] = ‘1.18.0’
—
4. 最後に：プロのエンジニアへ
Chefの実行順序でハマる原因は、ツールが悪いのではない。「Chefはスクリプトではなく、宣言的言語である」という原則を忘れているからだ。
`notifies` は単なる関数呼び出しではない。Chefの収束エンジンに対する「要求の予約」であると認識せよ。
- 遅延実行を活用して、インフラの変更コストを最小化せよ。
- Policyfileで実行環境を「一点の曇りもなく」固定せよ。
- コードレビューでは、リソースの「順序」よりも「宣言の整合性」を追え。
この視点を持てば、君の書くレシピは数千台のノードを管理する基盤となっても決して揺るがないはずだ。さあ、コードを書け。そして、インフラを完全に自動化せよ。