Wer Infrastruktur per Klick im Cloud-Portal aufsetzt, hat in zwei Jahren ein nicht-reproduzierbares Setup, das niemand mehr versteht. Infrastructure as Code (IaC) löst dieses Problem: Server, Netzwerke, Datenbanken und alle anderen Cloud-Ressourcen werden als Code beschrieben, versioniert und in Git verwaltet – wie jeder andere Code auch.
Warum Infrastructure as Code unverzichtbar ist
Manuelle Infrastruktur-Konfiguration hat drei tödliche Schwächen: Sie ist nicht reproduzierbar, nicht dokumentiert und nicht auditierbar. IaC löst alle drei Probleme gleichzeitig. Der Zustand der Infrastruktur ist nachvollziehbar (Git-History), reproduzierbar (gleicher Code = gleiches Setup) und auditierbar (Code-Reviews vor jeder Änderung).
Mit welchen Tools wir IaC umsetzen
Terraform – der Industriestandard
Terraform von HashiCorp ist das verbreitetste IaC-Tool. Cloud-agnostisch durch ein riesiges Provider-Ökosystem (AWS, Azure, GCP, Kubernetes, IONOS, Hetzner, hunderte andere). Wir nutzen Terraform mit modularer Architektur, sauberen State-Backends (S3 + DynamoDB für Locking) und striktem Code-Review-Prozess.
Ansible – für Configuration Management
Ansible ergänzt Terraform für die Innenausstattung von Servern: Software-Installation, Konfigurationsdateien, User-Management, Service-Setup. Agentless via SSH, idempotent, in YAML beschrieben.
Pulumi – IaC in echter Programmiersprache
Für Teams, die IaC in Python, TypeScript oder Go schreiben wollen statt in HCL, ist Pulumi eine moderne Alternative. Volle Sprach-Features, IDE-Unterstützung, native Test-Frameworks.
AWS CloudFormation und Azure ARM
Die Cloud-nativen IaC-Lösungen der Hyperscaler haben tiefere Integration in ihre jeweiligen Plattformen. Wir setzen sie ein, wenn Single-Cloud-Strategie klar ist und Plattform-Features wichtig sind.
IaC-Best-Practices, die wir umsetzen
Modulare Architektur
Wiederverwendbare Module für VPCs, RDS-Datenbanken, Application-Server, S3-Buckets. Damit baut man neue Umgebungen schnell und konsistent zusammen, statt jedes Mal neu zu schreiben.
Environment-Separation
Strikte Trennung von Development, Staging und Production – jeweils mit eigenem State, eigenem Variablen-Set und unterschiedlichen Berechtigungen. Damit kann ein Fehler in Dev nicht versehentlich Production zerstören.
Remote-State und State-Locking
Terraform-State liegt in S3 (oder gleichwertigem Remote-Backend) mit Locking über DynamoDB. Damit können mehrere Entwickler parallel arbeiten, ohne sich gegenseitig den State zu zerschießen.
Plan vor Apply – immer
Jede Änderung wird erst per `terraform plan` simuliert. Erst nach Review im Team und expliziter Freigabe folgt der Apply. Das verhindert „upps, ich wollte nur das eine Tag ändern, hab aber die ganze Datenbank ausgetauscht”-Vorfälle.
Drift-Detection
Manuelle Änderungen außerhalb von Terraform werden über regelmäßige `terraform plan`-Läufe erkannt. Drift wird entweder zurückgerollt oder in den Code übernommen – aber nie ignoriert.
Was Sie mit IaC gewinnen
- Reproduzierbarkeit – Disaster-Recovery wird machbar, weil das ganze Setup als Code vorliegt
- Dokumentation – die Infrastruktur dokumentiert sich selbst
- Versionierung – jede Änderung ist nachvollziehbar mit Autor und Begründung
- Code-Review – Infrastruktur-Änderungen laufen durch denselben Prozess wie Application-Code
- Automatisierung – IaC integriert sich perfekt in CI/CD-Pipelines
- Multi-Environment – neue Umgebungen entstehen mit einem Kommando
Verwandte Leistungen
IaC ist Teil von CI/CD-Pipelines. Cloud-Infrastruktur wird über IaC beschrieben: Cloud-Infrastruktur. Kubernetes-Cluster werden via Terraform aufgesetzt: Kubernetes & Docker. Sicherheit der IaC-Pipeline: DevSecOps. Übersicht: DevOps-Engineering.
Mini-Case aus unserer Praxis
IaC-Refactoring einer manuell konfigurierten Cloud-Umgebung
Übernahme einer AWS-Umgebung, die über zwei Jahre manuell via AWS Console konfiguriert wurde. Ausgangslage: niemand wusste mehr, welche EC2-Instanz wofür existiert, IAM-Rollen waren historisch gewachsen, Sicherheits-Audit stand bevor. Vorgehen: Phase 1 (3 Wochen) Inventarisierung mit terraformer-Tool zur Code-Generierung aus bestehender Infrastruktur. Phase 2 (4 Wochen) Refactoring zu modularer Terraform-Architektur, Environment-Separation, Remote-State mit S3 + DynamoDB-Locking. Phase 3 (2 Wochen) IAM-Cleanup, Tagging-Strategie, Cost-Optimization. Resultat: vollständige Infrastruktur-Dokumentation als Code, erfolgreiches Sicherheits-Audit, Identifikation und Stilllegung ungenutzter Ressourcen mit signifikanter Kosteneinsparung.
Häufige Fragen zu Infrastructure as Code
Terraform oder Pulumi – was empfehlen Sie?
Terraform für die meisten Teams: ausgereiftes Tooling, größte Community, breitester Provider-Support. Pulumi wenn Ihr Team in echter Programmiersprache (Python, TypeScript, Go) statt HCL arbeiten will – etwa für komplexere Logik oder bessere Testbarkeit.
Was ist mit CloudFormation oder Azure ARM?
Sinnvoll bei Single-Cloud-Strategie und tiefer Plattform-Integration. Nachteil: Vendor-Lock-in. Wir nutzen sie in spezifischen Setups, bevorzugen aber Terraform für Cloud-Agnostik.
Wie versionieren Sie Terraform-State?
Remote-State in S3 (oder gleichwertigem Object Storage) mit Versioning. State-Locking über DynamoDB oder Postgres. Damit können mehrere Entwickler parallel arbeiten, ohne sich gegenseitig den State zu zerschießen. State wird verschlüsselt gespeichert.
Wie gehen Sie mit Secrets in Terraform um?
Keine Secrets im Terraform-Code – Punkt. Wir nutzen HashiCorp Vault, AWS Secrets Manager oder Sealed Secrets als Quelle für sensitive Werte. Terraform liest sie zur Apply-Zeit, sie landen nicht im State (oder werden zumindest dort verschlüsselt gespeichert).
