I have 6 rails applications, with various databases on multiple
servers (2-4 per app). I’m evaluating Chef right now, and will be
honestly that I haven’t gotten very far yet. While researching, I
came across a slide[1] that suggested Chef Solo + MCollective over
Chef Server. The slide basically suggest that Chef Server is
complicated, not well suited for multiple environments, and not as
well suited for multiple projects and to use Chef Solo + MCollective
instead. As I said, I’m new to Chef and am looking for (1) further
explanation into these claims and (2) recommendations on which to use.
[1] http://www.slideshare.net/jweiss/build-your-own-clouds-with-chef-and-mcollective
(slide 25/61)
On Thu, Aug 30, 2012 at 7:49 PM, bradford fingermark@gmail.com wrote:
[1] Build your own clouds with Chef and MCollective | PPT
(slide 25/61)
-
Complex?
Chef server does have a number of components. The chef-server cookbook
will handle most of this for you reasonably well. If you use opscode
hosted chef or private chef, this is a non-issue.
-
concept of different environments?
Environments exist and are a first order concept in chef as of
v0.10.0. Maybe he was looking at an older version? Also with hosted or
private chef you can use multiple "organizations" too, which are like
logical chef servers. There are existing knife plugins in the
community that implement workflows people use for promoting stuff
between environments and/or organizations.
-
didn't want to run multiple chef servers?
Unnecessary, environments are a thing.
-
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.
-
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.
Hope that helps.
KC
On Fri, Aug 31, 2012 at 2:13 AM, KC Braunschweig
kcbraunschweig@gmail.com wrote:
- 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.
One thing to keep in mind is that is trivial to implement a "push when needed"
model on top of a primarily pull system. Doing the reverse of that is extremely
difficult ( i.e. using push to implement pull semantics ).
Great replies. Thanks, guys.
On Fri, Aug 31, 2012 at 12:02 PM, Booker Bense bbense@gmail.com wrote:
On Fri, Aug 31, 2012 at 2:13 AM, KC Braunschweig
kcbraunschweig@gmail.com wrote:
- 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.
One thing to keep in mind is that is trivial to implement a "push when needed"
model on top of a primarily pull system. Doing the reverse of that is extremely
difficult ( i.e. using push to implement pull semantics ).
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).
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” <lamont@opscode.commailto:lamont@opscode.com> 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).
On 8/31/12 11:32 AM, Nguyen, Dang wrote:
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.
my understanding is that is correct. you need to be very careful about
what happens with attributes during the chef run when you're doing
this. there's magic that happens at the end of the run to fix things
back up again and give you node data in the database which does not
violate the principle of least surprise, but the node attributes you see
inside the override run list run will have had all their default,
automatic and override attributes wiped and you may get confusing solr
search results back.