Engine Yard Blog RSS Feed

This guest post is by [Mike Barinek](http://pivotallabs.com/users/mbarinek/blog) from [Pivotal Labs](http://pivotallabs.com), 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.

Tagged:

comments powered by Disqus