If you’ve recently forked the ey-cloud-recipes on GitHub and then had issues
managing and deploying multiple projects with disparate dependencies using the
single forked gem, then we have a solution that has worked well on a recent project.
We’ve tucked the cookbooks directory underneath our Rails project. To apply Chef
changes, we installed the ‘engineyard’ gem and us ‘ey recipes upload’ and
‘ey recipes apply’ from within our Rails project.
Upside, everything you need to know about the project is local to the project.
. ├── Gemfile ├── Gemfile.lock ├── README.md ├── Rakefile ├── app ├── cookbooks │ ├── main │ │ ├── attributes │ │ │ └── recipe.rb │ │ ├── definitions │ │ │ └── ey_cloud_report.rb │ │ ├── libraries │ │ │ ├── ruby_block.rb │ │ │ └── run_for_app.rb │ │ └── recipes │ │ └── default.rb │ ├── redis │ │ ├── README.rdoc │ │ ├── recipes │ │ │ └── default.rb │ │ └── templates │ │ └── default │ │ ├── redis.conf.erb │ │ └── redis.monitrc.erb │ └── sunspot │ ├── recipes │ │ └── default.rb │ └── templates │ └── default │ ├── solr.erb │ └── solr.monitrc.erb
Having automated configuration live with your source code is the way things should always work. Chef recipes are just code that makes your code run. What makes today’s code run may be different from what makes last month’s code run. If you deploy last month’s code for some reason, it should work just as well as it did when you deployed it last month.
I’ll certainly try this out if I end up on an EY Cloud project.
August 27, 2010 at 9:44 pm
Have you added them as a submodule or did you just commit them as part of your project?
August 28, 2010 at 11:04 am
We didn’t use submodules. We’re treating the Chef cookbooks/recipes as source, similar to app source.
August 28, 2010 at 12:45 pm
Great idea. Why we have always kept these in separate repos is now a total mystery to me.
September 5, 2010 at 12:00 pm