[chef] Configuration location philosophies - what's yours?


Chronological Thread 
  • From: "Leinartas, Michael" < >
  • To: " " < >
  • Subject: [chef] Configuration location philosophies - what's yours?
  • Date: Fri, 30 Jul 2010 21:41:02 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

Title: Configuration location philosophies - what's yours?
As I set up an environment from scratch I've had to do some thinking about where I want to be putting the configuration within Chef.  Configuration can go in many places: The recipes themselves (e.g. a recipe that has a list of "user" resources in which you add to the recipe when you have new users), attribute files within recipes, in databags, in roles, on the nodes themselves (either set on the fly or by some json blobs you have lying around).  (that's about it, right?).

It feels proper to make a decision as to where you intend to put most of your configuration.  I can imagine someone using databags almost exclusively, or relying exclusively on hardcoded data in recipes, etc.  What I'm wondering is what the preferences of the people on this list are?  What's 'normal' for chef?

Here's what I've been trying (I'd love comments on this). Note that I just started with Chef in 0.9.6 so I dont know what it's like to not have databags, roles, attribute heirarchies, etc.
My instinct is to define the behavior (cookbooks) generically and keep the actual configuration separate.  In that, I've been writing cookbooks driven entirely from attributes. I define default attributes in the cookbook with the intent of overriding most of them.  In my model, all of my configuration goes into Roles.  In the case of any one-off configuration, I plan to further override at the node level (and expect this to be rare).  I have multiple server types and multiple environments and so have several types of roles, some of which override one another (order matters - this is where it breaks down since there's no way to set explicit role dependency).
So to illustrate, examples of 3 main types or levels of Roles:
ServerRole - base role that every server gets
WebappRole - a specific application category role - shouldnt conflict with another app role (like WebserverRole)
StagingRole - an environment role. overrides only those attributes within the previous roles that differ between environments

Any server in my environment that actually does anything will need one of each of these roles in this order (except dev which uses the defaults and doesnt need an env role).
So far I've only used databags for things truely global to the environment like a list of hostnames and IPs to generate identical /etc/hosts files on each box.

Comments? Is this way off from what other people do or does this fit with what youve seen before?



  • [chef] Configuration location philosophies - what's yours?, Leinartas, Michael, 07/30/2010

Archive powered by MHonArc 2.6.16.

§