Infrastructure as Code

Entstehung und Beteiligte

Infrastructure as Code wuchs aus Konfigurationsmanagement, automatisierter Systeminstallation und DevOps. CFEngine erschien 1993 durch Mark Burgess, Puppet 2005, Chef 2009. HashiCorp veröffentlichte Terraform 2014 für deklarative Infrastruktur über Anbieter-APIs.

Welches Problem sollte gelöst werden?

Manuell eingerichtete Server waren schwer reproduzierbar und drifteten auseinander. Infrastruktur sollte versionierbar, prüfbar und wiederholbar wie Software werden.

Technische Hürden und Lösungen

Zustand, Geheimnisse, Abhängigkeiten und nicht rückgängig machbare Änderungen verlangen sorgfältige Workflows. Deklarativer Code beschreibt Ziele, Anbieter-APIs bleiben jedoch fehlerhaft oder zeitabhängig. Tests und Reviews sind unverzichtbar.

Standardisierung und Einordnung

Cloud- und Plattformtechnik entstand aus Rechenzentrum, Virtualisierung, verteilten Systemen und automatisierter Softwareauslieferung. Die grundlegenden Probleme sind nicht neu: Ressourcen müssen geteilt, Ausfälle abgefangen, Änderungen reproduzierbar und Lastspitzen bewältigt werden. Neu ist die hohe Automatisierung und die Möglichkeit, Infrastruktur über Programmierschnittstellen in kurzer Zeit zu erzeugen oder zu verwerfen.

Technik im praktischen Betrieb

Im praktischen Cloudbetrieb müssen Automatisierung und Kosten gemeinsam beobachtet werden. Ressourcen entstehen schnell, verschwinden aber nicht immer automatisch. Tags, Limits, Richtlinien und getrennte Konten oder Projekte schaffen Verantwortlichkeit. Verfügbarkeit sollte über mehrere Fehlerdomänen geplant und mit realen Wiederanlaufproben belegt werden. Ein Anbieter übernimmt Gebäude, Hardware und Teile der Plattform; Konfiguration, Identitäten, Daten, Anwendungen und Backups bleiben je nach Dienstmodell ganz oder teilweise beim Kunden.

Warum das Thema heute noch relevant ist

Viele Cloudbegriffe klingen neu, beschreiben aber bekannte verteilte Systeme unter stärkerer Automatisierung. Die Geschichte hilft, Marketing und Architektur zu trennen. Ein Dienst bleibt von Netz, Speicher, Konsens und Identitäten abhängig, auch wenn diese Schichten nicht sichtbar sind. Betreiber sollten deshalb Ausfallmodelle, Datenexport und Abhängigkeiten dokumentieren. Je bequemer ein verwalteter Dienst ist, desto wichtiger wird die Frage, welche Kontrolle bewusst an den Anbieter abgegeben wurde.

Daten und Meilensteine

• 1993 erscheint CFEngine.
• 2005 folgt Puppet, 2009 Chef.
• 2014 wird Terraform veröffentlicht.
• Immutable Infrastructure ersetzt Systeme statt sie beliebig weiterzuverändern.

Was ist Infrastructure as Code?

Infrastructure as Code (IaC) beschreibt Infrastruktur (Server, Netzwerke, Datenbanken, Load Balancer) in Konfigurationsdateien, die versioniert, geteilt und automatisch ausgeführt werden. Statt GUI-Klicks oder manueller SSH-Befehle wird Infrastruktur deklarativ (Was soll existieren?) oder imperativ (Wie baue ich es?) beschrieben.

Vorteile: Reproduzierbarkeit (identische Umgebungen für dev/staging/prod), Versionierung im Git (Änderungshistorie, Rollback), Peer Review für Infrastrukturänderungen, Disaster Recovery (Infrastruktur aus Code neuaufbauen).

IaC-Tools

• Terraform (HashiCorp): Cloud-agnostisch, deklarativ, HCL-Syntax. State-Datei trackt aktuelle Infrastruktur. Modules für Wiederverwendbarkeit. Standard für Multi-Cloud.
• Ansible: Python-basiert, agentless (SSH), YAML-Playbooks. Stärken: OS-Konfiguration, Deployments, Day-2-Operations.
• AWS CloudFormation / Azure Bicep: Cloud-nativ, tief integriert, kein State-Management nötig.
• Pulumi: IaC mit echten Programmiersprachen (Python, TypeScript, Go) statt DSL.
• Chef / Puppet: Ältere Config-Management-Tools, heute weniger verbreitet.

GitOps und IaC-Workflows

GitOps wendet Git-Workflows auf Infrastruktur an: Der gewünschte Zustand ist im Git-Repository. CI/CD-Pipelines (GitHub Actions, GitLab CI) führen terraform plan und terraform apply automatisch aus. Code Review für jede Infrastrukturänderung. Drift Detection erkennt manuelle Änderungen.

Immutable Infrastructure: Statt Server zu patchen, werden neue Server-Images erstellt und alte ersetzt. Höhere Zuverlässigkeit durch bekannte, versionierte Zustände.