WEBVTT

00:00.820 --> 00:03.080
We now have a pretty good idea about

00:03.080 --> 00:05.080
how to get started with Terraform.

00:05.280 --> 00:07.220
We have learned how to write simple configuration

00:07.220 --> 00:09.110
files using HCL,

00:09.110 --> 00:11.110
declare and use variables,

00:11.110 --> 00:12.710
use reference expressions,

00:12.710 --> 00:14.710
and link resources together.

00:15.370 --> 00:16.170
Now

00:16.170 --> 00:18.170
let's get introduced to Terraform state

00:18.170 --> 00:20.170
and see what really happens under

00:20.170 --> 00:21.880
the hood when we run Terraform commands

00:21.880 --> 00:23.880
to provision infrastructure.

00:24.570 --> 00:26.570
Before we understand Terraform state,

00:26.570 --> 00:29.480
let us see the Terraform workflow once again.

00:30.250 --> 00:32.080
We have a configuration files

00:32.080 --> 00:35.220
in a directory called terraform-local-file.

00:36.140 --> 00:38.970
The main Terraform configuration with the resource blocks

00:38.970 --> 00:41.820
is defined in the file called main.tf.

00:42.080 --> 00:43.310
The variables used

00:43.310 --> 00:46.400
are defined inside the file called variables.tf.

00:47.250 --> 00:48.310
At this point,

00:48.310 --> 00:50.910
we do not have the local file resource created.

00:51.940 --> 00:52.570
First,

00:52.570 --> 00:54.370
we'll run the terraform init command

00:54.370 --> 00:56.370
to download the necessary plugins.

00:57.510 --> 00:58.280
Next,

00:58.280 --> 01:00.280
we can generate the execution plan

01:00.280 --> 01:02.910
by running the terraform plan command.

01:03.510 --> 01:05.140
The very first line that is

01:05.140 --> 01:06.600
printed when we run this command

01:06.600 --> 01:08.600
shows that Terraform tries to

01:08.600 --> 01:11.650
refresh the state in-memory prior to the plan.

01:12.080 --> 01:13.910
Since it's the first time we are running

01:13.910 --> 01:15.220
the terraform plan command,

01:15.220 --> 01:17.880
there will be no details related to a state printed,

01:18.050 --> 01:20.110
therefore implying that there is no state

01:20.110 --> 01:22.110
recorded at this moment in time.

01:22.620 --> 01:23.540
From this,

01:23.570 --> 01:25.400
Terraform also understands that

01:25.400 --> 01:27.540
currently there are no resources provisioned

01:27.540 --> 01:29.280
based on the configuration files,

01:29.280 --> 01:30.080
and then

01:30.080 --> 01:32.970
creates an execution plan of create.

01:34.480 --> 01:35.220
Moving on,

01:35.220 --> 01:37.220
let us now run terraform apply.

01:37.650 --> 01:39.450
This command also tries

01:39.450 --> 01:41.450
to refresh the in-memory state,

01:41.600 --> 01:44.310
finds that there is no state recorded at the moment,

01:44.450 --> 01:47.140
and then proceeds to create an execution plan.

01:47.620 --> 01:48.650
Once confirmed,

01:48.650 --> 01:51.710
Terraform creates the local file resource as expected.

01:52.140 --> 01:54.110
Terraform creates a unique ID

01:54.110 --> 01:56.370
for the resource as seen in the command output.

01:57.710 --> 01:58.770
As expected,

01:58.770 --> 02:01.080
we can see that the file has been created

02:01.080 --> 02:03.080
with the content that we provided.

02:03.570 --> 02:04.220
Now,

02:04.510 --> 02:05.620
what will happen if you

02:05.620 --> 02:07.970
run the terraform apply command again?

02:08.770 --> 02:10.540
Terraform knows that a local file

02:10.540 --> 02:12.540
resource by the name of pet

02:12.540 --> 02:14.710
and the same ID that we just saw

02:14.710 --> 02:15.970
already exists

02:15.970 --> 02:17.970
and it takes no further action.

02:17.970 --> 02:19.620
So

02:19.970 --> 02:21.280
How does Terraform know that?

02:21.740 --> 02:25.050
How does it know that the local file resource already exists?

02:25.910 --> 02:27.310
To understand that,

02:27.420 --> 02:30.820
let us check the contents of the configuration directory again.

02:31.820 --> 02:34.540
We can now see that there is an additional file

02:34.540 --> 02:37.970
called terraform.tfstate created in this directory.

02:38.800 --> 02:41.250
This file is called the terraform state file,

02:41.250 --> 02:43.250
which was created as a consequence

02:43.250 --> 02:44.880
of the terraform apply command

02:44.880 --> 02:47.420
that created the resource in the first place.

02:48.250 --> 02:49.940
This file is not created

02:49.940 --> 02:53.000
until the terraform apply command is run at least once.

02:54.220 --> 02:56.880
The state file is a JSON data structure

02:56.970 --> 02:59.600
that maps the real-world infrastructure resources

02:59.600 --> 03:02.370
to the resource definition in the configuration files.

03:03.570 --> 03:06.220
If we inspect the contents of this state file,

03:06.220 --> 03:07.910
we can see that it has the complete

03:07.910 --> 03:10.880
record of the infrastructure created by Terraform.

03:11.110 --> 03:12.370
In this case,

03:12.370 --> 03:14.250
we have a single resource

03:14.250 --> 03:15.650
of type local file

03:15.650 --> 03:17.650
and a logical name called pet.

03:18.510 --> 03:21.220
The details such as the resource ID,

03:21.220 --> 03:22.740
provider information,

03:22.740 --> 03:25.910
and all the resource attributes are stored within this file.

03:26.820 --> 03:27.680
It contains

03:27.680 --> 03:29.680
every little detail pertaining to the

03:29.680 --> 03:32.020
infrastructure that was created by Terraform,

03:32.020 --> 03:33.110
and it uses it

03:33.110 --> 03:34.820
as a single source of truth

03:34.820 --> 03:37.910
when using commands such as terraform plan and apply.

03:39.250 --> 03:42.080
If we make a change to the configuration file now,

03:42.080 --> 03:44.080
and rerun the terraform plan

03:44.080 --> 03:45.450
or apply command,

03:45.450 --> 03:48.510
Terraform by default refreshes the state again

03:48.510 --> 03:51.050
and compares it against the configuration file.

03:51.800 --> 03:55.280
It now knows that the resource argument called content

03:55.280 --> 03:57.770
has a different value in the configuration file

03:57.770 --> 04:00.710
as compared to the terraform state and the real world.

04:01.770 --> 04:04.310
The configuration value uses the string

04:04.310 --> 04:06.970
"We love pets!" for the content argument,

04:07.110 --> 04:09.250
but the state file record shows that the

04:09.250 --> 04:12.620
actual content in this file is "I love pets!"

04:13.650 --> 04:14.820
As a result,

04:14.820 --> 04:17.250
Terraform knows that the resource must be recreated

04:17.480 --> 04:19.370
and when we run terraform apply,

04:19.370 --> 04:21.370
it updates the state file as well.

04:22.220 --> 04:24.370
From the output of the apply command,

04:24.370 --> 04:26.370
we can see that the older local_file

04:26.370 --> 04:28.710
resource with the older ID is deleted

04:28.710 --> 04:30.710
and replaced with a new resource with

04:30.710 --> 04:33.650
a completely different ID with the updated content.

04:35.000 --> 04:37.970
The same can be seen in the terraform state file as well.

04:38.200 --> 04:39.540
It no longer has

04:39.540 --> 04:41.710
a reference for the older resource ID

04:41.710 --> 04:43.710
and now has the details recorded for

04:43.710 --> 04:45.200
the replaced file resource.

04:45.880 --> 04:47.420
At this point in time,

04:47.420 --> 04:48.710
the configuration file

04:48.940 --> 04:50.820
and the state file are in sync,

04:51.080 --> 04:53.340
and since they do not have any differences,

04:53.340 --> 04:55.850
there will be no changes to apply subsequently.

04:56.620 --> 04:58.420
The example we have used here

04:58.420 --> 05:00.420
contains only a single resource

05:00.510 --> 05:03.370
and the same is reflected in the terraform state file.

05:03.880 --> 05:05.480
In a real-world scenario,

05:05.480 --> 05:07.480
a terraform configuration may contain

05:07.480 --> 05:10.340
numerous resources belonging to several different providers.

05:10.880 --> 05:13.450
Irrespective of the size of the infrastructure,

05:13.600 --> 05:15.910
Terraform will always create a state file

05:15.910 --> 05:17.910
and use it to store information about

05:17.910 --> 05:20.050
the state of the infrastructure in the real world.

05:20.280 --> 05:21.940
It is non-optional.

05:22.540 --> 05:24.000
In the upcoming lectures,

05:24.050 --> 05:27.220
we will see why state is so important in Terraform.