<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 22 Aug 2011, at 12:31, Viktor Trón wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; position: static; z-index: auto; ">In the end <a href="http://help.opscode.com/kb/troubleshooting/may-i-use-rvm-to-install-ruby-andor-rubygems-that-the-chef-client-runs-under" target="_blank">http://help.opscode.com/kb/troubleshooting/may-i-use-rvm-to-install-ruby-andor-rubygems-that-the-chef-client-runs-under</a> convinced me to write my own bootstrap script to install ruby and rubygems from source before any of the chef magic happens.<br>
<div class="im"><br></div></blockquote><div>thanks Henry, does this not defeat the whole purpose kindof?<br></div></div></blockquote><div><br></div><div>I see what you're getting at, but I don't think it defeats the purpose. Bootstrapping a ruby environment is necessary because Chef and its dependencies are themselves gems. My customisation just installs a specified recent ruby version in place of the default distribution packages. I find this foundation reassuringly specific, and from this point on it's over to Chef as usual.</div><div><br></div><div>Fortunately all my apps can run on recent MRI versions and my gems are managed by bundler, so I don't need RVM's fine-grained control in production. Using update-alternatives is enough to cater for the unusual occasion where I want to migrate rubies, and avoids path-related headaches when using existing chef recipes using the 'gem' resource (which is not RVM-aware).</div><div><br></div><div>Fletcher's cookbook has changed hugely in the last month, so I will return to it when I next need to set up a production RVM. <a href="https://github.com/fnichol/chef-rvm">https://github.com/fnichol/chef-rvm</a> Or perhaps John will have finally converted me to Puppet...</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; position: static; z-index: auto; ">Opscode hosts an 'application' cookbook which aims to be a bit of a swiss army knife for deploying all manner of apps. I found it to be the single most helpful resource for figuring out how to deploy my app and dependencies (I ended up hacking it about to write my own application-specific cookbook as a learning exercise). <a href="https://github.com/opscode/cookbooks/tree/master/application" target="_blank">https://github.com/opscode/cookbooks/tree/master/application</a><br>
<br></blockquote><div><br>so you wrote your own? is this what you meant by chef deploy resource?<br></div></div></blockquote></div><br><div>Unless your entire installation can be expressed as configuration options to existing cookbooks, you'll find yourself writing your own.</div><div><br></div><div>The deploy resource is a chef standard <a href="http://wiki.opscode.com/display/chef/Deploy+Resource">http://wiki.opscode.com/display/chef/Deploy+Resource</a>. Its callbacks are a little different to Capistrano, but it keeps the current / shared / releases directory structure which makes it feel pleasantly familiar.</div><div><br></div></body></html>