PlatformEngr® Terraform course

Cheat notes · Module 00 · Orientation

Orientation: what a platform team keeps in Terraform

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

Terraform compares three things: the code in your .tf files, the state (its record of what it manages) and the real objects, and proposes the steps to make reality match the code. A platform team keeps the shared, long-lived things in it: here, each team's namespace and access.

Remember

  • Provider: a plugin that knows one API. The kubernetes provider turns resource blocks into calls to the API server; Terraform itself knows no API.
  • Root module: one directory you run Terraform in, with one state. The first one is envs/dev.
  • required_version in versions.tf says which CLI versions the code accepts. >= 1.11.0, < 2.0.0 allows every 1.x from 1.11.
  • ~> 1.5.0 lets only the last number grow: 1.5.x, below 1.6.0.
  • Terraform and OpenTofu read the same language. Pick one command per repo and keep it.
  • The kube context is kind-tf; one kind node is one Docker container.

Pitfalls

  • Unsupported Terraform Core version: the constraint and your CLI disagree. Widen the constraint to what the code needs; do not install an old CLI.
  • Running Terraform against whatever kube context is current. The provider names its context explicitly from module 01 on.

Commands

terraform versionThe CLI version, and the providers this directory uses
terraform initPrepare a directory: providers, modules, lock file, backend
kubectl config current-contextWhich cluster you are about to change

envs/dev/versions.tf (module 00)

terraform {
  required_version = ">= 1.11.0, < 2.0.0"
}

Test yourself

Answer in your head first, then open the answer.

Which three things does a plan compare?

The code, the state and the real objects.

What does ~> 1.5.0 accept?

1.5.0 and newer patch releases, below 1.6.0.

Why does the state matter?

It is the only way Terraform knows which real objects are its own, and which block each belongs to.

Where module 00 leaves you: A cluster kind-tf with one Ready node. Your repo on GitHub holds cluster/kind.yaml, .gitignore and envs/dev/versions.tf. terraform init succeeds in envs/dev. Nothing is managed yet.