Overview

This project houses the different cloud environments managed by Terraform. The modules are pulled from the Terraform Module Registry so no code lives in this project. All that you will find here are configuration values that drive the various modules.

Guidebook

Details about this project are contained in the guidebook and should be considered mandatory reading prior to contributing to the effort.

Prerequisites

working Terraform installation
working Linux installation. Testing was done on Ubuntu

Building

This project is a collection of Bash scripts and Terraform configuration files so there is nothing to build.

Installation

This project is a collection of Bash scripts and Terraform configuration files so there is nothing to install.

Tips and Tricks

Typical Work Flow

cd into the appropriate directory
edit backend.cfg to point to the S3 bucket where the current state should be stored
edit plan.tf to adjust the module's settings as desired
./initialize.sh to set up the environment. It is safe to do this more than once.
plan.sh to see see what changes will be made to resources
commit the changes, including proposed-changes.plan to source control
a peer pulls down your changes and runs ./review.sh to review the proposed changes
if the changes are accepted, run ./apply.sh to realize the proposed changes
when it comes time to dispose of the assets, run ./destroy.sh

Rates of Change

You will find that parts of your infrastructure change at different rates. For example, you can create a VPC to hold your testing resources and never change it after its creation. Other resources, such an ECS cluster, might need multiple modifications. To account for this, it is recommended to split up your resources into their own folder, based on anticipated rates of change. For example:

IAM roles and policies (global)
VPCs
Security Groups (VPC-specific)
project-specific resources (VPC-specific)

Folder Structure

The assets are divided based on the anticipated rate of change, following naming pattern: aws/account number/region/project/environment. For resources than span multiple contexts, the following conventions are used:

all-regions
all-projects
all-environments

Construction Sequence

Assuming you are starting from a clean slate, build resources from general to more specific.

aws/037083514056/all-regions/all-projects/examples/security/iam
aws/037083514056/us-east-1/all-projects/all-environments/application-services/api-gateway
aws/037083514056/us-east-1/all-projects/examples/networking/vpc
aws/037083514056/us-east-1/all-projects/examples/compute/security-groups
aws/037083514056/us-east-1/all-projects/examples/compute/load-balancer
aws/037083514056/us-east-1/ecs-sample/all-environments
aws/037083514056/us-east-1/ecs-sample/examples

jrnt30/terraform-environments