25-1 · Kapitel 25 · 5 Min. Lesezeit

Infrastructure as Code: Warum deine Serverkonfiguration ins Git gehört

Erfahre, warum Infrastructure as Code (IaC) der Schlüssel zu reproduzierbaren, versionierten und überprüfbaren Serverumgebungen ist – und wie du damit manuelle Fehler vermeidest.

Infrastructure as Code: Warum deine Serverkonfiguration ins Git gehört

Du stehst kurz davor, ein neues Feature auszurollen. Der Anwendungscode ist fertig, die Tests laufen grün, der Pull Request wurde genehmigt. Doch dann fragt jemand: „Haben wir den Load-Balancer für den neuen Endpunkt aktualisiert?“ Niemand ist sich sicher. Die Person, die die letzte Änderung am Load-Balancer vorgenommen hat, ist im Urlaub. Das Cloud-Dashboard zeigt die aktuelle Konfiguration, aber niemand weiß, was letzte Woche geändert wurde – oder warum.

Dieses Szenario spielt sich täglich in Teams ab. Infrastrukturänderungen hängen von Erfahrungswissen, manuellen Schritten und der Verfügbarkeit bestimmter Personen ab. Ist diese Person nicht erreichbar, wartet die Änderung. Vergisst sie einen Schritt, fällt der Server still und leise aus. Und wenn etwas schiefgeht, bedeutet die Ursachensuche, Chatverläufe, E-Mails und Erinnerungen zu durchforsten.

Es geht besser. Schreibe deine Infrastruktur als Code.

Was Infrastructure as Code wirklich bedeutet

Infrastructure as Code (IaC) ist die Praxis, deine Server, Netzwerke, Datenbanken, Load-Balancer und alle anderen Infrastrukturkomponenten in Textdateien zu definieren. Diese Dateien liegen in einem Versionskontroll-Repository – genau wie dein Anwendungscode.

Der entscheidende Wandel liegt darin, wie du Infrastruktur beschreibst. Statt schrittweisen Anweisungen wie „SSH auf den Server, führe diesen Befehl aus, um Nginx zu installieren, bearbeite dann diese Konfigurationsdatei“ schreibst du eine Deklaration des gewünschten Zustands. Zum Beispiel: „Ich möchte einen Server mit Nginx Version 1.24, der auf Port 443 lauscht, mit diesem TLS-Zertifikat und diesen Proxy-Regeln.“

Das Tool, das diese Dateien verarbeitet, liest deine Deklaration, vergleicht sie mit dem aktuellen Zustand deiner Infrastruktur und nimmt die notwendigen Änderungen vor, um die Übereinstimmung herzustellen. Dies wird als Desired-State-Management bezeichnet.

So sieht eine einfache deklarative Konfiguration in Terraform aus:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  user_data = <<-EOF
              #!/bin/bash
              apt-get update
              apt-get install -y nginx
              systemctl enable nginx
              systemctl start nginx
              EOF

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

resource "aws_security_group" "web_sg" {
  name        = "web-sg"
  description = "Allow HTTP and SSH"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Diese Datei deklariert genau das, was du willst: eine EC2-Instanz mit installiertem Nginx und eine Security Group, die Web-Traffic erlaubt. Terraform vergleicht diese Deklaration mit dem aktuellen Zustand deines AWS-Kontos und nimmt nur die Änderungen vor, die zur Übereinstimmung nötig sind.

Wie es deinen Arbeitsalltag verändert

Wenn Infrastruktur Code ist, bedeutet eine Änderung der Serverkonfiguration nicht mehr, sich auf einem Rechner anzumelden und Befehle einzutippen. Es bedeutet, eine Datei zu bearbeiten, einen Pull Request zu öffnen, ein Review zu bekommen und die Änderung zu mergen. Der Server aktualisiert sich automatisch, sobald die neue Konfiguration angewendet wird.

Das verschiebt den gesamten Workflow:

Jede Änderung wird nachverfolgt. Der Commit-Verlauf in deinem Repository sagt dir genau, wie die Produktions-Load-Balancer-Konfiguration letzten Dienstag aussah. Kein Rätselraten mehr, kein „Ich glaube, jemand hat diese Einstellung geändert.“
Änderungen sind überprüfbar. Bevor eine Infrastrukturänderung in Produktion geht, durchläuft sie denselben Code-Review-Prozess wie Anwendungsänderungen. Teammitglieder können kommentieren, Verbesserungen vorschlagen und Fehler erkennen, bevor sie Ausfallzeiten verursachen.
Jeder kann Änderungen vorschlagen. Ein Entwickler, der einen neuen Datenbank-Verbindungspool benötigt, kann die Konfiguration schreiben und einen Pull Request einreichen. Er muss nicht warten, bis das Betriebsteam Zeit hat. Das Betriebsteam reviewt die Änderung, anstatt sie auszuführen.
Rollbacks sind einfach. Wenn eine Konfigurationsänderung Probleme verursacht, machst du den Commit rückgängig und wendest die vorherige Version erneut an. Du musst dich nicht an die genaue Abfolge manueller Schritte erinnern, um die Änderung rückgängig zu machen.

Das Konzept des gewünschten Zustands (Desired State)

Die wichtigste Idee bei Infrastructure as Code ist der gewünschte Zustand. Deine Konfigurationsdateien beschreiben den idealen Zustand deiner Infrastruktur. Das IaC-Tool stellt kontinuierlich sicher, dass der tatsächliche Zustand mit dem gewünschten Zustand übereinstimmt.

Wenn jemand manuell eine Einstellung auf einem Server ändert, erkennt das Tool die Abweichung (Drift) und setzt sie zurück. Wenn ein Server abstürzt und ersetzt wird, richtet das Tool den neuen Server automatisch mit der korrekten Konfiguration ein. Du schreibst keine Skripte, die einmal ausgeführt werden. Du definierst ein Ziel, und das System hält dieses Ziel aufrecht.

Das unterscheidet sich grundlegend vom alten Ansatz, bei dem du ein Skript zum Einrichten eines Servers geschrieben, es einmal ausgeführt und gehofft hast, dass sich danach nichts ändert. Mit dem gewünschten Zustand ist das System selbstheilend und selbstprüfend.

Was Infrastructure as Code nicht ist

Infrastructure as Code ist kein bestimmtes Tool. Terraform, AWS CloudFormation, Ansible, Pulumi und viele andere sind Implementierungen des Konzepts. Das Tool ist weniger wichtig als die Praxis, die Infrastrukturkonfiguration als versionierten, überprüfbaren, deklarativen Code zu behandeln.

Es geht auch nicht darum, manuelle Arbeit vollständig zu eliminieren. Du musst deine Infrastruktur immer noch verstehen. Du triffst weiterhin Designentscheidungen zu Netzwerk, Sicherheit und Skalierung. Aber diese Entscheidungen sind in Dateien kodiert, die überprüft, getestet und reproduziert werden können.

Warum das für CI/CD wichtig ist

Infrastructure as Code ist die Grundlage dafür, Infrastrukturänderungen genauso zu behandeln wie Anwendungsänderungen in deiner CI/CD-Pipeline. Wenn deine Infrastruktur Code ist, kannst du:

Automatisierte Tests für Infrastrukturänderungen ausführen, bevor sie angewendet werden
Überprüfen, ob Konfigurationsdateien syntaktisch korrekt sind
Automatisch auf Sicherheitsrichtlinienverstöße prüfen
Änderungen über dieselbe Pipeline ausrollen, die auch deine Anwendung deployt
Konsistenz über verschiedene Umgebungen hinweg sicherstellen

Ohne Infrastructure as Code kann deine CI/CD-Pipeline nur Anwendungscode verarbeiten. Infrastrukturänderungen bleiben manuell, fehleranfällig und für die Pipeline unsichtbar. Das schafft eine Lücke, in der Anwendungsdeployments automatisiert sind, die zugrunde liegende Infrastruktur jedoch nicht.

Praktische Checkliste für den Einstieg

Wenn du über die Einführung von Infrastructure as Code nachdenkst, hier ein praktischer Startpunkt:

Wähle eine Umgebung für den Anfang. Versuche nicht, deine gesamte Infrastruktur auf einmal umzustellen. Beginne mit einer Staging- oder Entwicklungsumgebung.
Schreibe deklarative Dateien, keine Skripte. Konzentriere dich darauf, was du willst, nicht darauf, wie du es erreichst. Deklarative Dateien sind einfacher zu überprüfen und zu warten.
Lege alles in der Versionskontrolle ab. Dein Repository sollte alle Konfigurationsdateien enthalten, nicht nur die, die sich häufig ändern.
Überprüfe Infrastrukturänderungen wie Code. Fordere Pull Requests und Genehmigungen für Infrastrukturänderungen an, genau wie bei Anwendungsänderungen.
Teste vor dem Anwenden. Verwende Tools, die deine Konfigurationsdateien validieren und Änderungen simulieren können, bevor sie auf echten Servern landen.
Dokumentiere den gewünschten Zustand, nicht die Schritte. Deine Dateien sollten die Zielkonfiguration beschreiben, nicht die Befehlsfolge, um sie zu erreichen.

Das Fazit

Infrastructure as Code verwandelt Server von Black Boxes, die nur wenige verstehen, in dokumentierte, reproduzierbare und verwaltbare Komponenten. Jede Konfigurationsänderung hinterlässt eine Spur im Commit-Verlauf. Jeder Server kann von Grund auf mit konsistenten Ergebnissen neu aufgebaut werden. Jedes Teammitglied kann Infrastrukturverbesserungen vorschlagen, ohne tiefgehenden operativen Zugriff zu benötigen.

Wenn dich das nächste Mal jemand fragt, was sich letzte Woche in Produktion geändert hat, musst du nicht raten. Du öffnest das Repository und prüfst das Commit-Log. Das ist der Unterschied zwischen Infrastruktur als Kunst und Infrastruktur als Code.