[chef] Re: app deployments w/ chef

[Arnold Krille < >]

Hi,

I found Chef very rewarding for your #1. I don't see any need for
capistrano, fabric, whatever...

For your #2 if I understand you correctly you mean something like:
You have your in-house web-app. Historically it was deployed by
hand/capistrano to several nodes and worked well. Now you add nodes
doing the same tasks but are completely chef-managed.
I do have that scenario here too. And its a pain in the a**. But I made
_very_ good results by just completely scrapping these nodes after
deploying fitting nodes of category #1.
tl;dr: Replace that #2 nodes with #1 nodes.

#3: When you write the recipes to deploy your app(s), include an
attribute for the version. Your production-environment then has
versions/revisions fixed env-wide. While your staging/testing areas
don't have version/revision-constrains set. So when your CI-testing
turns green and the manual checking in staging also turns out good, you
can adopt the attributes in the production environment and have the
nodes pick up the new version within your normal interval.
When you have things like load-balancers, not only have them search for
nodes with the needed roles in the environment, but also check that the
last time they finished a chef-run isn't to long ago. Then the nodes
where the update failed will only get a limited number of request and
once you finished looking into them, they will be picked up again by
the load-balancers...

Maybe that helps,

Arnold

On Thu, 10 Oct 2013 13:25:21 -0600 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

Attachment: signature.asc
Description: PGP signature