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.
Re-usable modules are defined and structured using all of the same configuration language concepts we use in root modules. Most commonly, modules use:
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.
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.