Sollte ich Ansible heute noch nutzen?

In der modernen DevOps-Welt, dominiert von Kubernetes, Serverless und GitOps, wirkt Ansible auf den ersten Blick fast schon “klassisch”. Mit dem Aufstieg von deklarativen Infrastructure-as-Code (IaC) Tools wie Terraform, OpenTofu oder Pulumi stellen sich viele Teams die Frage: “Brauchen wir Ansible überhaupt noch?”

Die kurze Antwort ist: Ja. Aber nicht mehr für alles.

Die Rolle von Ansible hat sich gewandelt. Es ist nicht mehr das “Einer-für-alles”-Tool, das Cloud-Ressourcen provisioniert und Software konfiguriert. Um eine robuste, wartbare Infrastruktur zu bauen, müssen wir die Werkzeuge dort einsetzen, wo sie glänzen.

Hier ist mein Ansatz, wie OpenTofu, Cloud-Init und Ansible zusammenspielen sollten.

---

1. Die Infrastruktur-Ebene: Warum Ansible hier verliert

Früher haben wir oft Ansible-Module genutzt, um EC2-Instanzen oder Azure-Ressourcen zu starten. Das ist möglich, aber es fehlt ein entscheidendes Feature, das Tools wie OpenTofu oder Terraform mitbringen: State Management.

Ansible ist prozedural (“Tu dies, dann tu das”). OpenTofu ist deklarativ (“Ich will, dass die Welt so aussieht”). Wenn du eine Ressource aus deinem Code löschst, weiß OpenTofu durch sein State-File, dass es diese Ressource in der Cloud zerstören muss. Ansible würde sie einfach ignorieren, da der Task nicht mehr existiert.

Daher gilt für die pure Infrastruktur: Nutze OpenTofu, Terraform oder Pulumi für alles, was eine API hat und einen Lebenszyklus besitzt (VMs, VPCs, Load Balancer, Datenbanken). Hier ist das State-Handling unverzichtbar.

---

2. Die Lücke beim Bootstrapping: Cloud-Init

Wenn OpenTofu die virtuelle Maschine (VM) erstellt hat, stehen wir vor einem Problem: Wie kommen wir auf die Maschine drauf? Wie authentifizieren wir uns?

Hier kommt Cloud-Init ins Spiel. Es ist der Industriestandard für das “Early Bootstrapping”.

Cloud-Init ist perfekt für die “Day 0”-Konfiguration:

• Anlegen des initialen Users (z.B. eines ansible-Users).
• Hinterlegen der SSH-Public-Keys.
• Setzen des Hostnames.
• Initiale Paket-Updates.

Aber Vorsicht: Cloud-Init ist kein Configuration-Management-Tool. Es feuert in der Regel nur einmal beim ersten Boot. Wenn du später eine Konfiguration ändern willst, ist Cloud-Init das falsche Werkzeug. Es ist der “Zündschlüssel”, nicht der “Mechaniker”.

---

3. Configuration Management: Wo Ansible unschlagbar ist

Sobald die VM läuft und wir per SSH (dank Cloud-Init) Zugriff haben, beginnt die Domäne von Ansible.

Warum nicht einfach alles mit Shell-Skripten via Terraform remote-exec machen? Weil Shell-Skripte schnell unübersichtlich werden und Fehlerbehandlung (Error Handling) schwierig ist. Warum nicht alles ins VM-Image (Golden Image) backen? Weil das Bauen von Images (z.B. mit Packer) zeitaufwendig ist und Änderungen eine komplette Neuerstellung der VM erfordern.

Ansible ist der König der “Day 1” und “Day 2” Operations:

• Software-Installation & Konfiguration: Nginx installieren, Config-Files templaten (Jinja2), Services restarten. Das ist Ansibles Kernkompetenz.
• Idempotenz: Ansible stellt sicher, dass ein Playbook mehrfach ausgeführt werden kann, ohne Schaden anzurichten. Es ändert nur das, was abweicht.
• Agentless: Im Gegensatz zu Chef oder Puppet brauchst du keinen Agenten auf der Zielmaschine. SSH reicht.

Besonders für komplexe Applikations-Setups innerhalb von Linux, die nicht containerisiert sind (oder die Container-Runtime selbst), bietet Ansible eine Granularität und Lesbarkeit, die Terraform oder Pulumi nicht erreichen können.

---

4. Ein Sonderfall: Ansible und Kubernetes

Ein häufiger Streitpunkt ist die Rolle von Ansible im Kubernetes-Umfeld.

Warum Ansible nicht für das Deployment geeignet ist: Obwohl es Ansible-Module (kubernetes.core.k8s) gibt, um Manifeste auf einen Cluster anzuwenden, ist dies oft nicht der optimale Weg. Kubernetes ist nativ deklarativ. Tools wie Helm, Kustomize oder insbesondere GitOps-Lösungen (ArgoCD, Flux) sind hier weit überlegen, da sie den Zustand des Clusters kontinuierlich überwachen und abgleichen. Ansible hier “hineinzuzwingen” fühlt sich oft wie ein Fremdkörper an und bricht den GitOps-Workflow.

Die Ausnahme: Das Ansible Operator SDK Es gibt jedoch einen Bereich, in dem Ansible im Cluster glänzt: Das Ansible Operator SDK. Wenn du komplexe Applikationen auf Kubernetes betreiben willst, benötigst du oft einen “Operator”, der Day-2-Operations (wie Backups, Failover, Re-Sharding) automatisiert. Normalerweise müsste man diese Operatoren aufwändig in Go programmieren.

Mit dem Ansible Operator SDK kannst du diese Logik stattdessen in Ansible schreiben. Der Operator führt dann im Hintergrund Ansible-Rollen aus, wenn sich der Status einer Ressource im Cluster ändert. Für Teams, die bereits fit in Ansible sind, ist dies eine massive Erleichterung, um native Kubernetes-Erweiterungen zu bauen, ohne eine neue Programmiersprache lernen zu müssen.

---

Das Fazit: Die “Holy Trinity” der Provisionierung

Die Frage ist also nicht “OpenTofu oder Ansible?”, sondern “Wie kombiniere ich sie am besten?”.

Hier ist der ideale Workflow, den ich für die meisten Cloud-Setups empfehle:

1. Provisionierung (OpenTofu/Terraform): Erstellt die Netzwerke, Firewalls und die VM selbst.
2. Bootstrapping (Cloud-Init): Wird von OpenTofu als user_data an die VM übergeben. Es legt nur den User an und platziert den SSH-Key, damit Ansible zugreifen kann.
3. Konfiguration (Ansible): Verbindet sich auf die laufende Instanz, installiert Docker/Kubernetes/Applikationen, härtet das OS und managt zukünftige Updates.

Indem wir die Schichten trennen, erhalten wir das Beste aus beiden Welten: Eine saubere, verwaltete Infrastruktur-Basis und eine flexible, mächtige Software-Konfiguration.

Nutzt du noch Ansible für alles oder hast du deine Stacks bereits getrennt? Lass uns auf LinkedIn diskutieren oder schreib mir direkt.