[chef] Re: Re: Application cookbook

[Seth Chisamore < >]

Ohai Tim!

I just wanted to expand on the other thoughts shared here and give a little 
of the philosophy behind the application cookbook. As opposed to grouping the 
recipes in cookbooks by technology type as you suggested (ie Rails, Django, 
Java etc.) we chose to group things together by deployment style.

Basically all technology types share a similar data bag definition, role and 
usage style:

* pull code vs push code (ie cap or fabric)
* deploy the code (checkout code, install required packages, create env 
specific configs)
* serve the code (install app server, create app specific config file)

What's neat about this is once you grok the data-driven nature of the 
application cookbook you can deploy any application code (that the cookbook 
supports) following the exact same pattern! You can also have some external 
process (think Jenkins) create/update app data bag items for you on the fly 
using the Chef Server API.

One concern people have is the extra dependent cookbooks that come along for 
the ride...ie I'm deploying a Rails app why do I need the php cookbook! Just 
because a cookbook depends on another cookbook doesn't mean the code will be 
invoked during the chef run. This will only happen if a recipe includes the 
other recipe (either through a dependent recipe or explicitly using 
include_recipe). If the extra cookbooks are really that much of a concern 
they can also safely be commented out in the metadata.rb file.

For those that are interested, my high level roadmap for the application 
cookbook looks like this:

* refactor all recipes into LWRPs (this will allow multiple apps on the same 
app server)
* refactor java deploy to leverage tomcat manager if available (thanks 
Edmund!)
* add ASP.MVC (and other Windows web apps) support
* add node.js support
* refactor rails deploy recipe/lwrp into more generic rack recipe/lwrp
* refactor django deploy recipe/lwrp into more generic wsgi recipe/lwrp
* add php-fpm support
* add mod_wsgi_apache2 support

I would love to add other features the community wants to see!

Seth

-- 
Opscode, Inc.
Seth Chisamore, Senior Technical Evangelist
IRC, Skype, Twitter, Github: schisamo


On Wednesday, June 29, 2011 at 10:23 AM, Haselwanter Edmund wrote:

> Hi,
> 
> On 29.06.2011, at 15:46, Tim Diggins wrote:
> > Ohai chefs!
> > 
> > Can anyone answer why the application cookbook is grouped together? It 
> > seems like it would make more sense to have a rails cookbook, a 
> > java-container (or tomcat) cookbook, a django cookbook. 
> 
> I think that depends were you want to do the "data driven" part. at the 
> moment the application coobook loops through all databag application 
> definitions and runs the recipes for that.
> > Is there no way of separating out the commonalities between them other 
> > than having them all in the same cookbook?
> 
> recently I did some rework on that. have a look at:
> 
> http://www.iteh.at/en/blog/2011/06/23/deployment-of-java-web-applications-with-chef-from-opscode/
> https://github.com/iteh/vagrant-demos/tree/master/vagrant-java-application-reworked
> 
> were I moved the recipes to definitions.
> 
> then you can do something like:
> 
> app = 
> JSON.parse(File.open(File.join(File.dirname(__FILE__),"../databags/jolokia.json")).read)
> node.run_state[:current_app] = app
> 
> application_java_webapp "jolokia-java_webapp" do
> context_cookbook "zabbix"
> end
> 
> application_tomcat "jolokia-tomcat"
> 
> node.run_state.delete(:current_app)
> 
> in ay other recipe
> 
> ------
> 
> But this is still a very good question. Were to put all the supporting 
> stuff?
> If I have a reverse proxy for tomcat, should it go in the application 
> cookbook, the apache cookbook, or the tomcat cookbook ... ?
> 
> cu edi
> 
> --
> DI Edmund Haselwanter, 
> 
 
>  
> (mailto:
 ),
>  http://edmund.haselwanter.com/
> http://www.iteh.at ;| http://facebook.com/iTeh.solutions ;| 
> http://at.linkedin.com/in/haselwanteredmund ;