WEBVTT

00:00.590 --> 00:04.660
In this lecture, we will learn
how to input existing infrastructure

00:04.740 --> 00:08.890
into the Terraform configuration
using Terraform input command.

00:10.640 --> 00:14.100
So far in this course, we have
created and managed resources

00:14.180 --> 00:15.340
using Terraform.

00:16.210 --> 00:18.600
Ideally, we would
want the provisioning,

00:18.680 --> 00:22.110
updating and deletions of all
infrastructure resources

00:22.190 --> 00:23.680
to be managed by Terraform.

00:25.120 --> 00:27.010
in real world projects,

00:27.090 --> 00:29.760
there's a big chance that
this is not always the case.

00:31.260 --> 00:34.820
For example, there may be AWS
resources that are created

00:34.900 --> 00:36.510
using the management console

00:37.140 --> 00:38.920
or other resources
that are provision

00:39.000 --> 00:41.800
using another IAC
tool such as Ansible.

00:43.770 --> 00:47.300
What if you want to bring
resources created by other methods

00:47.380 --> 00:49.100
into the control of Terraform?

00:50.450 --> 00:51.280
How do we do that?

00:52.850 --> 00:56.440
Earlier, we saw how to read
data from other resources

00:56.520 --> 00:59.280
that are not managed by the
current Terraform configuration

00:59.660 --> 01:01.900
by making use of data sources.

01:03.230 --> 01:07.020
While this helps us to make use
of the attributes of the data source,

01:07.500 --> 01:10.810
the resource itself is not
managed by Terraform at this stage.

01:12.000 --> 01:15.360
For example, here we have
a data source block

01:15.440 --> 01:19.060
which will read the attributes
of an existing AWS instance

01:19.140 --> 01:20.920
with the matching instance ID.

01:22.180 --> 01:24.410
The data source is
called "newserver,"

01:26.050 --> 01:28.810
and we are making use of an
output variable to print

01:28.890 --> 01:32.220
the value of the public IP
of this EC2 instance.

01:33.430 --> 01:36.550
In spite of this,
the actual EC2 instance

01:36.630 --> 01:40.320
with this specific instance ID
is not managed by Terraform.

01:41.230 --> 01:44.860
We cannot update or delete this
resource using Terraform commands.

01:46.300 --> 01:50.760
To bring a resource completely in the
management and control of Terraform,

01:50.840 --> 01:52.460
we have to import it.

01:52.540 --> 01:56.160
For that, we can make use of
the Terraform import command.

01:57.820 --> 02:00.800
The syntax to use this
command is as follows.

02:01.720 --> 02:04.730
The command to be used
as Terraform import.

02:05.460 --> 02:07.440
This is followed by
the resource address,

02:07.730 --> 02:11.640
which is the resource type and
the resource name separated by a dot.

02:12.860 --> 02:14.990
Following this is
the resource attribute

02:15.070 --> 02:18.810
that can uniquely identify
the resource such as the ID.

02:20.040 --> 02:23.130
Using the same example that
we use for the data source,

02:23.210 --> 02:25.480
the import command
would translate to this.

02:26.950 --> 02:28.730
It feed on this command now.

02:28.810 --> 02:32.600
Don't expect our main.tf or any
other configuration files

02:32.680 --> 02:35.710
within the directory to be updated
with the resource block,

02:35.790 --> 02:38.160
put in into this AWS instance.

02:39.120 --> 02:41.650
Instead, the first time
we run this command,

02:41.730 --> 02:43.710
we should see an
error like this.

02:45.180 --> 02:47.820
This is because Terraform
import does not update

02:47.900 --> 02:49.580
the configuration files at all.

02:50.170 --> 02:52.560
It only updates the state
file with the details

02:52.640 --> 02:54.360
of the infrastructure being imported.

02:55.610 --> 02:59.450
As of this recording and as
of Terraform version 0.13,

02:59.980 --> 03:02.000
we have to manually
write the configuration

03:02.080 --> 03:03.690
for the resource being important.

03:04.680 --> 03:07.970
In order to fix this error
and continue with the iimport,

03:08.050 --> 03:10.830
we can write an empty
resource block like this.

03:12.690 --> 03:15.510
You will notice that the blog
does not contain any arguments

03:15.590 --> 03:18.080
at this moment,
required or optional,

03:18.600 --> 03:19.950
but that's okay for now.

03:21.430 --> 03:23.080
Once that resource
block is defined,

03:23.440 --> 03:25.150
we can rerun the
iimport command,

03:25.370 --> 03:28.010
and this time it should go
through without any errors.

03:29.670 --> 03:32.620
The resource is now imported
into the Terraform state file.

03:34.150 --> 03:37.210
Next, we can complete the
resource block for the webserver 2

03:37.680 --> 03:40.760
by defining all the resource
arguments and their values.

03:42.190 --> 03:45.510
To get the values for the
arguments for this EC2 instance,

03:45.590 --> 03:48.360
we can inspect the instance
from the management console.

03:49.850 --> 03:52.780
Alternatively, since it's
already been imported,

03:53.100 --> 03:56.620
we can also inspect the state file
instead and look for the attributes.

03:57.770 --> 03:59.460
Once we have all the details,

03:59.540 --> 04:02.510
fill in the arguments in the
resource block for the webserver 2.

04:04.010 --> 04:07.930
Here, we have added the
values for AMI instance type,

04:08.010 --> 04:11.560
the key name and the security
group ID used by this instance.

04:13.180 --> 04:16.540
Once all the arguments and
the correct values have been provided,

04:16.620 --> 04:18.810
the Terraform plan
will refresh the state

04:18.890 --> 04:21.680
and understand that the EC2
instance already exists

04:21.760 --> 04:23.440
and will carry out no action.

04:25.060 --> 04:27.710
The resource is now under
the control of Terraform.

04:28.800 --> 04:32.060
Going forward, any changes to
this resource can we carry it out

04:32.140 --> 04:33.990
by updating the
configuration file,

04:34.070 --> 04:36.860
add following the Terraform
workflow off in it,

04:36.940 --> 04:37.980
plan and apply.

04:39.580 --> 04:41.670
Now let's head over
to the hands-on labs

04:41.800 --> 04:44.590
and practice working with
the Terraform import command.