エンジニア諸君、ようこそ。今日はChefにおける「マルチプラットフォーム対応」という、多くのエンジニアが泥沼にハマりやすい難所を攻略しよう。
「WindowsとLinux、両方のサーバーを同じコードで管理したい」。一見、夢のような話だが、安易に`if/else`を乱立させると、コードはたちまちメンテナンス不可能な「スパゲッティ」と化す。
今日は、Chefの設計思想の核心である「抽象化」を用い、どちらのOSでも淀みなく動く、美しく堅牢なレシピの書き方を伝授する。
—
1. なぜ「抽象化」が必要なのか
インフラ自動化の最大の敵は「OSの差異」だ。
- パスの形式: `/etc/nginx` vs `C:\nginx`
- パッケージ管理: `apt/yum` vs `Chocolatey/MSI`
- サービス管理: `systemd` vs `Service Control Manager`
これらをベタ書きしたレシピは、未来の自分に対する負債でしかない。我々の目標は、「やりたいこと（What）」と「どうやるか（How）」を分離することだ。
2. 基礎のセットアップ：開発環境の準備
まず、Chefの動作確認ができる環境を整えよう。
1. Chef Workstationのインストール: [公式サイト](https://www.chef.io/downloads/tools/workstation)から入手。これがChefを操るための「コンソール」になる。
2. Chef Repoの作成: `chef generate repo my-infrastructure` で作業領域を作る。
3. HelloWorld的動作確認: 以下のコードを `cookbooks/my-app/recipes/default.rb` に書いてみよう。
動作確認：OS名をログに出力するだけのシンプルなレシピ
log “現在のプラットフォームは #{node[‘platform’]} です” do
level :info
end
`chef-client -z -o my-app::default` で実行し、ログにOS名が出れば準備完了だ。
—
3. 抽象化の極意：AttributesによるOS差異の吸収
ここからが本題だ。OSごとの差異をコードに埋め込むのではなく、Attributes（属性）に追い出すのが、プロの設計だ。
`attributes/default.rb` でOSごとに変数を定義する。
attributes/default.rb
case node[‘platform_family’]
when ‘debian’, ‘rhel’
default[‘my_app’][‘config_path’] = ‘/etc/my_app/config.conf’
default[‘my_app’][‘package’] = ‘my_app_pkg’
when ‘windows’
default[‘my_app’][‘config_path’] = ‘C:\my_app\config.conf’
default[‘my_app’][‘package’] = ‘my_app_installer’
else
raise “Unsupported platform: #{node[‘platform_family’]}”
end
この設計により、レシピ本体にはOS固有のロジックが一切漏れ出さない。
—
4. レシピの抽象化：`platform?` ヘルパーの活用
次に、レシピ本体（`recipes/default.rb`）を書いていこう。ここでは `platform?` ヘルパーを使い、宣言的に書くのがコツだ。
recipes/default.rb
1. パッケージのインストール（抽象化済み）
package node[‘my_app’][‘package’] do
action :install
end
2. 設定ファイルの配置（テンプレートを活用）
template node[‘my_app’][‘config_path’] do
source ‘config.conf.erb’
# WindowsとLinuxで権限管理が変わる場合は、ここだけ条件分岐させる
owner ‘root’ unless platform?(‘windows’)
mode ‘0644’ unless platform?(‘windows’)
end
3. サービスの制御
service ‘my_app’ do
action [:enable, :start]
# Windowsの場合のみサービス名を変更するようなケースにも柔軟に対応
service_name platform?(‘windows’) ? ‘MyWindowsService’ : ‘my_app’
end
5. この設計が「現場で最強」である理由
1. 冪等性（Idempotency）の担保: どの環境でも、Chefは「あるべき状態」を計算し、差分があるときだけ実行する。`platform?` を適切に使うことで、誤設定を防げる。
2. テスタビリティ: `Test Kitchen` を使えば、WindowsとLinuxの仮想マシンを同時に立ち上げ、このコードが両方で通ることを即座に検証できる。
3. 拡張性: 例えば、将来「macOS」対応が必要になっても、Attributesファイルを1箇所修正するだけで、メインのレシピは1行も直さなくて済む。
—
先輩エンジニアからのアドバイス
初心者の頃は、つい条件分岐でコードを埋め尽くしたくなるものだ。だが、「変更は一箇所に集約せよ」。これがインフラエンジニアとして生き残るための黄金律だ。
Chefは単なるツールではない。君たちのインフラに対する「思想」をコードとして表現するキャンバスだ。この抽象化パターンをマスターすれば、OSのバージョンアップやクラウドの移行など、どんな変化が訪れても動じない、鋼のようなインフラが作れるようになる。
さあ、次は君の手で、この美しい設計を実装してみよう。分からないことがあれば、いつでも聞くがいい。応援しているぞ。