// The Most Flexible IaC Platform

Terraform

Modules Cheatsheet
Modules are the building blocks for achieving more complex infrastructure,
making your code reusable

A reusable collection of Terraform resources defined together and managed as a group

You can think of modules as blueprint
Whenever you are adding a new module to a configuration, you have to run terraform init in order to create the .terraform directory and the .terraform.lock.hcl file;
this will download the module (even for local sources) and the required providers, setting also the versions in the lock file
All variables defined inside a module become parameters of the child objects created for that module (some of them will have default values, so you won’t be
required to specify them)

Supported Modules Sources

The source argument inside of the module block tells Terraform from which location it can get the module cod
The version argument inside the module block should be used with module registries

Local Source

Uses a path to a folder containing the configuration of the module

module "module1" {

source = "./module1"

Terraform registry

The module name should be referenced in the following form: <NAMESPACE>/<NAME>/<PROVIDER>

module "ec2-instance" {

source = "terraform-aws-modules/ec2-instance/aws"

version = "4.3.0"

Spacelift Registry

The name of the module should be referenced in the following form spacelift.io/<organization>/<module_name>/<provider>

module "module1" {

source = "spacelift.io/spacelift-io/module1/aws"

version = "1.0.1"

GitHub

Unprefixed github.com urls will be recognized by Terrafor

Similarly, the same is true for [email protected]

# HTTP

module "ec2_http" {

source = "github.com/user/ec2"

# SSH

module "ec2_ssh" {

source = "[email protected]:user/ec2.git"

BitBucket

Unprefixed bitbucket.org urls will be recognized by Terraform

module "module1" {

source = "bitbucket.org/user/module1"

HTTP

Terraform sends a GET request and gets the module from the http/https ur
Archives can also be used (supported types: zip, tar.bz2, tar.gz, tar.xz)

module "module1" {
module "module1" {

source = "https://example.com/modules/module1"
source = "https://example.com/module1?archive=zip"

} }

Generic Git Repositor y

O ther git repositories will be recognized if you prefix them with “git::”

# HTTP

module "ec2_http" {

source = "git::https://example.com/ec2.git"

# SSH

module "ec2_ssh" {

source = "git::ssh://[email protected]/ec2.git"

Selecting Revisions

B y default, the main branch will be selected, but you can use any tag, commit sha or branch to get a module

# branch

module "module1" {

source = "github.com/user/module1?ref=dev"

# tag

module "module1" {

source = "github.com/user/module1?ref=v1.0.1"

# commit sha

module "module1" {

source = "github.com/user/module1?ref=508c6c..."

S3 Bucket

Archives stored in S3 can be used with the “s3::” prefix

module "module1" {

source = "s3::https://s3-eu-west-1.amazonaws.com/terraform-modules/module1.zip"

Meta-Arguments

Depends_on

Establishes dependencies between a module and another component (even another module
Works the same as depends_on would work on any type of resource/datasource/local

module "module1" {

depends_on = [

null_resource.this

source = "./module1"

resource "null_resource" "this" {

provisioner "local-exec" {

command = "echo a"

# The depends_on inside module1, ensures the null resource is created before the module.

Providers

The provider block inside a module is pretty different than the ones inside of another component, mainly because it is a different data type (map vs
string
If there is only one provider inside the configuration, the providers block is not necessary as modules will inherit that single provide
However, if there are multiple providers inside the configuration and some of the same type (2 aws providers, one defined with an alias, for example), if
you want to use the one with the alias, you will need to explicitly specify it inside the providers block

module "module1" {

source = "./module1"

providers = {

aws = aws.eastus1

# If your module requires multiple providers, you can define all of them in providers block similar to the below code

module "module1" {

source = "./module1"

providers = {

aws.source = aws.usw1

aws.destination = aws.usw2

For_each

Used as you would use it on any other componen

Create multiple instances of the same module

module "module1" {

source = "./module1"

for_each = {

key = "value"

key2 = "value2"

# module.module1["key"]... will be created

# module.module1["key2"]... will be created

Count

Used as you would use it on any other componen

Create multiple instances of the same module

module "module1" {

source = "./module1"

count = 3

# module.module1[0]... will be created

# module.module1[1]... will be created

# module.module1[2]... will be created

Best Practices

Each Terraform module should live in its own repository and versioning should be leverage
Minimal structure: main.tf, variables.tf, outputs.t
Each Terraform module should have examples inside of the

Use input and output variables (outputs can be accessed with module.module_name.output_name
Used for multiple resources, a single resource module is usually a bad practic
Use defaults or optionals depending on the data type of your variable
Use dynamic block
Use ternary operators and take advantage of terraform built-in function
Test your modules

The Most Flexible IaC Platform