レガシーChefの呪縛を解け：Chef 12/13からChef 18+への「破壊と再生」ロードマップ
長年放置されたChef環境は、もはやインフラの資産ではなく「技術的負債」という名の時限爆弾だ。`chef-client`を走らせるたびに祈りを捧げる日々はもう終わりにしよう。
Chef 12/13から18+への移行は、単なるバージョンアップではない。「Procedural（手続き的）なスパゲッティコード」から「Declarative（宣言的）なモダンIaC」への意識改革である。現場で震えるほど役立つ、生存戦略としての移行ロードマップを伝授する。
—
1. 移行の「大前提」：破壊を恐れるな
Chef 12系から18系へのジャンプは、互換性の断絶を意味する。いきなり本番環境で`chef-client`を叩くのは自殺行為だ。
- Policyfileへの移行（最重要）: `environment`や`role`で構成を管理する時代は終わった。依存関係のバージョンをロックし、単一の成果物としてデプロイする`Policyfile`に完全に移行せよ。これにより「ある環境では動くが、他では動かない」というChef特有の悪夢から解放される。
- Chef Workstationの導入: `chef-client`や`knife`を個別にインストールするな。Chef Workstationを導入し、ツールチェーンを一括管理せよ。
2. 移行ロードマップ：段階的破壊の手順
Step 1: `Cookstyle`によるコードの自動診断
レガシーコードを人力で追うのは無駄だ。Chef純正のlintツール「Cookstyle」を全適用せよ。
プロジェクトルートで実行し、修正案を自動生成
cookstyle –auto-correct
これで非推奨構文（`if node[‘platform’]…`の乱用など）の8割は自動修正される。
Step 2: Custom Resourcesへの書き換え
`define`や複雑な`recipe`で実装されたレガシーなロジックを、すべて`Custom Resources`（`/resources`ディレクトリ）に落とし込め。
- 利点: リソースがカプセル化され、冪等性が保証される。
- テスト: `InSpec`を同時に導入し、実行後の状態が期待通りかを確認するパイプラインを組め。
Step 3: クライアントの段階的更新
一度に全ノードを更新してはいけない。
1. Test Kitchenの徹底: ローカルで`Kitchen`を回し、OSごとの挙動差分を撲滅する。
2. Canary Deployment: 全体の5%のノードのみを最新の`chef-client`に上げ、数日監視する。
—
3. 生産性を極限まで高める「神ツール」と設定
チームの生産性を底上げするために、今すぐ導入すべき構成例だ。
VS Code用「Chef Extension」の神髄
ただインストールするだけでなく、以下の設定を`settings.json`に追加せよ。
{
“ruby.lint”: {
“rubocop”: true
},
“editor.formatOnSave”: true,
“chef.cookbookPath”: [“./cookbooks”],
// 保存時に自動でCookstyleを走らせる設定
“editor.codeActionsOnSave”: {
“source.fixAll.cookstyle”: true
}
}
Policyfile.rb のベストプラクティス構成
レガシーな役割（Role）管理を捨て、以下のような構成で「再現性」を担保する。
Policyfile.rb
name ‘web-server-policy’
依存関係を完全にロック。これで環境ごとの「動かない」を防ぐ
default_source :supermarket
cookbook ‘nginx’, ‘~> 12.0’
cookbook ‘my_app_wrapper’, path: ‘./cookbooks/my_app_wrapper’
実行するレシピの順序を明示（run_list）
run_list ‘my_app_wrapper::default’
環境ごとの属性定義
named_definition :production do
default[‘nginx’][‘user’] = ‘www-data’
end
—
4. 現場でハマる「罠」とその対策
1. `ohai`の肥大化: 古いChefではカスタムohaiプラグインが原因でメモリを食い潰すことがある。最新版では標準属性を優先し、カスタムプラグインは必要最小限にせよ。
2. Chef Infra Serverのバージョン乖離: Serverが古いままではClient 18は動かない。必ず「Server -> Workstation -> Client」の順でアップデートすること。
3. 冪等性の崩壊: `execute`リソースで`shellout`を乱用していないか？`not_if`や`only_if`を必ず活用せよ。`execute`を使うのは「他に方法がない最終手段」であるべきだ。
—
結論：Chefを「管理対象」から「信頼できるエンジン」へ
Chef 18への移行は、単なるバージョンアップではなく、チームの「IaCリテラシー」を底上げする絶好のチャンスだ。
- 教訓: 「動いているから触らない」は技術的負債の養殖場である。
- 真理: 常に最新のバージョンを追い続け、`Policyfile`で構成を固定する。これだけで、運用コストは劇的に下がる。
さあ、古い`knife`の設定ファイルを閉じ、`cookstyle`を回すところから始めよう。君のインフラに真の平和が訪れることを期待している。