Tech Sketch Bucket of Technical Chips by TIS Inc.

Chef の勉強会をやってみた

Pocket

先日、サーバを自動構築するツール「Chef」について社内で勉強会を行いました。

ここでは、勉強会で取り上げた内容に触れつつ、私が Chef を使ったきっかけや、Chef をしばらく使ってみた印象について書いてみようと思います。


Chef とは?

サーバを自動構築する「Chef」というツールをご存知でしょうか?

ChefのWebサイト(米OPSCODE社)

Chef は米 OPSCODE 社が開発、保守している Ruby 製のツールで、あらかじめ定義しておいた状態に合わせて、サーバを構築したり、システム構成を変更する作業を自動化することができます。

同様の OSS ツールとして有名なのが Puppet ですが、それに並ぶツールとして Chef は近年急速に人気を集めてきています。

Chef を使い始めたきっかけ

私は弊社内でオープンソースソフトウェア(OSS)活用の推進役を担っており、活動の一環としてOSSミドルウェアを組合わせた推奨スタック(ISHIGAKI Template と呼んでいます)開発、検証、導入支援を行っています。

ISHIGAKI Template では Apache Web Server、JBoss Application Server、PostgreSQL を以下の様なクラスタ構成とすることで、可用性や性能拡張性の向上を図っています。

Cluster_mini.PNG

ただ、上図の様な複雑なシステム構成になったが故に、環境の構築手順が煩雑化してしまい、何かテストを行いたくてもすぐに検証環境を構築できないという悩みを抱えるようになりました。

当然、環境を構築する手順は「構築手順書」としてドキュメント化しているので、それに従えば構築できるはずなのですが、1度に3~6台のサーバを構築することになるので、

  • 設定ミスしたようで動かないサーバがあるが、どこを間違えたのかがわからない
  • 同じ値(サーバのIPアドレス等)を複数の設定ファイルに書くのが単純作業で苦痛

ということが繰り返されていました。

そんな時 Chef の存在を知り、この悩ましい作業を自動化しようと考えたのです。

以前は、検証環境の構築に下手をすると丸1日かかっていましたが、今では30分程度で確実に環境を構築できるようになり、Chef による自動化の恩恵をひしひしと感じています。

社内向け勉強会

というわけで個人的には Chef を使うようになっていたのですが、最近になって Web や雑誌で Chef の記事をよく目にするようになり、Chef の存在を知っている方は増えてきました。その一方で日本語で体系的に解説された情報が見あたらないために、

  • Chef でどういうことが出来るのかピンとこない
  • Chef を試したいが仕組みが難しそうで二の足を踏んでいる

という声を聞くようになりました。

実際のところ、私も使い始めた当初は内部の仕組みがなかなか理解できず、挫折しかかった経験があるので、二の足を踏みたくなる気持ちは理解できます。

そんな私も Chef を使い始めて半年強が経ち、仕組みや使い方はある程度理解できるようになっているので、布教活動の一環として、社内向けに勉強会を開くことにしました。

勉強会で語った内容については SlideShare に資料を公開したので、こちらをご覧ください。

今回の勉強会は「Chefでできること」を参加者にイメージしてもらうことを念頭に置いたので、タイトルにも「概要編」とあるように細かい部分の解説はばっさり割愛し、簡単なデモの動作を行いながら、Chef がどう作用したのかを解説したり、Chef を使った自動化が我々にどのような影響を及ぼすのかを大まかに伝えるスタイルにしました。

詳細な仕組みや使い方については次回以降に解説しようと思っています。

Chef をある程度使ってみて思うこと

最後にまとめとして、しばらく Chef を使った私が改めて感じていることを書きます。

初期の学習コストが大きいのが課題

Chef は高い汎用性を持っている反面、仕組みが分かりづらいです。
また、日本語の情報も少ないので、初期段階で躓くことが多いと思います。

現時点では Opscodeが公開しているCookbook のソースコードを読んだり、見よう見まねで書き換えたレシピの動作を確認しながら、自身で知識を深めていく努力が必要でしょう。

ただ、最近では 国内で商用サポートも開始 されたり、マニュアルの翻訳も開始されているようなので、今後は情報不足という問題が徐々に解消されていくものと期待しています。

なんでも自動化すればいいってもんじゃない

Chef がわかり始めると「何でも自動化しようぜ!」とノリノリになる時期がやってきますが、自動化に着手する前に「同じ様な環境を何度も構築するシーンがありそうか」を考えた方がよいです。

同じ環境を1度、2度しか構築しないのなら、自動化のChefレシピを書くより、手で構築した方が早いので、その辺はバランスを考えて判断すべきなのだと思います。

インフラエンジニアもコードを書く時代が来るかも

インフラ領域を担当してきたエンジニアにとって、Ruby(に近いChefのDSL) でコーディングしなければならない、というのはハードルかもしれません。(私も慌ててRubyに触れ始めたクチです)

ただ、最近では AWS の様に仮想化されたインフラをプログラムから操作するのが当たり前になりつつあり、プログラムコードに触れる機会が自然と増えてきそうなので、今のうちに素振りはしておいた方がいいと思っています。

エンジニア採用中!私たちと一緒に働いてみませんか?