# Serial deployment
**URL:** https://discourse.chef.io/t/serial-deployment/1599
**Category:** Chef Infra (archive)
**Created:** [November 2, 2010, 5:38pm UTC](https://discourse.chef.io/t/serial-deployment/1599 "2010-11-02T17:38:17Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Rob\_Guttman](https://discourse.chef.io/u/Rob_Guttman)
#### Post date: [November 2, 2010, 5:38pm UTC](https://discourse.chef.io/t/serial-deployment/1599/1 "2010-11-02T17:38:17Z")
We’re just starting to use chef for managing nagios configs - so far, so
good.
What we would like to eventually use it for is to deploy all of our web apps
and services. A specific use case we have is to be able to _serially_
deploy to hosts/instances within a cluster behind a load balancer. For
example, we would take one host out of rotation, deploy to it, warm it up
and/or smoke test, and when warming completes and/or if smoke tests pass
then put it back into rotation and move on to the next host in the cluster.
How best to achieve that?
Thanks.
- Rob
---
### Author:  [@Seth\_Falcon\_01](https://discourse.chef.io/u/Seth_Falcon_01)
#### Post date: [November 3, 2010, 8:04pm UTC](https://discourse.chef.io/t/serial-deployment/1599/2 "2010-11-03T20:04:32Z")
Hi Rob,
On Tue, Nov 2, 2010 at 10:38 AM, Rob Guttman [robguttman@gmail.com](mailto:robguttman@gmail.com) wrote:
> We're just starting to use chef for managing nagios configs - so far, so
> good.
Nice 🙂
> What we would like to eventually use it for is to deploy all of our web apps
> and services. A specific use case we have is to be able to _serially_
> deploy to hosts/instances within a cluster behind a load balancer. For
> example, we would take one host out of rotation, deploy to it, warm it up
> and/or smoke test, and when warming completes and/or if smoke tests pass
> then put it back into rotation and move on to the next host in the cluster.
>
> How best to achieve that?
Right now there isn't any automated tooling to support this sort of
deployment orchestration, but chef makes this fairly easy to manage in
a by-hand fashion.
Suppose you had a role for your app. A first pass at serial deploy
would be:
1. Update data bag or role describing what version should be deployed.
2. Login to load balancer, take server 1 out of config, restart
3. Run chef-client on server 1. Test it. Put it in rotation and take
out server 2.
[now repeat for each remaining server]
You could go a bit further by having the recipe that generates the
load balancer config check for an "active" attribute:
web\_apps = search(:node, "role:myapp AND active\_app:true")
Then you could take a node out of rotation by editing the node with
knife, setting active\_app:false, and running chef-client on the
load-balancer. You could also use this attribute to decide where to
deploy next:
knife ssh 'role:myall AND active\_app:false' sudo chef-client
If you decide to experiment with this approach, you should be aware
that there is some lag (about 1 minute on the Opscode Platform)
between saving a node and being able to search for updated attribute
values.
- seth
---
### Author:  [@James\_Sulinski](https://discourse.chef.io/u/James_Sulinski)
#### Post date: [November 3, 2010, 9:56pm UTC](https://discourse.chef.io/t/serial-deployment/1599/3 "2010-11-03T21:56:47Z")
Rob,
I know this isn't exactly what you're looking for, but figured I'd toss it
out there:
It's possible to do something like this using Unicorn and nginx, without
removing hosts from the proxy/load balancer. This assumes that you do "smoke
testing" in a staging environment prior to deploying to production. The
removal/warm up/addition process is no longer necessary: unicorn is capable
of rolling restarts, and nginx can skip hosts which aren't ready using the
proxy\_next\_upstream param.
James
On Tue, Nov 2, 2010 at 1:38 PM, Rob Guttman [robguttman@gmail.com](mailto:robguttman@gmail.com) wrote:
> We're just starting to use chef for managing nagios configs - so far, so
> good.
>
> What we would like to eventually use it for is to deploy all of our web
> apps and services. A specific use case we have is to be able to _serially_
> deploy to hosts/instances within a cluster behind a load balancer. For
> example, we would take one host out of rotation, deploy to it, warm it up
> and/or smoke test, and when warming completes and/or if smoke tests pass
> then put it back into rotation and move on to the next host in the cluster.
>
> How best to achieve that?
>
> Thanks.
>
> - Rob
---
### Author:  [@Ash\_Berlin](https://discourse.chef.io/u/Ash_Berlin)
#### Post date: [November 3, 2010, 10:07pm UTC](https://discourse.chef.io/t/serial-deployment/1599/4 "2010-11-03T22:07:27Z")
This is what we do.
Getting the particular invocation in the unicorn config file right get a number of attempts. In particular set Unicorn::HttpServer::START\_CTX[0]. The rest of the config file is pretty much a direct lift from the github's 'seamless with unicorn' post.
However saying that I can appreciate wanting something more complex.
-ash
On 3 Nov 2010, at 21:56, James Sulinski wrote:
> Rob,
>
> I know this isn't exactly what you're looking for, but figured I'd toss it out there:
>
> It's possible to do something like this using Unicorn and nginx, without removing hosts from the proxy/load balancer. This assumes that you do "smoke testing" in a staging environment prior to deploying to production. The removal/warm up/addition process is no longer necessary: unicorn is capable of rolling restarts, and nginx can skip hosts which aren't ready using the proxy\_next\_upstream param.
>
> James
>
> On Tue, Nov 2, 2010 at 1:38 PM, Rob Guttman [robguttman@gmail.com](mailto:robguttman@gmail.com) wrote:
> We're just starting to use chef for managing nagios configs - so far, so good.
>
> What we would like to eventually use it for is to deploy all of our web apps and services. A specific use case we have is to be able to _serially_ deploy to hosts/instances within a cluster behind a load balancer. For example, we would take one host out of rotation, deploy to it, warm it up and/or smoke test, and when warming completes and/or if smoke tests pass then put it back into rotation and move on to the next host in the cluster.
>
> How best to achieve that?
>
> Thanks.
>
> - Rob