Launching an API can mean configuring a load balancer, application tasks or instances, certificates, DNS, networking, and often a database. An application module packages the Terraform configuration for that application so deployments can reuse it rather than rebuild those pieces by hand. section 1.5.2 section 8.4.1
An application module is a Terraform module: a collection of related resources, data sources, and assets written in HCL. A root module is the entry point that configures providers and can call other modules. The application module may serve as that root, or a separate root module may call it. Input variables customize a call; outputs expose values such as the application URL. section 3.1 section 8.4.2 section 3.0
Listing 8.10 Environment main.tf example
variable "logging_api_key" { #1
sensitive = true #2
}
module "application" { #3
source = "registry.example.com/example/aws/application"
version = "1.1.1" #4
network_name = "dev_network" #5
db_size = 20 #5
num_tasks = 5 #5
logging_api_key = var.logging_api_key #6
}
output "application_url" { #7
value = module.application.url
}
The environment’s main.tf calls a registry-hosted application module at version 1.1.1, supplies network, database, task-count, and sensitive logging inputs, then exposes its URL as an output. section 8.4.2
Choose the root-module arrangement according to how independently environments must change:
- Use the application module itself as the root and supply environment-specific tfvars files. This keeps one codebase, but every environment shares the same underlying infrastructure configuration; variables do not let an environment retain an older module version. section 8.4.1
- Give each environment a thin root module that calls the application module. Each root can select its own module version and set its own parameters, allowing independent rollouts. Keep sensitive values out of source control. section 8.4.2
A module boundary organizes code, but it is not an execution barrier. Terraform plans relationships between underlying resources, so a resource in a dependent module can sometimes be created before another resource in the module it calls on. Express the resource relationships the deployment needs rather than relying on module order alone. section 5.2.3
