Working with Terraform Workspaces

Svg Vector Icons :

Create a Free Account

Signup today to secure your 10 free lab credits. Limited time.

As you have learned in previous lessons, Terraform manages infrastructures using states and state files. By default, you always have just one state file that binds the configurations in your Terraform project with the infrastructure it defines.

\ When working in an environment with infrastructures that serve users in real-time, there is often a need to test how code behaves before shipping it to a production environment. In such cases, you need to create multiple independent environments with similar infrastructure for testing purposes.

\ For example, we want to provision similar cloud infrastructure for 2 different environments: development and production, using Terraform.

\ Normally, you can achieve this by:

\ * Creating 2 different Terraform projects. * Writing a configuration file for each project.

\ This approach not only wastes time; it also causes unnecessary code repetition. That is where Terraform workspaces come in.

\ Workspaces are isolated environments in a Terraform project that can be configured using a single file.

When you create a project, Terraform stores the state file in a workspace named "default," which is the workspace you normally work with.

\ To achieve the aim of provisioning similar infrastructure for different environments, we can use the alternative approach of using workspaces.

\ To do that, we will:

  • Create a terraform project.
  • Create a single configuration file.
  • Create multiple workspaces, one for each environment.
  • Specify the intended workspace when applying the configuration.

\ This approach saves time and is easier to manage. Since each workspace has its own state file, it provides isolation between the configurations it manages. When you are working in one workspace, you do not have to worry about the changes or configurations in another workspace. That is, we can modify the development environment without tampering with the production environment and vice versa.


Why Use Workspaces?

The purpose of a workspace is to isolate a state file for multiple environments that are using the same configuration file(s).

\ It is common practice for organizations to have different environments for developing, testing, and deploying software services. Such environments often contain similar architecture—since the reason for multiple environments is to simulate how the software will behave in a live environment. In such a scenario, the purpose of Terraform workspaces is to allow you to easily create these three independent environments using the same configuration file.

\ \

\ \


When to use Workspaces?

Workspaces are a great way to separate resources by stage and are often used in multiple environments.

If you are using the same architecture for multiple environments, such as dev, staging, and production, you can use workspaces to manage the infrastructure easily.

\ The separation of resource configuration states is really helpful when managing large deployments. Instead of working with many configuration files in different directories, you can achieve this separation using one configuration file and multiple workspaces.

\ The lab section in this lesson will give you hands-on experience and a better understanding of workspaces.


Terraform Workspace Commands

The terraform workspace command provides different parameters that allow you to create, navigate, and manage workspaces. Let’s learn about the different commands that you will use when dealing with workspaces.


Creating a New Workspace

The command for creating a new workspace in a Terraform project is terraform workspace new <workspace name>.

\ The command below will create a new workspace with the given name. The state of the workspace will be empty—since we do not have any configurations in it yet.

\ ```bash

create the workspace named "dev"

$ terraform workspace new dev

create the workspace named "uat"

$ terraform workspace new uat ```

\ Note: You cannot have two workspaces with the same name.


Listing Workspaces

You can list all existing workspaces in a Terraform project using the following command:

\ bash $ terraform workspace list

\ The command will display a list of all available workspaces—an asterisk (*) is used to identify the current workspace.


Switch Workspaces

After creating multiple workspaces, if you need to switch to a workspace other than the current one, you can use the following command: terraform workspace select <workspace-name>.

\ ```bash

assume that we are currently in the dev workspace

$ terraform workspace select uat ```

\ The CLI will switch to the uat workspace.


Show Current Workspace

If you need to know the current workspace that you’re working in, you can use the following command:

\ bash $ terraform workspace show

\ This command will output the current workspace.


Deleting a workspace

The command to delete a workspace is:

\ bash $ terraform workspace delete <workspace-name>

\ There are a few conditions that need to be fulfilled before Terraform can delete a workspace.

  • You cannot delete your current.
  • The given workspace must already exist.
  • The state file of the workspace must be empty.

Lab Time!

Let's get some hands-on experience with workspaces. In this lab, you will create multiple Terraform workspaces, navigate through workspaces, and modify each workspace independently. Let's get started!


Create a Working Directory

You will use the same directory and file for all the steps in this lab. Create the directory now. Then, create the file in the folder and include the following code:

\ ```bash terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 4.0" } } }

provider "aws" { profile = "default" region = "us-west-2" } ```


Start the Lab

If you are using the Skillmix Labs engine, you can start the lab following the steps below. If you’re using your own environment, you can skip this step.

\ * Click on the “Lab is offline” button on the top right of the page. * Click on the Start Lab button when the sidebar opens. * Wait for all the credentials to appear.

\ \

\ \

Configure the AWS CLI profile

Once the lab credentials are prepared, make sure AWS CLI is installed before configuring the AWS CLI profile.

The following is how you can configure the AWS CLI profile on various operating systems:

\ Linux/Mac: open this file with a text editor ~/.aws/credentials

Windows: open this file with a text editor credentials.

Alternatively: Manually locate the .aws folder on your computer, then navigate to the "credentials" file and open it in a text editor.

\ ```json

...other profiles



aws_secret_access_key= ```

\ Remember to replace <lab access key> and <lab secret key> with the access key and secret key you get from the “Lab Environment” you started above.


Create the Workspaces

You will create three workspaces:

  • dev
  • staging, and
  • production

\ On your CLI, run the following command, one after the other, to create the three workspaces:

\ ```bash

Create a "dev" workspace

$ terraform workspace new dev

Create a "staging" workspace

$ terraform workspace new staging

Create a "production" workspace

$ terraform workspace new production ```

\ When you create a new workspace, Terraform automatically switches to the new workspace. After creating the 3 workspaces type:

\ bash $ terraform workspace list

\ You’ll see the list of workspace you now have in your project. Remember, the workspace denoted with an asterisk (*) is the workspace you're currently working in.

\ Additionally, you can run terraform show to specifically view your current workspace.

\ Notice that as soon as you create the workspace, Terraform creates a new terraform.tfstate.d folder in the project directory. This folder contains subfolders with the name of your workspaces. The state file for each workspace is stored independently in these folders.

\ \

\ \

Create a VPC

Since the aim of this lab is to experience Terraform workspaces in action, you will create a simple resource, a virtual private network (VPC). Append the code below to you r file and save it.

\ ```json

Store the name of the workspace in a local

locals { vpc_name = "${terraform.workspace}-vpc" }

Create the VPC

resource "aws_vpc" "main" { cidr_block = "" tags = { Name = "local.vpc_name" } } ```

\ Code Review

The locals block allows you to tap into the name of the workspace that provisions the instance, thereby allowing you to differentiate between each environment by denoting the name as dev-vpc, staging-vpc, or production-vpc.

\ Next, you will create the variable files to define the variables you used in the code above.


Create Variable Files

Since you are working across three independent environments (dev, staging, and production) using a single configuration file, best practice demands that you don't hard-code the values of your resources. Hence, you will declare them through variables.

\ 1. Create a file and declare the region variable. 2. Add the following code to the file and save it.


json variable "region" { type = string }


Set Variable Values

There are different ways you can set the value of the variables through the -var flag on the command line. But, to keep your variable values secure (when setting sensitive credentials) and organized, we will use variable (.tfvars) files.

\ Create three variable files:

  • dev.tfvars
  • staging.tfvars
  • production.tfvars


Tip: use this command: touch dev,tfvars staginig,tfvars vars

\ In each of the variable files above, you will make the value of the region variable different by environment. This will help you differentiate between the dev, staging, and production environments when inspecting through the AWS console.

\ Open the dev.tfvars file and input the following code:

\ json region = "us-west-2"

\ Input the following code in the staging.tfvars file:

\ json region = "us-east-1"

\ And finally, in the production.tfvars file, input the following code:

\ json region = "us-west-1"

\ Ensure that you save each of the files.


Create the VPC

Now, you will apply the configuration to the dev workspace and observe how it affects others.

\ On the CLI, run:

\ bash $ terraform workspace show

\ To see your current workspace. If it's not the dev workspace, run:

\ bash $ terraform workspace select dev

\ Initialize Terraform by running:

\ bash $ terraform init

\ Running terraform plan will prompt you to enter a value for the region variable on the CLI. We do not want to do this, so, skip it.

\ Notice that the dev workspace now has a terraform.tfstate file.

\ \

\ \ Inspect the staging and production state folders and you’ll see that they are still empty—since we have not created a resource in them yet.


Apply Configuration

Now, you will create the VPC resources in the dev environment only. To do that, we will inform terraform to use the dev workspace variable file:

\ bash $ terraform apply -var-file dev.tfvars

\ Type yes on the prompt and Terraform will create the resources on AWS.


Inspect the AWS environment

After the successful creation of the resources, it's time to head over to your AWS console and check if the VPC you created is there.

\ * Navigate to your VPC dashboard from the AWS console. * Click on VPC. * Remember that in your dev workspace variable file (dev.tfvars), the region you specified is us-west-2.

\ \

\ \ Ensure that your AWS is in the right region. You should see the VPC instance with the name "dev-vpc"

\ \

\ \ Change your AWS region to us-west-1, then us-east-1, you should not find any VPC instances there.

\ This is possible because, even though the 3 environments are making use of the same configuration file, the workspaces store their state file independently.

\ You can create another resource in a different workspace and inspect your AWS environment by switching across the regions.


Migrate State Files to a Remote Backend

You have successfully created and explored terraform workspace. Now, you will migrate the workspace state file to a remote backend to explore the workspace state files in remote S3 storage.


Manually Create a S3 Bucket for the Remote Backends

You can create the S3 bucket using Terraform, but you must not create it in the same project as the backend you want to store in it.

\ To avoid confusion and to make it easier, you will create the S3 bucket manually.

\ Navigate to the S3 dashboard from the AWS console and manually create a new S3 bucket in your preferred availability zone.

\ Note the bucket name you use in this step because you will use it in the subsequent step.


Update The Configuration File with the Remote Backend

After creating an S3 bucket, you will update your Terraform configuration file to use a remote backend. Open your and include the backend resource block.

\ ```json

...other code above

terraform { backend "s3" { bucket = "my-workspace-state-bucket" key = "path/to/my/workspace_state.tfstate" region = "us-west-2" } } ```

\ Replace "my-workspace-state-bucket" with the name of the S3 bucket you created.

\ You can use any key name you desire, but we recommend that you keep it descriptive as above.

Save the file.


Migrate to the Remote Backend

Next, use the Terraform CLI commands to migrate the local state file to the remote S3 repository.

\ * Run terraform init * Enter yes to the prompt * Run terraform plan, then terraform apply to successfully migrate the local backend to the remote S3 bucket.


Explore the Remote Backend

Head over to your AWS console to inspect the S3 bucket. You should find a new object in your S3 bucket in the directory you defined in the key argument of the backend block (path/to/my/workspace_state.tfstate). When you navigate through the folder, you'll find the state files of our Terraform project in a similar hierarchy to want we have in the local directory.


Delete Resources

Once you complete this lab, run terraform destroy to remove all the resources you created.

Svg Vector Icons :

Create a Free Account

Signup today to secure your 10 free lab credits. Limited time.