vagrant + puppet を使っての開発環境を作る場合に、いままでは、

• プロジェクト直下に vagrant.pp をおいてそこにすべてを詰め込む
• file resource を定義するとき、source で指定するファイルはプロジェクトで使う他の設定ファイル用のディレクトリに混ぜ込んでおいておいてフルパスハードコードで参照

source => '/vagrant/conf/my.cnf'

としていた。これはこれで機能していたし、手作業で構築する部分はゼロだった。ただ、この manifest を使いまわして puppet apply してAWS 上やら社内サーバーやらに QA 用の環境用意しようとなったとたん使い回しが効かなくて manifest 都度手直しとかするはめになってしまうことに気づいた。（まぁ、その環境でも /vagrant に git clone してもらえればそれはそれでいいんだけど…）

結局 manifest にフルパスをハードコードしないためには、モジュール化して、

source => 'puppet:///modules/mysql/my.cnf'

などとして参照できるようにすれば puppet apply –modulepath でどこに clone しても動く manifest になる。ということで、いまは以下の様な感じで作るのが自分の中のベストプラクティスとなった。

puppet
├── mysql
│   ├── files
│   │   └── my.cnf
│   └── manifests
│       └── init.pp
├── pound
│   ├── files
│   │   ├── example.com.pound.crt
│   │   └── pound.cfg
│   └── manifests
│       └── init.pp
└── site.pp

という感じで file resource 必要な奴はモジュール化。Vagrantfile は、

config.vm.provision :puppet do |puppet|
   puppet.module_path    = "puppet"
   puppet.manifests_path = "puppet"
   puppet.manifest_file  = "site.pp"
   puppet.options        = "--verbose"
end

とする。

これで、vagrant 使ってれば vagrant provision でもちろん行けるし、そうでない環境をどうにかしたいときには git clone してきて、

puppet apply --modulepath=$PWD/puppet puppet/site.pp

とすればよいだけ。

一手間あるといえばあるけど、アプリケーションが直接使うわけでもない my.cnf みたいなものを自然と別ディレクトリに分離できるし、心理的にもスッキリした感。しばらくこれでよさげ。