AWS OpsWorks
User Guide (API Version 2013-02-18)

Implementing Recipes for Chef 11.4 Stacks


Do not reuse built-in cookbook names for custom or community cookbooks. Custom cookbooks that have the same name as built-in cookbooks might fail. For a complete list of built-in cookbooks that are available with Chef 11.10, 11.4, and 0.9 stacks, see the opsworks-cookbooks repository on GitHub.

The primary limitation of Chef 11.4 stacks is that recipes cannot use Chef search or data bags. However, AWS OpsWorks Stacks installs stack configuration and deployment attributes on each instance that contain much of the information that you would obtain with search, including the following:

  • User-defined data from the console such as host or app names.

  • Stack configuration data generated by the AWS OpsWorks Stacks service, such as the stack's layers, apps, and instances, and details about each instance such as the IP address.

  • Custom JSON attributes that contain data provided by the user and can serve much the same purpose as data bags.

AWS OpsWorks Stacks installs a current version of the stack configuration and deployment attributes on each instance for each lifecycle event, prior to starting the event's Chef run. The data is available to recipes through the standard node[:attribute][:child_attribute][...] syntax. For example, the stack configuration and deployment attributes includes the stack name, node[:opsworks][:stack][:name].

The following excerpt from one of the built-in recipes obtains the stack name and uses it to create a configuration file.

template '/etc/ganglia/gmetad.conf' do source 'gmetad.conf.erb' mode '0644' variables :stack_name => node[:opsworks][:stack][:name] notifies :restart, "service[gmetad]" end

Many of the stack configuration and deployment attribute values contain multiple attributes. You must iterate over these attributes to obtain the information you need. The example below shows an excerpt from the stack configuration and deployment attributes, which are represented as JSON object for convenience. It contains a top-level attribute, deploy, which contains an attribute for each of the stack's apps, named with the app's short name.

{ ... "deploy": { "app1_shortname": { "document_root": "app1_root", "deploy_to": "deploy_directory", "application_type": "php", ... }, "app2_shortname": { "document_root": "app2_root", ... } }, ... }

Each app attribute contains a set of attributes that characterize the app. For example, the deploy_to attribute represents the app's deploy directory. The following excerpt sets the user, group, and path for each app's deploy directory.

node[:deploy].each do |application, deploy| opsworks_deploy_dir do user deploy[:user] group deploy[:group] path deploy[:deploy_to] end ... end

For more information on the stack configuration and deployment attributes, see Customizing AWS OpsWorks Stacks. For more information on deploy directories, see Deploy Recipes.

Chef 11.4 stacks do not support data bags, but you can add arbitrary data to the stack configuration and deployment attributes by specifying custom JSON. Your recipes can then access the data by using standard Chef node syntax. For more information, see Using Custom JSON.

If you need the functionality of an encrypted data bag, one option is to store sensitive attributes in a secure location such as a private Amazon S3 bucket. Your recipes can then use the AWS Ruby SDK—which is installed on all AWS OpsWorks Stacks instances—to download the data from the bucket.


Each AWS OpsWorks Stacks instance has an instance profile. The associated IAM role specifies which AWS resources can be accessed by applications that are running on the instance. For your recipes to access an Amazon S3 bucket, the role's policy must include a statement similar to the following, which grants permission to retrieve files from a specified bucket.

"Action": ["s3:GetObject"], "Effect": "Allow", "Resource": "arn:aws:s3:::yourbucketname/*",

For more information on instance profiles, see Specifying Permissions for Apps Running on EC2 instances.