|
We've accomplished something pretty close to this.
For #1, we're using Rackspace, so we create a template with chef-client pre-installed. We have a script that runs to deploy the node based on the template, pushes a chef config file and keys, sets up the basic node properties in chef including assigning
roles, and then triggers the initial chef run. I suppose we could do the same with knife but the script works better for our purposes.
For #2, our code is packaged into debian packages, uploaded to our private debian repository, and the package version is saved as an attribute in the environment. Each node installs the version that's in the environment assign to it. Upgrading means bumping
the version in the environment, and within 15 minutes all our nodes are upgraded.
For #3, chef runs every 15 minutes regardless. We only shut it down temporarily if we have to make an emergency change (and this requires wearing the hat of shame) that needs to get in place before the code or configuration change can make its way through
the build process (about 3 hours including full test suite), after which chef is enabled to implement the upgrade.
cheers
mike
--
Michael Hart
Arctic Wolf Networks
M: 226.388.4773
On 2013-10-10, at 3:25 PM, Wes Morgan <
">
> wrote: 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
|