WEBVTT

00:01.150 --> 00:04.090
Let us now look at some of the
considerations to keep in mind

00:04.260 --> 00:06.340
while making use of provisioners.

00:07.760 --> 00:09.870
We learned how to use provisioners
in Terraform

00:10.030 --> 00:11.430
in the previous lecture.

00:12.190 --> 00:13.820
While they are great
for running tasks

00:13.990 --> 00:16.870
such as a bootstrap script
using remote exec,

00:17.210 --> 00:20.040
Terraform recommends
to use provisioners sparingly,

00:20.570 --> 00:22.760
and this is because
of a couple of reasons.

00:24.280 --> 00:25.960
Making use of provisioners

00:26.090 --> 00:28.590
increase the complexity
of the configuration,

00:29.200 --> 00:32.320
and since we can, basically, run
any system supported command

00:32.490 --> 00:34.970
within the command
or inline argument,

00:35.190 --> 00:36.460
Terraform plan has no way

00:36.630 --> 00:39.380
to accurately model
the actions of a provisioner.

00:40.360 --> 00:43.870
Secondly, as we saw in the example
of remote exec,

00:44.130 --> 00:47.530
a connection block must be defined
for some provisioners to work.

00:48.310 --> 00:51.550
This means that the network
connectivity from the local machine

00:51.730 --> 00:53.680
and the authentication
must be established

00:53.840 --> 00:55.580
before the provisioner is run.

00:55.970 --> 00:58.920
And this may not always be desirable
or feasible.

01:00.250 --> 01:01.670
In order to avoid this,

01:01.820 --> 01:03.990
Terraform recommends
to make use of provisioners

01:04.150 --> 01:05.760
that are native to the resource.

01:06.540 --> 01:09.870
We already saw an example of this
when we use user data

01:10.030 --> 01:12.730
while creating the EC2 instance
for Terraform.

01:13.710 --> 01:17.060
User data is a native feature
of AWS EC2,

01:17.630 --> 01:19.840
and it runs during
the instance launch time

01:20.000 --> 01:22.410
without having to define
the connection block.

01:23.300 --> 01:27.370
The user data argument
is specific to the AWS EC2 resource,

01:27.560 --> 01:30.280
but there are similar arguments
for other cloud providers

01:30.450 --> 01:31.850
that can be used in the same way,

01:32.020 --> 01:34.400
instead of using
the remote-exec provisioner.

01:35.510 --> 01:37.560
Some of these options
are listed here.

01:38.860 --> 01:40.060
As a best practice,

01:40.200 --> 01:41.310
it is recommended to keep

01:41.480 --> 01:43.660
the post provisioning tasks
to a minimum

01:43.810 --> 01:45.050
and build custom images

01:45.220 --> 01:47.400
that will have all
the software and configurations

01:47.570 --> 01:49.770
required for a resource, beforehand.

01:50.790 --> 01:52.790
Following the same example as before,

01:52.940 --> 01:55.130
instead of installing NGINX
during launch time,

01:55.300 --> 01:58.200
using user data
or remote-exec provisioner,

01:58.390 --> 02:01.100
make sure that we use
a custom AMI of Ubuntu

02:01.270 --> 02:03.690
which already has NGINX installed.

02:04.540 --> 02:07.350
And this is where templating tools
come into the picture.

02:07.790 --> 02:09.470
We can build custom AMIs,

02:09.630 --> 02:11.070
either from an existing instance

02:11.240 --> 02:14.080
that has all the software
and configuration installed,

02:14.320 --> 02:16.370
or make use of tools like Packer

02:16.470 --> 02:18.580
which can do this
in a declarative way.

02:19.550 --> 02:21.020
Once this image is built,

02:21.150 --> 02:23.720
we can use it to build
an AWS Instance,

02:23.940 --> 02:24.760
and this time,

02:24.920 --> 02:28.410
there is no need to use user data
for remote-exec provisioner

02:28.580 --> 02:30.020
to install NGINX.