General discussion about Chef

[chef] Re: Re: App cookbooks


Chronological Thread 
  • From: Ranjib Dey < >
  • To:
  • Subject: [chef] Re: Re: App cookbooks
  • Date: Thu, 2 Jan 2014 16:16:00 -0800
+1

i dont think theres any universal rule. Chef cookbook reusability is same as code reusability in any other software projects. if you have commonality across application cookbooks you should definitely consider moving them into a single lwrp/hwrp and model the variable parts as resource attributes. this will also avoid node/role attribute cluttering.

we host jvm, ruby etc applications.  jvm apps reuse a common cookbook, while the ruby apps reuse a different parent cookbook. initially we didn't had multiple apps from same stack, and dedicated cookbooks for inidividual apps. now that our services/apps have grown and we see clear commonality within the jvm, ruby services we have refactored the cookbook to be more dry (and also why_run support etc.. which we wanted to do anyway). Also, we try not to go beyond 3 degree of inheritance (base + app_common + app_foo), we still have terminal cookbooks (app specific, app_foo) , but they are very thin (only consume the lwrp) and dictates only how the resources are assembled (attribute directed branching etc)

again, it really depends your apps (number, commonality, code quality) etc. 

cheers
ranjib


On Thu, Jan 2, 2014 at 4:01 PM, Tony Burns < " target="_blank"> > wrote:
I just finished refactoring our eight or so application cookbooks into a single one with LWRP’s for different application layers and I’m pretty happy with it so far. All of our applications at the moment are Rails with Sidekiq for workers and Unicorn for the web servers running behind nginx. The way I ended up breaking things down was an LWRP for each one of those pieces, and recipes inside the cookbook for each application (so app1_web uses the app_web resource, app1_app uses the app_unicorn resource, etc.) We use runit for process supervision so each application has a data bag for it’s environment that gets put into the shared/env directory for that application. Standardizing on configuration for things like unicorn, nginx, sidekiq, etc. has made my life a whole lot easier now, and if there’s things I might need to tweak per application like unicorn worker counts or which ssl cert to use for an application’s web resource, I’ve just added those as attributes on the LWRPs.

Tony

--
Tony Burns
Operations Engineer / Software Developer
Quad Learning, Inc.
1150 17th St Ste 310, Washington, DC 20036


In our case, I have to disagree, since most of our devs don't want to deal with devops.  We have a lot of apps, but not very much server complexity for any one app.  We have a git hook based deploy process, so if a single cookbook can provision servers based on a data structure in data bags,  I think I can limit the ops side to those who deal with server provisioning, and have the server set up ready to accept a git push to deploy the app.   Having all the servers provisioned with chef, though, will help standardize all the environments.  Eventually, the cookbooks will need very little maintenance, and I won't have to create a new cookbook every time we start a new app - just add some data values and bootstrap the new servers.

Later I may add a rails app to manage the data bag data, allowing for quick provisioning of new app servers.

On 1/2/14 5:13 PM, JJ Asghar wrote:
I like the idea of one cookbook per app.

It allows for expandability and scaling opportunity.  

If that makes sense :)



All -

What’s the community consensus on cookbooks to deploy applications. One per app? Or a generalized cookbook that can deploy any app (as long as it follows a set pattern)?

Thanks,
Mark

--
mark nichols | (t|a.n) @zanshin | (w) zanshin.net 



 


-- 
David Morton

 
 " target="_blank">



Archive powered by MHonArc 2.6.16.

§