WEBVTT

00:00.660 --> 00:05.730
In this section, we will learn
how to set up lifecycle rules in Terraform.

00:06.610 --> 00:10.020
Previously, we saw that
when Terraform updates a resource

00:10.020 --> 00:12.730
it frees the infrastructure
to be immutable,

00:12.730 --> 00:16.530
and first deletes a resource
before creating a new one

00:16.530 --> 00:18.780
with the updated configuration.

00:18.970 --> 00:20.180
For example,

00:20.180 --> 00:27.040
if we update the file permissions
on our local file resource from 777 to 700,

00:27.040 --> 00:28.930
and then run terraform apply,

00:28.930 --> 00:32.100
you would see
that the older file is deleted first

00:32.100 --> 00:34.620
and then the new file is created.

00:34.940 --> 00:39.290
Now, this may not be
a desirable approach in all cases.

00:39.290 --> 00:43.980
Sometimes you may want the updated
version of the resource to be created first

00:43.980 --> 00:46.290
before the older one is deleted,

00:46.290 --> 00:49.640
or you may not want the resource
to be deleted at all,

00:49.640 --> 00:53.540
even if there was a change made
in its local configuration.

00:53.760 --> 00:58.420
This can be achieved in Terraform
by making use of lifecycle rules.

00:59.280 --> 01:04.140
These rules make use of the same block syntax
that we have seen many times so far,

01:04.140 --> 01:08.980
and they go directly inside the resource
block whose behavior we want to change.

01:09.620 --> 01:14.490
The syntax of a resource block
with a lifecycle rule looks like this.

01:15.530 --> 01:17.260
Inside the lifecycle block,

01:17.260 --> 01:22.240
we add the rule which we want Terraform
to adhere to while updating resources.

01:22.240 --> 01:27.250
One such argument, or a rule,
is the create_before_destroy rule.

01:27.690 --> 01:31.090
Here, we have the same resource block
that has been updated

01:31.090 --> 01:35.490
with the lifecycle rule
of create_before_destroy set to true.

01:35.970 --> 01:37.650
This rule ensures that

01:37.650 --> 01:41.730
when a change in configuration
forces the resource to be recreated,

01:41.730 --> 01:46.130
a new resource is created first
before deleting the old one.

01:46.770 --> 01:53.050
Now, there would be cases where we do not want
a resource to be destroyed for any reason.

01:53.200 --> 01:57.460
For this, we can make use
of the prevent_destroy option.

01:57.820 --> 02:01.500
When it is set to true,
Terraform will reject any changes

02:01.500 --> 02:04.300
that will result
in the resource getting destroyed

02:04.300 --> 02:07.120
and display an error message like this.

02:07.420 --> 02:10.250
This is especially useful
to prevent your resources

02:10.250 --> 02:12.690
from getting accidentally deleted.

02:12.980 --> 02:18.020
For example, a database resource
such as MySQL or PostgreSQL

02:18.020 --> 02:21.800
may not be something that we want to delete
once it's provisioned.

02:22.490 --> 02:24.720
One important thing to note here is that

02:24.720 --> 02:29.500
the resource can still be destroyed if we
make use of the terraform destroy command.

02:29.970 --> 02:32.560
This rule will only prevent
resource deletion

02:32.560 --> 02:37.120
from changes that are made to
the configuration and a subsequent apply.

02:37.740 --> 02:40.450
The last argument type
that we're going to see here

02:40.450 --> 02:42.690
is the ignore changes rule.

02:42.940 --> 02:47.610
This lifecycle rule when applied
will prevent a resource from being updated

02:47.610 --> 02:52.220
based on a list of attributes
that we define within the lifecycle block.

02:53.170 --> 02:57.090
To understand this better,
let's make use of a sample EC2 instance,

02:57.090 --> 03:00.330
which is a virtual machine on the AWS cloud.

03:00.820 --> 03:04.220
This EC2 instance is to be used as a web server

03:04.220 --> 03:08.290
and can be created
with a simple resource block like this.

03:09.250 --> 03:12.960
Now, don't worry if this resource block
and the arguments look unfamiliar,

03:12.960 --> 03:17.290
we will cover it in much more detail
in the EC2 section of the course.

03:17.420 --> 03:21.170
For now, please note
that the resource called web server

03:21.170 --> 03:23.180
makes use of three arguments.

03:23.180 --> 03:28.020
The AMI and the instance type
are used to deploy a specific type of VM

03:28.020 --> 03:30.700
with a predefined specification.

03:30.700 --> 03:33.020
In this case, the values that we've chosen

03:33.020 --> 03:37.720
deploys a Ubuntu server
with one CPU and 1GB of RAM.

03:38.300 --> 03:41.820
We're also making use of a tag called Name,

03:41.820 --> 03:48.290
which has a value of ProjectA-Webserver
using the tags argument which is of type map.

03:48.730 --> 03:53.120
When we are on terraform apply,
the EC2 instance is created as expected

03:53.120 --> 03:57.560
with a tag called Name
and value of ProjectA-Webserver.

03:58.420 --> 04:01.800
Now, if changes are made
to any of these arguments,

04:01.800 --> 04:06.290
Terraform will attempt to fix it
during the next apply as expected.

04:06.290 --> 04:09.380
For example, if we modify the tag called Name

04:09.380 --> 04:12.280
and change its value
from ProjectA-Webserver

04:12.280 --> 04:14.380
to, say, ProjectB-Webserver

04:14.380 --> 04:18.600
either manually or using any other tool,
Terraform will detect this change

04:18.600 --> 04:21.860
and it will attempt to change it back
to what it was originally,

04:21.860 --> 04:24.160
which is ProjectA-Webserver.

04:24.600 --> 04:28.380
In some rare cases,
we may actually want the change in the name

04:28.380 --> 04:30.330
via any other method to be acceptable,

04:30.330 --> 04:34.580
and we want to prevent Terraform
from reverting back to the old tag.

04:35.340 --> 04:38.250
To do this,
we can make use of the lifecycle block

04:38.250 --> 04:41.280
with ignore changes argument like this.

04:41.480 --> 04:47.020
The ignore changes argument accepts a list
as indicated by the square brackets,

04:47.020 --> 04:50.090
and it will accept
any valid resource attribute.

04:50.200 --> 04:54.140
In this particular case,
we have asked Terraform to ignore changes

04:54.140 --> 04:58.340
which are made to the tags attribute
of the specific EC2 instance.

04:58.680 --> 05:02.400
If a change is made to the tags,
a subsequent terraform apply

05:02.400 --> 05:05.400
should now show that
there are no changes to apply.

05:05.560 --> 05:08.850
The change made to the tags
of a server outside of Terraform

05:08.850 --> 05:10.920
is now completely ignored.

05:11.540 --> 05:15.940
Since it's a list,
we can update more elements like this.

05:16.440 --> 05:19.970
You can also replace the list
with the All keyword.

05:19.970 --> 05:24.220
This is especially useful
if you do not want the resource to be modified

05:24.220 --> 05:27.220
for changes in any resource attributes.

05:27.770 --> 05:31.140
We will learn more about lifecycle rules
later in the course

05:31.140 --> 05:33.490
when we work with AWS resources.

05:33.490 --> 05:36.770
For now, here's a quick summary
of the three-argument types

05:36.770 --> 05:38.680
that we have seen in this lecture.

05:40.120 --> 05:42.490
Now, let's head over to the hands-on labs

05:42.490 --> 05:46.320
and practice working
with lifecycle rules in Terraform.