WEBVTT

00:00.363 --> 00:01.363
In this lecture,

00:01.531 --> 00:03.966
we will learn
about workspaces in Terraform

00:04.134 --> 00:05.327
and how to use them.

00:06.829 --> 00:09.193
Earlier in the course,
we learned about state

00:09.368 --> 00:11.817
and its use
when running Terraform operations.

00:12.935 --> 00:14.035
Whether stored locally

00:14.203 --> 00:17.525
or in remote backend
such as S3 and Terraform Cloud,

00:17.823 --> 00:20.873
state is essential
in mapping the real-world infrastructure,

00:21.033 --> 00:24.173
allowing Terraform
to model what changes it needs to apply

00:24.462 --> 00:27.112
based on the configuration
defined in the state files.

00:28.195 --> 00:31.345
Irrespective of whether the state
is stored locally or remotely,

00:31.663 --> 00:34.976
all the examples that we have seen so far
has one-to-one mapping

00:35.144 --> 00:37.844
between the configuration directory
and the state file.

00:38.835 --> 00:40.185
This means that we have had

00:40.353 --> 00:43.601
one Terraform state file
per configuration directory so far.

00:44.778 --> 00:46.078
Let us consider a scenario

00:46.246 --> 00:51.653
where we want to create an EC2 instance
in the AWS ca-central-1 region

00:51.821 --> 00:53.934
for a new project called ProjectA.

00:54.853 --> 00:58.085
This can be done by making use
of a simple configuration file

00:58.325 --> 01:00.738
in a configuration directory
called ProjectA,

01:01.175 --> 01:03.845
which is
inside the Terraform projects directory

01:04.013 --> 01:05.013
like this.

01:05.588 --> 01:08.953
If we run terraform apply now
inside this configuration directory,

01:09.289 --> 01:12.311
Terraform will create the EC2 instance
as expected.

01:12.715 --> 01:14.433
It will also create a state file.

01:14.619 --> 01:15.619
Now,

01:15.787 --> 01:18.287
what if we want to replicate
the same configuration

01:18.455 --> 01:20.689
for another project, say, ProjectB,

01:21.127 --> 01:24.936
but with a different AMI ID
and a server name as compared to ProjectA.

01:26.242 --> 01:27.492
How do we go about that?

01:28.523 --> 01:32.225
The logical way would be
to create a new directory called ProjectB,

01:32.695 --> 01:35.327
copy the configuration files
from ProjectA directory,

01:35.578 --> 01:37.952
change the AMI ID and the tags as needed,

01:38.132 --> 01:41.864
and repeat the steps that we did
for setting up the ProjectA instance.

01:42.927 --> 01:43.927
However,

01:44.130 --> 01:47.894
the goal of using Terraform
or any IaC tool for that matter

01:48.128 --> 01:52.441
is to eliminate repeatable steps
and efficiently make use of existing code

01:52.665 --> 01:54.346
as we saw in the module section.

01:55.248 --> 01:56.248
With that in mind,

01:56.416 --> 02:00.475
Terraform offers a feature that allows
configuration files within a directory

02:00.643 --> 02:03.361
to be reused multiple times
for different use cases,

02:03.604 --> 02:05.283
such as creating a ProjectA

02:05.518 --> 02:08.818
and a ProjectB environment
within the same configuration directory.

02:09.893 --> 02:11.721
This feature is called workspace.

02:12.527 --> 02:13.527
With workspaces,

02:13.695 --> 02:15.861
we can use
the same configuration directory

02:16.029 --> 02:17.945
to create
multiple infrastructure environments

02:18.113 --> 02:20.964
such as
the ProjectA and the ProjectB environment.

02:22.152 --> 02:25.589
To create a workspace,
we use the terraform workspace command.

02:26.058 --> 02:28.094
This is followed by the new subcommand

02:28.262 --> 02:30.862
and the name of the workspace
that we want to create.

02:31.700 --> 02:34.028
We will first create
the ProjectA workspace.

02:34.731 --> 02:37.040
Once the workspace is created
by this command,

02:37.275 --> 02:39.625
Terraform will immediately switch to it
as well.

02:40.416 --> 02:44.892
To list the workspace that was created,
use the terraform workspace list command.

02:45.782 --> 02:48.680
In this example,
this command lists two workspaces.

02:48.969 --> 02:52.570
The default workspace
is the one that is created by default.

02:52.865 --> 02:56.145
The new workspace that we just created
is called ProjectA

02:56.402 --> 02:58.503
and has got a star preceding it,

02:58.972 --> 03:02.022
which means that that is
the current workspace that we are on.

03:03.277 --> 03:05.299
Now that we have created workspaces,

03:05.581 --> 03:08.181
let us see
how to use it within configuration files

03:08.345 --> 03:12.269
to create EC2 instances
based on the workspace that we are in.

03:13.075 --> 03:15.137
Let us go over our requirements again.

03:15.903 --> 03:18.153
Without duplicating
the configuration files,

03:18.347 --> 03:20.208
we want to create EC2 instances

03:20.376 --> 03:23.037
for two projects
in the ca-central-1 region,

03:23.576 --> 03:26.912
ProjectA with the AMI ID ending with 279,

03:27.198 --> 03:28.791
instance type of t2.micro,

03:28.971 --> 03:30.271
and the name of ProjectA,

03:31.565 --> 03:33.854
and another instance for ProjectB

03:34.022 --> 03:35.022
with the AMI ID

03:35.190 --> 03:38.619
that ends with f4d
and the same instance type

03:38.787 --> 03:41.022
but with the name tag of ProjectB.

03:42.116 --> 03:44.716
To have a single configuration
that can achieve this,

03:44.884 --> 03:45.884
we have to update

03:46.052 --> 03:48.302
our configuration file
that we initially used.

03:49.541 --> 03:51.291
We have the variables.tf file

03:51.459 --> 03:54.162
with the variable region
set to ca-central-1.

03:55.474 --> 03:58.963
We now remove all the hard-coded values
from the main.tf file

03:59.131 --> 04:02.388
and configure them as variables
in the variable.tf file.

04:03.569 --> 04:07.349
We add an instance type
with a default value of t2.micro.

04:08.087 --> 04:11.446
We then add a new variable called AMI
of type map.

04:12.111 --> 04:14.166
Here, we have two key-value pairs.

04:14.334 --> 04:15.912
The first key is ProjectA,

04:16.080 --> 04:17.080
and to this,

04:17.248 --> 04:21.006
we have assigned a value of the AMI ID
that we want to use for ProjectA,

04:21.436 --> 04:23.116
and that ends with 279.

04:24.320 --> 04:27.273
Similarly, for the second key,
which is ProjectB,

04:27.587 --> 04:31.134
we have assigned the AMI ID
that ends with f4d.

04:32.415 --> 04:33.747
In the main.tf file,

04:33.943 --> 04:38.037
we have set the value of instance type
to use the variable called instance_type

04:38.205 --> 04:40.408
which is defined in the variables.tf file.

04:41.081 --> 04:44.092
Let us know update
the value of the AMI and the tags

04:44.260 --> 04:46.942
to make use of the values
associated with the workspace

04:47.091 --> 04:49.071
called ProjectA that we created.

04:49.945 --> 04:51.700
Let's start with the tags first.

04:51.868 --> 04:52.868
Here,

04:53.036 --> 04:55.936
we need the name of the workspace
that we are currently in,

04:56.104 --> 04:57.484
but how do we get that?

04:57.652 --> 05:00.802
How do we get the name
of the workspace that we are currently in

05:00.970 --> 05:02.470
within the configuration file?

05:03.419 --> 05:06.130
To do this,
we'll make use of terraform.workspace,

05:06.298 --> 05:09.498
which provides the value
of the current workspace that we are in.

05:10.269 --> 05:11.269
To test this,

05:11.437 --> 05:14.087
let's make use
of the terraform console command again.

05:14.315 --> 05:16.344
If we type in terraform.workspace,

05:16.512 --> 05:19.064
it should return
the workspace that we are currently in,

05:19.232 --> 05:20.892
which in this case is ProjectA.

05:21.899 --> 05:24.749
This is something we can make use of
in the main.tf file.

05:25.704 --> 05:29.617
We add this as the value [?]
with the key called Name.

05:31.074 --> 05:33.072
Next, for the AMI argument,

05:33.240 --> 05:36.690
let's use a lookup function
that we have used in the previous lecture.

05:37.208 --> 05:38.208
Remember,

05:38.376 --> 05:43.071
the lookup function is used to look up
the value of a specific key from a map.

05:44.431 --> 05:47.081
Let us make use
of the terraform console command again

05:47.249 --> 05:49.771
and test the value
that is returned by the lookup function

05:49.939 --> 05:54.738
when we use var.ami as the map
and terraform.workspace as the key.

05:56.144 --> 05:59.146
This returns the AMI ID ending with 279,

05:59.314 --> 06:01.832
which is associated
with the key called ProjectA,

06:02.000 --> 06:03.550
which is the current workspace.

06:04.295 --> 06:06.506
Now,
we can update the same lookup function

06:06.674 --> 06:10.397
as a value of our AMI argument
in the main.tf file.

06:11.327 --> 06:14.006
With that,
our configuration is now complete.

06:16.125 --> 06:17.651
If we run terraform plan now,

06:17.819 --> 06:20.914
we can see that it uses
the desired AMI and the tag

06:21.082 --> 06:24.541
for creating the instance
in the workspace called ProjectA.

06:25.440 --> 06:27.932
To create the corresponding instance
for ProjectB,

06:28.190 --> 06:31.199
all we have to do is create
a new workspace called ProjectB

06:31.367 --> 06:33.811
using the terraform workspace new command.

06:35.249 --> 06:37.949
This creates a new workspace
and also switches to it.

06:39.264 --> 06:41.600
We are now in workspace ProjectB.

06:41.957 --> 06:44.007
If we run the terraform plan command now,

06:44.175 --> 06:48.019
we can see that the AMI ID
and tag for ProjectB is applied.

06:48.676 --> 06:50.703
To switch from one workspace to another,

06:50.868 --> 06:53.906
we can make use
of the terraform workspace select command.

06:54.114 --> 06:55.114
For example,

06:55.282 --> 06:56.899
currently, we are in ProjectB,

06:57.313 --> 07:01.156
and to switch to ProjectA,
we can run the select command like this.

07:02.735 --> 07:05.535
We have now successfully used
the same configuration file

07:05.719 --> 07:08.597
to create resources
for two different projects.

07:08.973 --> 07:10.423
When we run terraform apply,

07:10.591 --> 07:13.466
it creates two different state files
for each workspace,

07:14.248 --> 07:18.313
but where does it store the state
for each of these individual workspaces?

07:19.806 --> 07:21.108
When using workspaces,

07:21.429 --> 07:24.667
instead of using
the default terraform.tfstate file

07:24.835 --> 07:26.385
in the configuration directory,

07:26.553 --> 07:28.103
Terraform stores the state file

07:28.271 --> 07:31.809
in a separate directory
called terraform.tfstate.d.

07:32.408 --> 07:33.623
Inside this directory,

07:33.791 --> 07:36.803
we can see another directory
by the name of each workspace

07:36.971 --> 07:39.771
for which we have at least completed
one terraform apply.

07:40.822 --> 07:41.922
Within this directory,

07:42.090 --> 07:44.270
there would be a terraform.tfstate file

07:44.438 --> 07:47.981
associated with the resources
created for that specific workspace.

07:49.271 --> 07:50.621
That's it for this lecture.

07:50.789 --> 07:52.693
Now, head over to the Hands-on Labs

07:52.861 --> 07:55.515
and practice working with workspaces
in Terraform.