最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。
Chefの役割
まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態&設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、本番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。
さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入ると答える人は、全てをChefで管理することになります。逆に入らないと考える人は別途アプリケーションのデプロイツールを導入すると思います。私は、後者の入らない派です。
Capistranoの役割
それでは、アプリケーションのデプロイツールはどういった役割を果たすのでしょうか?昔は、単純にソースコードを各サーバにコピーして必要に応じてアプリケーションサーバの再起動を行うだけのものでした。最近では、それに留まらずデータベースの定義変更(マイグレーション)や初期データの投入まで出来るようになっています。各言語ごとにその手のツールはありますが、Rubyで有名なのはCapistranoです。
ChefとCapistranoの組み合わせ
ChefとCapistranoの担当範囲をまとめると次のような図になります。OS層はもちろんAmazon AWSさんで、ミドルウェアをChef、アプリケーションをCapistranoで管理します。
Ruby on Railsの例
Ruby on Railsで上記の役割分担にすると、1つのコードでどの環境でも対応出来ることが出来ます。例えばApache+Passengerの場合、環境(開発、ステージング、本番)の切り替えは、httpd.confのRailsEnvで切り替えます。この部分をChefの変数にしておけば、同一のソースで複数の環境をつくれます。またアプリケーションもdatabase.yml等で環境ごとに設定ができるのでソースは1つです。まとめると次のような図になります。
まとめ
それぞれ得意とすることに集中させるという意味で、ChefとCapistranoを組み合わせは良いと思います。またCapistranoの実行をChefの中で行わせるというのも1つの方法ではないかと考えているので、その辺りのことも検討してみようかと考えています。
ちなみに7月にJAWS-UGがOpsWorks(Chef)特集です。今回書いたようなことを整理して、また実際の運用ではどうなのかというのを枠を貰って話す予定です。1日Chefとかなり濃度の濃いイベントですので、興味がある方は是非来てください。
See Also:
手動でサーバの設定をすることを禁ずる。入門Chef Solo
今更聞けないCapistranoでリリースの自動化
Capistranoのタスク一覧