サーバの構築作業やシステム管理を自動化する「Chef」

皆様、はじめまして。2010年9月に入社した並河です。
インフラ周りの話題を・・・ということで、今回はサーバの構築やシステム管理作業を楽にしてくれるツールである「Chef」について紹介します。

■ Chefとは

「Chef」は、サーバOSでのインストール・設定・各サービスの状態管理等、諸々のシステム構築や運用作業を自動化してくれるRuby製のシステム管理ツールで、オープンソースとして公開されており、既に、37signalsやEngine Yard、RightScaleなどでも使われており、利用実績も出始めています。

Ruby製のシステム管理ツールといえば「Puppet」を思い浮かべる方も多いのではないでしょうか。ChefはPuppetの競合ソフトウェアとなる位置付けで、出来ることだけでいうと、特別大きな差はないと感じていますが、Puppetは外部DSLとして設定を記載するのに対し、Chefは内部DSLで設定を記載できるといったような、"使い方"の違いがあります。

個人的には、Rubyのコードで、ある程度柔軟に設定を書いていけるような内部DSLは好みですが、人によっては好みがあると思いますので、システム管理者が使いやすい方を選択すれば良いのではないかと思います。

■ そもそも、サーバ構築・システム管理の自動化が必要なワケ

私の担当するアメーバピグというサービスは、現在(~~2010~~2011/01)約200台近くのサーバを利用しています。

管理するサーバが数台のうちは、あまり気にしなくて良いのですが、上記のような数十台・数百台といったオーダーになってくると、例えば以下のような様々な面倒事が発生してきます。

・サーバ一台一台に対して、全て手作業でオペレーションを行うのは大変
・手作業でのオペレーションミスは防止が困難

大規模なサービスになると、まとまった台数のサーバを投入することもしばしば。それらを1つ1つ手で作っていては大変ですし、何より投入までのリードタイムが長くなることで、投入が遅れ、機会損失を発生させることは避けたいところです。

また、サーバを運用していると、特定の役割のサーバ数十台に、ある設定を追加したい、等の作業もよくありますが、こういった作業についても、自動化の仕組みを作っておくことで、設定＋確認作業をミス無く実施(もしくは間違いが発生しても複数台に即修正を反映できる)ことは、大きなメリットであるといえます。

■ Chefの仕組み

Chefは、HTTP(S)通信でのやりとりを前提としたサーバ・クライアント式のモデルで、クライアント側からサーバへ情報を取得するPULL型のシステムアーキテクチャとなります。
尚、動作プラットフォームとしては、Linux、BSD、MacOS、Solaris等がサポートされています。(残念ながら、現状Windowsはサポートされていません。)

クライアント/サーバのソフトウェア構成は以下のようになります。

全てOSSでの構成となっていますので、各詳細については今回は割愛します(また機会があれば、紹介します)が、基本的には各々HTTPでREST形式のAPIを介して、データのやり取り・連携を行うアーキテクチャモデルとなります。

登場人物と役割

以下は、Chefの全ての設定がおさめられるリポジトリのディレクトリ構成の第一階層目です。


―――――――――――――――――――――
chef-repo/
|-- Rakefile
|-- certificates
|-- config
|-- cookbooks
|-- data_bags
`-- roles
―――――――――――――――――――――

Chefの仕組みを読み解いていくと、上記の中で、まずCookbooksとRolesの2種類の大きな設定があります。

Cookbooksは、Chef側でシステムのあるべき形を定義する設定を記述するものです。Rolesは、サーバ(Chefでいうと、clientまたはnodeと呼ばれます)の役割を定義した設定のことで、例えば"Webサーバ"や"DBサーバ"といった役割単位でグルーピングしたい場合などは、このRolesを定義します。

次に、先ほど紹介したCookbooksの中でも、様々な項目があります。以下がCookbooksディレクトリ内となります。


―――――――――――――――――――――
cookbooks/
|-- attributes
|-- definitions
|-- files
|-- libraries
|-- metadata.rb
|-- providers
|-- recipes
|-- resources
`-- templates
―――――――――――――――――――――

この中で基本となる部分は、recipes、templates、atteributesです。

recipesは、システムのあるべき姿、つまり設定内容を実際に記載したRubyスクリプトとなります。
例えば、Apacheのパッケージをインストールしたい場合は、以下のような感じです。


―――――――――――――――――――――
package "apache2" do
  action :install
end
―――――――――――――――――――――

また、以下のように記載しておくと、自動起動が有効になっているか、およびサービスが起動しているかどうかの確認も行ってくれます。(設定が有効になっていない場合は有効に、サービスが起動していない場合は、サービスを起動することが可能です。)


―――――――――――――――――――――
service "apache2" do
  action [ :enable, :start ]
end
―――――――――――――――――――――

次に、templateは、ERB形式で記述可能な実際にサーバへ配置するような設定ファイル(テンプレート)となります。動的にパラメータを変更したい箇所など、各サーバで、Chefを実行した際に、実際にそのサーバの役割にあった設定値をあてはめる場合などで利用します。
で、Chefでは、この実際にあてはめる設定値(パラメータ)のことをattributesと呼んでいます。

例えば、Apacheがインストールされたサーバで、役割ごとに設定値を変えたい場合、以下のようなports.fileのテンプレートを事前に作成しておきます。


―――――――――――――――――――――
Listen <%= port %>
NameVirtualHost *:<%= port %>
―――――――――――――――――――――

実際の設定値(attributes)に関しては、Roles(役割)ごとに設定することも出来ますし、各サーバ(node)ごとに設定することも出来ます。また、Rolesやnodeにattributesが設定されていない場合は、default値を決めておくこともできます。

■ 今後

と、ここまで簡単にではありますが、基本的な部分を説明してきましたが。実際のRecipeファイルを見たり、自分で触ってみないと、少しわかり辛い部分もあるかもしれません。

先日の別エントリでもありましたが、今後、サーバ仮想化プラットフォームと、こういったChefのようなツールを組み合わせることで、システム運用の自動化および省力化を進めていきたいと考えています。アイデアを書き始めると、また長くなってしまうので今回は割愛しますが、機会があれば、上記のような弊社での利用事例や、実際の設定ファイルの紹介なども今後していきたいと思います。

サイバーエージェント公式エンジニアブログ