[chef] Re: Re: Re: Re: Re: Re: Re: Starting out with the opscode platform.


Chronological Thread 
  • From: Bryan McLellan < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Starting out with the opscode platform.
  • Date: Tue, 31 May 2011 16:39:26 -0700

On Tue, May 31, 2011 at 4:07 PM, Tim Uckun 
< >
 wrote:
> Why not create a cookbok for that individual host and override the values 
> there?

Systems get treated as resources that can be thrown out and replaced.
Your database server isn't "romulus" and it may not even be "db01".
For example, at Opscode all of our systems have a unique id such as
EC2 instance ID or a partial GUID as their hostname (we also have a
more descriptive alias that is autogenerated based on roles) because
they're simply resources upon which to run services.

Imagine you have a bread company and ten bread trucks with the same
options and paint job. You can use any of them to make your delivery.
One of them gets a flat tire and can't run its route but you have
another that you could use. Do you delay the delivery so you can still
use that truck, or do you use another and fix the truck? You don't
want your trucks to be unique because you're not in the business of
driving trucks, but rather of baking and delivering bread.

We're not in the business of running servers, but whatever business we
are in requires that we run servers so we aim to turn it into a
commodity where reasonable. Chef is designed around this model.

If you have a host-specific cookbook, you're focusing on running that
specific host. Whenever you make another host, you have to create and
upload another cookbook. We want to reduce the number of manual
configuration steps with Chef, not increase them. Whenever possible,
it should only take a couple commands to build another server of the
same type (or role) as one you already have.

Most of us are trying to run a particular service on our servers, so
we make service and application specific cookbooks, and then tie them
together into a package with roles. Then when we register the servers
as nodes, we can apply one or more roles to that server based on what
services we want it to provide.

Depending on what these settings are, I'd personally set them on the
node after it is registered as an attribute.

In summary, you don't want any host specific settings. When you have
to have them, you should avoid changing the model so that it is built
around these settings.

Bryan



Archive powered by MHonArc 2.6.16.

§