Git + OpsWorks: Getting Organized

In OpsWorks, each “Layer” can be linked to its own repository. You can also specify a branch of your choosing. The terminology mapping between AWS, Git and Application Architecture can sometimes be a bit confusing and can lead to mal-configured OpsWorks stacks which can subsequently lead to OpsWorks being used inappropriately due to perceived technical constraints of the platform. In this post, I wanted to discuss this terminology, the mapping between the three realms (AWS, Git and Application Architecture) and how we might properly configure an Application in OpsWorks correctly.

OpsWorks Terminology

First, let’s look at how AWS OpsWorks elements map to an application’s configuration.

A common practices is to segment your AWS Account’s by Environment so you’d have separate accounts for Production, QA, Development, etc. In this setup, your AWS Account aligns with the environment your application instance resides within. An OpsWorks Stack corresponds to the application instance within this environment and an OpsWorks Layer corresponds to a configuration group.

This naming convention can be particularly confusing as often times an application’s architecture will conform to Architectural Layers that define roles and segment responsibilities for compute resources within an application. To muddle things even further, often times, these Architectural Layers conveniently correspond to the configuration required for the compute instance. Meaning, servers within a particular Architectural Layer tend to be configured the same way. However, this is not always the case. That’s why its important to recognize that the way you design your OpsWorks Layers is not as simple as creating an OpsWorks Layer for every Architectural Layer.

In more complex applications its common to see significantly different configurations within an Architectural Layer. This delineation would lead to additional OpsWorks Layers being created for each of the different configurations.

Organizing your Git Repositories

Git provides one method to store the configurations for each of the OpsWorks Layers. If an organization has segmented its environments using AWS Account as discussed above, then you will see one or more instances of an application within each Account. Which ultimately means, you will have an OpsWorks Stack for each application instance within the corresponding environment’s AWS Account.

Each OpsWorks Stack will be divided into OpsWorks Layers, which will then be assigned a Repository and Branch on the server.

Typically an organization or work group will have a single Git Server that supports multiple environments. Where the Environment fits in gets flipped.

In the above table, you can see the mapping between naming conventions for all the elements within the three realms (AWS, Application Architecture and Git).

In AWS, the Environment is the top level element, the AWS Account. So in AWS, the element hierarchy will follow the “Environment-Application-ConfigurationGroup” pattern.

In Git, the Environment is the bottom level element, the branch. So in Git, the element hierarchy will follow the “Application-ConfigurationGroup-Environment” pattern.

Above is an example mapping of the AWS OpsWorks elements to the Git elements. I’ve included blue labels to identify the example Application Architecture components.

You can see that the OpsWorks Layer for the Application’s Web Tier are all stored in a single repository. That repository has two branches that support both environments. The Application has two instances a “dev” and a “qa” instance. These instances are setup as two OpsWorks Stacks, one in the “dev” AWS Account and the other in the “qa” AWS Account.