Terraform Modules Tutorial

Question 1

Modules help organize configuration

Answer 1

Modules make it easier to navigate, understand, and update your configuration by keeping related parts of your configuration together.

Question 2

Modules help encapsulate configuration

Answer 2

Encapsulation can help prevent unintended consequences, such as a change to one part of your configuration accidentally causing changes to other infrastructure, and reduce the chances of simple errors like using the same name for two different resources.

Question 3

Modules help you reuse configuration

Answer 3

Using modules can save time and reduce costly errors by re-using configuration written either by yourself, other members of your team, or other Terraform practitioners who have published modules for you to use.

Question 4

What is a Terraform module

Answer 4

a set of Terraform configuration files in a single directory.

a simple configuration consisting of a single directory with one or more .tf files is a module.

Question 5

what is a root module

Answer 5

When you run Terraform commands directly from a directory, it is considered the root module

Question 6

calling modules

Answer 6

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.

sometimes referred to as a “child module” of that configuration.

Question 7

Module best practices - naming

Answer 7

Name your provider terraform-PROVIDER-NAME

You must follow this convention in order to publish to the Terraform Cloud or Terraform Enterprise module registries.

Question 8

Modules Best Practice - always think modules

Answer 8

Start writing your configuration with modules in mind.

Question 9

Modules best practice - encapsulation and organization

Answer 9

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.

Question 10

When building a module consider 3 things (best practices)

Answer 10

Encapsulation: Group infra that is always deployed together

Privileges: Restrict modules to privilege boundaries. Infra in module should belong to one group.

Volatility: Separate long-lived infrastructure from short-lived.

Question 11

Guidelines for MVP (Minimum Viable Product)

Answer 11

Target 80% of use cases.

Forget the edge cases.

Avoid conditional expressions. An MVP should have a narrow focus

Minimize the number of variables.

Maximize the number of outputs.

Question 12

Nesting Modules

Answer 12

A nested module is a reference to invoke another module from the current module.

Question 13

Where do you find and explore terraform Modules?

Answer 13

The Terraform Registry makes it simple to find and use modules.

Question 14

What is the syntax for referencing a registry module?

Answer 14

NAMESPACE/NAME/PROVIDER
// for example
module "consul" {
  source = "hashicorp/consul/aws"
  version = "0.1.0"
}

Question 15

What is the syntax for referencing a private registry module?

Answer 15

HOSTNAME/NAMESPACE/NAME/PROVIDER
// for example
module "vpc" {
  source = "app.terraform.io/example_corp/vpc/aws"
  version = "0.9.3"
}

Question 16

Required argument in module blocks

Answer 16

source and version
// example
module "consul" {
  source = "hashicorp/consul/aws"
}

Question 17

How do you access output variables from a module?

Answer 17

module.MODULE_NAME.OUTPUT_NAME

Question 18

When installing the modules and where does terraform save these modules?

Answer 18

.terraform/modules
// Example
.terraform/modules
├── ec2_instances
│   └── terraform-aws-modules-terraform-aws-ec2-instance-ed6dcd9
├── modules.json
└── vpc
    └── terraform-aws-modules-terraform-aws-vpc-2417f60

Question 19

What are the other optional meta-arguments along with the source when defining modules

Answer 19

version - string, specifies version constraints for the referenced module
providers - map, keys are provider configuration names that are expected by child module and whose values are corresponding provider names in the calling module.