Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
A Chef cookbook to deploy applications.
Ruby
Branch: master

README.md

Application cookbook

Build Status Gem Version Cookbook Version Coverage Gemnasium License

A Chef cookbook to deploy applications.

Getting Started

The application cookbook provides a central framework to deploy applications using Chef. Generally this will be web applications using things like Rails, Django, or NodeJS, but the framework makes no specific assumptions. The core application resource provides DSL support and helpers, but the heavy lifting is all done in specific plugins detailed below. Each deployment starts with an application resource:

application '/path/to/deploy' do
  owner 'root'
  group 'root'

  # ...
end

The application resource uses the Poise subresource system for plugins. This means you configure the steps of the deployment like normal recipe code inside the application resource, with a few special additions:

application '/path/to/deploy' do
  # Application resource properties.
  owner 'root'
  group 'root'

  # Subresources, like normal recipe code.
  package 'ruby'
  git '/path/to/deploy' do
    repository 'https://github.com/example/myapp.git'
  end
  application_rails '/path/to/deploy' do
    database 'mysql://dbhost/myapp'
  end
end

When evaluating the recipe inside the application resource, it first checks for application_#{resource}, as well as looking for an LWRP of the same name in any cookbook starting with application_. This means that a resource named application_foo can be used as foo inside the application resource:

application '/path/to/deploy' do
  owner 'root'
  group 'root'

  rails '/path/to/deploy' do
    database 'mysql://dbhost/myapp'
  end
end

Additionally if a resource inside the application block doesn't have a name, it uses the same name as the application resource itself:

application '/path/to/deploy' do
  owner 'root'
  group 'root'

  rails do
    database 'mysql://dbhost/myapp'
  end
end

Other than those two special features, the recipe code inside the application resource is processed just like any other recipe.

Available Plugins

  • application_git – Deploy application code from a git repository.
  • application_ruby – Manage Ruby deployments, such as Rails or Sinatra applications.
  • application_python – Manage Python deployments, such as Django or Flask applications.
  • application_javascriptComing soon!
  • application_javaComing soon!
  • application_goComing soon!
  • application_erlangComing soon!

Requirements

Chef 12 or newer is required.

Resources

application

The application resource has top-level configuration properties for each deployment and acts as a container for other deployment plugin resources.

application '/opt/test_sinatra' do
  git 'https://github.com/example/my_sinatra_app.git'
  bundle_install do
    deployment true
  end
  unicorn do
    port 9000
  end
end

Actions

  • :deploy – Deploy the application. (default)

Properties

  • path – Path to deploy the application to. (name attribute)
  • environment – Environment variables for all application deployment steps.
  • group – System group to deploy the application as.
  • owner – System user to deploy the application as.

Examples

Some test recipes are available as examples for common application frameworks:

Upgrading From 4.x

While the overall design of the revamped application resource is similar to the 4.x version, some changes will need to be made. The name property no longer exists, with the name attribute being used as the path to the deployment. The packages property has been removed as this is more easily handled via normal recipe code.

The SCM-related properties like repository and revision are now handled by normal plugins. If you were deploying from a private git repository you will likely want to use the application_git cookbook, otherwise just use the built-in git or svn resources as per normal.

The properties related to the deploy resource like strategy and symlinks have been removed. The deploy resource is no longer used so these aren't relevant. As a side effect of this, you'll likely want to point the upgraded deployment at a new folder or manually clean the current and shared folders from the existing folder. The pseudo-Capistrano layout used by the deploy resource has few benefits in a config-managed world and introduced a lot of complexity and moving pieces that are no longer required.

With the removal of the deploy resource, the callback properties and commands are no longer used as well. Subresources no longer use the complex actions-as-callbacks arrangement as existed before, instead following normal Chef recipe flow. Individual subresources may need to be tweaked to work with newer versions of the cookbooks they come from, though most have stayed similar in overall approach.

Database Migrations and Chef

Several of the web application deployment plugins include optional support to run database migrations from Chef. For "toy" applications where the app and database run together on a single machine, this is fine and is a nice time saver. For anything more complex I highly recommend not running database migrations from Chef. Some initial operations like creating the database and/or database user are more reasonable as they tend to be done only once and by their nature the application does not yet have users so some level of eventual consistency is more acceptable. With migrations on a production application, I encourage using Chef and the application cookbooks to handle deploying the code and writing configuration files, but use something more specific to run the actual migration task. Fabric, Capistrano, and Rundeck are all good choices for this orchestration tooling.

Migrations can generally be applied idempotently but they have unique constraints (pun definitely intended) that make them tricky in a Chef-like, convergence-based system. First and foremost is that many table alterations lock the table for updating for at least some period of time. That can mean that while staging the new code or configuration data can happen within a window, the migration itself needs to be run in careful lockstep with the rest of the deployment process (eg. moving things in and out of load balancers). Beyond that, while most web frameworks have internal idempotence checks for migrations, running the process on two servers at the same time can have unexpected effects.

Overall migrations are best thought of as a procedural step rather than a declaratively modeled piece of the system.

Sponsors

Development sponsored by Chef Software, Symonds & Son, and Orion.

The Poise test server infrastructure is sponsored by Rackspace.

License

Copyright 2015, Noah Kantrowitz

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Something went wrong with that request. Please try again.