[chef] Re: Re: Re: Re: Re: More on Cookbook Design Patterns

[Lamont Granquist < >]

On Thu Apr  3 07:29:05 2014, Jay Perry wrote:
> Thanks Tom.  So let me make sure I'm following you correctly about the
> base cookbook.  It would look something like:
>
> base cookbook
>   recipes
>     default.rb
>     monitoring.rb
>     chef-cleint.rb
>     etc

One good thing about a monolithic base cookbook the way that you are 
doing it now is that it provides consistency across all your servers.  
Then in emergencies you have standardization across your entire 
platform and there's no issues arising from dealing with different 
kinds of servers while you're time crunched trying to solve a problem.  
By enforcing standardization you also ensure that you don't 
accidentally miss critical cookbooks from all your different 
proliferating 'base' roles.

When you're confronted with a problem like needing different base 
config for datacenters (EC2 vs internal openstack) that may affect 
networking and DNS config (one set of servers may be published to dyn, 
one not), the wrong way to solve that problem is to start forking your 
base roles/cookbooks.  IMO, that intelligence should get pushed into 
the networking or dns cookbooks and broken up into different recipes 
for the different use cases and controlled by attributes at a lower 
level -- then your base role still only asserts that everything 
includes the networking::default recipe -- but the conditionals should 
be moved into that cookbook, not expressed at the base level.  Then you 
can look at the cookbook and the default recipe and know that all the 
logic across your entire platform for how you configure your networking 
is expressed right there.

Chef is flexible enough so that you can start breaking up your base 
roles and only including pieces of it, as required, but then I think 
you're missing something important that comes from standardization.  
From the perspective of the chef client its all managed well and you 
can follow the logic and eventually reason about your systems, but the 
beautiful simplicity of bludgeoning your entire infrastructure into 
looking absolutely identical to the highest extent possible may be lost.

I would wait until I see that I start really needing this kind of 
flexibility in what a base server looks like, rather than engineering 
it from the outset.  I'd almost consider this overflexibility a design 
flaw of Chef based on my experience.  I've used configuration 
management systems at a large scale which had hard-coded a single base 
role (in a 'language' that didn't support any conditionals) and doing 
that really forced standardization.  Chef will allow you to create a 
mess where you have different piles of servers that all have different 
'base' roles that all look fundamentally different (probably good that 
it lets you do it, but its like Singletons and global variables -- you 
need to know the consequences of using them to understand that they 
should be lightly used, if at all).