- From: Lamont Granquist <
- Subject: [chef-dev] Re: CHEF-2988 allowed_recipes, restricted_recipes, and override_recipes
- Date: Mon, 26 Mar 2012 13:57:46 -0700
My vote is for tighter integration between system config management and
application config management. I don't want a whole separate system and
separate database and have to replicate state between chef's node data
and data bags to the application deployment database and vice versa.
I've done that multiple times and it blows. You also always wind up
going down this messy road where your apps start to pull in requirements
like rpms and config files which are external to just simple
"application deployment" and you wind up dropping off config-engine code
fragments with your app deploy engine which are picked up and run by
your system config management convergence engine (often as root, with
devs able to push arbitrary system code, creating huge SOX violations in
process that the auditors just never uncover). Ultimately, the right
way is to have it integrated. You could have an extra tool that gets
added in addition to chef-client, but I think that extra tool is going
to wind up with so much of chef-client in it (we need node data and data
bags and search, and package resources, and file resources, etc, etc)
and will wind up getting called by chef-client, so you might as well do
the tight integration to begin with.
I also cut this ticket awhile back which is sort of an inverse problem:
There it isn't that I want to just do one recipe and not run a
convergence, its more that i require that every time a convergence is
run that a recipe must be executed, no matter how screwed up the rest of
the run is (even failures in required recipes are often not fatal to the
execution of later recipes, since with proper idempotency those
prerequisite recipes will be no-ops the vast majority of the time -- it
feels like a sin, but it normally will not seriously bite you, and at
the scale of 10,000s of servers it will just be a fact of life to have
busted recipes on some servers all the time...).
And if there's any philosophy to chef, I seriously hope it is just
getting our jobs done...
On 3/26/12 10:29 AM, Jay Feldblum wrote:
I think the key issue is that:
application deployment =/= node convergence
Trying to treat application deployment as though it were just another
part of node convergence possibly introduces friction into the
configuration management, depending on the nature of the application
deployment and the nature of the rest of the convergence.
For many people and for many applications, possibly most people and
most aplications, this discrepancy is not a problem, and for them,
application deploys during chef runs (node convergences) are perfectly
Sometimes the discrepancy is a problem, and I think the best solution
sometimes is to have a separate application-deployment mechanism. The
application-deployment mechanism is delivered during the node
convergence, but application-deployment actions are triggered
out-of-band (i.e., not during convergence). A simple
application-deployment mechanism is: building & packaging the
application on a build server and uploading the built package (slug,
deb, lxc-rootfs, etc.) to storage, a script dropped onto each
application server during the node convergence that pulls the latest
package and installs it, and knife-ssh to invoke the script. As Lusis
mentions, Jenkins or similar build systems may also work.
I don't think trying to treat Chef as a glorified script runner is as
useful as treating Chef as a declarative final-state convergence
engine. Application-deployment may sometimes not fit within the
declarative final-state convergence model, and when that happens, it
may be wiser not to try to shoehorn it in.
- [chef-dev] Re: Re: Re: Re: CHEF-2988 allowed_recipes, restricted_recipes, and override_recipes, (continued)
- [chef-dev] Re: CHEF-2988 allowed_recipes, restricted_recipes, and override_recipes, AJ Christensen, 03/26/2012
- [chef-dev] Re: CHEF-2988 allowed_recipes, restricted_recipes, and override_recipes, Bryan McLellan, 03/28/2012
Archive powered by MHonArc 2.6.16.