Chefは「冪等性の道具」ではない。運用の「意思」を記述するフレームワークだ
多くのエンジニアがChefを「設定ファイルを流し込むための自動化ツール」と誤解している。だが、真のSREにとってChefとは、「システムが崩壊した際、いかにして自律的に元の正常な状態（Desired State）へ復帰させるか」というリカバリ戦略を記述するためのコードだ。
今回は、Chef Infra Client実行中に発生する「致命的な例外」を制御し、システムを泥沼の死から救い出すための極限のアーキテクチャを伝授する。
—
1. 例外ハンドリングの深淵：Chef::Handler を使い倒せ
標準的なエラーログを出力して終わる構成管理は、もはや過去の遺物だ。本番環境では「エラー発生時に何を行うか（再起動、Slack通知、フェイルオーバー、あるいはリソースのロールバック）」をコードとして定義しなければならない。
現場で必須の「カスタム・リカバリ・ハンドラー」
`Chef::Handler` を継承して、収束失敗時にアクションを起こす仕組みを実装する。
files/default/handlers/recovery_handler.rb
require ‘chef/handler’
class RecoveryHandler < Chef::Handler def report # 実行が失敗した時のみ実行される if failed? Chef::Log.error("FATAL ERROR DETECTED: #{run_status.exception}") # 例：特定のサービスを強制再起動して復旧を試みる execute 'force-restart-critical-service' do command 'systemctl restart nginx && systemctl restart app-server' end # 通知ロジック（Slack/PagerDuty APIを叩く） notify_ops_team(run_status.exception) end end private def notify_ops_team(exception) # 実際はここでHTTPライブラリを使い、アラートを発報する puts "Alerting DevOps team via Webhook..." end end このハンドラーを `client.rb` に登録することで、収束の失敗を単なるログで終わらせず、システムが自律的に「治癒」を試みるセーフティネットを構築できる。 ---
2. 「Chefの死」を防ぐ冪等性設計の鉄則
Chefの実行が途中で力尽きると、リソースが「中途半端な状態」で放置される。これを防ぐためのベストプラクティスが「アトミック・リソース・パターン」だ。
- 遅延実行の活用: `notifies` や `subscribes` を乱用せず、リソースの更新順序を `ruby_block` と `lazy` で厳密に制御せよ。
- ガード句の極致: `only_if` と `not_if` は、単なる条件分岐ではない。「現在の環境がこのリソースを適用するに値するか」を問う門番だ。
失敗してはならない設定変更の例
template ‘/etc/app/config.json’ do
source ‘config.json.erb’
# 設定が構文エラーなら適用させない（Chefが失敗する前に止める）
verify ‘app-config-check -f %{path}’
action :create
notifies :restart, ‘service[app-service]’, :immediately
end
`verify` 属性を使い、設定適用前にバイナリでバリデーションをかける。これが本番環境を救う最後の一線となる。
—
3. チームの生産性を爆速化する「神設定」と運用ルール
優秀なテックリードは、ツールを個人の好みに委ねない。チーム全員の速度を揃えるための「規約」をコードベースに埋め込む。
推奨ツールと設定
- `chef-run` を愛せ: `chef-client` を実行して数分待つのは時間の浪費だ。単一のレシピを即座に適用する `chef-run` を使い、フィードバックループを秒単位まで縮めろ。
- `.chef/config.rb` の共有: チーム全員が同じ設定を参照するよう、リポジトリルートに `.chef/config.rb` を置き、パスを環境変数 `CHEF_CONFIG` で固定せよ。
実用的な設定ファイル構成（推奨）
{
“chef_type”: “client_config”,
“chef_server_url”: “https://chef-server.local”,
“client_key”: “/etc/chef/client.pem”,
“log_level”: “:info”,
“log_location”: “/var/log/chef/client.log”,
“handler_path”: “/var/chef/handlers”,
“chef_license”: “accept”,
“interval”: 1800,
“splay”: 300
}
- Splay（分散実行）: 本番環境で全サーバーが同時にChefを実行すれば、Chef Serverは即死する。`splay` 設定は必須。
—
4. 最後に：SREとしてChefをどう捉えるか
Chefは「サーバーを作るツール」ではなく、「サーバーの理想状態を定義し、逸脱を許さない憲法」である。
もしあなたが、実行エラーに怯えながら手動でSSHして修正しているなら、それはChefの設計思想を放棄しているのと同じだ。例外をコードで握り潰し、リカバリを自動化し、冪等性を極限まで高める。その先にあるのは、エンジニアが寝ている間も自ら修正を繰り返す「不滅のインフラ」だ。
次にChefを触る時、その一行が「ただ動くか」ではなく「障害時にどう振る舞うか」を意識してほしい。それがプロフェッショナルへの第一歩だ。