- From: Wes Morgan <
>
- To: "
" <
>
- Subject: [chef] app deployments w/ chef
- Date: Thu, 10 Oct 2013 13:25:21 -0600
Ohai,
I know this is a perennial bugaboo, but I'm curious how folks are handling
internally-developed app deployments with Chef these days, and specifically
if anyone has found a good solution that achieves all of the following:
1. When provisioning a new node, Chef can deploy the app(s) that should be on
that node. knife ec2 server create … should be the only command I need to run
to go from "no server" to "it's added to the LB and handling requests." In
other words, you don't need to provision with Chef, then deploy with
Capistrano, etc.
2. When running chef-client on nodes that already have some version of the
app(s) running, make sure that they all run the same version and upgrade
simultaneously and atomically (or as close to that as possible). So, for
example, if you were storing a git rev in a data bag as the "current version
I want deployed" and then one node kicked off its regular chef-client run and
upgraded to that, the other nodes running that app would then still be on an
old version of that code. That shouldn't happen, but it would with the
simplest use of the Chef deploy resource and the splayed, regular interval
chef-client runs.
3. Don't lose the ability to run chef-client automatically at regular
intervals on all nodes. This is important. I have better things to do than
running Chef code manually on servers when things change (and running that
detection algorithm in my brain) and then cleaning up whatever bit rot
breakage occurred since the last chef-client run hours/days/weeks/months ago.
It seems the main tension here is #1 requires Chef to be able to kick off a
deploy to a single node, whereas #2 requires Chef to either never deploy code
to nodes that already have some version of it (and thus require a separate
manual process to do simultaneous, atomic upgrades) OR to kick off an
orchestrated run across all nodes that need to be upgraded (which really
isn't Chef's forte, AFAICT).
Something like Capistrano is handy because multi-server orchestration is its
bread and butter, but getting Chef and Capistrano to communicate and share
data is… tricky.
If the deploy resource could be configured to only deploy when no version of
the app was present (covering #1), or when a defaulted-false parameter were
set to true by a manual knife ssh run covering all nodes that run that app,
that could work. Does that seem reasonable?
- Wes
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
- [chef] app deployments w/ chef, Wes Morgan, 10/10/2013
- [chef] Re: app deployments w/ chef, Morgan Blackthorne, 10/10/2013
- [chef] Re: app deployments w/ chef, Graham Christensen, 10/10/2013
- [chef] Re: app deployments w/ chef, Michael Hart, 10/10/2013
- [chef] Re: app deployments w/ chef, Arnold Krille, 10/10/2013
- [chef] Re: app deployments w/ chef, Lamont Granquist, 10/10/2013
- [chef] Re: app deployments w/ chef, Clif Smith, 10/16/2013
Archive powered by MHonArc 2.6.16.