Chef Habitat × Chef Infra：ImmutableとMutableの「いいとこ取り」でインフラを極める
こんにちは。クラウドインフラの深淵を覗き続けているエンジニアです。
皆さんは「Chef」と聞くと、何を思い浮かべますか？「サーバーの設定をコードで書く（Chef Infra）」というイメージが強いでしょう。しかし、現代のクラウドネイティブな世界では、それだけでは足りません。
今日は、「アプリケーションのライフサイクル管理」を担う Chef Habitat と、「OSレベルの環境構築」を担う Chef Infra を融合させた、最強のハイブリッド運用アーキテクチャについて語ります。
これをマスターすれば、あなたのインフラは「壊れない、汚れない、再現できる」という理想の姿へ一歩近づきます。
—
1. なぜ「ハイブリッド」が必要なのか？
インフラエンジニアとして避けて通れないのが、「どこまでをImmutable（不変）にし、どこまでをMutable（可変）にするか」という問いです。
- Chef Habitat (Immutable): アプリケーションとその依存関係を一つの「ポータブルなパッケージ」に閉じ込めます。OSが何であろうと、どこでも同じように動く。これが現代のアプリケーションのあり方です。
- Chef Infra (Mutable/Configuration): OSの設定、ユーザー管理、セキュリティパッチの適用など、環境固有の「土台」を整えます。
「アプリケーションはHabitatで封印し、土台はInfraで耕す」。 この役割分担こそが、トラブルが起きない堅牢なシステムの秘訣です。
—
2. まずはHabitatで「ポータブルなアプリ」を作る
まずは、アプリを「Habitatパッケージ」にしてみましょう。ここでのゴールは、「OSに依存しないアプリの実行単位」を作ることです。
セットアップ（macOS/Linux）
まずはHabitat CLIをインストールします。
ツールチェーンのインストール
curl https://raw.githubusercontent.com/habitat-sh/habitat/master/components/hab/install.sh | sudo bash
HelloWorld: `plan.sh` の魔力
Habitatは `plan.sh` という一つのファイルでアプリのビルド方法を定義します。
plan.sh
pkg_name=”hello-world”
pkg_origin=”my_company”
pkg_version=”0.1.0″
pkg_deps=(core/bash) # 依存関係を明示的に指定（これがポータブルの秘密）
アプリのビルド工程
do_build() {
return 0
}
アプリのインストール工程
do_install() {
# 実行ファイルをbinディレクトリに配置
cp -v hello.sh $pkg_prefix/bin/
}
この `plan.sh` を作成して `hab pkg build .` を叩けば、あとは自動でコンテナやパッケージが生成されます。環境差分による「自分の環境では動いたのに」という言い訳は、今日で卒業です。
—
3. Chef Infra で「土台」を整える
Habitatでパッケージ化したアプリをサーバーに配備する際、OSの設定がバラバラだと本末転倒です。ここでChef Infraの出番です。
Chef InfraでHabitatを管理する
Chef Infraのレシピ内で、Habitatをインストールし、サービスを起動するコードを記述します。
recipes/default.rb
1. Habitatパッケージのインストール
habitat_package ‘my_company/hello-world’ do
strategy :at_once
end
2. Habitatスーパーバイザーの起動とアプリ実行
habitat_service ‘my_company/hello-world’ do
strategy :rolling
action [:load, :start]
end
このコードの美しさは、「冪等性（べきとうせい）」が担保されていることです。何度実行しても、サーバーの状態は「指定したバージョンのアプリが、正しく設定されたOS上で動いている」という状態に収束します。
—
4. このアーキテクチャの何が「劇的に楽」なのか？
初心者のうちは、「設定ファイルが散らばる」ことに恐怖を感じるかもしれません。しかし、この構成をとることで以下のメリットが生まれます。
1. デプロイの失敗が激減: Habitatパッケージは検証済みです。OSのライブラリ不足で動かないという事故が起きません。
2. ロールバックが瞬時: Habitatは過去のパッケージを保持しているため、不具合があればバージョンを指定してコマンド一つで戻せます。
3. インフラのコード化: 「サーバーの中身」が完全にコードで定義されているため、誰が触っても（あるいは自動化ツールが触っても）同じ結果になります。
—
最後に：エンジニアとしての心構え
「ツールを覚える」のではなく、「システムがどうあるべきか」を考える。これが、私が皆さんに一番伝えたいことです。
Chef HabitatとChef Infraを組み合わせることは、単なる技術導入ではありません。それは、「人間が手作業でサーバーを触る」という不確実な時代から、「コードがインフラを制御する」という予測可能な時代への転換です。
まずは、手元の小さなスクリプトを `plan.sh` に書き換えるところから始めてみてください。その小さな一歩が、将来の巨大なインフラを支える強固な土台になるはずです。
何か詰まったら、いつでも聞いてくださいね。応援しています！