さようならPuppet、こんにちはChef

30th Aug, 2010 | chef sysadmin puppet ruby

ここ最近、サーバの設定ファイルの管理で Chef を使い始めている。まだ全然詳しくないけど、今感じている「Chefの楽しさ」を誰かに伝えておきたかったので、ファーストインプレッションを簡単に。

Puppetを今までそこそこ使っていたので、どうしてもそことの比較な感じになっちゃいます。Puppetも良いのだけど、Chefは後発ということでさらに良くなっている感じ。

基本的な仕組

これは、Puppetとほぼ同じ。クライアント-サーバ型のシステム。設定を書き、それをサーバに置いておく。クライアントはサーバと接続し、自分自身の設定を書き換えたり、必要なソフトウェアをインストールしたりする。

rubyな設定ファイル

Puppetは基本的に独自DSLで設定ファイルを記述すので「覚えるのがめんどくさい」「細かいこと、ちょっと無茶なことをしようとすると大変」。Chefの設定ファイルはrubyそのものなので、rubyで表現できることは何でもできる。とは言えDSL風にもなってるのでrubyを知らなくてもなんとかなるレベルでもある。その辺はさすがにruby。実際にどんな感じで設定を書くか、というのは、この辺参照。

ローカルでのテストが楽

chef-soloというコマンドがあり、これを使うとChefサーバに接続せずにローカルだけでテストができる。大袈裟なテスト環境を作らなくても自分の環境でテストできるのがとても楽。

設定ファイルが直感的

Puppetは、manifestとかmoduleとかclassとか、どうも最後まで慣れなかったが、Chefは初めの数時間で、すーっと頭に入ってきた。この差はでかい。

いくつかの理由があるけど、まず、設定ファイルのディレクトリ構成がわかりやすいというのが大きい。

設定ファイル内の主要なディレクトリは、cookbooksとrolesの二つだけ。cookbooksの中には、cookbookと呼ばれるソフトウェア毎の設定を置くサブディレクトリがある。一つのcookbookに関連する設定はそのサブディレクトリ内にすべて置く。

例:

cookbooks
  + sshd
    + recipes
    + templates
    + attributes
  + sudo
    + recipes
    + templates
    + attributes
  + apache2
    + recipes
    + templates
    + attributes
  + .....
roles
  + hoge_app.rb
  + hoge_rproxy.rb

この「cookbook内で完結し独立している」というのがとても扱いやすい。完結しているので、自分で管理するのももちろん楽だけど、他の人や会社がが作っているcookbookの流用もしやすい。 Chef公式のcookbook はもちろん、 37 signalsのcookbooks もよく参考にしている。

roleは、どのcookbookをどういう設定で使うか、というのを書く。そして作成したroleを実際のサーバに割り当てる。一つのサーバが複数のroleを持つこともできる。このroleとcookbookという関係もとてもわかりやすい。

各roleの中にはどのcookbookを使うか、というのを羅列する。例えば，

run_list "recipe[apache2]", "recipe[apache2::mod_ssl]", "role[monitor]"

みたいな感じ。そして、cookbookに対する設定もrole内に書く。

default_attributes "apache2" => { "listen_ports" => [ "80", "443" ] }

(このサンプルから引用)

こんな感じ。とってもわかりやすいでしょ？

Git等との距離感

設定ファイルはもちろんGitとかで管理するのだけど、それと実際のChefの動作部分は特に関係ない。設定ファイルを書き換えた後commit/pushで設定の反映ではなく、rake upload_cookbooks 等のコマンドでサーバへ反映。これがなかなか気持ちいい。ソフトウェアをdeployする感覚と似ている。