Creating Modules

What is a module? A module is a container for various resources that are clubbed to be used together. 

Modules are used in creating lightweight and effective abstractions so that one can describe the infrastructure in terms of its architecture rather than directly in physical form.

Whenever you run terraform plan or terraform apply, the documents and files of ".tf " in your given working set directory collectively form the root module. That module may call other modules to connect by passing output values of one to input values of another.

In this section, we will learn about creating re-usable modules that use configurations, including module blocks.

Module structure

Re-usable modules are defined and structured using all of the same configuration language concepts we use in root modules. Most commonly, modules use:

• Input variables for accepting the input values from the calling module.
• Output values for returning output results to the calling module can then be used to populate arguments somewhere else.
• Resources to define one or more infrastructure objects that the module will have to manage.

To describe a module, create a new directory for it and place one or even more .tf files inside just as you would do for your root module. Terraform can load modules either from local relative paths and if wanted from remote repositories; if many configurations re-use a module, you can also desire to place it in its version control repository.

Modules can also connect with other modules using a module block. Still, we recommend keeping the module tree relatively flat and easy and using module composition as an alternative to an intensely nested tree of modules. This makes the individual modules easier to re-use various combinations.

When to write a module

In principle, any and various combination of resources and other constructs can be factored and structured out into a module. Still, over-using and breaching the limits of modules can make all of the Terraform configurations even harder to understand and maintain, so we very much recommend moderation.

An impactful and effective module should raise the level of abstraction by describing a new and different concept in your architecture constructed from providers' resource types.

For example,  aws_elb  and aws_instance are the types of resources belonging to the AWS provider. But in case you also might want to use a module to represent the higher-level concept cluster executing in AWS, which may happen to be constructed from these and some other AWS provider resources.

We do not recommend writing modules that are just thin like wrappers and revolve around the concept of single and other resource types. Face trouble finding a name for your own module that isn't the same as the main resource type inside it. That may be a sign that your module is not creating any new abstraction and so the module is just adding and giving rise to unnecessary complexity. Instead, you can just infuse the resource type directly in the calling module.