Infrastructure as Code: the idea

Why servers and networks get described as code in git: declarative state, reproducibility, review, and drift.

How servers used to be set up

The classic way to set up a server: SSH in and install packages by hand, write configs, open ports. Works fine until you have five servers, then ten. That's when the problems start:

• nobody remembers exactly what's configured on each machine;
• a new server gets built "from memory" and ends up slightly different from its neighbor;
• the person who configured everything leaves, and the knowledge leaves with them.

Infrastructure as Code (IaC) is an approach where you don't configure infrastructure by hand, you describe it as text instead. The description lives in git, and a tool brings reality in line with it.

Declarative, not step-by-step

The core idea of IaC: describe the desired state, not a sequence of steps. You don't write "create a network, then a subnet, then a VM." You write "there should be a network, a subnet, and a VM with these parameters," and the tool figures out what to do to get there.

A fragment of a virtual machine description in Terraform for Yandex Cloud (the required disk and network blocks are left out; the full example comes in the next lesson):

resource "yandex_compute_instance" "web" {
  name = "web-01"

  resources {
    cores  = 2
    memory = 4
  }
}

This is the same approach as in Kubernetes manifests: you describe what should exist, and a controller brings the cluster in line with it. The tool compares the description with what already exists and does only the diff: it creates what's missing, changes what differs, and Terraform also removes what was dropped from the description. That's why you can apply the description as many times as you want. If reality already matches it, running it again changes nothing. This property is called idempotency.

What this gets you

• Reproducibility. The same description builds an identical server, whether you do it once or ten times. Dev, staging, and prod get built from shared code.
• Versioning. Infrastructure lives in git: you can see who changed what and when, and roll back to a previous state.
• Review. An infrastructure change comes in as a merge request, and colleagues look at it before it's applied, just like regular code.
• Documentation. To learn how prod is set up, you read the files instead of asking people. The description is the documentation, as long as it matches reality.

Configuration drift

The main enemy of IaC: drift. Someone logged into a server by hand and changed something outside the code. Now reality has diverged from the description in git, and the description is lying.

That's why mature teams have a rule: no touching prod by hand, every change goes through code. If you fix something by hand in an emergency, you move that same fix into the code right away, otherwise the next apply will roll it back.

The IaC tool itself helps you spot drift. terraform plan re-reads the real objects in the cloud before building a plan and shows the difference between the code and reality before anything is applied. The command terraform plan -refresh-only shows only what changed from outside, without any changes from the code. But not every tool can do this: some compare the code not with the live system, but with whatever they themselves applied last time.

Where this fits in the DevOps stack

IaC is a description layer. Specific tools split up the responsibilities:

• Terraform / OpenTofu provision resources from cloud providers: networks, VMs, databases, load balancers.
• Ansible configures machines that already exist: packages, configs, services. Ansible modules describe the desired state ("package is installed," "file has this content"), but the playbook's tasks run in order, top to bottom.
• Kubernetes manifests describe what runs inside the cluster.

All these descriptions live in git. From there, CI applies them automatically, like any regular pipeline.

Common mistakes

• Fixing something by hand and not moving it into code. The fix survives until the next apply, then quietly disappears. Or worse: nobody applies the code anymore, because people are afraid of wiping out manual fixes.
• Recreating everything for a single change. Tearing down and bringing everything back up is the easiest option, but it means downtime and lost data wherever it isn't stored in volumes. The IaC tool can apply just the diff. Use that instead.
• Trusting that the code describes reality without checking. The description matches reality only if nobody changed anything outside the code. Before you make a change, check what the tool is about to do (plan, diff).

What you'll need for the tasks

In the labs, you'll work through the same ideas with Docker Compose. A Compose file is a declarative description too: which services, from which images, with which ports and limits. The command docker compose -f <file> up -d brings the containers in line with it.

name: demo
services:
  web:
    image: nginx:1.27.3-alpine
    deploy:
      resources:
        limits:
          memory: 64M
          cpus: "0.25"

You'll use:

• docker compose -f <file> up -d applies the description;
• docker compose -f <file> ps shows the project's containers;
• docker inspect <container> shows what settings the container is actually running with (limits are in the HostConfig.Memory and HostConfig.NanoCpus fields);
• flag reference: docker compose up --help.

The next lesson walks through your first Terraform resource in practice.