Chefを試してみた

直近の仕事でそこそこの規模のインフラを構築する機会ができたこともあり、以前からちょっと気になっていたChefを試してみた。
ChefはPuppetと同じようなインフラの構成管理ツール。現行のバージョンは0.9.8。

Puppetと同じように管理対象となる各マシンにはChefのクライアントを入れ、構成を管理するために一台Chefサーバーを立てるという運用をする。
このサーバーのインストールがけっこうしんどかった。

セットアップには主に以下のページを参照。

• Installation – Chef – Opscode Open Source Wiki

Chefクライアントのインストール

RubyとRubyGemsが入っていればgemでさくっと入る。
必要なRubyのバージョンは1.8.6以上。

$ sudo gem install chef

Debian、Ubuntuならばapt-getで、CentOS、RHELならばyumで入れることも可能。

• Debian and Ubuntu
• RHEL and CentOS 5

しかしこっちの方法はRubyのパッケージがずらずらと入るので個人的にはちょっと気持ち悪い。
RubyをChefにしか使わない人は別に気にする必要はないけれど。

インタラクティブシェル Shef

クライアントを入れた時点でShefと言うインタラクティブシェルを利用できるようになっているので、ちょっと試してみると面白い。
設定なしに起動したShefはStandaloneモードで動作するので、ここで実行したレシピはChefサーバーを介さずにローカルに反映される。

Shefは以下のコマンドで起動。

$ sudo shef -a

プロンプトが表示されるのでレシピを入力してrun_chefで適用。

chef > recipe
chef:recipe > file "/tmp/shef_example.txt" do
chef:recipe >   action :create
chef:recipe ?>   content "hoge"
chef:recipe ?>   mode "0600"
chef:recipe ?> end
chef:recipe > package "httperf" do
chef:recipe >   action :install
chef:recipe ?> end
chef:recipe > run_chef 

ファイルの作成とhttperfのインストールを試してみた。

抜けるときはquitで抜けられる。

SoloモードやClientモードで起動することもでき、その場合はCookbookを利用してローカルにレシピを適用したり、サーバーからレシピの適用を受けることもできるようだ。

Chefサーバーのインストール

動作するのにCouchDBやRabbitMQなどが必要。なかなかFatな印象である。
その他にgemの依存パッケージとしてmerbやthinなど。

Chefサーバーをインストールするには大きく分けて以下の三つの方法がある。

• gemで入れたChefクライアントを利用して入れる
• パッケージで入れる Debian,Ubuntu RHEL,CentOS
• 手動で入れる

一番上の方法がかなりおしゃれなかんじなのであるが、CentOSでは残念ながら動かなかった。（後で気がついたがCookbook内にエラーになるレシピがひとつでも含まれているとそれをrun_listに入れてなくてもエラーが出て動かないようだ）

パッケージで入れるのは古いバージョンのRubyのパッケージがずらずら入るのが気に入らなくてスルー。
しかしおそらくこれが一番楽なのだろうと思う。

というわけで手動で入れることにしたのだが、なかなかに茨の道であった。

RubyをChefにしか使わない人という人ならばパッケージで入れる方法をオススメしたい。

以下CentOSの場合の手順。

yum

$ sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
$ sudo yum install couchdb erlang rabbitmq-server java libxml2-devel zlib-devel

EPELのリポジトリを有効にしていろいろとインストール。

CouchDB

$ sudo service couchdb start

これは起動するのみでOK。

RabbitMQ

$ sudo service rabbitmq-server start
$ sudo rabbitmqctl add_vhost /chef
$ sudo rabbitmqctl add_user chef testing
$ sudo rabbitmqctl set_permissions -p /chef chef ".*" ".*" ".*"

起動してChefに必要な設定も行う。

gem

$ sudo gem install chef-server chef-server-api chef-solr chef-server-webui merb
$ sudo gem install sqlite3-ruby -v 1.2.5

chefサーバーおよび依存パッケージをgemで入れる。
CentOSのSQLiteは古くてsqlite3-rubyの最新版が入らないので-v 1.2.5を指定。

Chefサーバーの起動

まずChef IndexerとChef SOLR Serverなるものを起動する。

$ sudo chef-solr-indexer
$ sudo chef-solr

次にChefサーバーを起動する

$ sudo chef-server -N -e production

ついでにWebUIも起動しておく。

$ sudo chef-server-webui -p 4040 -e production

最後に必要ならば自動起動の設定など。
とりあえずは実験なので割愛。

Chefサーバーにレシピを登録してクライアントに適用

ここからは主にHello World exampleを参考にしている。

実験なので同一マシン上で。ここからのコマンドは全部rootで実行。

chef-repoを用意する

# cd /opt
# git clone git://github.com/opscode/chef-repo.git

設定やCookbookを保存する場所を準備する。
Opscodeのchef-repoをひな形に。

Gitが使えない場合はtarballでも落とせる。（参考）

knifeの設定

knifeはchefを操作するためのコマンド。

# knife configure -i

これでknifeを使うのに必要な設定ファイル（~/.chef/knife.rb）が生成される。

Cookbookをアップロードする

OpscodeのCookbookを拝借。

# cd /opt/chef-repo
# rm -rf cookbooks
# git clone git://github.com/opscode/cookbooks

次のコマンドでChefサーバーにアップロードする。

# knife cookbook upload -a -o /opt/chef-repo/cookbooks

これでCookbook内のRecipeが使えるようになった。

Roleの設定

まずはRoleを定義する。

/opt/chef-repo/roles/examples.rbの内容を以下のように編集。

name "example"
description "Example role for the chef repository"
run_list("recipe[zsh]", "recipe[screen]", "recipe[git]")

zshとscreenとgitをインストールするというレシピを適用するという内容。

次は定義したRoleをRakeでChefサーバーに登録。

# rake roles

これでCouchDBに入ったわけですな。
確認は以下のように。

# knife role show example

なお同一マシンでやっているので混乱するかもしれないが、これは本来Chefサーバー側の作業。

Nodeの設定

NodeにRoleをひも付ける。
Nodeは個々のマシンであり、RoleはWebサーバーやDBサーバーのような役割。
このRoleとNodeの概念は同じ構成のNodeをたくさん作るのに便利である。

以下のコマンドでひも付け。
node01.example.comがNodeのホスト名。

# knife node run_list add node01.example.com "role[example]"

以下のコマンドで確認。

# knife node show node01.example.com -r

出力が以下のようになっていれば問題ない。

{
  "run_list": [
    "role[example]"
  ]
}

これも本来Chefサーバー側の作業。

レシピの適用

次のコマンドでめでたくレシピが適用される。

# chef-client

こちらは本来クライアント上で実行するもの。
Chefのサーバーとクライアントのマシンが別個の場合は鍵の登録などが必要になるが、同じマシン上で実行しているため省略。

WebUI

http://localhost:4040/にアクセスするとWebUIが利用できる。
レシピの適用状態などが確認しやすくて便利。

しかしログインできなかった

WebUIを利用するには認証が必要で、デフォルトのIDとパスワードがadmin,p@ssw0rd1ということなのだが、何度やってもうまいことログインできなかったのでコードを修正して認証を強制的に通るようにした。

chef-server-webui-0.9.8/app/controllers/users.rbの130行目あたりにパスワードが間違っていたら例外を投げるコードがあったのでざっくりコメントアウト。
無理矢理ログインした。

本運用するならば課題だ。

雑感

本格的に運用したらまた印象が変わるかもしれないけれど雑感。

レシピの書き方

Rubyで書いていけるレシピの記法はたしかになじみやすい。
Puppetはなじむまでけっこう時間がかかった覚えがある。

またレシピが指定した順番通りに実行されるため直感的に分かりやすい。
Puppetの場合は先に書いたタスクが先に実行されるとは限らないので、必要ならば依存関係などを明示的に書く必要があり、これは躓きの要素になっていたと思う。（明示的に書くことによるメリットもあるが）

クックブックを単位として設定ファイルのテンプレートなどを含めた一式が同じ場所まとまるのもよい。
そのためレシピがポータビリティに優れ配布もしやすくなっている。

chef-solo

SoloモードではChefサーバーを必要とせずレシピを適用できるようになっているので、作成中のレシピをテストするにも便利だし、マシンが1台だけしかないような小規模インフラではChefサーバーを立てずにSoloで運用するのもありかもしれない。

レシピの記法よりこちらに心惹かれる。（なんだかんだでPuppetの記法にも慣れているので）

Chefサーバーをインストールするのがしんどかった

途中で心がくじけそうになるほどに。
Chefを本格的に気に入ったら自分でレシピ書こう。

参考

• Home – Chef – Opscode Open Source Wiki
• さようならPuppet、こんにちはChef – Masatomo Nakano Blog
• Chefを最速で使いこなすためのいくつかのポイント – Masatomo Nakano Blog