liveBook · Manning

Module source

As explained in Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu

A module source is the registry address, filesystem path, or repository reference from which Terraform obtains a module.

When you call a reusable Terraform module, the required `source` argument tells Terraform where to obtain its code. It can identify a registry module, a filesystem path, or a Git repository. The module block then supplies inputs to the resources defined by that module. section 2.8

Use a registry module

To use a published module for infrastructure setup, write `module "vpn" { source = "tedivm/cloudinit/general" version = "~> 1.0" services = ["consul", "nomad"] }`. The source identifies the registry module; `version` limits its allowed versions. That version argument applies to registry sources, not every kind of module source. section 3.1.1

For a module you are developing locally, point `source` at its directory instead. A separate workspace can call it with a relative path, look up the subnet it needs, and expose one of its outputs. Run `terraform init` in that workspace before reviewing and applying the plan. section 3.8.4

Listing 3.36 Testing our local module
data "aws_vpc" "default" {                                   #1
  default = true                                             #1
}                                                            #1
 
 
data "aws_subnets" "default" {                               #1
  filter {                                                   #1
    name   = "vpc-id"                                        #1
    values = [data.aws_vpc.default.id]                       #1
  }                                                          #1
}                                                            #1
 
module "test_instance" {
  source    = "../"
  subnet_id = data.aws_subnets.default.ids[0]                #2
}
 
output "aws_instance_arn" {                                  #3
  value = module.test_instance.aws_instance_arn
}

The test workspace uses `source = "../"` to call the module in its parent directory. A subnet data lookup supplies an input, and an output reads a value from the called module. section 3.8.4

Listing 3.37 Using our published module
variable "subnet_id" {                                      #1
  type        = string
  description = "The Subnet to launch this resource in."
}
 
module "my_instance" {
  source        = "github.com/YOU_USERNAME/terraform-aws-in-depth//modules/
ec2_instance"                                             #2
  subnet_id     = var.subnet_id                             #3
  instance_type = "t3.large"                                #4
}
 
output "instance_arn" {
  value = module.my_instance.aws_instance_arn
}
#1 We previously used the data object to look this up, but it’s also common to use variables for things like network settings.
#2 Point this at your Git repository, and make sure you keep the folder to point at the ec2_instance module. The double slash is used to reference a submodule inside of the repository.
#3 We left this as a variable this time so you can set it to any subnet in the aws region.
#4 The instance type is configurable now.

A published module can be called from a GitHub repository. In this source address, `//modules/ec2_instance` selects a module inside the repository; omitting that folder would not point to the intended submodule. `terraform init` downloads and installs the referenced module. section 3.8.5

Choose a source that matches how the module is shared: a relative path while testing nearby code, or a published location for other projects. Keep the module’s input arguments and provider configuration distinct from its source address. section 3.8.4 section 3.8.5

How Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu covers it

How deep it goes
Defines supported source locations and works through registry, local-path, and GitHub calls without detailing module download internals.
Examples
Uses a public registry module, a relative-path test workspace, and a GitHub repository subdirectory.
What it assumes
Assumes basic Terraform configuration while defining what `source` does and showing module calls with concrete inputs.
What you can do after
Operate/configure it by selecting a module source and initializing a workspace that calls the module.
How it connects
Links module blocks to module version constraints, input variables, outputs, and Terraform initialization.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu. The section links point to the parts of the book it draws on.