Multiple environments

When working with infrastructure as code, it’s common to have multiple environments, such as development, staging, and production. Terrateam provides several features and configuration options to help you manage multiple environments within a single Terraform repository.

Using directories and workspaces

One way to organize your Terraform code for multiple environments is to use a combination of directories and workspaces. You can create separate directories for each logical group of resources (e.g., ec2, rds) and use workspaces to represent different environments within each directory.

Here’s an example of how you can set up your Terrateam configuration file (.terrateam/config.yml) to use directories and workspaces for multiple environments:

dirs:
  ec2:
    tags: [ec2]
    workspaces:
      development:
        tags: [development]
      production:
        tags: [production]

In this example, we have an ec2 directory with two workspaces: development and production. We also assign tags to the directory and workspaces, which can be used with tag queries to target specific environments when running Terrateam commands.

Using tfvars files

Another approach to managing multiple environments is to use separate .tfvars files for each environment. You can define different variable values for each environment in their respective .tfvars files and use them when running Terrateam operations. Consider the following scenario:

A single repository named terraform with Terraform code
Two environments: qa and production

Shared Terraform state

In this example, we’ll use a shared Terraform state file for all environments.

Terraform directory structure

.
└── aws
    ├── main.tf
    ├── production.tfvars
    └── qa.tfvars

Backend Configuration

Define a single Terraform state file using the local backend in your main.tf file:

terraform {
  backend "local" {
    path = "terraform.tfstate"
  }
}

resource "null_resource" "foobar" {
}

Terrateam configuration file

.terrateam/config.yml

when_modified:
  autoplan: false
dirs:
  aws:
    create_and_select_workspace: false
    tags: [aws]
    workspaces:
      qa:
        tags: [qa]
      production:
        tags: [production]
workflows:
  - tag_query: aws qa
    plan:
      - type: init
      - type: plan
        extra_args: ["-var-file=qa.tfvars"]
  - tag_query: aws production
    plan:
      - type: init
      - type: plan
        extra_args: ["-var-file=production.tfvars"]

Pull request behavior

With the above configuration, when creating a new pull request with a Terraform change against the aws directory, Terrateam won’t take any action because autoplan is set to false.

Triggering Terrateam operations

To trigger a plan for the qa environment against the aws directory, comment:

terrateam plan aws qa

To trigger an apply for the qa environment against the aws directory, comment:

terrateam apply aws qa

To trigger a plan for the production environment against the aws directory, comment:

terrateam plan aws production

To trigger an apply for the production environment against the aws directory, comment:

terrateam apply aws production

Separate Terraform state

In this example, we’ll use separate Terraform state files for each environment.

Terraform directory structure

.
└── aws
    ├── backend-production.conf
    ├── backend-qa.conf
    ├── main.tf
    ├── production.tfvars
    └── qa.tfvars

Backend configuration

Define separate backend configuration files for each environment, which will be merged with the main.tf backend block during terraform init: main.tf

terraform {
  backend "local" {
  }
}
resource "null_resource" "foobar" {
}

backend-qa.conf

path = "qa.tfstate"

backend-production.conf

path = "production.tfstate"