自動化ツールの必要性
昨今、仮想化およびクラウドの普及に伴い、サーバを短時間で増設することが容易になってきました。例えばユーザアクセスが増えてシステムの負荷が高くなった場合、サーバそのものは即座に準備できるようになりました。しかし、システムの設定は別途実施しなければいけないという状況も多々見受けられています。
サーバの台数が少なければ一台一台構築や設定を行えますが、何百台ものサーバを扱うとなると時間がかかって迅速性は失われてしまいますし、多くの人手が必要となれば設定の間違いが起こる可能性も高くなるでしょう。そして管理するサーバが増えたとしても、それらを管理する人は増えていないのが現状です。
そのため、サーバ構築とともにアプリケーションやミドルウェアの設定をも実施する自動化ツールが注目されています。
Chefとは
Chef（シェフ）は、米Opscode社が提供するクラウドコンピューティングを自動化することに特化した、オープンソースのシステム統合フレームワークです。
構築しようとしているシステムが物理環境や仮想環境およびサーバ台数にかかわらず、Chefを利用することで必要なサーバやアプリケーションを自動的に構築および調整できます。
コンフィギュレーション管理に必要なプロビジョニング機能、Rubyライブラリが利用可能なDSL、システムインテグレーション機能を兼ね備えたChefを用いることで、完全に自動化されたインフラを容易に構築できます。
Chefのメリット
スケーラビリティ
Opscodeの創業者たちは、スケールアウトするインフラを運用するためのノウハウに基づきChefを作り出しました。これによりインフラで急激にリソースが必要とされる場合でも、Chefを用いることでスケールアウトに対応できます。
効率的
Chefでインフラの構成を自動化すれば、環境構築時に立ち戻って同じ作業を繰り返す必要はなくなります。さらに、Recipeは共有できるのですべて自分で用意する必要はありません。Chefコミュニティが提供しているRecipeを活用することで、サーバ運用のベストプラクティスを共有できます。
自動運用
Chefは常に各ノードと通信しデータ収集しています。例えば、実運用環境で必要なWebサーバの一覧をChefで調べ必要な手順を自動化することができます。ソースコードを変更する必要も手順書を読みながら手動で実行する必要もありません。ユーザや仮想マシンの一覧などどのようなデータでもクラスとしてモデル化し、Chefサーバに保存できます。また、サーバに保存されている属性データを再利用することもできます。
世代管理
Chefはインフラ構築および運用時に利用したRecipeを用いることで、運用中の環境の実質的なクローンを構築できます。例えば、インフラにトラブルが発生した場合でも、Recipeを活用することで数分から数時間以内にシステム全体の再構築が可能です。また、トラブルが発生していない過去の運用環境へと素早くロールバックすることができます。
コスト節約
Chefならば、大きく複雑なインフラが必要になったとしても、最低限の人数かつ作業でコストを抑えつつ、インフラの構築および拡張が可能です。
Chef構成と用語説明
1. Chefの基本的な用語
Chefで用いられる用語には、一般的に用いられているものがあるため、少々混乱を招きやすい点があります。そこで、よく使用される基本的な用語を確認しておきます。
Server
設定情報をはじめ、各種情報を集中管理するホストを指します。
Web UIやREST APIを提供しており、それを用いて各種クライアントと通信し、Nodeの管理やCookbookを提供します。
Workstation
Chefを管理するホストを指します。NodeではないClientであり、Knifeコマンドの実行やCookbookを作成するホストになります。
Node
Chefで管理されるホストを指します。NodeはClientの一種ですが、ClientのすべてがNodeというわけではありません。
Client
Chef Serverに接続して情報をやりとりするツールやホストを指します。非常に間違いやすいのですが、Chefで管理するホストのことではないので注意が必要です。
Knife
Chefを管理するコマンドラインツールです。
Recipe
Rubyで記述する設定情報の定義です。
Cookbook
Recipeなどの設定情報をひとまとめにしたものです。
上記の関係を図にすると、次のような構成になっています。
