IaC principles & Terraform basics

Why infrastructure as code

Clicking in a console doesn't scale: nobody can review it, repeat it, or say exactly what changed last Tuesday. Infrastructure as code (IaC) puts infrastructure in files:

• Reviewable: changes go through pull requests.
• Repeatable: the same code builds dev, staging and prod.
• Auditable: Git history says who changed what, and why.
• Recoverable: lose an environment, rebuild it from code.

Terraform in one picture

your .tf files (desired state) ──┐
                                 ├──► terraform plan ──► list of changes ──► terraform apply ──► provider APIs
state (what Terraform manages) ──┤                                                              (AWS, Kubernetes, libvirt…)
reality (read via providers) ────┘

• Providers are plugins that talk to APIs (AWS, Azure, Kubernetes, Helm, GitHub, libvirt, hundreds more).
• Resources are the things you manage (aws_s3_bucket, kubernetes_namespace).
• State records which real objects belong to which resource (lesson 02).

Your first configuration (no cloud needed)

# main.tf
terraform {
  required_version = ">= 1.6"
  required_providers {
    random = { source = "hashicorp/random", version = "~> 3.6" }
    local  = { source = "hashicorp/local",  version = "~> 2.5" }
  }
}

resource "random_pet" "server" {
  length = 2
}

resource "local_file" "inventory" {
  filename = "${path.module}/inventory.txt"
  content  = "server: ${random_pet.server.id}\n"
}

output "server_name" {
  value = random_pet.server.id
}

$ terraform init
Initializing provider plugins...
- Installing hashicorp/random v3.6.x...
- Installing hashicorp/local v2.5.x...
Terraform has been successfully initialized!
$ terraform plan
  # local_file.inventory will be created
  # random_pet.server will be created
Plan: 2 to add, 0 to change, 0 to destroy.
$ terraform apply
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
Outputs:
server_name = "fluent-heron"

Notice: Terraform created random_pet first, because local_file references it. References build the dependency graph automatically.

Run terraform apply again: no changes. That's idempotency: running the same code twice doesn't do anything twice.

Reading a plan

Replacing a database or a cluster by accident is the classic Terraform disaster. Read every plan.

The dependency lock file

terraform init writes .terraform.lock.hcl with the exact provider versions and checksums chosen. Commit it. Upgrade deliberately with terraform init -upgrade, and review the diff.

Recap

• IaC = infrastructure as reviewable, repeatable, auditable code.
• Providers talk to APIs; resources describe desired objects; state tracks them.
• init → plan → apply (→ destroy); references build the dependency graph; re-runs are idempotent.
• Read plans carefully (-/+ = replacement) and commit the lock file.