[chef] Re: Organizing multiple "clients" and cookbooks

[Seth Chisamore < >]

The DRYest approach would be common cookbooks with individual roles per client.  The roles could override unique client attributes, things like apache, tomcat and mysql tuning parameters...or ports that apache runs on.  Since each role also has it's own run_list it would allow you to account for the different groupings of software each client may also have (ie some clients use apache only, no tomcat).

One way to help visualize the different components of Chef (and what goes where) is to think of it as an MVC for your infrastructure.  The model is represented by data bags and attributes, the recipes (and resource actions) are controllers and the rendered templates and final resource states are views.  And just like in a web application you wouldn't want to "hard code" a lot of client specific logic into a controller...you would try to externalize it as model data.  Trying to approach things as data-driven as possible will also mean less Chef cookbook code to maintain and an infrastructure that will scale as you grow.

Seth

--
Opscode, Inc.
Seth Chisamore, Technical Evangelist
T: (404) 348-0505 E: " target="_blank">
Twitter, IRC, Github: schisamo

On Tue, Oct 19, 2010 at 8:18 AM, Brian Akins < "> > wrote:

Greetings,

Perhaps this has been covered before, but a quick search turned up empty.

We have many large "clients."  Each of these clients runs a multitude of apps (tomcat, apache, nginx, mysql, etc).  As we use chef more and more, we really need to decide how we are going to organize them.  How are other people doing it?  Should we have a cookbook per client and put the recipes there, including other recipes as needed (this is how we currently do it in puppet) or should we put everyone's apache stuff in the apache cookbook, etc?

I think a cookbook per client makes sense, however, I fear we may repeat ourselves allot and possibly have multiple implementations of common tasks if we are not careful.

Thoughts?

--Brian