Re: ChefとCapistranoの境界線 #opschef_ja
この間の Chef Casual Talks での id:nekoruri さんの発表、ChefとCapistranoの境界線 に対する
僕の考え方を書いておこうと思います。
Chefを導入する時の「考え方」
完全に同意します。
僕は community cookbooks を使おうとみんなに吹聴して回っているように、
大抵の環境で必要とされる内容は community cookbooks に収録されていることが多いです。
ただ、細く設定ができなかったり、ちょっと代わった入れ方をしたいときが出てくると
community's ではカバーできなくなります。
そんなときは僕も
- fork して書き換える
- include_recipe して、追加の処理を書き足す (設定ファイルをごそっと上書きしたりとか)
- あたらしいものを作る
などをして回避しています。
例えば、今関わっているお仕事では Apache 1.3, 2.0, 2.2 のそれぞれで Apache モジュールの動作確認が必要なので
独自の cookbook を作って回避しています。
この環境でしか使わないことはほぼ明らかなので、script リソースでごりごり configure; make; make install してます。
というわけで、深追いし過ぎない程度に community cookbooks と付き合っていくのが、素早く環境構築することへの近道だと思います。
プログラムのデプロイをChefでどこまでやるべきか
僕は環境構築とデプロイは別の作業だと考えているので、chef ではアプリケーションのデプロイは行なっていません。
chef はあくまで環境構築までが守備範囲ということで、capistrano のデプロイをするための準備段階までしか進めていません。
つまり、id:nekoruri さんと同様に、
- Capistrano rootディレクトリの作成
- 各種ログディレクトリの作成
- ログファイルlogrotateの設定ファイル
- Unicornを立ち上げるinit.d script配布
- MySQLのデータベース/ユーザ作成
あたりですね。
環境構築とデプロイを分けている理由はいくつかあります。
ひとつは、アプリケーションのアップグレードをする際の手順が常にひとつとは限らないことです。
ソースコードを更新すればいいだけのことが多いですが、DB マイグレーションが必要となるケースがあったり、
バグで壊れたデータを修正しないといけないケースなどもあったりします。
こうしたとき、chef のような定義ベースのツールより、capistrano や fabric のような手順ベースのツールの方が
扱いやすいのではないかと考えています。
もうひとつは、ロールバック(ダウングレード)が必要になった場合です。
デプロイしたアプリケーションにバグがあり、ひとつ前のバージョンに戻したいという状況で、
どのように chef でそれを表現すればよいのでしょうか。
これは、アップグレードのケースと同様にどのように戻すと良いのは常に決まるわけではありません。
サービスを一時停止する、ソースコードを戻す、データの扱い、お知らせなどの運用にまつわるあれやこれや…
問題が起きた場合の対処については自動化することは難しいだろうと思われる中、
アプリケーション自体を chef で管理していると、冪等性という性質に足を引っ張られる可能性があるのでは、と懸念があります。
ラストは単純に capistrano の運用に慣れてきている、というそれだけのものです。
このあたりは、僕の経験と知識による(しかも現時点での)結論なので、他の方の意見も聞いてみたいですね。
ですから、是非僕の意見へのツッコミをもらえるとありがたいです。
そんじゃーね。
