Chefでサーバのセットアップ・管理作業を楽チンにしよう～実践編その１～

昨日1日ケータイでアラートメール以外に受け取った唯一のメールを紹介します。

「
この前はありがとう！！久々メッチャ楽しかった～
みんながいる前だったからちょっと恥らっちゃったけど、2人っきりだったら私も同じ気持ちだったょ（はぁと

恥ずかしいけど・・・

次は2人っきりで会えませんか？？

返事楽しみに待ってます（はぁと
」

「え？誰？誰？これ？」ってどんなに心当たりがないシチュエーションでも、とりあえずその可能性を記憶に見出そうとするのが男なんだなあ、と、スパム道の奥深さを知ったhiroshiです。

前回に引き続きChefについてです。

今回は、DECOLOGで実際に使っているrecipeや運用を紹介しながらの実践編です。
※この記事の元になるChefのAPIのバージョンはv0.9.12です。

その前に、いろいろ準備します。クイックスタートあたりを読んでクイックに準備しましょう。
この辺は環境依存も多いと思うし、僕やってないから華麗に通り過ぎて次行きます。

あと、このくらいの英語は翻訳サイトとか使わずに読めるようになっておいたほうが幸せになれると思います。逃げちゃだめだ！

さて、クイックに準備できたら始めます。

前回の記事でもちょっと触れましたが、chefはソフトウェア単位で扱うイメージです。
なので、今回はphpを題材にしてみます。

phpをchefで扱うまでの手順をおおざっぱに書くと

1. cookbookを作る
2. 必要ファイルを調達する
3. レシピを書いたりする
4. chef-soloでテストする
5. cookbookをchefサーバにアップする
6. gitにコミットしとく

という感じでしょうか。ウチの場合。


1.cookbookを作る
まず、cookbookを作ります。chefで管理するソフトの数だけcookbookを作っていくことになります。

無理やり料理に当てはめると、
この料理人(chef)は食材(ソフトウェア)ごとにレシピ(recipe)をまとめた料理帳（cookbook)を管理しているようです。

さあ、うまいこといったつもりになったところでさっそく実行です。

rake new_cookbook COOKBOOK=php

※ただし「knife cookbook create」を使えと怒られます。が、knifeコマンドはあらかじめセットアップをしておかないと正しく動作しないので、今回はこれで。

とします。すると{chef-repo}/cookbook/php配下にじゃららーと以下のようなディレクトリとファイルが作られます。

attributes
definitions
files
libraries
providers
recipes
resources
templates
metadata.rb
README.rdoc

いらないものもたくさんあるので、いらないことに気づいたタイミングで消したらいいと思います。

ここはこれで終わりです。


2.必要ファイルを調達する
本当にphpだけだったら、php-5.3.x.tar.bz2とphp.iniだけあればいいかと思います。

php-5.3.x.tar.bz2は

{chef-repo}/cookbook/php/files/default

直下に置いておきます。

php.iniはphp.ini.erbという名前にして

{chef-repo}/cookbook/php/templates/default

直下に置いておきます。

いったん終わりです。

3.レシピを書いたりする
ここに書いていきます。

{chef-repo}/cookbook/php/recipes/default.rb

さっきから各所で「default」が目につきますが、細かいことはあとで気にすることにして、ここはおとなしくdefault.rbに書いていきます。

さて、どこから書いていくかですが、その前にchefがどういうものかおさらいします。

chefは
「手でやってたセットアップ手順をrubyで記述すると、定期的にその手順の結果の状態になっているかチェックして、そうなってなければその状態にしようとする」
ツールです。

なので、手でやってた手順をそのまま記述していくことになります。

chef導入以前、DECOLOGではphpをシェルスクリプトでインストールしてたのですが、その内容は大まかにいうと

• apacheをソースからインストール
• phpをソースからインストール
• pearのライブラリいろいろいれる
• peclのライブラリいろいろいれる

といった感じでした。apacheありきです。

なので、apacheのインストールからやることになりますが、apacheも１つのソフトウェアなのでcookbookから作っていくことになります。というわけで、今回はすでにapacheのcookbookはできあがっている前提で進めます。


まずはapacheありきのphpなのでapacheのセットアップを行います。

include_recipe "apache"

こんな感じでapacheのレシピを発動させます。

次に、phpのconfigオプションで使うことになるrpmパッケージをインストールしておきます。

package "curl-devel"
package "libjpeg-devel"
package "libpng-devel"
～後略～

ここででてくるpackageというのはchef側で用意してくれている便利コマンドみたいなもので、「Resource」と呼ばれています。

<Resource>
Recipe内で行う操作を抽象化して宣言文ぽくしたもの。パッケージ管理、デーモン管理、ファイル管理、コマンド実行などが用意されている。

※前回のエントリ参照

Resourceはいろんなのがあるのでhttp://wiki.opscode.com/display/chef/Resourcesに目を通しておくとよいと思います。

DECOLOGの場合はOSがCentOS環境なので、特に何も指定してなければyum installしてくれることになります。



・・・ああっ、もうガッツが足りなくなってきました。まだまだ途中ですが、最後まで書こうとするとこの倍くらいになってしまうので続きはまた次回にさせてください＞＜


よろしくお願い申し上げます。

Chefでサーバのセットアップ・管理作業を楽チンにしよう～構成編～

どうもhiroshiです。こんなに更新が早くてすみません。

今回もChefについてです。

前回の選定編に続いて、今回はChefの構成を見てみます。もちろんこれも「tommy report in Oct. 2010」からの抜粋です。

5/26 追記）この記事はv0.9.12に基づいてます。

Chefの構成の概要図
こんな感じです。

ツール群
<chef-server>
情報を集約して管理するサーバプロセス。各ClientとはJSON/RESTスタイルで通信する。

<chef-client>
設定を適用する各マシンにインストールされるデーモン。定期的にchef-serverをポーリングして、その内容に従ってレシピを実行する。

<chef-solo>
サーバ無しでレシピを実行するツール。

<knife>
chef-serverに登録されている情報の取得・変更を行うツール。切り刻むよ。

<webui>
chef-serverのWebインターフェース。なんか上手くログインできないので無視。

ということでうちではwebui使ってません。「それは大いなる損失だよ！」ということがありましたら是非教えてください。


主な構成要素
<Cookbook>
Recipe,Template,Attributeなどをひとまとめにしたディレクトリ。ソフトの種類毎に作るのがお約束ぽい。

<Recipe>
実行内容の定義本体。RubyのDSLで記述する。

<Resource>
Recipe内で行う操作を抽象化して宣言文ぽくしたもの。パッケージ管理、デーモン管理、ファイル管理、コマンド実行などが用意されている。


<Template>
設定ファイルを生成するためのテンプレート。中身は eRuby。


<Attribute>
環境依存の処理を吸収するための変数。


<File>
バイナリファイルなど、単にコピーして使うためのファイルを置くところ。


<Metadata>
Cookbookの説明とかのメタ情報。


<Role>
複数のRecipeをまとめて「役割」として定義するためのもの。


<Node>
chef-serverから見た管理対象のマシンのこと。


<run_list>
Nodeに対して適用するRoleやRecipeを指定したリスト。


<Client>
chef-serverにアクセスするツール類のこと。


なんやらいっぱいありますが、すぐ慣れます。寄生獣の後藤も「何事も慣れだ」と言ってました。これ、言うの2回目ですね。
とにかくRecipeです。普通7割くらいRecipe書くのに時間使います。
TemplateとFileは使い分けが若干微妙なところがでてくるかもしれませんが、書き換え可能なファイル（つまりテキストファイル）はTemplate、そうじゃないのはFileというルールでやってます。

例えばapacheなら、http-2.2.xx.tar.bz2はFileだし、httpd.confはTemplateの下に置いとくって感じです。


Attributeについて
レシピで使える属性値は大きく2種類に分かれます。

1. Nodeの属性値。Nodeから収集した様々なパラメータ(IPとか)がツリー状のデータとして取得できるので、レシピで条件分けに使う。またknifeコマンドでも参照できる。
2. 自前で設定する属性値。
1. デフォルト値はCookbookのattributes/*.rbで定義する。
2. RoleやNodeに対して、デフォルトの設定値を上書きする値を設定できる。これで一部のマシンだけ別設定みたいなことが実現できる。

1についてですが、具体的にはこんな感じです。

$knife node show {domain}
～前略～
    "platform_version": "5.x",
    "fqdn": "hoge.example.jp",
～中略～
    "domain": "xxx.xxx.xx",
    "os": "linux",
    "idletime": "13 days 13 hours 28 minutes 20 seconds",
    "network": {
      "default_interface": "eth0",
      "interfaces": {
        "lo": {
          "flags": [
            "UP",
            "LOOPBACK",
            "RUNNING"
          ],
          "addresses": {
            "::1": {
              "scope": "Node",
              "prefixlen": "128",
              "family": "inet6"
            },
            "127.0.0.1": {
              "netmask": "255.0.0.0",
              "family": "inet"
            }
          },
          "mtu": "16436",
          "encapsulation": "Loopback"
        },
        "eth0:xxx.xxx": {
          "flags": [
            "UP",
            "BROADCAST",
            "RUNNING",
            "MULTICAST"
          ],
～後略～

該当ホスト上でコマンド打ったら取れるような情報は全部入ってるんじゃないでしょうか。

例えば以下はapacheのconfファイルですが、まいど自FQDN名を設定するところがありますが、そんなときにこんな感じで使えます。

# Server port for sending active checks
ServerRoot      "/usr/local/apache"
ServerName      <%= node[:fqdn] %> ←ココ！！

2について、たとえば基本的にapacheのバージョンは2.2.xxを利用する、ということにします。そういう場合、cookbook/apache/attributes/default.rbに

default[:apache][:version] = "2.2.xx"

と書いておいて、apacheのrecipeに

buildtool_make_install "apache" do
  action :install
  tarball node[:apache][:tarball]
  srcdir "httpd-#{node[:apache][:version]}" ←ココ！！
  config_option configure_option()
  not_if {check_compile_setting}
  notifies :create, "template[/etc/httpd/httpd.conf]"
  notifies :restart, "service[httpd]"
end

と書いておけば、基本的にはこの2.2.xxのapacheをインストールさせることができます。

「そんなんじゃ、わかんねーよ！」って思った方、、、、ですよねー。そうだと思います。。
とりあえず、現時点ではなんとなく、で通り過ぎていただければ幸いです。。

ちょっと今回はこのあたりで切り上げます。

次回は、適当なcookbookを例に取って説明ができたらいいな、という「実践編」を書きたいと思いますが、その際、またこの「構成編」の内容をちょくちょく振り返りつつになる気がします。

chefって、一回やってみないと全体像が見えにくいんですよねー。ぼくは3回くらいやってようやく見えてきました＞＜


というわけで、最後に女子力上げたところでまた次回にさせてください～。

Chefでサーバのセットアップ・管理作業を楽チンにしよう～選定編～

>>hiroshiの母でございます。この度は(ry

最近お会いしたエンジニアの方から「他社さんのブログとかは規模や難易度が凄過ぎて真似できないことが多いんですが、DECOLOG TECH BLOGは僕らでも利用できるレベルのネタが多いので助かってます！」と言われて今まで感じたことのないキモチになったhiroshiです。

今回はChefのお話です。

去年の10月くらいの話だったんですが、「あっちのwebサーバとこっちのwebサーバ、設定微妙に違くね？」みたいなことが発覚し(いや、前から知ってたけど）、それ自体はその時点で大きな問題ではなかったんですが、「このままだといつかなんかやるよね」と危機感を覚え、システムの構成管理ができるようなツール探しをしました。

つまり、Chefとは上記ような問題点が解決できるツールで、パッケージやミドルウェア（って同じ？）を定義した状態に保ってくれるツールです。「定義した状態に保つ」ということは、定義したソフト等が入っていなかったらインストールしてくれたりするのです！！

オープンソースなものだと他にはPuppetというのがあります。

かねてよりPuppetの存在は存じていたので「じゃあ、噂のPuppetがいけそうか調べてみるかー」といった感じでミツバチの銀の弾丸tommyが調査担当になりました。鉄砲作成を依頼するとキャノン砲ができあがるのがtommyさんです。Puppetを調べてもらったらChefを見つけてきてPuppetと比較してくれました。

以下、「tommy report in Oct. 2010」です。

共通点

• サーバクライアント構成。構成情報をサーバマシンで一括管理して、各クライアントマシンに配信する。
• マシンに役割(WebサーバとかDBサーバとか)を設定して、その役割に必要なアプリのインストールとか設定ファイルなどをひとまとめにして管理できる。
• マシンごとの設定の差異などは変数として管理できる。
• 設定ファイルはテンプレートから生成できる。マシンごとに一部の値を変えるとか。
• LDAP連携。LDAP上で各マシンの役割を定義できるみたい。
• Subversion/Git連携(詳細はまだよく調べてない)。
• Ruby製。

比較表

※間違っている部分もあるかもだし、当時まとめたものなのでもう変わっているところもあるかもです。

なぜChefにしたか
機能的にはそれほど差はないようでした。
決定打となったのは
tommy「ぶっちゃけChefの方が設定書きやすそうなのでだんぜん好印象ですねー。」
というコメントでしょうか。

その当時の時点で管理対象サーバは400台を超えていたし、稼働しているミドルウェア等もたくさんありました。だから、設定が書きやすいという点は重要なところです。
また、最初にChefの調査導入というフロンティア役を担ったtommyが「設定書きやすそう」っていうんだからChefだね！という感じで決めました。


というわけで今回はChef導入のきっかけのお話でした。次回以降は、Chefの構造や実際の設定例などについて書きたいと思います。

では！