Infrastruktur als Code schreiben, bevor du noch einen Button klickst

Du hast eine Anwendung, die einen Server und eine Datenbank braucht. Der übliche Weg ist, sich ins Dashboard des Cloud-Anbieters einzuloggen, durch ein paar Seiten zu klicken, Instanztypen auszuwählen, Speicher zu konfigurieren, Netzwerk einzurichten – und zu hoffen, dass du keinen Schritt vergessen hast. Wenn du das Gleiche für die Staging-Umgebung machen musst, wiederholst du den gesamten Vorgang. Wenn ein Teammitglied fragt, welche Infrastruktur in Produktion läuft, schickst du Screenshots.

Dieser Workflow funktioniert – bis er es nicht mehr tut. Ein vergessenes Häkchen, eine falsche Region, eine vergessene Security-Group-Regel, und deine Anwendung läuft entweder gar nicht oder mit einer Sicherheitslücke, die du nicht beabsichtigt hast.

Es gibt einen besseren Weg: Schreibe deine Infrastruktur als Code.

Was Infrastruktur als Code wirklich bedeutet

Infrastruktur als Code (IaC) ist die Praxis, Server, Datenbanken, Netzwerke und andere Cloud-Ressourcen in Textdateien zu definieren, anstatt durch eine Benutzeroberfläche zu klicken. Diese Dateien beschreiben den gewünschten Zustand deiner Infrastruktur. Du speicherst sie in der Versionsverwaltung, reviewst sie wie Anwendungscode und wendest sie konsistent über alle Umgebungen hinweg an.

Der entscheidende Punkt ist: Du schreibst kein Skript, das sagt „Schritt eins: Server erstellen, Schritt zwei: warten, Schritt drei: Datenbank erstellen“. Stattdessen deklarierst du, wie der Endzustand aussehen soll. Das Tool ermittelt die Reihenfolge der Operationen anhand der Abhängigkeiten zwischen den Ressourcen.

Deine erste Konfiguration schreiben

Terraform ist eines der am weitesten verbreiteten IaC-Tools. Du schreibst Konfigurationsdateien mit der Endung .tf. Jede Datei deklariert die Ressourcen, die du benötigst, und wie sie zusammenhängen.

Beginne mit einer Datei namens main.tf. Als Erstes definierst du den Provider. Ein Provider ist ein Plugin, das Terraform die Kommunikation mit einer bestimmten Plattform wie AWS, Google Cloud oder Azure ermöglicht. Er sagt Terraform, wo Ressourcen erstellt werden sollen und welche Anmeldedaten zu verwenden sind.

provider "aws" {
  region = "ap-southeast-1"
}

Sobald der Provider gesetzt ist, definierst du Ressourcen. Jede Ressource folgt diesem Muster: resource "typ" "lokaler_name". Der lokale Name wird nur innerhalb deiner Konfiguration verwendet. Es ist nicht der Name, der in der Konsole des Cloud-Anbieters erscheint.

So erstellst du einen virtuellen Server, den AWS als EC2-Instance bezeichnet:

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "app-server"
  }
}

Und hier eine PostgreSQL-Datenbank mit RDS:

resource "aws_db_instance" "app_database" {
  allocated_storage    = 20
  engine               = "postgres"
  engine_version       = "15"
  instance_class       = "db.t3.micro"
  db_name              = "myapp"
  username             = "admin"
  password             = var.db_password
  skip_final_snapshot  = true
}

Beachte etwas Wichtiges: Du hast keine Schritte geschrieben. Du hast nicht gesagt „Erstelle zuerst den Server, warte dann, bis er bereit ist, und erstelle dann die Datenbank.“ Du hast deklariert, was du haben willst. Terraform analysiert die Konfiguration, erkennt, dass die Datenbank nicht vom Server abhängt, und erstellt sie parallel. Wenn eine Ressource von einer anderen abhängt, kümmert sich Terraform automatisch um die Reihenfolge.

Warum sich das zunächst schwerer anfühlt

Das Schreiben von Konfigurationsdateien dauert anfangs länger als das Klicken durch ein Dashboard. Du musst die genauen Ressourcentypen, ihre erforderlichen Argumente und die Struktur der Dateien kennen. Das Dashboard zeigt dir Dropdown-Menüs und Kontrollkästchen. Die Konfigurationsdatei erwartet, dass du weißt, was ami-0c55b159cbfafe1f0 bedeutet oder worauf sich db.t3.micro bezieht.

Aber dieser anfängliche Aufwand zahlt sich aus, sobald du die Einrichtung duplizieren musst. Du brauchst eine Staging-Umgebung, die die Produktion abbildet? Kopiere die Dateien, ändere ein paar Werte und führe dieselbe Konfiguration aus. Du willst verstehen, welche Infrastruktur läuft? Lies die Dateien, anstatt durch die Konsole zu jagen. Du willst eine Änderung überprüfen, bevor sie wirksam wird? Erstelle einen Pull-Request und lass dein Team den Diff kommentieren.

Konfiguration in der Versionsverwaltung speichern

Deine .tf-Dateien sollten in einem Git-Repository liegen. Das kann dasselbe Repository wie dein Anwendungscode oder ein separates Infrastruktur-Repository sein. In beiden Fällen durchläuft jede Änderung an der Infrastruktur denselben Workflow wie Code-Änderungen: schreiben, committen, reviewen, mergen, anwenden.

Das bringt mehrere Vorteile:

• Jede Infrastrukturänderung wird mit dem Autor und dem Grund aufgezeichnet.
• Du kannst zu einem früheren Zustand zurückkehren, wenn etwas schiefgeht.
• Neue Teammitglieder können die gesamte Infrastruktur durch Lesen des Repositorys verstehen.
• Automatisierte Prüfungen können die Konfiguration validieren, bevor sie in Produktion geht.

Was du nicht tust

Wenn du Infrastruktur als Code schreibst, schreibst du kein Deployment-Skript. Ein Skript führt Befehle nacheinander aus. Wenn Schritt drei fehlschlägt, bricht das Skript ab, und du hast eine teilweise erstellte Infrastruktur. IaC-Tools wie Terraform sind deklarativ. Sie vergleichen den aktuellen Zustand deiner Infrastruktur mit dem gewünschten Zustand in deiner Konfiguration und nehmen nur die Änderungen vor, die nötig sind, um diesen Zustand zu erreichen.

Dieser Unterschied ist wichtig, wenn du die Infrastruktur aktualisieren musst. Anstatt ein neues Skript zu schreiben, das den aktuellen Zustand berücksichtigt, aktualisierst du die Konfigurationsdatei. Terraform ermittelt, was hinzugefügt, geändert oder entfernt werden muss.

Der praktische Workflow

Der typische Workflow für Terraform besteht aus drei Phasen: Schreiben, Planen, Anwenden.

Zuerst schreibst oder änderst du deine .tf-Dateien. Hier definierst du die gewünschte Infrastruktur.

Zweitens führst du terraform plan aus. Dieser Befehl zeigt dir, was Terraform tun wird, ohne es tatsächlich zu tun. Er gibt einen detaillierten Diff aus: welche Ressourcen erstellt, welche geändert und welche gelöscht werden. Du überprüfst diesen Plan, bevor du fortfährst.

Drittens führst du terraform apply aus, um den Plan umzusetzen. Terraform tätigt die API-Aufrufe an deinen Cloud-Anbieter, um Ressourcen zu erstellen, zu aktualisieren oder zu löschen, bis der tatsächliche Zustand deiner Konfiguration entspricht.

Eine kurze Checkliste für dein erstes IaC-Setup

• Wähle einen Cloud-Anbieter und installiere die Terraform-CLI.
• Erstelle eine main.tf-Datei mit deinem Provider-Block.
• Definiere mindestens eine Ressource, z. B. eine virtuelle Maschine oder eine Datenbank.
• Führe terraform init aus, um das Provider-Plugin herunterzuladen.
• Führe terraform plan aus, um zu sehen, was erstellt wird.
• Führe terraform apply aus, um die Ressourcen zu erstellen.
• Speichere alle .tf-Dateien in einem Git-Repository und pushe sie.

Der wahre Wert zeigt sich später

Infrastruktur als Code zu schreiben, fühlt sich am ersten Tag nach zusätzlicher Arbeit an. Am dreißigsten Tag, wenn du eine neue Umgebung hinzufügen oder einen Fehler beheben musst, fühlt es sich an wie der einzig vernünftige Weg. Die Konfigurationsdateien werden zur einzigen Quelle der Wahrheit für deine Infrastruktur. Kein Rätselraten mehr, was in Produktion läuft. Keine manuellen Schritte mehr, die jemand vergessen könnte. Keine Infrastruktur mehr, die nur eine Person neu aufsetzen kann.

Beginne mit einer Ressource. Schreibe sie in eine Datei. Lege sie in Git ab. Füge dann die nächste Ressource hinzu. Die Gewohnheit bildet sich schneller, als du denkst, und das Vertrauen, das sie dir gibt, ist die anfängliche Reibung wert.