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

[Lamont Granquist < >]

On Thu Apr  3 14:17:56 2014, Jay Perry wrote:
> 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 yo
u get, hopefully the less likely this is a real concern).
> >

as long as the special configuration is really special to myapp then 
i'd put it directly in myapp::default.  once you repeat yourself then 
you should probably push that into your acme_tomcat_server cookbook.  
ideally all your tomcat servers use acme_tomcat_server::default.  as 
you create slightly different common sub-flavors of tomcat servers 
you'll create additional complexity in that cookbook.  you might switch 
behavior based on node attributes, based on LWRP attributes, you might 
have different versioned 'branches' (1.x vs 2.x) of the cookbook, you 
might have different flavors of recipes, and you might even bust out 
two acme_tomcat_server_v1 and acme_tomcat_server_v2 cookbooks.  all of 
those different approaches to handling conditional logic have their 
strengths and weaknesses but you probably want to prefer solutions 
closer to the beginning of that list than the end.

i would say that the myapp cookbook is a role cookbook, but i don't 
really care about the name you give the thing.  it is a cookbook that 
expresses what is different about myapp from your other apps (database 
credentials, github repo, artifacts to install, special magic sauce 
that only gets applied to myapp).  then you want another cookbook that 
expresses what is the same between all your different tomcat apps 
(which probably exports some LWRPs and may have a default recipe for 
common setup).  you write the latter to look more like a library 
cookbook pattern where its intended to be reused.  the myapp cookbook 
isn't intended to be reused at all.