Handling State

DockerBeginner
Practice Now

Introduction

In the previous labs, you acted as the Chef, writing menus (configurations) for the Robot (Terraform) to cool (build). But how does the robot remember what it has already cooked?

Imagine if you had a warehouse but lost the inventory list. You wouldn't know what you have, where it is, or if something was stolen.

In Terraform, this inventory list is called state. It is Terraform's memory. It records what resources it created and maps configuration objects to real-world infrastructure objects.

State is what makes declarative management practical. Without it, Terraform could read your files, but it would have no reliable memory of which real objects correspond to those declarations.

State is one of Terraform's most important ideas. Without it, Terraform would not know what already exists, what changed, or what must be updated or recreated.

In this lab, you will see how Terraform uses this state to keep your infrastructure healthy. You will play the role of "Chaos," manually breaking things, and watch as Terraform detects the damage and "heals" the system automatically.

Inspect the State

We have pre-configured this environment for you. A main.tf file exists, and terraform apply has already been run. This means the infrastructure (a Docker container) is already live.

First, let's verify that the container is running:

sudo docker ps

You should see a container named tutorial.

Now, look at the files in your directory. You will see terraform.tfstate.

ls -l

This file is Terraform's "Secret Diary". It writes down everything it does here. Let's peek inside.

cat terraform.tfstate

The output is in a format called JSON. It might look complicated at first, but it is just a structured way for computers to take notes.

Somewhere in that text, you will see docker_container and the ID of the running container. This proves that Terraform "knows" about this specific container.

Critical Rule: Never edit this file manually. If you change it, Terraform gets amnesia and might accidentally delete or corrupt your infrastructure. Always let Terraform manage its own diary.

That warning matters because state is authoritative metadata, not just a log. Corrupting it can lead Terraform to make destructive or confusing decisions later.

Create Drift

Terraform expects to be the only boss managing these resources. But in the real world, things happen. Maybe a server crashes, or a colleague accidentally deletes something manually.

This situation is called Drift. It means "Reality" no longer matches "The Plan".

Drift is common in shared environments because humans, scripts, crashes, and external systems may all change infrastructure outside Terraform's normal control loop.

Let's cause some chaos. We will go behind Terraform's back and delete the container directly using Docker commands.

sudo docker rm -f tutorial

Verify that the container is truly gone:

sudo docker ps

At this moment, we have a problem:

  • Reality: The container is dead.
  • State File: Terraform thinks the container is still alive (because nobody told it otherwise).

Detect Drift

Now, let's see if Terraform notices the theft.

When you run terraform plan, the first thing Terraform does is a "Refresh". It calls up Docker and says, "Hey, does the container with ID XYZ still exist?"

Run the plan command:

terraform plan

Look closely at the output. You should see: docker_container.nginx: Refreshing state...

Then, it will show you a plan with a green + (create).

Terraform will perform the following actions:

  ## docker_container.nginx will be created
  + resource "docker_container" "nginx" { ... }

Terraform figured it out! It reasoned: "My plan says there should be a container. Reality says there is none. Therefore, I must Create a new one to obtain the desired state."

This reconciliation behavior is one of Terraform's most important operational properties. It compares desired state, recorded state, and live reality to decide what correction is needed.

Heal Infrastructure

This is the "Self-Healing" capability of Infrastructure as Code. Because our code defines the Desired State (A running container), Terraform can automatically fix any drift that occurs.

Run apply to fix the problem:

terraform apply

Type yes when prompted.

Once completed, check Docker again:

sudo docker ps

The container is back! It might have a new ID and it might be a fresh instance, but functionally, your infrastructure is back to exactly how you defined it in the blueprint.

Summary

In this lab, you witnessed the power of State.

You learned:

  • The State File: Terraform's memory of what exists (terraform.tfstate).
  • Drift Detection: How Terraform notices when things change behind its back (like manual deletion).
  • Self-Healing: How terraform apply automatically restores missing resources to match your code.

This reliability is why Terraform is trusted to manage critical infrastructure. Even if disasters happen, Terraform helps you get back to a known good state quickly.