Terraform Tips & Tricks, Issue 2: Registry, Locals and Workspaces

So you've probably seen our Terraform Lightning Course.

The goal of that course was to introduce you to Terraform, so that you know how it works and how to use it.

But there are many little features and nuances in day to day Terraform usage. In this bonus episodes I will show some of them.

In this issue of Terraform Tips and Tricks, I will show you 2 new Terraform features and one tip to save time on creating Terraform modules.

Let's start with the modules.

You might remember from the Terraform Lightning Course that modules allow you to reduce the duplication of your code and create re-usable sets of infrastructure components.

But what you might not know is that there is a public registry of community Terraform modules available at https://registry.terraform.io/.

You can either use these modules as it is or take inspiration from them when implementing your own corporate modules. It's also a great way to learn some of more advanced Terraform techniques.

Talking about modules, let me show you a Terraform feature that was not mentioned in the course: locals.

Locals allow you to assign the result of an expression to a re-usable parameter.

With locals you can further reduce the duplication in your code. Let's take a look at an example.

This is internal mkdev ec2 instance module.

Inside data.tf we define a number of locals.

One of them is called base_name and the value of this local is a nicely formatted string consisting of an environment, an application group and an application name.

Other locals are referencing the outputs of the remote state.

To use locals, you need to type the local keyword followed by the local name, like we do here in a security group resource. Locals are a great way to refactor your Terraform code so that it is easier to read and maintain.

Final Terraform feature I want to show you today is called "terraform workspaces".

Workspaces are simply multiple state files for the same set of Terraform templates.

There is always a default workspace when you apply your templates, but you could create more.

For example, you could create a test workspace by running terraform workspace new test command.

You could then reference the workspace name inside your templates or provide a different variables file specific to this workspace.

After you run terraform apply and verify your infrastructure, you can switch to default workspace by running

terraform workspace select default

and apply your templates once again, this time against the default workspace.

I am using the local state file here, so let's check how workspaces work behind the curtains.

There is a new directory called terraform.state.d.

Inside this directory we see a subdirectory for a custom workspace.

The workspace statefile is inside this subdirectory. Workspaces do not guarantee the proper isolation that you might want between different environments, but they are useful in certain automation scenarios.

DevOps consulting: DevOps is a cultural and technological journey. We'll be thrilled to be your guides on any part of this journey. About consulting

Here's the same article in video form for your convenience: