やあ。インフラの深淵を覗き、自動化の快楽を知り尽くした者へ。
今日は「Chef」という古豪を、現代的な「不変インフラ（Immutable Infrastructure）」の文脈でどう蘇らせるかという話をしよう。
多くのエンジニアは、Chefを「サーバーに入って定期的に設定を書き換えるツール」だと思っている。だが、それはもう過去の遺物だ。本番環境でChef Clientを回し続けるのは、いわば「走りながらエンジンの部品を交換する」ようなもの。リスクが高すぎるし、構成ドリフト（設定のズレ）の悪夢から逃れられない。
真のプロは、「ChefをAMI（マシンイメージ）を焼くための調理器具として使い、デプロイ時には一切の変更を許さない」というアプローチを採る。今日はその極意を伝授しよう。
—
1. なぜ「Packer + Chef」なのか？
結論から言おう。「速さ」と「完全性」のためだ。
- 従来のChef: サーバー起動後に設定を適用。完了まで時間がかかり、途中でネットワークエラーが起きればサーバーは中途半端な状態で放置される。
- Immutable Chef: Packerが仮のインスタンスを立ち上げ、ChefがそこでOSを完璧に調理し、最終的に「冷凍保存（AMI化）」する。
デプロイ時はそのAMIを並べるだけ。起動時間は秒単位になり、実行中にChefがコケる心配もない。これが、SREが寝る時間を確保するための技術だ。
—
2. 環境構築：まずは道具を揃える
まずはマシンにChef WorkstationとPackerをインストールしよう。
インストールコマンド:
Chef Workstation (macOSの場合)
brew install –cask chef-workstation
Packer
brew install hashicorp/tap/packer
次に、最も重要な「HelloWorld」的構成を作ろう。今回は「Nginxをインストールしただけの強固なAMI」を焼く。
—
3. 実践：Immutable AMIビルドパイプライン
ディレクトリ構成はこうだ。シンプルに保て。
.
├── build.pkr.hcl # Packerの設定
└── cookbooks/
└── web/
└── recipes/
└── default.rb # Chefのレシピ
① Chefのレシピを書く (`cookbooks/web/recipes/default.rb`)
ここでは「Nginxをインストールして起動する」という宣言だけを行う。
Nginxのインストール
package ‘nginx’ do
action :install
end
Nginxサービスの制御
service ‘nginx’ do
action [:enable, :start]
end
② Packerの設定 (`build.pkr.hcl`)
Packerに対し、「AWSでEC2を立ち上げ、Chefで設定し、AMIとして保存せよ」と命じる。
packer {
required_plugins {
amazon = { version = “>= 1.0.0”, source = “github.com/hashicorp/amazon” }
chef = { version = “>= 1.0.0”, source = “github.com/chef/chef” }
}
}
source “amazon-ebs” “nginx-ami” {
ami_name = “my-nginx-server-{{timestamp}}”
instance_type = “t3.micro”
region = “ap-northeast-1”
source_ami = “ami-xxxxxxxxxxxxxxxxx” # Amazon Linux 2023などを指定
ssh_username = “ec2-user”
}
build {
sources = [“source.amazon-ebs.nginx-ami”]
# ここでChefを呼び出す
provisioner “chef-solo” {
cookbook_paths = [“./cookbooks”]
run_list = [“web::default”]
}
}
—
4. 実行：魔法をかける
準備ができたら、以下のコマンドを叩くだけだ。
設定のバリデーション
packer validate build.pkr.hcl
AMIのビルド開始
packer build build.pkr.hcl
Packerが裏でEC2を立ち上げ、Chefがレシピを実行し、最後にそのインスタンスをシャットダウンしてAMIを保存する。完了すれば、君の手元には「テスト済みで、誰がいつ起動しても全く同じ挙動をする」完璧なサーバーイメージが手に入る。
—
5. 先輩からのアドバイス：この設計の「深淵」
この手法をマスターすると、君のインフラ運用は劇的に変わる。
1. ドリフトの撲滅: サーバーに変更を加えたいときは、レシピを修正して再度Packerを回すだけだ。稼働中のサーバーをいじる必要はない。
2. ロールバックが即時: 新しいAMIにバグがあっても、Auto Scaling GroupのAMI指定を一つ前に戻すだけで、全サーバーが数分で健全な状態に復帰する。
3. テスト駆動開発: `Kitchen`などのツールを併用すれば、AMIを焼く前にローカルでChefのレシピが正しく動くかテストできる。
「サーバーをペットのように可愛がるな、家畜のように扱え」という言葉があるが、僕らSREにとっては「サーバーは使い捨ての氷の彫刻」だ。Chefという名の彫刻刀で理想の形を作り上げ、一度完成したら、あとはそれを並べるだけ。
これが、大規模インフラを安定して回し続けるための「正解」の一つだ。まずはこの小さな一歩から始めてみてほしい。毎日の作業が、驚くほど静かで平和なものになるはずだよ。
何か詰まったら、いつでも聞きに来るといい。インフラの道は険しいが、自動化の果てには絶景が待っている。応援しているよ。