Für EinsteigerSuchen⌘K

Infrastructure as Code

Wie Teams Infrastrukturänderungen planbar, prüfbar und reproduzierbar machen – vom gewünschten Zustand bis zum kontrollierten Betrieb.

Das Prinzip, IT-Infrastruktur (Server, Netzwerke, Datenbanken) nicht manuell zu konfigurieren, sondern als versionierten Code zu definieren und automatisch bereitzustellen.

Fortgeschritten2 Min Lesezeit

Erklärung starten

Auf einen Blick

3 Punkte

  1. Infrastruktur wird in Konfigurationsdateien beschrieben, nicht manuell geklickt
  2. Versionierbar in Git – Änderungen sind nachvollziehbar und rückgängig machbar
  3. Ermöglicht identische Umgebungen für Dev, Staging und Production

Sofortantwort

Infrastructure as Code einfach erklärt

Infrastruktur wird als versionierter Code definiert und automatisch bereitgestellt.

Kurz gesagt
Infrastruktur wird in Konfigurationsdateien beschrieben, nicht manuell geklickt
Typischer Einsatz
Reproduzierbare Umgebungen, Disaster Recovery, KI-Infrastruktur
Wichtig zu wissen
Ermöglicht identische Umgebungen für Dev, Staging und Production

Infrastructure as Code im Überblick

Früher wurden Server manuell konfiguriert: SSH rein, Pakete installieren, Konfigurationsdateien bearbeiten. Das Problem: Niemand weiß genau, was auf dem Server läuft, Änderungen sind nicht nachvollziehbar, und eine neue Umgebung aufzubauen dauert Stunden.

Infrastructure as Code dreht das um: Die gesamte Infrastruktur wird in Textdateien beschrieben. Ein terraform apply oder ansible-playbook baut dann alles automatisch auf. Die Konfigurationsdateien liegen in Git – jede Änderung ist dokumentiert, überprüfbar und rückgängig machbar.

Vorteile auf einen Blick:

ManuellInfrastructure as Code
UndokumentiertVersioniert in Git
Nicht reproduzierbarIdentisch wiederholbar
FehleranfälligAutomatisiert und testbar
LangsamMinuten statt Stunden

Technisch betrachtet

Terraform-Beispiel: AWS EC2-Instanz

resource "aws_instance" "inference_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "g4dn.xlarge"  # GPU-Instanz für KI-Inferenz

  tags = {
    Name        = "llm-inference"
    Environment = "production"
  }
}

Pulumi-Beispiel (TypeScript)

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

const server = new aws.ec2.Instance("inference-server", {
  ami: "ami-0c55b159cbfafe1f0",
  instanceType: "g4dn.xlarge",
  tags: { Name: "llm-inference" },
});

GitOps-Workflow

Code-Änderung → Pull Request → Review → Merge → CI/CD → terraform apply

Jede Infrastrukturänderung durchläuft denselben Review-Prozess wie Anwendungscode.

Schritt für Schritt

Infrastruktur wie Produktcode behandeln

IaC macht Änderungen sichtbar und wiederholbar. Der Sicherheitsgewinn entsteht erst durch Reviews, geschützte Zustände, Tests und bewusste Freigaben.

  1. Gewünschten Zustand beschreiben

    01

    Definiere Ressourcen, Zugriffe, Netzwerke und Konfigurationen als nachvollziehbare, modulare Deklarationen.

    Umgebung → Ressourcen → Zugriffe → Grenzen

  2. Wiederverwendbare Module schneiden

    02

    Gemeinsame Bausteine werden standardisiert, während Umgebungsunterschiede bewusst über Konfigurationen geführt werden.

    Modul + Eingaben → konsistente Ressource

  3. Änderungen vorab planen

    03

    Ein Plan zeigt, welche Ressourcen erstellt, verändert oder entfernt würden, bevor eine Umgebung beeinflusst wird.

    Codeänderung → Plan → Review → Freigabe

  4. Secrets und State schützen

    04

    Zugänge gehören nicht in Konfigurationsdateien; Zustandsdaten und Berechtigungen erhalten eigenen Schutz und Kontrolle.

    Secrets Store + geschützter State + Least Privilege

  5. Drift und Wiederherstellung üben

    05

    Prüfe, ob die reale Umgebung noch dem Code entspricht, und teste Wiederaufbau oder Rückfallwege kontrolliert.

    Ist-Zustand ↔ Code → Drift → Korrektur / Recovery

Konkretes Beispiel

Beispiel: Staging-Umgebung für eine Web-Anwendung

Ein Team braucht wiederholbar dieselben Netz-, Daten- und Laufzeitgrundlagen für sichere Tests vor dem Release.

Betriebsproblem

Manuelle Einstellungen unterscheiden sich zwischen Umgebungen und Änderungen lassen sich später nicht zuverlässig nachvollziehen.

Versionierter Ablauf

Modulare Infrastrukturdefinitionen, überprüfbare Änderungspläne, getrennte Konfigurationen pro Umgebung und ein geschützter Prozess für Freigaben.

IaC ist wertvoll, wenn es nicht nur Infrastruktur erstellt, sondern Änderungen als überprüfbaren und wiederholbaren Arbeitsablauf etabliert.

Einordnung

Vorteile und Grenzen

Das spricht dafür

  • Reproduzierbarkeit: Umgebungen lassen sich konsistent erstellen und nachvollziehbar verändern.
  • Bessere Zusammenarbeit: Reviews und Versionshistorie machen Infrastrukturentscheidungen sichtbar.
  • Sicherer Betrieb: Pläne, Policies und wiederkehrende Checks können Risiken vor einer Änderung erkennen.

Das solltest du beachten

  • Eigene Komplexität: Module, Provider, State und Berechtigungen brauchen Pflege und Fachwissen.
  • Gefährliche Reichweite: Fehler im Code können viele Ressourcen betreffen und erfordern klare Schutzschranken.
  • Kein Selbstläufer: Manuelle Änderungen und ungeprüfte Notfallwege erzeugen weiterhin Drift.
Vertiefung · für Fortgeschrittene

Der IaC-Änderungskreislauf

Code, Plan, Review und kontrollierte Ausführung verbinden den gewünschten Zustand mit der laufenden Infrastruktur.

Wissenskarte

Versionierte Beschreibung von Ressourcen, Konfiguration und Abhängigkeiten.

IaC verschiebt Infrastruktur von individuellen Klicks zu einem transparenten, testbaren und kontrollierbaren Systemprozess.

01Einsatzbereiche

Wann ist Infrastructure as Code sinnvoll?

Geeignet für

  • Reproduzierbare UmgebungenDev, Staging und Production sind identisch konfiguriert – 'works on my machine' gehört der Vergangenheit an
  • Disaster RecoveryNach einem Ausfall kann die gesamte Infrastruktur in Minuten aus dem Code neu aufgebaut werden
  • KI-InfrastrukturGPU-Cluster, Vektordatenbanken und Inference-Endpoints automatisch provisionieren und skalieren

↑ Inhalt

02Werkzeuge

Womit Infrastructure as Code umgesetzt wird

↑ Inhalt

Merksatz

IaC ist wie ein Kochrezept statt mündlicher Überlieferung

Statt jemandem zu erklären, wie man ein Gericht kocht, schreibst du das Rezept auf. Jeder kann es reproduzieren, du kannst es versionieren, und wenn etwas schiefläuft, weißt du genau, was geändert wurde.

  1. Infrastruktur wird in Konfigurationsdateien beschrieben, nicht manuell geklickt
  2. Versionierbar in Git – Änderungen sind nachvollziehbar und rückgängig machbar
  3. Ermöglicht identische Umgebungen für Dev, Staging und Production

03Wissensnetz

Diese Begriffe brauchst du ebenfalls

Nicht „ähnliche Artikel", sondern die Rolle, die jeder Begriff für Infrastructure as Code spielt.

Alle Begriffe

↑ Inhalt

04Redaktion

Herkunft und Stand

Redaktion und Aktualität

Ebenex RedaktionRedaktion

Veröffentlicht
Aktualisiert

Dieses Feld entwickelt sich schnell. Oben stehen Veröffentlichung und letzte Änderung; ein Prüfdatum kommt dazu, sobald die Erklärung nach ihrer letzten Änderung geprüft wurde.

↑ Inhalt

05FAQ

Häufige Fragen zu Infrastructure as Code

Was ist der Unterschied zwischen deklarativem und imperativem IaC?

Deklarativ (Terraform, CloudFormation): Du beschreibst den gewünschten Endzustand – das Tool entscheidet, wie es dorthin kommt. Imperativ (Ansible, Skripte): Du beschreibst die Schritte, die ausgeführt werden sollen. Deklarativ ist meist wartbarer, imperativ flexibler.

Was bedeutet 'State' in Terraform?

Terraform speichert den aktuellen Zustand der Infrastruktur in einer State-Datei (terraform.tfstate). Beim nächsten Apply vergleicht Terraform den gewünschten Zustand (Code) mit dem aktuellen Zustand (State) und führt nur die notwendigen Änderungen durch.

Ist IaC nur für Cloud-Infrastruktur?

Nein. IaC funktioniert für Cloud (AWS, GCP, Azure), On-Premises-Server, Netzwerkgeräte und sogar für die Konfiguration von Anwendungen. Ansible zum Beispiel kann beliebige Server konfigurieren, unabhängig vom Hosting.

↑ Inhalt

06Weiterlernen

Was möchtest du als Nächstes verstehen?

↑ Inhalt