インフラストラクチャ自動化フレームワーク「Chef」の基本（1/2 ページ）

DevOpsというキーワードに関連して、「Chef」というツールの名前を聞いたことのある人も多いのではないでしょうか。この記事では、インフラにおける構成管理、展開作業を自動化するChefの構造および基本的な使い方について解説します。

» 2013年07月03日 18時00分公開

インフラストラクチャ自動化フレームワーク「Chef」

　Chefは、物理、仮想、クラウドといったさまざまな大きさのインフラに対して、サーバやアプリケーションの展開を容易にするための自動化フレームワークです。　Chefの重要な要素の1つに﹁Infrastructure as Code﹂という概念があります。インフラをどのように構築し、維持するべきかという定義はRubyの文法で記述され、ソースコードのように扱うことができます。つまり、あたかもRubyでプログラミングをするように、インフラの構成管理をコードによって行えることがChefの利点の1つです。　自然言語による手順書を作成したり、実作業を人手に任せたりする必要がなく、プログラミング言語によるインフラの定義を作成し、後の動作はChefに任せて自動化できてしまうと聞けば、日々の作業に追われているインフラエンジニアの心に響くことでしょう。

﹁Cookbook﹂と﹁Recipe﹂の役割

　Rubyの文法で記述されたインフラの定義は﹁Cookbook﹂と呼ばれ、複数の要素で構成されていますが、特に﹁Recipe﹂が中心的な役割を担っています。　Recipeはインフラをあるべき姿に構築し、維持する具体的なプログラムコードと考えてください。RecipeはRubyの文法を用いることができる上、﹁Resource﹂と呼ばれるChef専用の命令を用いることができるので、柔軟かつ容易にインフラの姿を記述できます。

　例えば、﹁Apache HTTP Serverの導入、設定を行いたい﹂という状況を考えてみましょう。　まず、導入先のLinuxディストリビューション公式のパッケージをインストールするとします。Red Hat系であればパッケージ名は﹁httpd﹂、パッケージ管理システムは﹁yum﹂です。Debian系であればパッケージ名は﹁apache2﹂、パッケージ管理システムは﹁apt﹂です。一口にApache HTTP Serverの導入といってもこのような差異があるため、自然言語で手順書を記述しようとすると複雑かつ長くなってしまいますし、シェルスクリプトで記述するにしても煩雑な条件判定や分岐が必要になってしまうでしょう。　そこでChefを使ってこのRecipeを記述してみましょう。

package 'apache2' do
  case node[ :platform ]
  when 'redhat', 'centos'
    package_name 'httpd'
  when 'debian', 'ubuntu'
    package_name 'apache2'
  end
end

　どうでしょうか？たったこれだけです。Chefのpackage Resourceは先に挙げたようなディストリビューションごとの差異を吸収してくれるばかりか、パッケージのインストールエラーなどが発生した際の例外処理まで行ってくれます。　ChefのResourceには、package以外にもさまざまな種類が用意されており、標準的なResourceを利用するだけでもたいていの要求が実現できます。機能に不足がある場合はResourceを自作したり、Ruby以外にもPerlやPython、bashスクリプトを直接実行することもできます。

何度繰り返しても同じ結果を得られる﹁べき等性﹂

　そして、Chefのもう1つの重要な要素に﹁べき等性﹂があります。これは、ある操作を一度行っても何度行っても結果が同じである、という概念です。　先に示したコードは何回実行してもApache HTTP Serverがインストールされた状態に収束し、何回も繰り返しインストールされたり、既にインストールされているからといってエラーになったりすることはありません。　ほとんどの場合、Chefの動作はべき等性が保証されていますが、CookbookやRecipeの書き方によってはべき等性が保証されないことがあります。例えば、自作したResourceやスクリプトについては、べき等性が保証されるように自分でプログラムコードを作り込む必要があります。

Chefを構成する各要素〜Client/Server、Solo

　それではCookbookはどのようにインフラに適用されるのでしょうか。混乱を避けるため、以降はCookbookを適用する対象のコンピュータをノードと記載します。

　まず1つはクライアント・サーバによる集中管理形式、もう1つはノードごとに独立したコマンドを実行するスタンドアロン形式です。　クライアント・サーバ形式では、中央に﹁Chef Server﹂というインフラの集中管理サーバを設置し、各ノードに置かれたChef ClientがChef ServerにCookbookや必要な情報を問い合わせることにより、インフラの構築・維持を行います。　スタンドアロン形式では、ノードにChef Soloという独立したコマンドに加えて、Cookbookや必要な情報をすべて設置し、インフラの構築・維持を行います。　クライアント・サーバ形式とスタンドアロン形式とで、Cookbookの書き方に変わりはありません。このため、各形式に依存している個所がなければ、ほとんどの場合どちらでも利用できます。一方、どちらもメリット・デメリットがあります。　クライアント・サーバ形式のメリットとしては、Chef Serverにインフラの情報が集積されるため、そちらを参照することでインフラ全体の状態が把握しやすいこと、ノード間の連携が行いやすいことが挙げられます。反面デメリットとしては、Chef Server自体の維持・管理が必要なこと、Chef Clientの設定作業が必要なことなどが挙げられます。　スタンドアロン形式のメリットとしては、Chef Soloや必要なものを一括で準備するだけで済むという導入の容易さが挙げられます。反面、インフラ全体の確認や各ノードの連携などは自前で構築する必要があることがデメリットとなります。　先に述べた通り、Cookbookは両形式のどちらでも基本的に適用可能ですし、知識や概念も大きく変わるものではありません。まずは規模の小さなインフラやテスト環境に対してスタンドアロン形式を導入して学習した上で、大きなインフラに対してクライアント・サーバ形式を導入するという順を追うのがよいと思います。

ChefのインストールとChefを使ったインストール作業

　　　　　　 1|2 次のページへ

SpecialPR