Managing Multiple Environments with Terraform

Introduction

Infrastructure as a code (IAC) allows you to manage infrastructure through configuration files rather than through graphical interface. Terraform allows you to define resources and infrastructure in human readable and declarative configuration files. Terraform stores resources metadata in a state file which can be used later to update and delete those resources. Terraform is a cloud-agnostic tool which can share attributes across multiple cloud providers.

At Techify, we automate the provisioning of cloud infrastructure with terraform for our customers so they can save time on building infrastructure and can focus on developing applications.

Sometimes customers want to create multi-environment infrastructure so they can ensure the separations of application on the basis of environments such as development/QA/production.
So in the next part of this blog we will talk about managing multiple environments with Terraform.

How to Manage Multiple Environments with Terraform?

When Terraform deploys resources, it stores metadata to track the resources in a state file. So if we want to deploy resources for multiple environments such as production/QA/Staging, we need to differentiate deployment actions and state files as well. However with Terraform workspaces and Reusable modules architecture we can achieve separate environment provisioning.

  1. Terraform Workspaces- Terraform Workspaces allows us to manage separate state files for each workspace in the provided backend from a single source of configuration files
  2. Reusable Modules- In this architecture, configuration files are stored inside a single directory. With module block we can source that directory and pass the variables.

So let's go in depth & explore Terraform workspaces,

Workspace does isolate the terraform.tfstate file from other workspaces in the same backend.

Below is an architecture with some configuration files for AWS resources and backend as s3 bucket-

Right now, we have a workspace named default, which is default one and can’t be deleted ever-

workspace screenshot

Below are few commands to manage workspaces,

  1. terraform workspace list --> To list workspaces
  2. terraform workspace new --> To create a new workspace
  3. terraform workspace select --> To select appropriate workspace
  4. terraform workspace delete --> To delete workspace

I created some other workspaces. Dev & prod-

dev screenshot

In this demo, we used s3 as the backend to store state files. Configure s3 bucket, region and key in the backend block of terraform. Configure AWS cli profile, region etc. in the AWS provider block-

AWS provider block screenshot

Based on the key which is defined in the backend block, inside the bucket it will create a defined path for default workspace and env folder for workspaces-

env folder screenshot

Inside env, it will create other folders for each workspace and store the terraform.tfstate file-

terraform.tfstate file screenshot

We have below resource blocks and variables configuration. Now let’s launch an ec2 instance and security group from terraform configuration files-

EC2 configuration:
In the configuration below, we have a data block to fetch amazon linux ami id to launch the instance from that ami, and the resource block to configure launch of ec2 instance. In the resource block, we provided “${terraform.workspace}” to provide the current workspace name to the specific parameters in the specified block

EC2 configuration screenshot

Below is the configuration of the security group, it will create a security group upon below configuration-

security-ec2 screenshot

We have configured variables.tf file to expose variables and we will provide values of those variables in tfvars files. We created dev.tfvars for dev and prod.tfvars for prod workspace-

variables screenshot

Let’s deploy resources in dev workspace, Let’s switch workspace to dev workspace with command “terraform workspace select dev”, and give terraform plan to view execution plan of defined AWS resources, then apply if everything is as expected-

terraform workspace select dev screenshot

After apply completes, it will store the metadata in the state file-

state file screenshot

Let’s deploy same resource in prod workspace-

state file prod workspace screenshot

I created an output block for instance name and tags output-

output

Let’s check that output value in both workspaces-

●Dev workspace:
Dev workspace output screenshot

●Prod workspace:
Prod workspace output screenshot

So, this is the first way to manage multiple environments deployments with terraform workspaces. Now let’s look at the other method to manage multiple environments.

Reusable modules

Reusable modules architecture is based on the module block of terraform which can source directory stored “.tf” configurations and can pass variables.

In this architecture we would have one folder containing all the resource configurations files including variables and output conf files. Then we will create separate folders for dev and stage, we will define module block, provider block, backend configuration etc there.

Right now we have below configuration for ec2 and s3 creation in multiple environments from a single source of configuration files-

Reusable modules screenshot

In order to differentiate state files we need to update the backend manually
Reusable modules screenshot

Below is the ec2 configuration of modules folder-
Reusable modules screenshot

S3 configuration inside modules folder-
Reusable modules screenshot

We have below module blocks in main.tf inside dev and prod which are sourcing the path of configuration files-
Reusable modules screenshot

Referenced variables in module block are exposed in variables.tf and provided values in terraform.tfvars file in each environment’s directory-
Reusable modules screenshot

Tfvars files-
Reusable modules Tfvars files screenshot

Let’s deploy this first in the dev environment:
dev environment screenshot
dev environment screenshot

Now we deploy in Prod environment:
Prod environment screenshot
Prod environment screenshot

Conclusion:

We saw how workspaces and reusable modules help us to manage separate infrastructure from separate state files. Reusable modules function on separate directory architecture and contain module blocks, variables, provider and backend configuration etc. Where workspaces work on a single source of configuration files and creates workspace specific state files in the backend.

Techify & DevOps

Techify propels better business results with DevOps Operations through automated structures with less planning and specialists available to perform every requirement you have.
If you are looking for DevOps experts to help you with your solution, Click Here.

References

Spread the love

Leave a Reply

Your email address will not be published.Email address is required.

nineteen − eight =