# Application cookbook

**URL:** <https://discourse.chef.io/t/application-cookbook/1902>\
**Category:** Chef Infra (archive)\
**Created:** [June 29, 2011, 1:46pm UTC](https://discourse.chef.io/t/application-cookbook/1902 "2011-06-29T13:46:40Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tim\_Diggins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tim_diggins/32/810_2.png) [@Tim\_Diggins](https://discourse.chef.io/u/Tim_Diggins)\
**Post date:** [June 29, 2011, 1:46pm UTC](https://discourse.chef.io/t/application-cookbook/1902/1 "2011-06-29T13:46:40Z")

</div>

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. Is there no way of separating out the  
commonalities between them other than having them all in the same cookbook?

all the best

Tim

---

<div class="post-metadata">

**Author:** ![Haselwanter\_Edmund](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/haselwanter_edmund/32/635_2.png) [@Haselwanter\_Edmund](https://discourse.chef.io/u/Haselwanter_Edmund)\
**Post date:** [June 29, 2011, 2:23pm UTC](https://discourse.chef.io/t/application-cookbook/1902/2 "2011-06-29T14:23:07Z")

</div>

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/](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](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, [edmund@haselwanter.com](mailto:edmund@haselwanter.com), [http://edmund.haselwanter.com/](http://edmund.haselwanter.com/)  
[http://www.iteh.at](http://www.iteh.at) | [Facebook](http://facebook.com/iTeh.solutions) | [http://at.linkedin.com/in/haselwanteredmund](http://at.linkedin.com/in/haselwanteredmund)

---

<div class="post-metadata">

**Author:** ![Matthew\_Drobnak](https://avatars.discourse-cdn.com/v4/letter/m/f1d935/32.png) [@Matthew\_Drobnak](https://discourse.chef.io/u/Matthew_Drobnak)\
**Post date:** [June 29, 2011, 2:34pm UTC](https://discourse.chef.io/t/application-cookbook/1902/3 "2011-06-29T14:34:41Z")

</div>

The way I'm doing it right now (based on Edmund's Tomcat LWRP and additions to application to support paths and such), is anything that can be easily deployed - ie just the war file, or just the installation of tomcat, is done using the stock stuff.

However I have an app that relies on some support files, and that is put into it's own recipe. I have found, unfortunately, that I cannot rely on the automagic install of tomcat from the application cookbook.

In an ideal world:  
Application is single war file  
Application uses a DB  
Chef is aware of DB

All you need in the run list is  
recipe[application]

But, in my case, it's now:

recipe[tomcat],  
recipe[myapp::asv], #Determines an node-specific value that is needed for the configuration template, and stores it as a node attribute...  
recipe[myapp],  
recipe[application]

So this ensures tomcat's there, so I can dump the necessary files in the tomcat directories with the myapp recipe, and then the war file is handled by the application cookbook.

Not as simple, but not that hard, either.

I think chef is absolutely worth the effort to get working right, and it'll pay off many dividends in the end...

-Matt

From: Haselwanter Edmund [[mailto:edmund@haselwanter.com](mailto:edmund@haselwanter.com)]  
Sent: Wednesday, June 29, 2011 10:23 AM  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
Subject: [chef] Re: Application cookbook

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/](http://www.iteh.at/en/blog/2011/06/23/deployment-of-java-web-applications-with-chef-from-opscode/)

> **[iteh/vagrant-demos](https://github.com/iteh/vagrant-demos/tree/master/vagrant-java-application-reworked)**
>
> Some small vagrant demo configurations. Contribute to iteh/vagrant-demos development by creating an account on GitHub.

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, [edmund@haselwanter.com](mailto:edmund@haselwanter.com)[mailto:edmund@haselwanter.com](mailto:edmund@haselwanter.com), [http://edmund.haselwanter.com/](http://edmund.haselwanter.com/)  
[http://www.iteh.at](http://www.iteh.at) | [http://facebook.com/iTeh.solutions](http://facebook.com/iTeh.solutions) | [http://at.linkedin.com/in/haselwanteredmund](http://at.linkedin.com/in/haselwanteredmund)

---

<div class="post-metadata">

**Author:** ![Tim\_Diggins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tim_diggins/32/810_2.png) [@Tim\_Diggins](https://discourse.chef.io/u/Tim_Diggins)\
**Post date:** [June 29, 2011, 2:41pm UTC](https://discourse.chef.io/t/application-cookbook/1902/4 "2011-06-29T14:41:02Z")

</div>

edi -

My main query is about whether one should have an "application" cookbook at  
all, rather than having a "django", "rails", "tomcat" cookbook, and then  
creating a specific cookbook/recipe for one's own application itself (e.g.  
my-django-app), which co-ordinates the other cookbook recipes (say python,  
django-specifics, nginx&gevent coordination, etc)

also - (slightly off topic) but instead of your vagrant/solo-specific  
version:  
app =  
JSON.parse(File.open(File.join(File.dirname( **FILE** ),"../databags/jolokia.json")).read)  
you might want to instead consider monkey-patching the data\_bag,  
data\_bag\_item and search methods (I had a stab at this before... see  
gist[https://gist.github.com/867960](https://gist.github.com/867960)and fuller config/background at  
[Workflow for Chef with Vagrant | Red56 blog](http://red56.wordpress.com/2011/03/13/chef-and-vagrant-workflow/) trying to  
make recipes sharable across vagrant + chef-solo, and chef-server/platform)

T

On Wed, Jun 29, 2011 at 3:23 PM, Haselwanter Edmund  
[edmund@haselwanter.com](mailto:edmund@haselwanter.com)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:
> 
> [\>\> eyeCatch - Ihr Partner mit Durchblick - en blog 2011 06 23 deployment-of-java-web-applications-with-chef-from-opscode](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](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, [edmund@haselwanter.com](mailto:edmund@haselwanter.com),  
> [http://edmund.haselwanter.com/](http://edmund.haselwanter.com/)  
> [http://www.iteh.at](http://www.iteh.at) | [http://facebook.com/iTeh.solutions](http://facebook.com/iTeh.solutions) |  
> [http://at.linkedin.com/in/haselwanteredmund](http://at.linkedin.com/in/haselwanteredmund)

## --

Tim Diggins  
[http://red56.co.uk](http://red56.co.uk)  
[tim@red56.co.uk](mailto:tim@red56.co.uk)

07515 931 642 / +447515931642

---

<div class="post-metadata">

**Author:** ![John\_E\_Vincent\_lusis](https://avatars.discourse-cdn.com/v4/letter/j/c89c15/32.png) [@John\_E\_Vincent\_lusis](https://discourse.chef.io/u/John_E_Vincent_lusis)\
**Post date:** [June 29, 2011, 2:43pm UTC](https://discourse.chef.io/t/application-cookbook/1902/5 "2011-06-29T14:43:01Z")

</div>

We use a modified version of some of the application cookbook ideas  
around here. Basically we have app specific cookbooks that allow us to  
override the container and container version as attributes so we can  
test our code on different containers fairly easily. There's still a  
lot of duplicated code. We need to move more of the generic stuff into  
a databag.

Waiting patiently to give Edmund's new stuff a shot.

On Wed, Jun 29, 2011 at 10:23 AM, Haselwanter Edmund  
[edmund@haselwanter.com](mailto:edmund@haselwanter.com) 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/](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](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, [edmund@haselwanter.com](mailto:edmund@haselwanter.com),  
> [http://edmund.haselwanter.com/](http://edmund.haselwanter.com/)  
> [http://www.iteh.at](http://www.iteh.at) | [Facebook](http://facebook.com/iTeh.solutions) |  
> [http://at.linkedin.com/in/haselwanteredmund](http://at.linkedin.com/in/haselwanteredmund)

---

<div class="post-metadata">

**Author:** ![Seth\_Chisamore](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/seth_chisamore/32/488_2.png) [@Seth\_Chisamore](https://discourse.chef.io/u/Seth_Chisamore)\
**Post date:** [June 29, 2011, 2:56pm UTC](https://discourse.chef.io/t/application-cookbook/1902/6 "2011-06-29T14:56:19Z")

</div>

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/](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](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, [edmund@haselwanter.com](mailto:edmund@haselwanter.com) ([mailto:edmund@haselwanter.com](mailto:edmund@haselwanter.com)), [http://edmund.haselwanter.com/](http://edmund.haselwanter.com/)  
> [http://www.iteh.at](http://www.iteh.at) | [Facebook](http://facebook.com/iTeh.solutions) | [http://at.linkedin.com/in/haselwanteredmund](http://at.linkedin.com/in/haselwanteredmund)

---

<div class="post-metadata">

**Author:** ![Tim\_Diggins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tim_diggins/32/810_2.png) [@Tim\_Diggins](https://discourse.chef.io/u/Tim_Diggins)\
**Post date:** [June 29, 2011, 3:15pm UTC](https://discourse.chef.io/t/application-cookbook/1902/7 "2011-06-29T15:15:26Z")

</div>

Yes, the dependency on "irrelevant" cookbooks makes me feel somehow nervous

- it feels somehow hacky.

Your pull-deploy-serve overview/description was very helpful. Maybe it's the  
term "application" that has been confusing me here... it's more the fact  
that chef is provisioning something which is 'deployable' (from source  
control) as opposed (in the other cases) to merely 'installable'.  
('application' services are configurable and startable, but this is true  
for the services in other cookbooks)

And I'm beginning to see why having the application configuration as node-  
and cookbook- independent, stored in databags and adjustable by multiple  
processes is powerful, but... then I query why they are in the  
git-controlled repo. Maybe instead they should be in some other versioning  
system (just as, when you're building a webapp' you source-control the  
source, but you timestamp-backup the database and assets). BTW - in some  
ways this also applies to roles (have been having this discussion with  
@lordcope, too - he may be able to express this more cogently than I can).

Tim

On Wed, Jun 29, 2011 at 3:56 PM, Seth Chisamore [schisamo@opscode.com](mailto:schisamo@opscode.com)wrote:

> 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:
> 
> [\>\> eyeCatch - Ihr Partner mit Durchblick - en blog 2011 06 23 deployment-of-java-web-applications-with-chef-from-opscode](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](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, [edmund@haselwanter.com](mailto:edmund@haselwanter.com) (mailto:  
> > [edmund@haselwanter.com](mailto:edmund@haselwanter.com)), [http://edmund.haselwanter.com/](http://edmund.haselwanter.com/)  
> > [http://www.iteh.at](http://www.iteh.at) | [http://facebook.com/iTeh.solutions](http://facebook.com/iTeh.solutions) |  
> > [http://at.linkedin.com/in/haselwanteredmund](http://at.linkedin.com/in/haselwanteredmund)

## --

Tim Diggins  
[http://red56.co.uk](http://red56.co.uk)  
[tim@red56.co.uk](mailto:tim@red56.co.uk)

07515 931 642 / +447515931642

---

<div class="post-metadata">

**Author:** ![Haselwanter\_Edmund](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/haselwanter_edmund/32/635_2.png) [@Haselwanter\_Edmund](https://discourse.chef.io/u/Haselwanter_Edmund)\
**Post date:** [June 29, 2011, 3:26pm UTC](https://discourse.chef.io/t/application-cookbook/1902/8 "2011-06-29T15:26:38Z")

</div>

On 29.06.2011, at 16:41, Tim Diggins wrote:

> edi -
> 
> My main query is about whether one should have an "application" cookbook at all, rather than having a "django", "rails", "tomcat" cookbook, and then creating a specific cookbook/recipe for one's own application itself (e.g. my-django-app), which co-ordinates the other cookbook recipes (say python, django-specifics, nginx&gevent coordination, etc)

Seth posted a nice answer to that. I too think that a more abstract data-driven concept is very powerful.

And somewhere in the mailing list archive is a thread about creating a kind of manifest for this data driven concept, but I can't find it ...

> also - (slightly off topic) but instead of your vagrant/solo-specific version:  
> app = JSON.parse(File.open(File.join(File.dirname( **FILE** ),"../databags/jolokia.json")).read)  
> you might want to instead consider monkey-patching the data\_bag, data\_bag\_item and search methods (I had a stab at this before... see gist and fuller config/background at [Workflow for Chef with Vagrant | Red56 blog](http://red56.wordpress.com/2011/03/13/chef-and-vagrant-workflow/) trying to make recipes sharable across vagrant + chef-solo, and chef-server/platform)

Oh, I do use that 🙂 This is just an easy way to move that specific "app" out of the application deployment into the zabbix recipe but still using the same data-driven description 😉

## cu edi

DI Edmund Haselwanter, [edmund@haselwanter.com](mailto:edmund@haselwanter.com), [http://edmund.haselwanter.com/](http://edmund.haselwanter.com/)  
[http://www.iteh.at](http://www.iteh.at) | [http://facebook.com/iTeh.solutions](http://facebook.com/iTeh.solutions) | [http://at.linkedin.com/in/haselwanteredmund](http://at.linkedin.com/in/haselwanteredmund)

---

<div class="post-metadata">

**Author:** ![Joshua\_Timberman](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/joshua_timberman/32/424_2.png) [@Joshua\_Timberman](https://discourse.chef.io/u/Joshua_Timberman)\
**Post date:** [July 10, 2011, 7:18am UTC](https://discourse.chef.io/t/application-cookbook/1902/9 "2011-07-10T07:18:57Z")

</div>

Hello,

On Wed, Jun 29, 2011 at 9:15 AM, Tim Diggins [tim@red56.co.uk](mailto:tim@red56.co.uk) wrote:

> Yes, the dependency on "irrelevant" cookbooks makes me feel somehow nervous
> 
> - it feels somehow hacky.

The dependencies are tightly coupled like this to ensure you get all  
the possible things you might need from various cookbooks because Chef  
(and knife) don't know what you're going to want out of a cookbook  
that provides a number of features like this application cookbook  
does. This is somewhat a side effect of the Chef Server itself being  
only a publishing service that executes no arbitrary code in cookbooks  
to determine what might be needed to distribute to clients.

--  
Opscode, Inc  
Joshua Timberman, Director of Training and Services  
IRC, Skype, Twitter, Github: jtimberman