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

[Jay Perry < >]

Okay, so is the acme_tomcat_server cookbook app specific or a platform 
cookbook that can be shared?  If myapp need special configuration or extra 
setup very specific to myapp can that go in myapp::default?  I guess in your 
example is the myapp cookbook serving a dual role.  It manages what the role 
would have done and it handles app specific settings and any specialized 
setup?  For example say "myapp" required a special mongo setup.

-- Jay

> On Apr 3, 2014, at 5:03 PM, Lamont Granquist 
> <
 >
>  wrote:
> 
>> On Thu Apr  3 13:38:12 2014, Jason Perry wrote:
>> What I'm also following is that it's probably not a good idea to combine 
>> the application cookbook with a role cookbook.  Currently our application 
>> cookbooks have replaced the roles runlist setting where previously the 
>> role would have a run list that was something like 
>> "recipe[acme_java],recipe[tomcat],recipe[groovy],recipe[myapp]" with the 
>> role being called "myapp".  Now the myapp default recipe has a bunch of 
>> include_recipe calls and the role now just has "recipe[myapp]".  When the 
>> node is bootstrapped the run list ends up looking like so 
>> "role[datacenterA],role[base],role[myapp]".  In this model I would have to 
>> move whatever the base role is doing down to the myapp::default recipe 
>> level or parts of it for testing.  I think this is probably the most 
>> tricky part of  it all and how to avoid too many dependencies with still 
>> being able to test the cookbooks purpose.
>> 
>>   -- Jay
> 
> i'd suggest that all roles do is map 1-1 with role cookbooks.  then i'd 
> suggest that recipe[myapp] be pretty thin and it would just setup some 
> attributes to point at the instance of the software to deploy and then 
> include_recipe something like "acme_tomcat_server".  the acme_tomcat_server 
> recipe would be more complicated and would express all the dependencies 
> including pulling in the your java cookbook, and the actual tomcat cookbook 
> along with monitoring and whatnot.  you might want to have this export an 
> LWRP that your myapp cookbook could use rather than have it be 
> attribute-driven.
> 
> then if installing java requires setting up an internal corporate yum repo 
> mirror then you would want to break that out into its own recipe and 
> include_recipe it there in the java cookbook.  you might also 
> include_recipe this from the base role cookbook as well, but that's fine.  
> chef will figure that out and the yum repo will get setup before anything 
> that depends on it.   if you're doing your testing correctly and expressing 
> your dependencies correctly then you shouldn't have any issues with this.  
> myapp will pick up the tomcat_server cookbook which will pickup the java 
> cookbook which will pickup your yum repo cookbook (even if your base role 
> comes after your role cookbook it should still work out fine so long as 
> you've tested your myapp cookbook in isolation and it has passed -- 
> although generally i'd suggest that base comes first so that your user 
> accounts get setup early so you can login to servers and troubleshoot -- 
> but the further down the test-driven-infrastructure road you get, hopefully 
> the less likely this is a real concern).
>