Re: Chefに挫折したあなたへ。Fabricのすすめ
Chefに挫折したあなたへ。Fabricのすすめ という記事を読んだので、呼ばれてもいないのに勝手に返事を書いてみます。
追記(3/13 10:00): タイトルを typo していたようなので訂正しました。
ちなみに僕のポジションとしては chef 推進派です。
仕事の空き時間や自分の時間で、開発環境の自動化を模索する趣味 chef 使いです。
これまで他の自動化ツールはこれまでほとんど使っておらず、
ミスや手順書のボリューム削減のためにシェルスクリプト化を進めるぐらいでした。
ちなみに、chef を使いはじめる際に、比較検討のために puppet や fabric などのいくつかのツールについて
ドキュメントやブログを読みあさった経験はあります。
あと、chef と組み合わせて使うために capistrano を最近使っています。
学習に時間がかかる
同意します。chef のもっぱらの敵は学習コストです。
もし自分一人が使えるようになったとしても、同僚も使えるにようにならなければ意味がありません。
これは chef に限らず同じ系統の fabric などでも言えることではあるのですが、
構成がリッチな chef はより理解しづらいのだと思っています。
また、chef 自体の情報も散らばっていて効率のよいやり方にたどり着くのに時間がかかります。
僕の手元では「あって当たり前」だとおもっている librarian-chef や vagrant が再発見されている様子を見ると、
定石となるやり方が作り上げられていくのはこれからだと思います。
これは僕もなかなかブログを書いていないので、反省すべきところですね。
追記(3/13 9:00):
id:naoya さんが入門Chef Solo - Infrastructure as Codeという電子書籍を出版されたそうです。
まだ読んでいませんが、これで学習コストは下がるかもしれませんね。すてき！
対象サーバにインストールする必要がある
おっしゃるとおりです。対象サーバに ruby や chef を入れる必要があります。
これがハードルになるのであれば、chef を利用するのは難しいでしょう。
自分の環境(職場/プロジェクト)では、そこに制限はないので導入の障壁にはなりませんでした。
また、
本来Rubyを使わない環境だったり、あまりいろいろ入れたくないという環境では少し使いにくいです。
という部分に関しては、サーバ構築の主義主張かもしれませんね。
ただ、Ruby を使わない環境であっても、便利なツールであれば入れちゃえばいいじゃない、と思ってる人がいることだけ表明しておきます。
実際、僕が今携わっているプロジェクトは Python のものですが、構わず Ruby と chef を入れています。
自動化するまでに結構な手作業をしている。
Chefのインストールや一連の作業を適当な一般ユーザで行うのであれば、ユーザとsshの設定を済ませておかなければいけません。 最初からそれらが用意されている環境では気にならないでしょうが。
これは誤解ではないでしょうか。
chef を使おうが、fabric を使おうが、はたまた手動でセットアップをしようが、
どのみちユーザ作成とネットワーク設定、ssh サーバの設定は必要です。
もちろん OS のインストールもね :-)
公開されているレシピがそのまま使えないことがよくある
これはその通りです。
特に community cookbook は ubuntu ベースで書かれたものが多いため、
RedHat 系の OS をターゲットにしている場合はそのまま使えないことがあります*1。
僕自身、その手の問題に大量に引っかかっているため、
まだまだ落とし穴が多いと言わざるを得ません。
もし、公開されているレシピを使えば「ハマらない」と考えているのであれば、
勘違いなのでハマる前に自分で書いたほうが幸せかもしれません。
でも、僕自身は一個ずつ直して、pull request して、よくなったものを共有していくことが、
良い方向につながっていくと思うので、ちょこちょこやっていきたいと思っています。
同じ事をするのに、全員が毎回似たようなスクリプトを書いているのってもったいないですからね。
ファイルを設置すれば十分な事が多い
これは環境によりそうです。
自分のケースでは、Web サーバや DB サーバ、依存ライブラリに開発ツールのインストール・ビルドなど、
ファイルを設置以外にやるべきタスクが並んでいます。
これはどういうサーバをセットアップするのか、というものによってしまうので
あまり議論のポイントではないかもしれませんね。
構築と運用の垣根が低い
「学習に時間がかかる」と一緒ですね。
あれこれ覚えることの多い chef より、fabric の方が導入に向いていると思います。
chef を使っていると、chef 以外の手動作業を除外したくなるので、
chef に慣れていない人を除外しやすい構造になってしまうかもしれません。
じゃあなんで chef がいいの? (@tk0miya の場合)
僕は chef のもつ「冪等性」と「community cookbook の存在」がいいと信じて使っています*2。
冪等性
冪等性は先のブログでも紹介されていますが、何度実行しても結果が変わらない性質を指します。
chef ではあるサーバで、何度 chef を実行してもセットアップの結果が変わりません。
ですから、後からサーバを追加することになっても、(ハードウェア故障などで)ちょっと古い状態のサーバであっても、
どの環境でも chef を実行すれば最新の状況になることが保証されています。
冪等性のないツールの場合は、基本的に差分更新になってしまうため、
最新の状況にするためには「正しい順序で差分を実行していく」ことが求められます。
fabric の場合は cuisine という冪等性をサポートするライブラリ(アドオン?)があるので、
これを組み合わせていくと幸せになるのではないでしょうか。
community cookbook の存在
もう一つの「community cookbook の存在」は、先ほど触れたとおりです。
今は不完全かもしれませんが、仕上がってしまえば、必要な cookbook を選んでパラメータを設定するだけで
システムが組み上がるコンポーネント集になる可能性を秘めています。
実際、Amazon の OpsWorks は Web UI から Layer (chef cookbook 相当)を選んで、
出てくるフォームにパラメータを入れていくだけでサーバを構築することができます*3。
OpsWorks の場合は選べるコンポーネントも少なく、まだ OpsWorks だけでサーバまるごと一台を構築することは出来ませんが、
chef によってもたらされるパワーのひとつを実現していると感じます。
まとめ (今北産業)
- chef は学習が大変だし
- community cookbook も不完全だけど
- 使っていくとそのうちいいことあるかもよ。
ちなみに、夢とか将来とか甘っちょろいことを言ってないで、
自動化を手早く実現するのであれば fabric はかなりいい選択肢だと思います。
できれば、レシピ共有サービスが出てくると最高なんですけどねえ。だれか知ってたら教えて下さい。
おわる。
