[chef] Gradual deployments


Chronological Thread 
  • From: "Mark J. Reed" < >
  • To:
  • Subject: [chef] Gradual deployments
  • Date: Tue, 19 Oct 2010 13:30:08 -0400
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DPJwk0qUuco/yX0VNDJY66tUoAUMKNbGFkMd8OG8kjyfiDnNQvFp8n0K9KtwVvUHCG yVJX4s2kZmoYX1UwxHNAG+W8tSxU7uhc3m5LUPWM8YHHGBWN0DAZaCXYewk+jUW1TXT/ Z/4s/54R7qI3npjTq1AnsxI71UHWwxe+mOj30=

What techniques do you use for controlling the deployment of recipe
changes via Chef server? We're looking for a way to automate canary
deployments, rolling changes to first one, then a few, and then the
rest of the affected nodes.

New templates etc. can take advantage of file specificity (though it'd
be nice to have other options there for giving an arbitrary set of
nodes the same non-default file), but it's not much help if you have a
new version of the actual recipe code or a whole cookbook or a role.
One option is to give the new version a different name and shuffle run
lists around, then move it into place and shuffle back, but that can
be awkward to automate, especially if you're modifying something that
gets pulled in by other roles that depend on it.

You can copy cookbooks out and try them with chef-solo, but I don't
trust that to get the same results as a full chef-client run against
the server; it feels like more of a unit test than a deployment step.

We've thought about migrating nodes between two different Chef servers
(or two different Opscode Platform accounts), but that seems like an
awfully heavyweight solution.

Other ideas?

-- 
Mark J. Reed 
< >



Archive powered by MHonArc 2.6.16.

§