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
> DI Edmund Haselwanter, "> (mailto: "> ), http://edmund.haselwanter.com/
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
>
> --
Archive powered by MHonArc 2.6.16.