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
On 19 October 2010 21:32, Andrew Willis andrewwillis@yahoo.com wrote:
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?
I'm using it for deployment of any new applications at a client's
company, and the way we do it is to have a staging environment where
things are tested first. That environment is an identical clone of the
production one, except deployments come from a staging branch instead
of a production one. By running all deployments there first we can be
(relatively) certain it's not going to break when it hits production.
Jon
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
god1 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ó
On Tue, Oct 19, 2010 at 10:32 PM, Andrew Willis andrewwillis@yahoo.comwrote:
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
I just reference a specific commit hash or tag name in the data bag. No more unexpected deploys!
Brian
Sent from my iPhone
On Oct 21, 2010, at 3:34 AM, László Bácsi lackac@lackac.hu wrote:
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ó
The deploy resource is idempotent (like the rest of Chef)...you can target a
commit sha, branch, or tag and rest easy knowing your nodes will only update
their copy of the code when it has changed in the repo. If you don't want
to update a data bag entry for every deploy (as mentioned by Brian), you
could also have a branch that is for production deployment only...a lot of
people use master for this.
Also be sure to take a look at the "application" cookbook:
http://github.com/opscode/cookbooks/tree/master/application/
It uses the deploy resource but also adds some extra logic on top including
a capistrano-style deployment structure. The goal of this cookbook is to
create a way to deploy applications that is completely data-driven vs being
hardcoded inside the cookbook.
Seth
--
Opscode, Inc.
Seth Chisamore, Technical Evangelist
T: (404) 348-0505 E: schisamo@opscode.com
Twitter, IRC, Github: schisamo
On Thu, Oct 21, 2010 at 8:12 AM, Brian McKelvey brian@worlize.com wrote:
I just reference a specific commit hash or tag name in the data bag. No
more unexpected deploys!
Brian
Sent from my iPhone
On Oct 21, 2010, at 3:34 AM, László Bácsi lackac@lackac.hu wrote:
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.orghttp://god.rubyforge.org