In this section, we will learn what modules are and
how to use them within our terraform configuration.
While progressing through the course you'd have
noticed that our terraform configuration files have become increasingly
long.
We started off with resources such as the local file
and the random pet to begin with but since
the beginning of the AWS section, we have been deploying.
I am rules policies S3 buckets
dynamodb tables and easy to instances
to name a few.
For example the resource blocks that
we see here have the definition for two easy to instances
a key pair a security group and a
dynamodb database.
The two ec2 instances can be quite similar with
much of their code being duplicated between the two configuration
blocks.
When dealing with large infrastructure projects with hundreds
of resources, we can still opt to write the configuration
with an a single file like this terraform does
not impose any limit on the number of resources per
configuration file. However, this would mean
that our configuration file will contain hundreds to
thousands of lines of code within no time.
Alternatively, we can also split the configuration into
multiple files within the configuration directory and
things will work the same way.
We saw earlier that terraform will consider every
file within the configuration directory as a configuration file
as long as it has the dot DF extension.
While this would organize arter from code a
bit better as compared to writing it all in a single configuration
file. There are still a lot of disadvantages in
following this approach when implementing terraform
For starters, it does not fix the complexity of
the code that is written within the configuration directory or
the problem of duplication.
Due to the complexity of the configuration. It also
becomes increasingly difficult to update a resource.
Updates to one part of the configuration can have
unintended effects on other resources.
And finally this configuration severely limits the reusability.
If you want to share a part of this code with
a teammate for instance, the only plausible way would
be to copy and paste the relevant part of the code, which can
be prone to errors.
These problems can be addressed by making use of modules
in terraform.
Funnily enough module Is Not A New Concept and it
is something that we have been using all throughout this course.
Any configuration directory containing a set of configuration files
is called a module.
For example, let us consider a configuration directory called
AWS instance in our local machine.
This directory is created under slash root terraform projects.
This directory has terraform configuration files that
is used to create a simple ec2 instance in the
AWS Cloud as shown here.
Since this directory has the terraform configuration files. It is
also a module.
If we directly run Tera from commands from within
this directory as we've been doing so far this directory
is considered to be the root module.
But how does this address the issues that we
just discussed?
Let us consider a use case where we want to make use of
the quote written inside AWS instance directory
to create a new development web server instance.
For this let us create a new directory called development within
the terraform projects directory.
Now instead of writing the configuration for
creating the dev AWS instance from scratch or copy
and paste the code. We can use a module block
to use the code, which is already inside the AWS instance
directory.
To do this inside the development directory create
a configuration file containing a module block like
this.
Within this module block, we can provide the path
to the local AWS instance directory which contains
the actual terraform configuration to create the ec2
instance.
Since our configuration directory where we will be running terraform
commands is now the development directory. It becomes
the root module and the AWS instance directory
that we are calling from within our main.tf file
is considered to be the child module.
Let us inspect the syntax of the module block closely.
We use the module keyword followed by The Logical name
of the module. In this case. We have called it Dev
web server.
Inside the module block. We have one required argument, which
is the source.
This is the path where the child module is stored.
Make a note that in this example the path for the child
module is specified as a relative path with respect to
the configuration directory or the root module which in
this case is the development directory.
This could also have been the absolute part to
the child module. We just happen to be using the relative part
in this example.
In this case the child module which is the directory called
AWS instance is located under the terraform projects
directory just like our configuration directory.
This part can be defined as a relative path from
the development directory by making use of two dots followed
by the directory name, which is AWS instance.
The Source path for the module can hence be declared as
dot dot slash AWS instance
Well, that's it for this lecture in the upcoming lecture.
We'll learn how to create our own module and use
it within terraform.