Terraform WorkSpace – Multiple Environment

Do you manage your infrastructure using terraform? Are you duplicating your code for creating environments like DEV, STAGING, QA or PROD? Are you tired of writing/managing different codes for your different environments with several complexities? Well there is a native solution from terraform called as “TERRAFORM WORKSPACE”
Before we dive deep, let’s have a brief introduction to terraform
What is Terraform and Infrastructure as Code (IaaC)? Terraform allows you to keep your infrastructure in code form and was developed by HashiCorp. It is based on the concept of write once and runs many times and you will get your desired infrastructure in no time and same every time. If you need a change ? just change it and it will do the delta changes in infrastructure for you. In short, it can build, change/modify and manage infrastructure safely and repetitively. The language used for this is called the HashiCorp Configuration Language (HCL), you can also use JSON and moreover it is Cloud agnostic which supports almost every cloud such as Amazon Web Services, IBM Cloud (formerly Bluemix), Google Cloud Platform, DigitalOcean, Linode, Microsoft Azure, Oracle Cloud Infrastructure, OVH, or VMware vSphere as well as OpenNebula and OpenStack

What are Terraform workspaces?

The whole idea is to write code once and run for multiple  environment such as testing and production, with mostly the same setup but keeping a few variables different, like instance type, quantity, configuration, resources name etc.
Terraform workspaces allow you to maintain separate state files for the same configuration with the compatibility of the remote backend like AWS s3, helping in managing terraform state file in a shared and large team.

Let’s start with a hands-on Activity

Step 1: Clone this below terraform repo and edit remote_state.tf to set your bucket name for storing tfstate file
kapendra@opstree:~$ git clone git@gitlab.com:ashwani.singh1/workspace.git --branch development && cd workspace/

kapendra@opstree:~/workspace$ ls -l
total 56
-rw-rw-r-- 1 kapendra kapendra  129 Mar 17 15:48 dev.tfvars
-rw-rw-r-- 1 kapendra kapendra  348 Mar 17 15:48 main.tf
-rw-rw-r-- 1 kapendra kapendra  166 Mar 17 15:48 out.tf
-rw-rw-r-- 1 kapendra kapendra 3565 Mar 17 15:48 planfile
-rw-rw-r-- 1 kapendra kapendra  129 Mar 17 15:48 prod.tfvars
-rw-rw-r-- 1 kapendra kapendra   63 Mar 17 15:48 provider.tf
-rw-rw-r-- 1 kapendra kapendra  142 Mar 17 15:48 remote_state.tf
-rw-rw-r-- 1 kapendra kapendra  129 Mar 17 15:48 stag.tfvars
-rw-rw-r-- 1 kapendra kapendra  103 Mar 17 15:48 vars.tf

  • .tf files are files to provide the configuration. 
  • .tfstate  holds the last-known state of the infrastructure on S3.
  • dev.tfvars or prod.tfvars or <name>.tfvars contain values for the declared variables.
Step 2: Initialize Terraform to download the required modules
obstree@opstree:~/workspace$ terraform init
Initializing modules...

- module.bastion_host
  Getting source "../bastion_host"
- module.elastic_ip
  Getting source "../elastic_ip"

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Step 3: create your workspace e.g. dev
obstree@opstree:~/workspace$ terraform workspace new dev

Created and switched to workspace "dev"!

You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.
you may also try running commands like
  1. terraform workspace list – List available Workspaces
  2. terraform workspace select workspace_name – Select relevant Workspace
  3. terraform workspace show – Shows the selected Workspace
Step 4: Create Your Environment using environment variable file but before that try running plan.
obstree@opstree:~/workspace$ terraform plan -var-file=dev.tfvars

Plan: 2 to add, 0 to change, 0 to destroy.


Note: You didn't specify an "-out" parameter to save this plan, so Terraform
if we would have passed prod.tfvars then we would have watching prod environment spinning up in the plan. so let’s apply our code
obstree@opstree:~/workspace$ terraform apply -var-file=dev.tfvars

2 added successfully
Step5: Delete created Infra This is totally optional if want to keep your created infra then, you can skip this step
obstree@opstree:~/workspace$ terraform apply -var-file=dev.tfvars

2 destroyed successfully

Conclusion. : Terraform is evolving so fast and you need to keep eye on it to make most out of it.  terraform workspace solved our issue to maintain multiple copies for multiple environments and now developers may focus more wring reusable modules and get there desired environments by just changing variable values from specific environment single file.

  Opstree is an End to End DevOps solution provider

One thought on “Terraform WorkSpace – Multiple Environment”

  1. Hi kapendra.
    This is a good article on workspaces, however I have question about vcs_repo that we use while creating workspaces
    We have to specify a branch while creating a workspace. Thing is every team will test their code with ther own feature branches and not the one we specify in vcs_repo . so it will be pain managing this stuff as before doing anything wl first have to change the branch and then trigger terraform code. Any solution do you have or anything I am missing here?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: