Managing Multiple Environments with Terraform
Introduction to Managing Multiple Environments with Terraform
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.
- 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
- 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-
Below are few commands to manage workspaces,
- terraform workspace list –> To list workspaces
- terraform workspace new –> To create a new workspace
- terraform workspace select –> To select appropriate workspace
- terraform workspace delete –> To delete workspace
I created some other workspaces. Dev & prod-
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-
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-
Inside env, it will create other folders for each workspace and store the terraform.tfstate file-
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
Below is the configuration of the security group, it will create a security group upon below configuration-
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-
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-
After apply completes, it will store the metadata in the state file-
Let’s deploy same resource in prod workspace-
I created an output block for instance name and tags output-
Let’s check that output value in both workspaces-
●Dev workspace:
●Prod workspace:
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-
In order to differentiate state files we need to update the backend manually
Below is the ec2 configuration of modules folder-
S3 configuration inside modules folder-
We have below module blocks in main.tf inside dev and prod which are sourcing the path of configuration files-
Referenced variables in module block are exposed in variables.tf and provided values in terraform.tfvars file in each environment’s directory-
Tfvars files-
Let’s deploy this first in the dev environment:
Now we deploy in Prod environment:
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. Contact Now