>>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の構造や実際の設定例などについて書きたいと思います。
では！