Resources, variables, outputs and references

📘What it really is

• Terraform files end in .tf and use HCL. Terraform reads every .tf file in the folder together; the split into main.tf, variables.tf and outputs.tf is a convention for people.

• A resource is one thing to manage: hcl resource "docker_volume" "db" { name = "${local.prefix}-db" } docker_volume is the type (from the provider) and db is your name for it. Its address is docker_volume.db.

• References connect resources: volume_name = docker_volume.db.name. Terraform builds a dependency graph from them, so the volume is created before the container that uses it. Use depends_on only for dependencies Terraform can't see from references.

• Input variables make one configuration serve many situations: hcl variable "app_count" { type = number default = 2 validation { condition = var.app_count >= 1 && var.app_count <= 8 error_message = "app_count must be between 1 and 8." } } Set them with -var app_count=3, a .tfvars file, or an environment variable TF_VAR_app_count=3. Files ending .auto.tfvars are read automatically (Project 2's pipeline and Project 3's autoscaler use this).

• Locals are named values inside the configuration: locals { prefix = "routerani-${var.env}" }, used as local.prefix.

• Outputs publish values for people and tools: output "app_version" { value = var.app_version }, read with terraform output -raw app_version.

• count makes several copies: count = var.app_count creates docker_container.app[0], [1] and so on; count.index is each copy's number, and docker_container.app[*].name lists all names. for_each does the same over a map or set of names, which is safer when items are added or removed from the middle.

• Checks before applying: terraform fmt lays files out consistently (-check fails if anything needs formatting), and terraform validate checks the configuration is well formed.