某所ではリア充イメージ（？）の強い弊社ですが、所属するインフラ部門は男性100％で構成されている上、私は女性っぽい名前ながらも中年のおっさん（趣味は料理）でございます。すんません。
それはさておき、ご存じの方もいらっしゃるかもしれませんが、弊社ではオーケストレーションツールとしてChefを使っております。私は参加しませんでしたが、最近、ChefConf 2013も開催されたことですし、最近の弊社でのDevOps、特にその中でも一風変わったChefの使い方についてお伝えしようと思います。
EC2インスタンスをつくる
最近ではOpsWorksなんかもありますが、本稿執筆時点（2013年6月）ではまだまだ発展途上で、弊社がサービスを作る上で必要な機能が網羅されていませんでしたので、自前のChef Serverを利用しています。
Chefはサーバが起動してからの仕組みですので、これだけだとEC2インスタンスは自分で作成する必要があります。これはManagement Consoleの他、APIをたたくコマンド等でもできますが、これがなかなかめんどくさい...。
というわけで、knifeコマンドでChefからインスタンス作成に必要な情報を引っ張り出して、インスタンスを作るようにしています。
$ knife neoec2 list aws@account.name
Instance ID Name Public IP Private IP Flavor Image Security Groups Chef State
i-12345678 amzn-ami-2013.03.x86_64-ebs.ca t1.micro ami-1e3e3212 default, make-ami ng stopped
i-23204932 cyberagent-app001 x.x.x.x 192.168.1.20 m1.small ami-f4f42123 default, app, http ok running
i-230423a2 cyberagent-db001 192.168.1.21 m1.small ami-f4f42123 default ok running
$ knife neoec2 create server001
knifeにはknife-ec2というプラグイン（Apache License 2.0）が既にありますが、こちらは引数でインスタンス作成に必要な情報を渡す必要があったり、複数のAWSアカウントで利用するのが難しかったりします。
ですから、弊社ではこれを一部参考にする形で、インスタンス作成プラグインを自前で作成（Closed License）しています。
弊社で使っているプラグインの主な特徴は以下の通りです。
- ChefのAttributeからインスタンス作成に必要な情報を取得
- 複数AWSアカウントに対応（Attribute内で使うAWSアカウントを選択）
- AMIからのインスタンス作成時にrootボリュームの拡張や追加EBSボリュームの作成に対応
- 起動後のインスタンスでChef Clientを自動実行
そのため、例えば追加ディスクが必要なDBサーバを作成する場合であっても、1コマンドでEBSの作成をして、さらにChefからファイルシステムを作成してマウント（必要であればRAIDも）して、自動でお目当てのサーバを作ることができます。
あんまり変わり映えしないですね...。
次はもう少し事例が少なそうな内容を
ChefのCookbookから監視設定を自動生成
Chefを使ってセットアップ、例えばApacheをインストールする場合はApacheがインストールされるCookbookを使います。これらのサービスに関わるCookbookに対し、監視に必要な情報、例えばTCPで特定のポートを監視するとか、特定のプロセスの生存を監視するとかのメタ情報を埋め込んでおけば、このCookbookを使った時点でそのサーバの監視対象が判ることになります。
先のApacheの例だと
- TCP:80で応答があること
- "/"宛にHTTPリクエストを発行すると200 OKのレスポンスがあること
この２つの監視メタ情報を入れておきます。
同様にその他のCookbookに対しても監視メタ情報を入れていくと、標準化されたCookbookを選択していくだけで、監視設定を生成するために必要な情報があつまります。で、このまとまった情報を取得できるWebAPIを作ってあるので、以下のようにすると監視設定が取得できるようになっています。
$ curl http://chef-server.address/api/generate -X POST -d "type=icinga" -d 'targets=group1/*' -d 'environment=prd'
（監視設定がずらずら...）
typeには「icinga」が入力されていますので、Icinga（Nagios亜種）の設定が出力されます。ここを同じく弊社がよく利用しているMuninなんかにすると、Munin用の設定が出力されます。curlで取れる内容なので、teeとかすれば設定ファイルとして保存することができます。
まとめると...
- 標準化されたCookbookが存在するミドルウェアなら
- どんな組み合わせ方で、何台のサーバを構築しても
- サーバの構築の自動化と、それらを監視する監視サーバの設定の自動生成
- 特にクラウド（AWSなど）を利用している場合は、サーバの準備も自動化
ができます。
弊社では１つのサービスあたりを数十台から数百台で構成することが多いですが、その位の台数なら、使い慣れたミドルウェアを利用しているサービスであれば、その気になれば一人で一日で作ることも可能です。
弊社には自前のプライベートクラウドがありますが、こちらでもAWS同様の仕組み化することが可能です。