[chef] Re: Re: Re: Chef Server vs Chef Solo and MCollective


Chronological Thread 
  • From: "Nguyen, Dang" < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: Chef Server vs Chef Solo and MCollective
  • Date: Fri, 31 Aug 2012 11:32:48 -0700
  • Accept-language: en-US
  • Acceptlanguage: en-US

Is the "--override-runlist" option temporary, meaning it's just for the current run only and the node's normal run list is reset back? I'm thinking that in the case when we have the chef-client running as a daemon, we'd have it on a "normal" run list and then use the --override-runlist option for a one-off chef run.


On 8/31/12 11:22 AM, "Lamont Granquist" < "> > wrote:

On 8/31/12 2:13 AM, KC Braunschweig wrote:

- lifecycle events?
I don't know what he means. The bootstrap concept is well defined. If
you're written your recipes correctly, the box is fully configured in
1 run so there is no partially converged state to report back about.

when you start getting to very complex full convergences some people
want to be able to do a deployment separate from a full convergence.  
but there's been added an --override-runlist option to chef-client to do
this in order to just kick off the recipe that deploys a piece of software.

- pull/push?
When we did application deployment with chef at my last company we
looked and puppet+mcollective first. What we found was that the push
model we envisioned with mcollective we could basically do as a pull
model with chef-server's built-in search api and it was much simpler
to get started. We found people think they want push much more than is
needed. Push models have their place, but you have to be very careful
about creating coupling. The pull model is more likely to force you to
keep things nicely decoupled so nodes can do their thing and
independently converge on your goal state. It takes a little thought
up front, but I think it's less likely to lead you down a dark path.


having torn out a 1,000-node push based rdist infrastructure and
replaced it with a pull-based cfengine one, i don't really know what to
say about the argument that entirely push based infrastructures are
better other than "nope".

and if you want push-based deployments with chef you can start with
something like:

knife ssh 'role:foo-server' 'sudo chef-client --override-runlist
'recipe[deploy::foosoftware]'

then create a software deployment user that allows passwordless logins
from your central deployment host(s) and ACL the authorized_keys to only
be able to run your deployment commands and give it passwordless sudo to
only kick off chef deployments (probably create a wrapper script around
chef-client and only give out sudo to that wrapper script).






Archive powered by MHonArc 2.6.16.

§