Application cookbooks status: Shipped!

Ohai, Chefs!

This is a follow-up to Andrea Campi’s post to the Chef user mailing

in April. We want to let everyone know the status of our application
, and
discuss the recent releases and near-term plans.

Purpose and Motivation

The main purpose of the application cookbook has always been to
provide a primitive for describing an application deployment through
data, and then abstract the details away. It takes common deployment
patterns for web application architectures like Ruby on Rails,
Python/Django or Java/Tomcat, and makes them reusable. However, as
reported in COOK-404 and
COOK-634, it wasn’t
flexible enough, and due to the way Chef tracks recipe inclusion,
multiple apps couldn’t be deployed on a single system (e.g.,
full-stack testing nodes).

The application cookbook now includes a lightweight resource/provider,
and the associated “application_*” cookbooks provide sub-resources
that can be used as parameters for pluggable ways to shape the
deployment. Each of the language-specific cookbooks implements the
sub-resource used by the “application” resource.

For example, in the “application_ruby” cookbook, each of “rails” and
"passenger_apache2" are sub-resources. While this is currently unique
to these cookbooks for now, there are other possibilities for using
this kind of primitive. All this gives cookbook authors a nice DSL for
describing their application.

The older version of the application cookbook, 0.99.14 (and earlier
versions), used recipes for doing all this from a data bag, and we
will keep these recipes for a couple more months, with plans to remove
them from the “application” cookbook in August. You can update to the
1.0.0 release and get the new LWRPs, and keep the existing use of the
recipes as is, without modification at all.


The application cookbook has been updated and released as version
1.0.0. The associated application cookbooks that provide sub-resources
have all been released to the Chef Community Site as well, at version
1.0.0 each. They are related, but not dependent and version numbers
may vary over time.

You can download them to your Chef Repository with knife, or directly
from their pages. As with all our supported cookbooks, we recommend
that you do not use the GitHub repositories directly, as those may be
in active development.


A simple example of this for Rails would start like this:

application "my_app" do
  path "/deploy/to/dir"
  repository ""
  revision "production"
  rails do
    # Rails-specific configuration
  passenger_apache2 do
    # Passenger-specific configuration

More complex examples are available:

You can also use the DSL with an existing “apps” data bag, similar to this:

app = data_bag_item(:apps, "my_app")
application app['id'] do
  path app['deploy_to']
  owner app['owner']
  group app['group']
  repository app['repository']
  reivision app['revision']
  migrate app['migrate']
  packages app['packages'].keys
  rails do
    gems app['gems'].keys
    database do
      database app['database']['name']
      username app['database']['username']
      password app['database']['password']

Upcoming Plans

The documentation for each of these cookbooks lives in their
respective’s. We are working to update these, and will also
provide more guides on usage, with a wider variety of example
applications. In the longer term, Opscode will update the fast start
guides to use the new application LWRPs instead of the existing


The code in these cookbooks has been tested for the example uses
above. We would love to hear feedback, and fix any bugs or issues that
people are running into.

If you encounter any issues with these cookbooks, please file COOK
tickets in Jira
. If you would like to
contribute improvements, please see how to contribute to Opscode

We want to keep changes to bug fixes for now, and will look at new
features later this year.

Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman