September 9th 2010 By Dr Nic Williams

Managing your ey-cloud-recipes

This guest post is by Mike Barinek from Pivotal Labs, an Engine Yard Premier Partner.

If you’ve recently forked the ey-cloud-recipes 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 at Pivotal Labs.

We’ve tucked the cookbooks directory underneath our Rails project. To apply Chef changes, we installed the engineyard gem and use ‘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 source. This also means it is versioned alongside the application code.

.
├── 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
This article was originally [published](http://pivotallabs.com/users/mbarinek/blog/articles/1384-managing-your-ey-cloud-recipes) on Pivotal Lab's blog Pivotal Blabs.

Share your thoughts with @engineyard on Twitter