chef-soloで構成管理する問題VMをぽこぽこ作りながらあれこれツールを入れて試してみたりしたいという時に、chefを使って構成管理はしたいけど、chef-serverを入れるのは面倒、というか、構成パッケージの記述・インストールだけできればいいという要求からするとオーバスペックなように感じるのだし、また、ホストの管理にはcapistranoを使っているので、cap実行側のみで処理が完結する方がよいという場合もあろうかと思う。chef-soloが使える状態であるものとする(そこまではなんらかの方法でがんばる)解決案そこで、chef-soloという、chef-serverなし、スタンドアロンにレシピの実行を行うコマンドをcapで実行するようにしてみる方法を試してみた。例として、GrowthForecastを動かすホストの構成管理を取り上げる。ディレクトリ構成は以下の通り。chef-repochef-repoを作成、submoduleにする今回はGrowthForecastに必要なパッケージ(Alien::RRDtoolを入れるのに必要なパッケージ)のみですが、それに限らず、共通に使いまわせるレシピをあれこれと書いていきます。以下のようなrole構成にしました(リストの階層が継承関係を示す)。GrowthForecastに特化したrole。chef-soloの実行chef-soloを実行するタスクは以下の通り。endendまた、上記コード内のconfig/chef.jsonは以下の通り。]}chef-soloの設定ファイルは、chef-soloリポジトリ内にconfig/solo.rbとして置かれている。"roles").to_sconfig/chef.jsonにrun_listを、modules/chef-solo/config/solo.rbにchef-soloの設定を書くようにするというふたつのルールを導入することで、capのタスクを一般的に使えるようにしている。chef:soloと実行することで、config/chef.jsonに書かれた、個々のアプリケーションの構成に必要なroleでもって、かつ、chef-reposに蓄積された共通のレシピを利用して、構成管理を行える。問題点submoduleにしている関係上、全てのホストにchef-repos一式が存在することになって、冗長な感じがする。gitrepositoryだけで管理できるのは、気軽でよい感じがする。その他chefには直接関係ないが、以下のようなことも行っているGrowthForecastを直接使うのではなく、そのGitリポジトリをsubmoduleにする。Perlモジュールの管理はcartonで行うことにする。モジュールの増減は、システム側というよりはアプリの都合でころころ変わることになるだろうので、chefでやるよりcartonだとか、rubyでいえばbundlerだとかでやる方がいい感じがする。carton:installというタスクを用意したgrowthforecastの起動にはsupervisorを用いている。