08 · From Zero to Deployed

Cloud-Ressourcen von Hand zusammenzuklicken ist fehleranfällig und schwer zu wiederholen. Beschreibst du sie in einer Datei, kannst du dieselbe Umgebung jederzeit aufbauen — und sauber wieder abbauen.

Die Idee

Statt in einer App überall Knöpfe zu drücken, schreibst du einen Zettel, was es geben soll: „ein Dienst, der den Container ausführt, eine Datenbank, eine öffentliche Adresse.“ Ein Werkzeug liest den Zettel und baut genau das.

Wenn Instagram in einer neuen Region startet, will niemand hundert Server von Hand einrichten. Man beschreibt die Umgebung einmal als Code und baut sie per Knopfdruck — überall gleich, jederzeit wiederholbar.

So funktioniert es

Infrastructure as Code (IaC): deine Cloud-Umgebung als Textdatei. Terraform ist das führende Werkzeug dafür. Du beschreibst den Soll-Zustand, Terraform bringt die Cloud dorthin. Drei Befehle:

terraform plan — Vorschau: was würde sich ändern? (baut noch nichts)
terraform apply — baut es wirklich.
terraform destroy — räumt alles wieder ab.

So sieht ein Ausschnitt aus, der den Cloud-Run-Dienst für das Instagram-Backend beschreibt:

resource "google_cloud_run_v2_service" "app" {
  name     = "instagram-backend"
  location = var.region

  template {
    containers {
      image = "${var.region}-docker.pkg.dev/${var.project_id}/app:latest"
      ports { container_port = 8080 }

      # Passwort kommt aus einer Variable, nie hart in die Datei
      env {
        name  = "DATABASE_URL"
        value = var.database_url
      }
    }
  }
}

flowchart LR
    A[main.tf
Soll-Zustand] --> P[terraform plan
Vorschau]
    P --> Y[terraform apply
bauen]
    Y --> C[Cloud Run + Cloud SQL]
    C --> D[terraform destroy
aufräumen]

So steuerst du es

Terraform ist deklarativ: Du beschreibst das Ziel, nicht die Schritte. Es vergleicht Soll (deine Datei) mit Ist (der Cloud) und erzeugt einen Plan, der die Differenz schließt. Ein State merkt sich, was schon existiert.

Gute Praxis: erst plan lesen, dann apply; Geheimnisse über Variablen hereingeben (var.database_url), nie hart in die Datei schreiben; nach Experimenten destroy.

So sagst du es dem Agenten:

„Schreibe eine main.tf für Cloud Run plus Cloud SQL. Das DB-Passwort kommt aus einer Variable, nicht hart in die Datei.“

„Zeig mir terraform plan und erkläre, was gebaut, geändert oder gelöscht wird, bevor wir apply ausführen.“

„Setze deletion_protection = false auf der Datenbank, damit terraform destroy später sauber aufräumen kann.“

Typische Fehler: den Plan blind bestätigen; Passwörter in die .tf-Datei schreiben (landen in Git); oder den terraform.tfstate versehentlich committen — er enthält sensible Werte.

Kurz-Check

Was beschreibt eine Terraform-Datei — Schritte oder Ziel?
Wofür sind plan und apply da?
Warum kommt das DB-Passwort aus einer Variable?

Antworten anzeigen

Das Ziel (den Soll-Zustand). Terraform findet die Schritte selbst.
plan zeigt eine Vorschau der Änderungen; apply führt sie aus.
Damit das Geheimnis nicht im Code und in Git landet; die Variable füllt es erst beim Ausführen.

Clicking cloud resources together by hand is error-prone and hard to repeat. Describe them in a file and you can rebuild the same environment any time — and tear it down cleanly.

The idea

Instead of pressing buttons all over an app, you write one note for what should exist: "a service that runs the container, a database, a public address." A tool reads the note and builds exactly that.

When Instagram launches in a new region, nobody wants to set up a hundred servers by hand. You describe the environment once as code and build it with one command — the same everywhere, repeatable any time.

How it works

Infrastructure as Code (IaC): your cloud environment as a text file. Terraform is the leading tool for it. You describe the desired state, Terraform brings the cloud there. Three commands:

terraform plan — preview: what would change? (builds nothing yet)
terraform apply — builds it for real.
terraform destroy — tears it all down again.

Here is a snippet that describes the Cloud Run service for the Instagram backend:

resource "google_cloud_run_v2_service" "app" {
  name     = "instagram-backend"
  location = var.region

  template {
    containers {
      image = "${var.region}-docker.pkg.dev/${var.project_id}/app:latest"
      ports { container_port = 8080 }

      # password comes from a variable, never hard-coded in the file
      env {
        name  = "DATABASE_URL"
        value = var.database_url
      }
    }
  }
}

flowchart LR
    A[main.tf
desired state] --> P[terraform plan
preview]
    P --> Y[terraform apply
build]
    Y --> C[Cloud Run + Cloud SQL]
    C --> D[terraform destroy
clean up]

How you steer it

Terraform is declarative: you describe the goal, not the steps. It compares desired (your file) with actual (the cloud) and produces a plan that closes the gap. A state remembers what already exists.

Good practice: read plan first, then apply; pass secrets via variables (var.database_url), never hard-coded in the file; run destroy after experiments.

How to tell the agent:

"Write a main.tf for Cloud Run plus Cloud SQL. The DB password comes from a variable, not hard-coded in the file."

"Show me terraform plan and explain what gets built, changed, or deleted before we run apply."

"Set deletion_protection = false on the database so terraform destroy can clean up later."

Common mistakes: blindly approving the plan; writing passwords into the .tf file (they end up in Git); or accidentally committing terraform.tfstate — it contains sensitive values.

Quick check

Does a Terraform file describe steps or a goal?
What are plan and apply for?
Why does the DB password come from a variable?

Show answers

The goal (the desired state). Terraform figures out the steps itself.
plan shows a preview of the changes; apply carries them out.
So the secret does not end up in the code and in Git; the variable fills it in only at run time.

08 · Terraform und Infrastructure as Code

08 · Terraform and Infrastructure as Code