[chef] Re: how are people using the deploy_revision resource?

[László Bácsi < >]

Hey Andrew,

we use it for deploying our Ruby webapps to multiple app servers. The trick we rely on is that every app server accesses the files through shared storage (nfs mounted to /data). This way we only need to run the chef-client on one of our app servers, and the code will be there on all other servers. After the deployment is over the app server processes are restarted by god[1] which monitors the /data/project/current/tmp/restart.txt file and restarts processes if it has been modified.

One thing I'm working on at the moment is to prevent the deploy_revision resource from taking action when the chef client runs periodically. We wouldn't want to deploy every time there's something pushed to the repository. The trick I will use here is to check Chef::Config[:interval] and/or Chef::Config[:daemonize] values in the deploy_revision resource to decide on the action to take.

László

[1]: http://god.rubyforge.org

On Tue, Oct 19, 2010 at 10:32 PM, Andrew Willis < " target="_blank"> > wrote:

Hi All,

I recently started playing around with the deploy_revision resource, and it works exactly how I expect it to. I have questions about how this would work when used with a cluster of application servers all running the same rails app. I'm betting others are using it in this configuration, and I'd love to hear more about your experience with it. When it comes time to do a deploy, do you use chef to roll out the new code to all of the servers? If so, how do you deal with the fact that the deploy may not work on a given server? Capistrano is nice in that if it can't complete each one of its tasks on each server, it rolls back the deploy. And if you aren't using chef to do your app deploys, how do you do them?

thanks!

-Andrew