Terraform Workspaces are used to manage your state files in different environments.
In this Terraform workspace demo I’m going to be using the files from demo.3 from the following git repo https://github.com/terraformtraining/terraform.git and using version > 0.10 of Terraform.
[markb@feddy demo.3] $ terraform -v Terraform v0.10.0
So to start off with I have the following files within my working folder.
-rw-rw-r--. 1 markb markb 246 Jul 29 12:20 deploy_website.sh -rw-rw-r--. 1 markb markb 714 Jul 29 12:21 instance.tf -rw-rw-r--. 1 markb markb 128 Jul 30 15:44 provider.tf -rw-rw-r--. 1 markb markb 101 Aug 11 13:35 terraform.tfvars -rw-rw-r--. 1 markb markb 307 Jul 30 15:44 vars.tf
This simply spins up an AWS micro instance, pushes a script to the instance that creates a websever. But say we wanted to test to see if this worked first. Well we could first create a new workspace called
dev enter this workspace and run
terraform apply this would create a completely new state file and we can safely work in this workspace without disrupting any other resources. Whenever we use Terrafrom without workspaces we are using the
default workspace as shown below.
[markb@feddy demo.3] $ terraform workspace show default
The Terraform workspaces commands are shown below.
show Show the current workspace name. list List workspaces. select Select a workspace. new Create a new workspace. delete Delete an existing workspace.
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.
├── deploy_website.sh ├── instance.tf ├── provider.tf ├── terraform.tfstate.d │ └── dev │ └── terraform.tfstate ├── terraform.tfvars └── vars.tf
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
[markb@feddy demo.3] $ terraform workspace list default dev * 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.
├── deploy_website.sh ├── instance.tf ├── provider.tf ├── terraform.tfstate.d │ ├── dev │ │ └── terraform.tfstate │ └── prod │ └── terraform.tfstate ├── terraform.tfvars └── vars.tf
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, see here for a full guide.
Don’t forget to go back into each workspace and run
terraform destroy or you may get charged by Amazon.