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:
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
andproduction
Shared Terraform state
In this example, we’ll use a shared Terraform state file for all environments.
Terraform directory structure
Backend Configuration
Define a single Terraform state file using the local
backend in your main.tf
file:
Terrateam configuration file
.terrateam/config.yml
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:
To trigger an apply for the qa
environment against the aws
directory, comment:
To trigger a plan for the production
environment against the aws
directory, comment:
To trigger an apply for the production
environment against the aws
directory, comment:
Separate Terraform state
In this example, we’ll use separate Terraform state files for each environment.
Terraform directory structure
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
backend-qa.conf
backend-production.conf
Terrateam configuration file
.terrateam/config.yml
Pull request behavior
With the above configuration, when creating a new pull request with a Terraform change against the aws
directory, Terrateam will automatically trigger two plan operations: one for the qa
environment and one for the production
environment, both with their respective backend-config
and var-file
arguments.
Triggering Terrateam operations
To trigger a plan for the qa
environment against the aws
directory, comment:
To trigger a plan for the production
environment against the aws
directory, comment:
To trigger a plan for both the qa
and production
environments against the aws
directory, comment:
To trigger an apply for the qa
environment against the aws
directory, comment:
To trigger an apply for the production
environment against the aws
directory, comment:
Best practices
- Use a consistent naming convention for your directories, workspaces, and
.tfvars
files to make it easy to identify which environment they belong to. - Use tags and tag queries to target specific environments when running Terrateam operations, making it easy to manage multiple environments within a single repository.
- Consider using separate Terraform state files for each environment to reduce the risk of accidental changes affecting multiple environments.