Interact with Terraform modules

Question 1

Where do you find and explore terraform Modules?

Answer 1

The Terraform Registry makes it simple to find and use modules.
The search query will look at module name, provider, and description
to match your search terms. On the results page, filters can be used
further refine search results.

Question 2

How do you make sure that modules have stability and compatibility?

Answer 2

By default, only verified modules are shown in search results.
Verified modules are reviewed by HashiCorp to ensure stability and
compatibility.
By using the filters, you can view unverified modules as well.

Question 3

How do you download any modules?

Answer 3

You need to add any module in the configuration file like below
module "consul" {
source = "hashicorp/consul/aws"
version = "0.1.0"
}
terraform init command will download and cache any modules referenced
by a configuration.

Question 4

What is the syntax for referencing a registry module?

Answer 4

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

Question 5

What is the syntax for referencing a private registry module?

Answer 5

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

Question 6

The terraform recommends that all modules must follow semantic versioning. Is
this true?

Answer 6

True

Question 7

What is a Terraform Module?

Answer 7

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.

Question 8

Why do we use modules for?

Answer 8

Organize configuration
Encapsulate configuration
Re-use configuration
Provide consistency and ensure best practices

https://learn.hashicorp.com/terraform/modules/modules-overview

Question 9

How do you call modules in your configuration?

Answer 9

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.

Question 10

How many ways you can load modules?

Answer 10

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.

Question 11

What are the best practices for using Modules?

Answer 11

1. 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.
2. 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
   significantlty reduce the burden of maintaining and updating your
   configuration as your infrastructure grows in complexity.
3. 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.
4. 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. We
   will see how to do this in a future guide in this series.
   https://learn.hashicorp.com/terraform/modules/modules-
   overview#module-best-practices

Question 12

What are the different source types for calling modules?

Answer 12

Local paths
Terraform Registry
GitHub
Generic Git, Mercurial repositories
Bitbucket
HTTP URLsS3 buckets
GCS buckets
https://www.terraform.io/docs/modules/sources.html

Question 13

What are the arguments you need for using modules in your configuration?

Answer 13

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

Question 14

How do you set input variables for the modules?

Answer 14

The configuration that calls a module is responsible for setting its
input values, which are passed as arguments in the module block.
Aside from source and version, most of the arguments to a module
block will set variable values.
On the Terraform registry page for the AWS VPC module, you will see
an Inputs tab that describes all of the input variables that module
supports.

Question 15

How do you access output variables from the modules?

Answer 15

You can access them by referring

module..

Question 16

Where do you put output variables in the configuration?

Answer 16

Module outputs are usually either passed to other parts of your
configuration, or defined as outputs in your root module. You will
see both uses in this guide.
Inside your configuration’s directory, outputs.tf will need to
contain

Question 17

How do you pass input variables in the configuration?

Answer 17

You can define variables.tf in the root folder
variable "vpc_name" {
description = "Name of VPC"
type
= string
default
= "example-vpc"
}
Then you can access these varibles in the configuration like thismodule "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "2.21.0"
name = var.vpc_name
cidr = var.vpc_cidr
azs
= var.vpc_azs
private_subnets = var.vpc_private_subnets
public_subnets = var.vpc_public_subnets
enable_nat_gateway = var.vpc_enable_nat_gateway
}
tags = var.vpc_tags
}

Question 18

What is the child module?

Answer 18

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

Question 19

When you use local modules you don’t have to do the command init or get every time there is a change in the local module. why?

Answer 19

When installing a local module, Terraform will instead refer directly
to the source directory.
Because of this, Terraform will automatically notice changes to local
modules without having to re-run terraform init or terraform get.

Question 20

When you use remote modules what should you do if there is a change in the module?

Answer 20

When installing a remote module, Terraform will download it into the
.terraform directory in your configuration’s root directory.
You should initialize with terraform init

Question 21

A simple configuration consisting of a single directory with one or more .tf files is a module. Is this true?

Answer 21

True

Question 22

When using a new module for the first time, you must run either terraform init or terraform get to install the module. Is this true?

Answer 22

True

Question 23

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

Answer 23

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

Question 24

What is the required argument for the module?

Answer 24

source
All modules require a source argument, which is a meta-argument
defined by Terraform CLI. Its value is either the path to a local
directory of the module’s configuration files, or a remote module
source that Terraform should download and use. This value must be a
literal string with no template sequences; arbitrary expressions are
not allowed. For more information on possible values for this
argument, see Module Sources.

Question 25

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

Answer 25

version - (Optional) A version constraint string that specifies which
versions of the referenced module are acceptable. The newest version
matching the constraint will be used. version is supported only for
modules retrieved from module registries.
providers - (Optional) A map whose keys are provider configuration
names that are expected by child module and whose values are
corresponding provider names in the calling module. This allows
provider configurations to be passed explicitly to child modules. If
not specified, the child module inherits all of the default (un-
aliased) provider configurations from the calling module.