Zum Inhalt springen

Automatisierung

Terraform, Ansible, Puppet, Chef — Infrastructure as Code erklärt.

Terraform

Infrastruktur-Provisionierung

Ansible

Konfigurationsmanagement

Puppet/Chef

Flotten-Management

CI/CD

Automatisierte Pipelines

Infrastructure as Code ist kein Trend — es ist Hygiene

Jede manuell konfigurierte Maschine ist technische Schuld. Infrastructure as Code (IaC) macht Infrastruktur reproduzierbar, versionierbar und reviewbar — genau wie Anwendungscode. Änderungen durchlaufen Pull Requests, werden in der Pipeline validiert und landen erst nach Review in Produktion. Das eliminiert Snowflake-Server, dokumentiert den Ist-Zustand automatisch und ermöglicht Disaster Recovery in Minuten statt Tagen.

Das richtige Tool für den richtigen Zweck

Terraform, Ansible, Puppet, Chef — jedes Tool löst ein anderes Problem. Terraform provisioniert Infrastruktur, Ansible konfiguriert sie, Puppet erzwingt Compliance auf großen Flotten. Die Werkzeuge konkurrieren weniger miteinander als viele denken — sie ergänzen sich. Entscheidend ist nicht die Wahl des Tools, sondern das Verständnis seiner Stärken, Grenzen und Fallstricke.

Terraform

Deklarativ, State-File basiert, Provider-Ökosystem.

Terraform beschreibt Infrastruktur als Code und provisioniert sie über Provider bei AWS, Azure, GCP, VMware und hunderten weiteren Diensten. Der deklarative Ansatz definiert den Zielzustand — Terraform berechnet den Weg dorthin.

  • Stärke: Cloud-Infrastruktur provisionieren — VMs, Netzwerke, DNS, Load Balancer, IAM-Rollen. Ein terraform plan zeigt exakt was passiert, BEVOR es passiert
  • Fallstrick: State-File Drift entsteht sobald jemand manuell ändert. Bei Team-Arbeit ist State-Locking Pflicht — ohne S3+DynamoDB oder Terraform Cloud als Backend entstehen Race Conditions und korrupte States
  • Fallstrick: Module werden schnell komplex. Verschachtelte Module mit vielen Variablen sind schwer zu debuggen und noch schwerer zu refactoren

Ansible

Agentless, SSH-basiert, YAML Playbooks, Push-Modell.

Ansible verbindet sich per SSH, führt Tasks aus und verschwindet wieder. Kein Agent, kein Daemon, kein zentraler Server nötig. Die YAML-Syntax ist lesbar, der Einstieg flach — das macht Ansible zum meistgenutzten Konfigurationsmanagement-Tool.

  • Stärke: Konfigurationsmanagement, Software-Deployment, Ad-hoc Tasks. Einfacher Einstieg, flache Lernkurve, riesige Community
  • Fallstrick: Idempotenz muss bei shell und command Modulen selbst sichergestellt werden — diese Module sind NICHT idempotent. creates und when-Conditions sind Pflicht
  • Fallstrick: Bei großen Inventories (500+ Hosts) wird es ohne Tuning langsam. Facts-Gathering auf jedem Host ist ein Bottleneck — gather_facts: false und strategy: free helfen

Puppet

Deklarativ, Agent-basiert, Pull-Modell, eigene DSL.

Puppet erzwingt den definierten Zustand auf jeder Node — alle 30 Minuten per Default. Der Agent prüft, korrigiert und meldet zurück. Das Pull-Modell skaliert besser als Push bei großen Flotten.

  • Stärke: Große Flotten (1000+ Nodes), Compliance-Enforcement, Convergence. Puppet garantiert den Zielzustand — kontinuierlich, nicht einmalig
  • Fallstrick: Eigene DSL statt YAML — Puppet-Code ist weder Ruby noch JSON, sondern eine eigene Sprache. Die Lernkurve ist steiler als bei Ansible
  • Fallstrick: PuppetDB als Abhängigkeit, Agent auf jedem Node, Catalog-Compilation bei komplexen Modulen langsam. Debugging erfordert Verständnis des Catalog-Compilation-Prozesses

Chef

Ruby-basiert, Recipes/Cookbooks, Agent-basiert.

Chef setzt auf Ruby als Basis — Recipes sind Ruby-Code, keine deklarative DSL. Das gibt maximale Flexibilität, erfordert aber Ruby-Kenntnisse und ein gutes Verständnis des Convergence-Modells.

  • Stärke: Flexibilität durch Ruby, ausgereiftes Test-Ökosystem mit InSpec und ChefSpec. Compliance-as-Code über InSpec ist nach wie vor relevant — auch ohne Chef
  • Fallstrick: Ruby-Kenntnisse sind Voraussetzung, die Einstiegshürde liegt höher als bei Ansible oder Terraform
  • Fallstrick: Chef Server als zentrale Abhängigkeit. Die Community ist kleiner geworden seit Ansible den Markt dominiert — weniger Module, weniger Updates, weniger Hilfe auf Stack Overflow

Ohne IaC

  • Manuelle Konfiguration über SSH und Klick-Interfaces
  • Snowflake-Server — jede Maschine ist ein Unikat
  • "Works on my machine" als Standardantwort
  • Dokumentation veraltet am Tag nach der Erstellung
  • Disaster Recovery heißt: hoffen, dass jemand sich erinnert

Mit IaC

  • Reproduzierbar — jede Umgebung entsteht aus dem gleichen Code
  • Versioniert — git log zeigt wer wann was geändert hat
  • Reviewbar — Änderungen durchlaufen Pull Requests
  • git diff zeigt was sich geändert hat
  • git revert macht es rückgängig

Praxis-Tipp

Die Wahl des Tools ist weniger wichtig als die Disziplin es konsequent einzusetzen. Ein gut gepflegtes Ansible-Repository schlägt jedes Terraform-Setup das nur halb durchgezogen wurde. Entscheidend ist: Kein manueller Eingriff ohne Code-Änderung. Kein Deploy ohne Pipeline. Kein Drift ohne Alert.

Automatisierung im Kopf? Lassen Sie uns über Ihren Stack sprechen