Infrastructure as code, and where Terraform fits

Why clicking in the console doesn't scale

The first server is easy: open the AWS console, click through the wizard, done. Six months later you have 40 resources, and:

• Nobody remembers which settings staging was built with, so production is "almost the same".
• Rebuilding after a bad day means following a wiki page that's three changes out of date.
• A security group was opened "just for a minute" in March, and it's still open.
• There's no review: one wrong click goes straight to production, and there's no history of who did it.

None of that is anyone's fault. It's what happens when the only record of your infrastructure is the infrastructure itself.

Infrastructure as code

Infrastructure as code (IaC) means describing servers, networks, databases and permissions in text files, and letting a tool create them from those files. The files live in Git, next to the app. That gives you four things:

1. Repeatable. Run the same code and get the same environment, for staging, production or a new region.
2. Reviewed. A change is a pull request. Teammates read it, and CI checks it, before it touches anything real.
3. Versioned. git log tells you who changed the firewall, when and why, and git revert takes it back.
4. Documented. The code is always an up-to-date description of what exists.

Most IaC tools are declarative: you describe the end result ("one bucket, versioning on"), not the steps. The tool works out what to create, change or delete to get there.

How Terraform works

Terraform is the most widely used IaC tool. You write configuration in HCL, a readable language made of blocks, and Terraform talks to cloud APIs for you.

⤢ View

Write, init, plan, apply. The state file is how Terraform remembers what it built.© Diagram: DevOps Academy

Close

The workflow is the same for every provider, which is the main reason Terraform spread: learn it once for AWS and you can manage DNS, GitHub repos or Kubernetes the same way.

What teams use it for

• Building whole environments in the cloud: networks, servers, load balancers, databases.
• Creating the same setup in several regions or accounts from one module.
• Managing things around the cloud, too: DNS records, monitoring alerts, GitHub repositories and team permissions.
• Short-lived environments: a full copy of the stack for each pull request, destroyed when it merges.

Terraform vs Ansible

People often ask "Terraform or Ansible?" They mostly do different jobs:

A common split: Terraform creates the servers, and Ansible, cloud-init or a pre-built image sets them up. With containers, there's often nothing left to configure inside the server at all.

Install it and run your first plan

# Ubuntu / Debian: add HashiCorp's signed package repository, then install
$ wget -O - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
$ sudo apt update && sudo apt install terraform

# macOS
$ brew tap hashicorp/tap && brew install hashicorp/tap/terraform

$ terraform version
Terraform v1.x.x          # your version will be newer or older; any recent 1.x works

Your first configuration doesn't need a cloud account. The local provider manages files on your own machine, which is perfect for learning the workflow:

# ~/tf-hello/main.tf
terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.9"
    }
  }
}

resource "local_file" "hello" {
  filename = "${path.module}/hello.txt"
  content  = "Built by Terraform"
}

$ cd ~/tf-hello
$ terraform init               # downloads the providers into .terraform/
Terraform has been successfully initialized!
$ terraform plan
  # local_file.hello will be created
  + resource "local_file" "hello" {
      + content  = "Built by Terraform"
      + filename = "./hello.txt"
      ...
    }

Plan: 1 to add, 0 to change, 0 to destroy.
$ terraform apply              # shows the plan again and waits for you to type yes
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
$ cat hello.txt
Built by Terraform

Read every plan before you apply it. The last line, Plan: 1 to add, 0 to change, 0 to destroy, is the one to check first: an unexpected number in the destroy column is how outages start.

$ cd ~/tf-hello
$ rm hello.txt                     # the "manual change"
$ terraform plan
  # local_file.hello will be created
...
Plan: 1 to add, 0 to change, 0 to destroy.
$ terraform apply -auto-approve
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
$ cat hello.txt
Built by Terraform