Terraform 101 - Inception to Mastering Terraform - Part 4 -Terraform Workspace

In the dynamic landscape of DevOps, where speed, scalability, and reliability are paramount, selecting the right provisioning tool can make or break your infrastructure management strategy. Enter Terraform - a game-changer in the realm of infrastructure as code (IaC). But what sets Terraform apart from other provisioning tools? The answer lies in its ingenious feature: workspaces.

Understanding Terraform Workspaces

Terraform workspaces are the unsung heroes of infrastructure orchestration. They empower DevOps teams to manage multiple deployments of the same configuration with unparalleled ease and efficiency. Whether it's testing configurations, orchestrating regional deployments, or maintaining sanity in multi-account environments, Terraform workspaces offer a versatile toolkit for infrastructure management.

A Closer Look at Workspaces

When you embark on your Terraform journey, each configuration comes with an associated backend, defining how Terraform operates and stores persistent data. Initially, a single workspace reigns supreme, housing the Terraform state for that configuration. However, some backends provide support for multiple named workspaces, enabling the management of distinct configuration instances without the hassle of configuring new backends or juggling authentication credentials.

Terraform Workspaces vs. Terraform Modules: Deciphering the Dichotomy

It's essential to discern between Terraform workspaces and modules, as they serve distinct purposes in the Terraform ecosystem. While workspaces isolate state files, allowing for the management of different infrastructure sets using the same configuration, modules act as logical containers for grouping resources, enhancing reusability, and fostering code organization.

Git branches vs. Terraform workspaces

Don't get confused between branches in the version control systems with Terraform workspaces. Both have different purposes.

Git branches maintain various versioned copies of the same configuration used to develop new features or Terraform modules, whereas workspaces completely depend upon the state file maintained in the remote backend by Terraform.

It is not recommended to use feature branches for deployments in the default workspace. The table below summarizes the impact of various combinations. It assumes that:

1. The Terraform configuration is maintained in a Git repository
2. Workspaces are used to create replica sets for debugging or developmental purposes
3. The remote backend is configured for Terraform workflow

• Default workspace (main branch) - This is the desired scenario.
• Test workspace (main branch) - When we want to create a scaled-down replica of the existing environment for debugging or development purposes.
• Default workspace (feature branch) - Strict no. Feature branches may contain configurations and modules which are still under development. So deploying this using the default workspace should be avoided at all costs.
• Test workspace (feature branch) - This may not break the production but would interfere with someone else’s work in progress. Maybe consider creating a new workspace.

When working with Terraform, if workspaces are used, they take precedence over the version control strategy.

Harnessing the Power of Current Workspace Interpolation

Within your Terraform configuration, the ${terraform.workspace} interpolation sequence emerges as a potent ally. Leveraging this interpolation, you can tailor resource provisioning based on the current workspace. Whether adjusting cluster sizes or dynamically naming resources, the possibilities are endless with current workspace interpolation.

Referencing the current workspace is useful for changing behavior based on the workspace. For example, for non-default workspaces, it may be useful to spin up smaller cluster sizes. For example:

resource "aws_instance" "example" {
count = "${terraform.workspace == "default" ? 5:1}"
# ... other arguments
}        

Another popular use case is using the workspace name as part of naming or tagging behavior:

resource "aws_instance" "example" {
tags = {
  Name = "web - ${terraform.workspace}"
}
  # ... other arguments
}        

or

resource "aws_instance" "my_vm" {
 count         = terraform.workspace == "default" ? 3 : 1
 ami           = var.ami //Ubuntu AMI
 instance_type = var.instance_type
 
 tags = {
   Name = format("%s_%s_%s", var.name_tag, terraform.workspace, count.index)
 }
}        

Note: the format() function is used to concatenate multiple strings for a valid name value.

Mastering the Terraform Workspace Command

Embarking on your Terraform odyssey, you'll encounter the versatile Terraform workspace command. This command serves as your trusty companion, facilitating seamless navigation through workspaces. From listing available workspaces to creating and deleting them, the terraform workspace command equips you with the tools to traverse your infrastructure landscape effortlessly.

• Run terraform workspace show

Note: Terraform comes with a "default" workspace which you cannot delete.

• Run terraform workspace list

To be sure that no other workspaces currently exist, run the list command as shown below.

• Create a new workspace:

Once this workspace is created, terraform will automatically hold a record of it in the "environment" file inside of the ".terraform" folder.

• Delete a terraform workspace

Note: Terraform will not allow you to delete the workspace where resources are being managed.

Terraform Workspaces and State Files: A Symbiotic Relationship

As you go deeper into Terraform's intricacies, the symbiotic relationship between workspaces and state files becomes apparent. With each new workspace creation, Terraform crafts a bespoke state file, meticulously housing configuration specifics. This isolation ensures that modifications in one workspace remain insulated from others, fostering a safe environment for experimentation and validation.

When we look at the contents of the Terraform state S3 bucket, apart from our default terraform.tfstate file, we see that a new directory named “env:/” is created, within which another directory with the name of our workspace (test_ws) is created. A new terraform.tfstate file is maintained at this location.

The size of the default state file will be considerably larger than that of the custom workspace-specific state file. This shows that the new state file is created, but it does not hold any information from the default state file. This is how Terraform creates an isolated environment and maintains its state file differently.

The contents of the test_ws state file before running terraform apply are shown below:

{
  "version": 4,
  "terraform_version": "1.2.3",
  "serial": 0,
  "lineage": "c1aa5782-da15-419e-70f8-7024cadd0cfe",
  "outputs": {},
  "resources": []
}        

As a result of this, if we run the plan command in the same directory now, Terraform will consider the state file as per the selected workspace. No resources are captured or maintained in this state file, so it will propose creating a new EC2 instance.

Terraform workspaces' best practices

Introducing workspaces in terraform workflow and existing Git practices increases the risk of human error. If the is not well-educated in using workspaces and branches in conjunction, the chances of wrong infrastructure deployment or modification are high.

As we have seen before, the workspaces create a separate working directory structure to store state files. This also means that the plugins and modules are cached separately for each workspace. In the team where developers may create their workspaces to test their changes, this can cause bandwidth and space issues on the remote backend host.

The best use of the workspace is to test changes in an isolated replica of infrastructure just before the live production deployment. The whole purpose of these workspaces is to be temporary and not a solution to manage multiple staging environments since organizations usually want these environments to be strictly separate.

A few noteworthy best practices I can think of before I write an article about it:

1. Remoted backend to store state file.
2. Import existing infrastructure to different workspaces (test, dev, prod)
3. Avoid variable hardcoding to increase reusability.
4. Tagging of resources.
5. Use loops and bulti-in functions.

Terraform workspaces epitomize the marriage of simplicity and sophistication, revolutionizing the way DevOps teams orchestrate infrastructure. As you embark on your Terraform journey, remember: with great power comes great responsibility. Harness the magic of Terraform workspaces judiciously, and chart a course toward infrastructure nirvana.

Thanks for the read. Click here to check out my Terraform all-in-one GitHub repo.

Follow for the upcoming part of the Terraform learning journey.

image source