2013-04-04

　ChefとFabric、どちらが良いか悩んでいるうちに、Chefが一気にブレイクしてしまった今日この頃です。と言うことで、Chefを中心に今後のサーバ構築・運用について考え中です。そこでまず出てくる問題が、Chef Server+ClientとChef Solo + Knife Solo、どちらの構成が運用しやすいかという点です。
　状況を整理する為に、まずは簡単にChef Server, Chef Solo, Knife Soloの関係や役割をまとめて見ます。

Chef Server

　サーバーの状態を管理し、それに関する情報を保持しておくのがChef Serverです。Client側は個々のサーバにインストールされて、Chef Serverに司令を問い合わせて実行します。Chef ServerはDBやキューなどを持ち、少し複雑な構造です。同じカテゴリーの製品として、PuppetやFabricなどがあります。

Chef Solo

　たかだか数台のサーバーを管理するのにChef Server+Chef Clientの構成は大仰だよね。もっと手軽に使いたいという人の為に用意されているのがChef Soloです。ローカルの環境の中にChef ServerとClientの機能があって、1台で完結するイメージです。recipeの管理は、Git等のリポジトリでされることが一般的です。最初にレシピを作る時に、手軽で便利です。

Knife Solo

　"ローカルからchef- solo 叩いていいのは小学生まで "というコンセプトで作られたのが、Knife Soloです（半分ウソ）。開発者の説明によると、Chef SoloをChef Serverチックにリモートから扱えるようにしたツールです。複数のサーバーを、まとめて管理するのが便利です。

何故、Knife Soloがあるのか？

　Chef Server ⇒　Chef Soloの流れは理解出来ると思いますが、何故Knife Soloというのが出てきたのでしょうか？Chef SoloをChef Serverチックに使いたいのであれば、最初からChef Serverでええやんと疑問が出てくると思います。まさしくそこが、Chef ServerとChef Solo + Knife Soloの、どちらで運用するかの悩みのタネなのだと思います。
　まずレシピの管理で言えば、Gitで管理するのが一番扱い易いです。他のプロジェクトからの使い回しも容易ですし、変更履歴の管理もしやすいです。一方で、サーバの固有情報をレシピに入れてしまうと、Gitでの管理は破綻します。その点、Chef Serverはサーバの情報を状態を管理するDBを持っているので、構築情報（レシピ）とサーバの状態の分離はしやすいです。
　その反面、Chef Serverは全ての情報を自身のDBで管理するので、プロジェクト間でのレシピの共有はGitに比べてし難いです。また最初にRecipeを作る時は、ちょっと試しては前の状態に戻してといった試行錯誤の連続です。そういった時に、Chef Solo + (Vegrant)は便利です。
　また、そもそもサーバはAutoScaleなどで負荷に応じて増減するものだというのが、クラウド時代のサーバ運用です。そうなると、そもそも個々のサーバの状態は必要かという話も出てきて、Chef Solo + Knife Soloでも充分という話もあると思います。

結局、どちらを選択するの？

　上記のようなことをグルグルと考えましたが、どちらを選択するかは個々のプロジェクトの環境次第かと考えています。どちらにしろRecipeを書くのは変わりないので、Chef Solo + Knife Soloで小さく始めるのも良い選択肢だと思います。一方で、数十〜数百台のサーバの管理が必要なのであれば、始めからChef Serverでも問題ないと思います。