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
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, edmund@haselwanter.com, http://edmund.haselwanter.com/
http://www.iteh.at | Facebook | http://at.linkedin.com/in/haselwanteredmund
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]
Sent: Wednesday, June 29, 2011 10:23 AM
To: 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/
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.commailto:edmund@haselwanter.com, http://edmund.haselwanter.com/
http://www.iteh.at | http://facebook.com/iTeh.solutions | http://at.linkedin.com/in/haselwanteredmund
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
gisthttps://gist.github.com/867960and fuller config/background at
Workflow for Chef with Vagrant | Red56 blog 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.comwrote:
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] = appapplication_java_webapp "jolokia-java_webapp" do
context_cookbook "zabbix"
endapplication_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,
http://edmund.haselwanter.com/
http://www.iteh.at | Facebook |
http://at.linkedin.com/in/haselwanteredmund
Tim Diggins
http://red56.co.uk
tim@red56.co.uk
07515 931 642 / +447515931642
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 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 recipeBut 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 ediDI Edmund Haselwanter, edmund@haselwanter.com,
http://edmund.haselwanter.com/
http://www.iteh.at | Facebook |
http://at.linkedin.com/in/haselwanteredmund
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:
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:
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-reworkedwere 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] = appapplication_java_webapp "jolokia-java_webapp" do
context_cookbook "zabbix"
endapplication_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://www.iteh.at | Facebook | http://at.linkedin.com/in/haselwanteredmund
Yes, the dependency on "irrelevant" cookbooks makes me feel somehow nervous
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.comwrote:
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: schisamoOn 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] = appapplication_java_webapp "jolokia-java_webapp" do
context_cookbook "zabbix"
endapplication_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://www.iteh.at | Facebook |
http://at.linkedin.com/in/haselwanteredmund
Tim Diggins
http://red56.co.uk
tim@red56.co.uk
07515 931 642 / +447515931642
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 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 
DI Edmund Haselwanter, edmund@haselwanter.com, http://edmund.haselwanter.com/
http://www.iteh.at | Facebook | http://at.linkedin.com/in/haselwanteredmund
Hello,
On Wed, Jun 29, 2011 at 9:15 AM, Tim Diggins 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