Chefを最速で使いこなすためのいくつかのポイント

7th Sep, 2010 | chef sysadmin ruby

前回書いた さようならPuppet、こんにちはChef が、それなりに反響あったので調子に乗ってもうちょっと書いてみる。

前回、ChefはPuppetに比べて簡単！とか書いたが、実際には慣れるまでそれなりに戸惑うところがあった。

ドキュメント を読み、実際に触っただけでは一発で理解できなかった部分を、自分のメモを元に晒しておく。これだけ読んでもいまいちだと思うので、関連するドキュメントへのリンクも張っておくので合わせて読んでみると高速でChefを理解できるかも！

client vs node

ドキュメントを読んだりChefを触っていると client と node という二つのワードが出てくる。この二つは似ているけど別物。

client は文字通り Chef server の相手になるもの。 Chef server にアクセスするものはすべて client になる。例えば、管理ツールである knife (後述)や、管理用のWeb UIなども client になる。認証や通信はすべて client が Chef server と行う。

一方、 node というのは、Chefで管理するマシン/サーバ自体を指す。各 node は Chef server にアクセスし自分の設定を持ってくるのが、これは実際には node にある client 経由で行う。

そのため通常は node は client でもある。そして、 client数 >= node数 になる。

書いてしまうと簡単なのだけど、最初は両者がごちゃごちゃになってしまっていた。ここをしっかり理解しておくとトラブルシューティングもしやすくなる。

トラブルシューティングの例:

ある node (の client )で、サーバにアクセスするのに必要な秘密鍵を間違って消してしまい Chef server へのアクセスができなくなってしまった。この場合どうすればいいか？

対応策: 鍵情報は client に結びついているので、 client の鍵ペアを作り直せばいい(または、 client をサーバから削除して作り直す)。 どちらの場合も、 node の情報をいじる必要ない。

knife

Chefサーバ上にあるデータを触るためのコマンドラインツール。主に手作業でサーバの情報にアクセスしたいときに使う。管理者が使用するもの。上に書いたように knife 自体も client になる。管理者毎に別の client として登録する。

特に、 node の情報は、他の設定と違いサーバ上にしかないので、このコマンドをよく使う。

例1： node の情報(JSON形式)を $EDITOR で開き編集する

$ knife node edit hogehoge.example.com

例2： 指定した client を削除

$ knife client delete fugafuga.example.com

node と cookbook (recipe) と role

まず、 node は、上にも書いたように管理対象のサーバのこと。

cookbook は、実際にChefで行いたい設定の手順を記述したもので、基本的に環境に依存するのものは書かない。依存するものは role や node の attributes に書く(後述)。

recipe とは、設定を記述したrubyスクリプトのことを指す(ドキュメント等で cookbook のことを recipe と呼んでいるケースもあるので注意)。

一つの cookbook は複数の recipe を持つことができる。例えば， LDAP cookbookの中に、 LDAPクライアント用の recipe と、LDAPサーバ用の recipe を持つことができる。

role は、サーバの役割を記述したもの。 どの recipe を使うかということを主に書く。また、 node は、基本的に1つ以上の role を持つ。ただし、ちょっとややこしいが、 node は recipe を role を介さないで直接持つこともできる。

たとえば、 “hoge-system-app” role というのを考えてみる。これは “hoge-system” という Webシステムのアプリケーションサーバを想定する。

ここで、

  • hoge-system-app1.example.com
  • hoge-system-app2.example.com
  • hoge-system-app3.example.com

という3つの node があったとする。3つとも、"hoge-system-app" role を持つ。ただし “hoge-syste-app1.example.com” だけは、特別に、"git" クライアントも入れたい。こういう場合には、gitの recipe を直接指定することもできる。

  • hoge-system-app1.example.com
    • hoge-system-app role
    • git recipe
  • hoge-system-app2.example.com
    • hoge-system-app role
  • hoge-system-app3.example.com
    • hoge-system-app role

もちろん、gitの recipe を持つような、 developer role みたいのを作り、それにgitを持たせ、 node にセットすることもできる。

基本的には、 role 経由で管理したほうがいいが、本当に例外の場合はわざわざ role を作らなくてもいいかもしれない。これは設計次第。

attributes

attributes は、実際に設定したい値(パラメータ)のこと。上述したように、 cookbook / recipe には、サイト固有の情報を持たせないのが原則なので、そういうものはすべて attributes にして外出しにする。

attributes は recipe 自体や、 recipe 経由で template (erbで記述) から使われる。基本的にrubyのHashそのもの。

attributes は recipe にも設定できるし、 role や node にも書ける。

recipe に書いた attributes がその recipe のデフォルト値で、それを role や node の attributes で必要に応じて上書きする、と考えると理解しやすい。

例：まず、 tokyo-office という role があったとしよう。とある東京オフィスにあるサーバ群はこの role を使うというルールになっている。今、この role に対して、LDAPクライントを設定したいとする。

最初に、LDAP cookbook ( recipe ) を作成する。このとき、LDAPサーバのホスト名(IP address)みたいなのがサイト固有の情報になるので、 attributes に切り出す。

次に作成した、 recipe を tokyo-office role に設定する。このとき attributes として切り出した LDAPサーバの IP addresses を role の attributes ととして設定する。

ここで、もし、その中のある、特定の node だけに対して例外的に特別な値(例えば、テスト用のLDAPサーバを見させたいとか)を書きたい場合には、 その node の attributes に書いて、 role の attributes を上書きする。

自分が理解しているのはこんな感じ。enjoy cooking!


記事の内容についての質問、苦情、間違いの指摘等なんでもtwitterでどうぞ。