Modules

• Basic introduction can be found here.

Problems

• As you manage your infrastructure with Terraform, you will create increasingly complex configurations. There is no intrinsic limit to the complexity of a single Terraform configuration file or directory, so it is possible to continue writing and updating your configuration files in a single directory. However, if you do, you may encounter one or more problems:

  • Understanding and navigating the configuration files will become increasingly difficult.

  • Updating the configuration will become more risky, as an update to one section may cause unintended consequences to other parts of your configuration.

  • There will be an increasing amount of duplication of similar blocks of configuration, for instance when configuring separate dev/staging/production environments, which will cause an increasing burden when updating those parts of your configuration.

  • You may wish to share parts of your configuration between projects and teams, and will quickly find that cutting and pasting blocks of configuration between projects is error prone and hard to maintain.

Solution to above problems

• Organize configuration

• Encapsulate configuration

• Reusability

• Provide consistency and ensure best practices

What is it?

• A Terraform module is a set of Terraform configuration files in a single directory. Even a simple configuration consisting of a single directory with one or more .tf files is a module.

• When you run Terraform commands directly from such a directory, it is considered the root module. So in this sense, every Terraform configuration is part of a module. You may have a simple set of Terraform configuration files such as:

      .
      ├── LICENSE
      ├── README.md
      ├── main.tf
      ├── variables.tf
      ├── outputs.tf

Calling Modules

• Terraform commands will only directly use the configuration files in one directory, which is usually the current working directory. However, your configuration can use module blocks to call modules in other directories. When Terraform encounters a module block, it loads and processes that module's configuration files.

• A module that is called by another configuration is sometimes referred to as a child module of that configuration.

Local and Remote modules

• Modules can either be loaded from the local filesystem, or a remote source. Terraform supports a variety of remote sources, including the Terraform Registry, most version control systems, HTTP URLs, and Terraform Cloud or Terraform Enterprise private module registries.

Best practices

1. Name your provider terraform-<PROVIDER>-<NAME>. You must follow this convention in order to publish to the Terraform Cloud or Terraform Enterprise module registries.

2. Start writing your configuration with modules in mind. Even for modestly complex Terraform configurations managed by a single person, you'll find the benefits of using modules outweigh the time it takes to use them properly.

3. Use local modules to organize and encapsulate your code. Even if you aren't using or publishing remote modules, organizing your configuration in terms of modules from the beginning will significantly reduce the burden of maintaining and updating your configuration as your infrastructure grows in complexity.

4. Use the public Terraform Registry to find useful modules. This way you can more quickly and confidently implement your configuration by relying on the work of others to implement common infrastructure scenarios.

5. Publish and share modules with your team. Most infrastructure is managed by a team of people, and modules are important way that teams can work together to create and maintain infrastructure. As mentioned earlier, you can publish modules either publicly or privately.

Use Modules from a registry

• Read about it here.

Build and use a local module

• Read about it here.