Slide 1
Most trusted JOB oriented professional program
DevOps Certified Professional (DCP)

Take your first step into the world of DevOps with this course, which will help you to learn about the methodologies and tools used to develop, deploy, and operate high-quality software.

Slide 2
DevOps to DevSecOps – Learn the evolution
DevSecOps Certified Professional (DSOCP)

Learn to automate security into a fast-paced DevOps environment using various open-source tools and scripts.

Slide 2
Get certified in the new tech skill to rule the industry
Site Reliability Engineering (SRE) Certified Professional

A method of measuring and achieving reliability through engineering and operations work – developed by Google to manage services.

Slide 2
Master the art of DevOps
Master in DevOps Engineering (MDE)

Get enrolled for the most advanced and only course in the WORLD which can make you an expert and proficient Architect in DevOps, DevSecOps and Site Reliability Engineering (SRE) principles together.

Slide 2
Gain expertise and certified yourself
Azure DevOps Solutions Expert

Learn about the DevOps services available on Azure and how you can use them to make your workflow more efficient.

Slide 3
Learn and get certified
AWS Certified DevOps Professional

Learn about the DevOps services offered by AWS and how you can use them to make your workflow more efficient.

previous arrow
next arrow

Terraform workspace explained!!!

Spread the Knowledge

What is Terraform workspace?

Have you worked with terraform workflow? such as terraform init/plan/apply/destroy with terraform configuration file? If Yes, you already have worked with Terraform workspace. YES. Thats a default workspace which you always been working with.

It allows you to create different and independent states on the same configuration. And as it’s compatible with remote backend this workspaces are shared with your team.

Each Terraform configuration has an associated backend that defines how operations are executed and where persistent data such as the Terraform state are stored.

The persistent data stored in the backend belongs to a workspace. Initially the backend has only one workspace, called “default”, and thus there is only one Terraform state associated with that configuration.

Certain backends support multiple named workspaces, allowing multiple states to be associated with a single configuration.

Multiple workspaces are currently supported by the following backends:

  • AzureRM
  • Consul
  • GCS
  • Local
  • Manta
  • Postgres
  • Remote
  • S3

In the 0.9 line of Terraform releases, this concept was known as “environment”. It was renamed in 0.10 based on feedback to workspace.

Terraform starts with a single workspace named “default”. This workspace is special both because it is the default and also because it cannot ever be deleted. If you’ve never explicitly used workspaces, then you’ve only ever worked on the “default” workspace

There are a couple of advantages to using Workspaces:

  • They are defined by Hashicorp, so it’s possible that improved features could be developed in the future
  • They reduce the usage of code

However, Workspaces also present a couple of challenges:

  • They are still an early implementation
  • They are not yet supported by all backends
  • It is not clear at the time of deployment (terraform apply) which workspace will be used (terraform workspace show)

Working with Terraform workspace?

$ terraform -help workspace
Usage: terraform workspace

  New, list, show, select and delete Terraform workspaces.

    delete    Delete a workspace
    list      List Workspaces
    new       Create a new workspace
    select    Select a workspace
    show      Show the name of the current workspace

Demo Code –

So lets create a new dev workspace by running terraform workspace new dev and then run terraform apply. As we can see below instead of creating a terraform.tfstate file in the working folder Terraform created a new folder called terraform.tfstate.d/dev and places the state file within that.

├── terraform.tfstate.d
│   └── dev
│       └── terraform.tfstate
├── terraform.tfvars

Ok so our webserver is now up and we are happy with the results, lets create and switch to a prod workspace. So we run terraform workspace new prod. This automatically places us in the prod workspace.

$ terraform workspace list
* prod

Now lets run terraform apply again. Note if we were not using a different workspace Terraform would say no changes were needed as the remote and local state would match.

├── terraform.tfstate.d
│   ├── dev
│   │   └── terraform.tfstate
│   └── prod
│       └── terraform.tfstate
├── terraform.tfvars

And now we have a prod folder with a new state file. So as we can see above we can use Terraform workspaces to manage differences between development, staging, and production.

You can also backup the remote state of each workspace to S3

# Backend configuration is loaded early so we can't use variables
terraform {
  backend "s3" {
    region = "eu-central-1"
    bucket = ""
    key = "state.tfstate"
    encrypt = true    #AES-256 encryption

Create workspaces:

$ terraform workspace new dev
Created and switched to workspace 'dev'
$ terraform workspace new preprod
Created and switched to workspace 'preprod'
$ terraform workspace new prod
Created and switched to workspace 'prod'

Select the dev workspace:

$ terraform workspace select dev

List workspaces:

$ terraform workspace list
* dev

With this workspace configuration, when a terraform apply is successfully executed, your tfstate will be now stored in the good environment folder in the s3 bucket:
Rajesh Kumar