Infrastructure as Code: Reproduzierbar deployen

Wer schon einmal einen Produktionsserver „per Hand" aufgesetzt hat, kennt das Problem: Nach drei Monaten weiß niemand mehr genau, was darauf läuft und warum. Jede Änderung landet irgendwo im Kopf des Admins, der das damals gemacht hat, oder bestenfalls in einem Wiki-Artikel, der schon beim Schreiben veraltet war. Infrastruktur as Code löst genau das: Statt Server manuell zu konfigurieren, beschreibt man den gewünschten Zustand in Dateien versioniert, reproduzierbar, automatisch ausführbar.

Dieser Artikel erklärt, was IaC konkret bedeutet, welche Tools sich für welche Anwendungsfälle eignen und wie Teams den Einstieg schaffen, ohne alles auf einmal umkrempeln zu müssen.

Was ist Infrastruktur as Code?

Infrastruktur as Code (IaC) bedeutet: Die Konfiguration von Servern, Netzwerken, Datenbanken und anderen Infrastrukturkomponenten wird nicht manuell durchgeführt, sondern in maschinenlesbaren Dateien definiert. Diese Dateien werden wie normaler Anwendungscode behandelt, sie liegen im Git-Repository, werden per Pull Request geändert und durchlaufen eine Pipeline, bevor sie in Produktion landen.

Es gibt zwei grundlegende Ansätze:

Deklarativ beschreibt den Zielzustand. Das Tool kümmert sich darum, wie dieser Zustand erreicht wird. Terraform ist das bekannteste Beispiel: Man definiert, welche Ressourcen existieren sollen, und Terraform ermittelt selbst, was erstellt, geändert oder gelöscht werden muss.

Imperativ beschreibt die Schritte, die ausgeführt werden sollen. Ansible-Playbooks funktionieren so: Man schreibt eine Abfolge von Tasks, die in dieser Reihenfolge ausgeführt werden.

In der Praxis wird meist beides kombiniert. Terraform provisioniert die Infrastruktur, Ansible konfiguriert die darauf laufenden Dienste.

Das Problem mit manueller Infrastruktur

Manuelle Konfiguration hat einen Namen bekommen, der das Problem gut beschreibt: Snowflake-Server. Jeder Server ist ein Unikat. Zwei Systeme, die eigentlich identisch sein sollten, unterscheiden sich in Details, die niemand dokumentiert hat. Mit der Zeit driften sie auseinander, Patches werden auf einem eingespielt, auf dem anderen nicht. Eine Library wird auf einem manuell aktualisiert, weil ein Dienst nicht lief. Drei Monate später funktioniert etwas auf Produktion, aber nicht auf Staging.

Das führt zu konkreten Problemen:

• Keine Reproduzierbarkeit. Wenn ein Server ausfällt, kann man ihn nicht zuverlässig neu aufbauen, weil niemand genau weiß, was auf ihm installiert war.
• Fehlende Versionierung. Wer hat was wann geändert? Bei manuellen Anpassungen gibt es keine automatische Antwort darauf.
• Langsames Onboarding. Neue Teammitglieder müssen verstehen, wie die Infrastruktur aussieht. Wenn das nirgendwo beschrieben ist, dauert das.
• Schwierige Compliance-Nachweise. Auditoren wollen wissen, wer wann welche Änderung vorgenommen hat. Ohne Versionskontrolle ist das mühsam.

Kernprinzipien von Infrastruktur as Code

Idempotenz ist eines der wichtigsten Prinzipien. Ein IaC-Tool muss denselben Endzustand produzieren, egal ob es einmal oder zehnmal ausgeführt wird. Wenn ein Server bereits im gewünschten Zustand ist, passiert nichts. Das macht Deployments sicher und wiederholbar.

Single Source of Truth bedeutet: Der Code im Repository definiert, wie die Infrastruktur aussehen soll. Was auf den Servern läuft, sollte diesem Code entsprechen. Weicht der tatsächliche Zustand ab, man spricht von Configuration Drift, ist das ein Problem, das behoben werden muss.

Versionierung mit Git bringt die gewohnten Workflows der Softwareentwicklung in die Infrastruktur. Änderungen werden per Pull Request eingereicht, reviewed und nachverfolgt. Bei einem Problem kann man in der Git-History nachsehen, wer was wann geändert hat und bei Bedarf zurückrollen.

Die wichtigsten IaC-Tools im Überblick

Der Markt für IaC-Tools ist gewachsen. Hier ein Überblick über die meistgenutzten Werkzeuge und ihre Stärken.

Terraform

Terraform von HashiCorp ist der de-facto-Standard für Cloud-Infrastruktur-Provisionierung. Die deklarative Sprache HCL (HashiCorp Configuration Language) ist lesbar und gut dokumentiert. Terraform verwaltet einen State, der den aktuellen Zustand der Infrastruktur abbildet, und berechnet bei jeder Änderung einen Plan, der zeigt, was sich ändern wird, bevor etwas ausgeführt wird.

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

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

Ein wichtiger Aspekt: Der Terraform State muss sicher gespeichert werden, in einem Remote Backend wie S3, nicht lokal auf dem Rechner eines Entwicklers.

Ansible

Ansible eignet sich besonders für Configuration Management: Software installieren, Konfigurationsdateien ausrollen, Dienste starten. Es ist agentlos, auf den Zielsystemen muss nichts installiert sein, nur SSH-Zugang und Python. Die Playbooks sind in YAML geschrieben und gut lesbar.

- name: Nginx installieren
  hosts: webservers
  tasks:
    - name: Nginx-Paket installieren
      apt:
        name: nginx
        state: present

Ansible ist kein direkter Konkurrent zu Terraform, sondern ergänzt es. Terraform baut die Infrastruktur, Ansible konfiguriert sie.

Pulumi

Pulumi verfolgt einen anderen Ansatz: Statt einer eigenen Konfigurationssprache kann man mit echten Programmiersprachen arbeiten – TypeScript, Python, Go oder C#. Das macht IaC zugänglicher für Entwickler, die keine neue DSL lernen wollen, und ermöglicht komplexere Logik ohne Workarounds.

import * as aws from "@pulumi/aws";

const bucket = new aws.s3.Bucket("my-bucket", {
    acl: "private",
});

Für Teams, die bereits stark in TypeScript oder Python investiert sind, kann Pulumi eine natürlichere Wahl sein als Terraform.

Helm & Kustomize

Im Kubernetes-Kontext übernehmen Helm und Kustomize die Rolle von IaC-Tools für Workloads. Helm ist ein Package Manager für Kubernetes: Man definiert Charts mit Templates und Values, die unterschiedliche Konfigurationen für verschiedene Umgebungen ermöglichen. Kustomize setzt auf eine andere Philosophie – statt Templates werden Base-Manifeste mit Overlays angepasst, ohne sie direkt zu verändern.

Beide Tools sind keine Konkurrenten zu Terraform, sondern decken eine andere Ebene ab: Terraform verwaltet den Cluster, Helm und Kustomize verwalten die Workloads darauf.

IaC in Kubernetes-Umgebungen

Kubernetes hat IaC nicht erfunden, aber es zu einem zentralen Bestandteil des Workflows gemacht. Kubernetes-Manifeste sind selbst schon deklarativ: Man beschreibt den gewünschten Zustand, und der Controller sorgt dafür, dass er erreicht wird.

GitOps geht einen Schritt weiter und ist ein zentraler Baustein im Platform Engineering. Bei GitOps ist das Git-Repository die einzige autoritative Quelle für den Cluster-Zustand. Tools wie ArgoCD oder Flux überwachen das Repository und synchronisieren den Cluster automatisch, wenn sich etwas ändert. Das ist ein Pull-Modell: Der Cluster zieht Änderungen aus Git, statt dass jemand von außen Änderungen pushed.

Das hat praktische Vorteile: Man deployed nicht mehr mit kubectl apply auf dem Laptop, sondern durch einen Merge in den main-Branch. Der gesamte Deployment-Prozess ist damit auditierbar und reproduzierbar.

Typischer IaC-Workflow in der Praxis

Ein realistischer Workflow für ein Team, das IaC konsequent nutzt, sieht ungefähr so aus:

1. Änderung als Code schreiben. Ein Entwickler fügt eine neue Datenbank hinzu, indem er eine Terraform-Ressource in einer .tf-Datei definiert.
2. Pull Request öffnen. Die Änderung wird zur Review eingereicht. Automatisch wird ein terraform plan ausgeführt und dessen Output im PR kommentiert, so sieht jeder, was sich ändern wird.
3. Review und Merge. Nach der Freigabe wird in main gemergt.
4. Automatisches Apply. Eine CI/CD-Pipeline führt terraform apply aus. Bei einem GitOps-Setup für Kubernetes übernimmt ArgoCD oder Flux die Synchronisation.
5. Monitoring. Nach dem Deployment wird überprüft, ob der tatsächliche Zustand dem gewünschten entspricht.

Dieser Ablauf ist für jede Infrastrukturänderung gleich, egal ob es um einen neuen Server, eine Firewall-Regel oder eine Kubernetes-Konfiguration geht.

Häufige Fehler und wie man sie vermeidet

Configuration Drift ist der häufigste Fallstrick. Jemand macht eine schnelle manuelle Änderung direkt auf dem Server, „nur kurz, damit es wieder läuft". Das Problem: Diese Änderung steht nicht im Code. Beim nächsten Apply wird sie überschrieben – oder schlimmer, sie bleibt bestehen und niemand weiß mehr, warum.

Die Lösung: Manuelle Änderungen konsequent unterbinden und alle Änderungen durch den IaC-Workflow erzwingen. Das erfordert Disziplin, zahlt sich aber aus.

Secret-Management ist ein weiterer kritischer Punkt. Secrets wie Passwörter oder API-Keys gehören nicht in Git, auch nicht verschlüsselt als Terraform-Variable im Repository. Bessere Ansätze: HashiCorp Vault, AWS Secrets Manager, oder Kubernetes Secrets mit einem externen Secret-Operator.

Zu granulare Module machen Terraform-Code schnell unübersichtlich. Statt für jede Ressource ein eigenes Modul zu bauen, lieber mit wenigen, gut durchdachten Abstraktionen arbeiten und erst dann aufteilen, wenn es echten Mehrwert bringt.

Infrastruktur as Code und Compliance

IaC macht Compliance-Anforderungen erheblich einfacher zu erfüllen. Jede Änderung an der Infrastruktur ist im Git-Log dokumentiert: wer, was, wann, warum (Commit-Message). Das reicht für viele Audit-Anforderungen als Nachweis.

Policy-as-Code geht noch einen Schritt weiter. Tools wie Open Policy Agent (OPA) oder Conftest erlauben es, Richtlinien als Code zu definieren und automatisch zu prüfen. Beispiel: „Alle Storage-Buckets müssen verschlüsselt sein" kann als Policy formuliert und in der CI-Pipeline geprüft werden – bevor der Code überhaupt angewendet wird.

deny[msg] {
    resource := input.resource.aws_s3_bucket[_]
    not resource.server_side_encryption_configuration
    msg := sprintf("Bucket %v muss verschlüsselt sein", [resource])
}

Das verschiebt Compliance-Prüfungen nach links. Probleme werden früh erkannt, nicht erst beim Audit.

Einstieg für Teams ohne IaC-Erfahrung

Der größte Fehler beim IaC-Einstieg ist der Versuch, alles auf einmal zu migrieren. Das funktioniert selten. Stattdessen empfiehlt sich ein schrittweiser Ansatz:

Schritt 1: Neues zuerst. Alle neuen Ressourcen werden von Anfang an per IaC erstellt. Bestehende Infrastruktur bleibt zunächst wie sie ist.

Schritt 2: Importieren, nicht neu erstellen. Terraform und andere Tools bieten Import-Funktionen, um bestehende Ressourcen in den State zu übernehmen, ohne sie zu löschen und neu anzulegen.

Schritt 3: Graduell migrieren. Kritische, stabile Systeme werden schrittweiser in den IaC-Workflow überführt, sobald das Team Erfahrung gesammelt hat.

Schritt 4: Tooling etablieren. CI/CD-Pipelines für Terraform, Linting, automatische Plan-Ausgaben im Pull Request – das ist kein Nice-to-have, sondern Voraussetzung für sicheres Arbeiten im Team.

Fazit

Infrastruktur as Code ist kein „nice to have", sondern die Grundlage für skalierbare, sichere und nachvollziehbare Infrastruktur. Sobald Infrastruktur versioniert, reviewbar und automatisiert ausgerollt wird, verschwinden Snowflake-Server, Drift wird sichtbar und Deployments werden wiederholbar.

Wer pragmatisch starten will, nimmt sich eine überschaubare Ressource (z.B. Netzwerk, Datenbank oder einen Kubernetes-Cluster), etabliert den Git-Workflow (PR, Plan, Apply) und baut von dort aus Schritt für Schritt aus. Der wichtigste Hebel ist dabei weniger das Tool als die Konsequenz: Änderungen passieren im Code, nicht „mal eben" per Hand.