Skip to content
This repository has been archived by the owner on May 14, 2021. It is now read-only.

Latest commit

 

History

History
94 lines (69 loc) · 3.71 KB

README.md

File metadata and controls

94 lines (69 loc) · 3.71 KB

poise-appenv

Build Status

Quick Start

Attributes

In your default attributes file configure the name of the cookbook that determines your application environment:

default['poise-appenv']['cookbook'] = 'role-myapp'

Then create one attribute file for each app_environment with a header like:

include_attribute 'role-myapp'
return unless node.app_environment?('prod')

This header will prevent executing the file unless the app_environment matches the given name(s). Put any shared attributes on the default.rb file and per-app_environment attribute in the relevant file.

Recipes

The cookbook specified in node['poise-appenv']['cookbook'] is used to determine which app_environment we are in. Each recipe within the cookbook maps to an app_environment of that name, so adding role-myapp::prod to the run list will mark the node as being in the prod app_environment. If you add plain role-myapp to the run list, it will use the name of the chef_environment.

To accomplish this you need to create stub recipes like recipes/prod.rb which just include the default recipe:

include_recipe 'role-myapp'

The default recipe should contain the normal code for installing your application, generally this will be one more include_recipe to other cookbooks.

Application Environments

Application environments offer a way to have different node attributes applied via a cookbook. Combined with role or environment cookbooks this lets you separate the varying configuration of an application in different deployment scenarios from the code to install the application.

As a concrete example, imagine you have two Chef environments; prod and test. You run a cluster of servers in each environment with your application installed. Now you want to launch a new cluster in your test environment running an experimental build and divert some portion of traffic to it. You could create a new Chef environment by copying the existing test one, but almost all the settings will be the same, only the version to deploy and similar attributes need to be overridden for the new servers. Application environments give you a way to apply those customizations.

Reference

node.app_environment(cookbook=nil)

node.app_environment returns the name of the detected application environment based on the given or configured cookbook. Note that this is a method, not a node attribute.

node.app_environment?(*names)

node.app_environment? returns true if the current application environment is any of the given names.

node['poise-appenv']['cookbook']

node['poise-appenv']['cookbook'] is a node attribute used to configure which cookbook is searched for to determine the current application environment.

Why?

Why not just use Chef environments? Sometimes you want to deploy slightly different applications in the same Chef environment. An example would be launching a new branch of your code in the test environment. You could copy the Chef environment and tweak the settings you want, but this results in a lot of duplicated configuration which is error prone and difficult to update. Additionally, even though it is slightly different, this hypothetical new application cluster is still semantically in the "test" environment, and currently Chef environments don't have any kind of heirarchical relationship.