問題
VMをぽこぽこ作りながらあれこれツールを入れて試してみたりしたいという時に、chefを使って構成管理はしたいけど、chef-serverを入れるのは面倒、というか、構成パッケージの記述・インストールだけできればいいという要求からするとオーバスペックなように感じるのだし、また、ホストの管理にはcapistranoを使っているので、cap実行側のみで処理が完結する方がよいという場合もあろうかと思う。
前提
- デプロイ先ホストには、公開鍵認証でログインできるものとする(capを使うので)
- デプロイ先ホストでは、既にgit, chef-soloが使える状態であるものとする(そこまではなんらかの方法でがんばる)
解決案
そこで、chef-soloという、chef-serverなし、スタンドアロンにレシピの実行を行うコマンドをcapで実行するようにしてみる方法を試してみた。例として、GrowthForecastを動かすホストの構成管理を取り上げる。ディレクトリ構成は以下の通り。
├── .carton
├── .git
├── .gitignore
├── .gitmodules
├── Capfile
├── Makefile.PL
├── carton.lock
├── config
│ ├── chef.json
│ ├── deploy.rb
│ └── supervisor.ini
├── local
└── modules
├── GrowthForecast
└── chef-repo
chef-repoを作成、submoduleにする
今回はGrowthForecastに必要なパッケージ(Alien::RRDtoolを入れるのに必要なパッケージ)のみですが、それに限らず、共通に使いまわせるレシピをあれこれと書いていきます。とりあえず、以下のようなrole構成にしました(リストの階層が継承関係を示す)。
- role[base]: 大元のrole
- role[supervisor]: supervisor使う用
- role[perlbrew] (opscodeで共有されているものに手を入れたもの): Perlのプロダクトを動かす用
- role[growthforecast]: GrowthForecastに特化したrole。今回はこれを使う。
chef-soloの実行
chef-soloを実行するタスクは以下の通り。
namespace :chef do
task :solo do
sudo <<-"EOS", :pty => true
chef-solo -c #{deploy_to}/current/modules/chef-repo/config/solo.rb -j #{deploy_to}/current/config/chef.json
EOS
end
end
また、上記コード内のconfig/chef.jsonは以下の通り。
{
"run_list": [ "role[growthforecast]" ]
}
chef-soloの設定ファイルは、chef-soloリポジトリ内にconfig/solo.rbとして置かれている。
require 'pathname' basedir = Pathname.new(__FILE__).realpath.dirname.parent file_cache_path "/tmp/chef-repo" cookbook_path (basedir + "cookbooks").to_s role_path (basedir + "roles").to_s
- config/chef.jsonにrun_listを、
- modules/chef-solo/config/solo.rbにchef-soloの設定を書くようにする
というふたつのルールを導入することで、capのタスクを一般的に使えるようにしている。同様のディレクトリ構成を取ることで、他のプロダクトについても
$ cap chef:solo
と実行することで、config/chef.jsonに書かれた、個々のアプリケーションの構成に必要なroleでもって、かつ、chef-reposに蓄積された共通のレシピを利用して、構成管理を行える。
問題点
- submoduleにしている関係上、全てのホストにchef-repos一式が存在することになって、冗長な感じがする。
- capを叩かないと構成変更を更新することができない(自動的に更新したりしない)
- 実行速度が遅かったりする？
冗長であるとはいえ、複雑なchef-serverを介することなくcap + gitrepositoryだけで管理できるのは、気軽でよい感じがする。
その他
chefには直接関係ないが、以下のようなことも行っている
- GrowthForecastを直接使うのではなく、そのGitリポジトリをsubmoduleにする。
- Perlモジュールの管理はcartonで行うことにする。モジュールの増減は、システム側というよりはアプリの都合でころころ変わることになるだろうので、chefでやるよりcartonだとか、rubyでいえばbundlerだとかでやる方がいい感じがする。
carton:installというタスクを用意した
- growthforecastの起動にはsupervisorを用いている。
supervisor:(start|stop|restart)などといったタスクを用意した
