Adoptable Cookbooks List

Looking for a cookbook to adopt? You can now see a list of cookbooks available for adoption!
List of Adoptable Cookbooks

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

Select Badges

Select Supported Platforms

Select Status

RSS

application (38) Versions 5.0.0

A Chef cookbook for deploying application code.

Policyfile
Berkshelf
Knife
cookbook 'application', '= 5.0.0', :supermarket
cookbook 'application', '= 5.0.0'
knife supermarket install application
knife supermarket download application
README
Dependencies
Changelog
Quality 100%

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_javascript – Manage server-side JavaScript deployments using Node.js or io.js.
  • 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)
  • :start - Run :start on all subresources that support it.
  • :stop - Run :stop on all subresources that support it.
  • :restart - Run :restart on all subresources that support it.
  • :reload - Run :reload on all subresources that support it.

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.
  • action_on_update – Action to run on the application resource when any subresource is updated. (default: restart)
  • action_on_update_immediately – Run the action_on_update notification with :immediately. (default: false)

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.

Application Signals and Updates

The application resource exposes start, stop, restart, and reload
actions which will dispatch to any subresources attached to the application.
This allows for generic application-level restart or reload signals that will
work with any type of deployment.

Additionally the action_on_update property is used to set a default
notification so any subresource that updates will trigger an application
restart or reload. This can be disabled by setting action_on_update false if
you want to take manual control of service restarts.

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.

Dependent cookbooks

poise ~> 2.4
poise-service ~> 1.0

Contingent cookbooks

application_buildpack Applicable Versions
application_git Applicable Versions
application_java Applicable Versions
application_javascript Applicable Versions
application_just_nodejs Applicable Versions
application_just_ruby Applicable Versions
application_mvn Applicable Versions
application_nginx Applicable Versions
application_nodejs Applicable Versions
application_php Applicable Versions
application_play Applicable Versions
application_procfile Applicable Versions
application_python Applicable Versions
application_ruby Applicable Versions
application_static Applicable Versions
application_wlp Applicable Versions
boilerplate_php Applicable Versions
cyclesafe_chef Applicable Versions
docker-registry Applicable Versions
errbit-server Applicable Versions
inwx-dns-updater Applicable Versions
ish Applicable Versions
jones Applicable Versions
nodestack Applicable Versions
phpstack Applicable Versions
postgresql_studio Applicable Versions
pythonstack Applicable Versions
rails_application Applicable Versions
seyren Applicable Versions
solr_app Applicable Versions
sugarcrm-ce Applicable Versions
variomedia-dns-updater Applicable Versions
zarafa-sabre Applicable Versions

Poise-Application Changelog

v5.0.0

  • Massive rewrite on top of newer Chef patterns. See the 5.0 README for details.

v4.1.6

  • Support for Chef 12.
  • Add strict_ssh option to enable host key checking.
  • Add keep_releases option to control number of releases to keep.
  • Allow passing a path to a file for deploy_key.

v4.1.4

  • COOK-3343 - Can't parse release candidate version number.

v4.1.2

  • COOK-3343 - Can't parse release candidate version number.

v4.1.0

  • [COOK-3343] - Can't parse release candidate version number.

v4.0.0

  • Removes compatability with Chef 10.
  • COOK-3564 - Replace calls to Chef::Mixin::RecipeDefinitionDSLCore.

v3.0.0

  • [COOK-3306]: Multiple Memory Leaks in Application Cookbook.

v2.0.4

  • [COOK-2812]: application cookbook doesn't allow to specify a block as restart_command.

v2.0.2

  • [COOK-2537]: Provide proper respond_to behavior when using method_missing.
  • [COOK-2713]: application resource should Allow sub-resource attributes to propogate up.

Improvement

  • [COOK-2597]: Allow customization for shallow_clone when doing a git deploy.

v2.0.0

This release is incompatible with previous releases (hence major version change). The recipes used in older versions are deprecated and completely removed. See README.md for further detail.

  • [COOK-1673] - deploy_revision in the application cookbook gives an argument error.
  • [COOK-1820] - Application cookbook: remove deprecated recipes.

v1.0.4

  • [COOK-1567] - Add git submodules to application cookbook.

v1.0.2

  • [COOK-1312] - string callbacks fail with method not found (really included this time).
  • [COOK-1332] - add release_path and shared_path methods.
  • [COOK-1333] - add example for running migrations.
  • [COOK-1360] - fix minor typos in README.
  • [COOK-1374] - use runit attributes in unicorn run script.

v1.0.0

This release introduces the LWRP for application deployment, as well as other improvements. The recipes will be deprecated in August 2012 as indicated by their warning messages and in the README.md.

  • [COOK-634] - Implement LWRP for application deployment.
  • [COOK-1116] - use other SCMs than git.
  • [COOK-1252] - add :force_deploy that maps to corresponding action of deploy resource.
  • [COOK-1253] - fix rollback error.
  • [COOK-1312] - string callbacks fail with method not found.
  • [COOK-1313] - implicit file based hooks aren't invoked.
  • [COOK-1318] - Create to_ary method to resolve issue in resources() lookup on "application[foo]" resources.

v0.99.14

  • [COOK-1065] - use pip in virtualenv during deploy.

v0.99.12

  • [COOK-606] application cookbook deployment recipes should use ipaddress instead of fqdn.

v0.99.11

  • make the _default chef_environment look like production rails env.

v0.99.10

  • Use Chef 0.10's node.chef_environment instead of node['app_environment'].

Foodcritic Metric
            

5.0.0 passed this metric