Module Composition and Sources

The idea in one sentence

The source argument on a module block tells Terraform where to fetch that module’s code from, and real, non-trivial infrastructure gets built by composing several small modules together — one module’s output feeding directly into another module’s input variable.

Where a module’s code comes from: the source argument

Every module block needs a source, and there are three kinds you will run into constantly. A local relative path points at a directory inside your own repository. The public Terraform Registry resolves a short <namespace>/<name>/<provider> address to a published, versioned module. A Git URL points directly at a repository, optionally pinned to a specific tag, branch, or commit with ?ref=.

# local relative path
module "storage" {
  source = "./modules/storage-account"
}

# public Terraform Registry
module "vnet" {
  source  = "Azure/vnet/azurerm"
  version = "~> 5.0"
}

# Git URL pinned to a specific tag
module "vnet_from_git" {
  source = "git::https://github.com/acme/terraform-modules.git//vnet?ref=v1.4.0"
}

All three forms are just different answers to the same question: where does Terraform go get the .tf files for this child module. Nothing about how you write variables.tf, main.tf, or outputs.tf inside the module changes based on which kind of source a caller happens to use.

Composing modules: one output becomes another’s input

A single flat configuration with hundreds of resources is hard to read and impossible to reuse. Real infrastructure is built from small, focused modules wired together through their outputs and inputs. A vnet module exposes the identifiers other modules need:

modules/vnet/outputs.tf

output "vnet_id" {
  description = "ID of the created virtual network"
  value       = azurerm_virtual_network.this.id
}

output "subnet_ids" {
  description = "IDs of the subnets"
  value       = azurerm_subnet.this[*].id
}

A virtual-machine module declares the inputs it needs to launch into that network:

modules/virtual-machine/variables.tf

variable "vnet_id" {
  description = "ID of the virtual network to launch the VM into"
  type        = string
}

variable "subnet_id" {
  description = "ID of the subnet to launch the VM into"
  type        = string
}

The root configuration is what actually wires them together, passing one module’s output straight into another module’s input:

# root main.tf
module "vnet" {
  source        = "./modules/vnet"
  address_space = "10.0.0.0/16"
}

module "web_server" {
  source = "./modules/virtual-machine"

  vnet_id   = module.vnet.vnet_id
  subnet_id = module.vnet.subnet_ids[0]
}

Neither module needs to know the other exists. The vnet module has no idea a virtual-machine module will ever consume its outputs, and the virtual-machine module has no idea its vnet_id came from a module rather than a hardcoded string. The root configuration is the only place that knows both modules and connects them.

The public Terraform Registry as a productivity lever

Common patterns like “a virtual network with public and private subnets” have been solved many times already. The public Terraform Registry hosts well-maintained, widely-used community modules — the Azure organization’s modules, such as Azure/vnet/azurerm and Azure/naming/azurerm, being some of the most common starting points for Azure infrastructure — and reaching for one of these is usually a better use of your time than writing the equivalent from scratch.

module "vnet" {
  source  = "Azure/vnet/azurerm"
  version = "~> 5.0"

  resource_group_name = azurerm_resource_group.main.name
  vnet_name           = "acme-app-vnet"
  address_space       = ["10.0.0.0/16"]
  subnet_prefixes     = ["10.0.1.0/24", "10.0.2.0/24"]
  subnet_names        = ["private", "public"]
}

That said, “widely used” is not the same as “safe to trust blindly.” Before you build production infrastructure on top of a Registry module, read what it actually creates — its resources, its default values, and any role assignments it provisions on your behalf. A Registry module is still someone else’s code running with your Azure credentials.

flowchart LR
  subgraph root["Root configuration"]
    vnetmod["module vnet"]
    vmmod["module web_server"]
  end
  subgraph vnet["Child module: vnet"]
    vnetout1["output vnet_id"]
    vnetout2["output subnet_ids"]
  end
  subgraph vm["Child module: virtual-machine"]
    vmin1["var.vnet_id"]
    vmin2["var.subnet_id"]
  end
  vnetmod --> vnetout1
  vnetmod --> vnetout2
  vnetout1 -->|module.vnet.vnet_id| vmin1
  vnetout2 -->|module.vnet.subnet_ids[0]| vmin2
  vmin1 --> vmmod
  vmin2 --> vmmod

A vnet module's outputs feeding a virtual-machine module's inputs from the root configuration

🏗️ The one-line takeaway

The source argument tells Terraform where a module’s code lives — a local relative path, the public Terraform Registry, or a Git URL with an optional ?ref= for a specific version — and real infrastructure is built by composing small, focused modules together, with one module’s output passed straight into another module’s input variable inside the root configuration that wires them up. The public Registry’s well-maintained community modules, like Azure/vnet/azurerm and Azure/naming/azurerm, are usually a better starting point than writing common patterns from scratch, but you should still read what a Registry module actually creates before trusting it in production.

Which three kinds of module source does this lesson describe

Only local relative paths are a valid module source A local relative path, the public Terraform Registry, and a Git URL with an optional ref Only modules published to the public Terraform Registry can be used as a source A Blob Storage URL, a Docker image, and an environment variable

In the vnet and virtual-machine composition example, how does the virtual-machine module receive the subnet it should launch into

The virtual-machine module hardcodes its own subnet_id value internally The root configuration passes module.vnet.subnet_ids[0] as the value of the virtual-machine module subnet_id input Terraform automatically infers the subnet from the AzureRM provider region The vnet module directly calls the virtual-machine module without going through the root configuration

Does the vnet module in the example need to know that a virtual-machine module will consume its outputs

Yes, the vnet module must import the virtual-machine module to expose compatible outputs No, the vnet module only exposes its outputs, and the root configuration is the only place that connects the two modules Yes, Terraform requires modules to declare which other modules may consume their outputs No, because module composition only works when both modules come from the same source

When does reaching for a public Terraform Registry module make more sense than writing your own from scratch

Never, hand-written modules are always safer than Registry modules Always, Registry modules never need to be reviewed before use For common, well-solved patterns like a standard vnet layout, though you should still read what the module creates before trusting it in production Only when the module source is a local relative path

Submit

Mark as complete