Terraform oder Ansible: Welches Werkzeug du wofür einsetzt
Terraform erzeugt Infrastruktur, Ansible konfiguriert sie. Die beiden konkurrieren nicht, sie greifen ineinander. Wer Server mit Ansible provisioniert oder Software mit Terraform ausrollt, kämpft dauerhaft gegen das jeweilige Werkzeug.
Warum die Abgrenzung in der Praxis so oft verschwimmt
Der typische Ausgangspunkt sieht so aus: Es gibt gewachsene Shell-Skripte, ein paar Ansible-Playbooks für die Paketinstallation und irgendwo eine Handvoll VMs, die jemand vor drei Jahren im Portal angeklickt hat. Sobald ein zweites Rechenzentrum, ein Cloud-Konto oder eine Staging-Umgebung dazukommt, reicht das nicht mehr. Reproduzierbarkeit heißt dann, dass Netzwerke, Subnetze, Security Groups, Load Balancer und Instanzen aus einer versionierten Beschreibung entstehen und nicht aus einem Ticketverlauf.
Genau hier liegt die Trennlinie. Terraform beziehungsweise der Fork OpenTofu beschreibt den Zielzustand von Ressourcen deklarativ, gleicht ihn über Provider-APIs ab und führt Buch darüber in einer State-Datei. Ansible ist prozedural aufgebaut, arbeitet agentenlos über SSH oder WinRM und bringt einen bereits existierenden Host in den gewünschten Konfigurationszustand: Pakete, systemd-Units, Dateien, Benutzer, Firewall-Regeln über nftables. Beide Werkzeuge können theoretisch das andere Feld mitbedienen, und genau daraus entstehen die Probleme.
Die typischen Fehler sind gut dokumentiert. VMs werden mit dem Ansible-Cloud-Modul angelegt, wodurch niemand mehr sauber erkennt, welche Ressourcen zum Stack gehören und ein Rückbau zur Handarbeit wird. Oder Terraform bekommt lange provisioner-Blöcke mit remote-exec, die bei jedem Fehlschlag den State inkonsistent hinterlassen. Dazu kommt die State-Datei im lokalen Verzeichnis oder im Git-Repository, ohne Remote-Backend und ohne State Locking, was bei zwei parallel laufenden Applies zu zerstörten Ressourcen führen kann.
Von der API bis zum Workload: Wer macht was
- 01 Terraform oder OpenTofu: Ressourcen provisionieren
- 02 Remote State mit Locking und Umgebungstrennung
- 03 Dynamisches Inventory aus Tags und Outputs
- 04 Ansible: Betriebssystem und Dienste konfigurieren
- 05 CI/CD: Plan, Review, Apply, Prüfung
- 06 GitOps: Workloads im Cluster abgleichen
So sieht eine saubere Aufgabenteilung aus
Die belastbare Antwort auf die Frage Terraform oder Ansible lautet in den meisten Umgebungen: beides, aber mit klar gezogener Grenze. Terraform oder OpenTofu erzeugt und verwaltet die Ressourcen, Ansible konfiguriert, was darin läuft. Diese Punkte bringen dich zu einem Aufbau, der auch nach zwei Jahren noch wartbar ist.
Grenze am Lebenszyklus ziehen
Alles, was eine Cloud- oder Hypervisor-API anlegt und löscht, gehört zu Terraform: Netze, Storage, Instanzen, DNS-Einträge, Kubernetes-Cluster, IAM-Rollen. Alles, was innerhalb eines laufenden Betriebssystems passiert, gehört zu Ansible. Diese eine Regel löst die meisten Streitfälle im Team.
State ernst nehmen
Der Terraform-State gehört in ein Remote-Backend mit Locking, etwa S3 mit DynamoDB, einen HTTP-Backend-Dienst im GitLab oder Consul. Dazu kommen getrennte States pro Umgebung, ein Umgang mit terraform import für bestehende Ressourcen und die Erkenntnis, dass Secrets im State im Klartext landen können und der Zugriff darauf entsprechend beschränkt werden muss.
Module und Rollen sauber schneiden
In Terraform kapselst du wiederkehrende Bausteine in Module mit klaren Variablen und Outputs statt in kopierte Verzeichnisse. In Ansible entspricht dem die Rolle mit definierten defaults, handlers und Molecule-Tests. In beiden Fällen gilt: kleine, versionierte Einheiten statt einer großen Datei, die niemand mehr anfasst.
Die Übergabe zwischen beiden Werkzeugen definieren
Der saubere Weg führt über ein dynamisches Inventory, das Ansible seine Hosts direkt aus Cloud-Tags oder aus Terraform-Outputs zieht, statt über hartkodierte IP-Listen. Alternativ übernimmt cloud-init nur das Minimum für den SSH-Zugang, und der eigentliche Konfigurationslauf startet danach als eigener Pipeline-Schritt.
Idempotenz prüfen statt annehmen
Ein terraform plan ohne Änderungen und ein zweiter Ansible-Lauf mit changed=0 sind die einzigen belastbaren Belege dafür, dass deine Automatisierung wirklich zustandsorientiert arbeitet. Wo command und shell ohne creates oder changed_when stehen, ist diese Eigenschaft meist schon verloren.
Beides in Pipeline und GitOps einhängen
Plan im Merge Request, Apply nach Review und Freigabe, dazu Policy-Prüfungen und ein Scan der Konfiguration vor dem Rollout. Für Kubernetes-Workloads übernimmt danach ein GitOps-Werkzeug wie Argo CD oder Flux, während Terraform den Cluster selbst und Ansible die Knoten außerhalb des Clusters verantwortet.
Kurse zu Terraform und Ansible bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Teste dich und finde deinen Weg
Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.
Häufige Fragen zu Terraform und Ansible
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktKann ich Terraform komplett durch Ansible ersetzen?
Kann ich Ansible komplett durch Terraform ersetzen?
Was bedeutet die Aufspaltung in Terraform und OpenTofu für meine Entscheidung?
Brauche ich Ansible noch, wenn ich alles auf Kubernetes betreibe?
Womit fange ich an, wenn heute noch alles über Shell-Skripte läuft?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
Automatisierung im Kurs sauber aufsetzen
Bei cmt kannst du beide Seiten lernen: den Ansible Kompaktkurs für den Einstieg ins Konfigurationsmanagement, den Kurs Ansible für Fortgeschrittene gegen Playbook-Chaos sowie die Terraform-Kurse für AWS und Azure von der Einführung bis zum Aufbaukurs. Wenn du Infrastructure as Code direkt mit GitOps verbinden willst, schau dir den Kurs zu Terraform und GitOps an. Alle Termine gibt es Live-Online oder als Inhouse-Schulung. Sag uns kurz, wie deine Umgebung aussieht, dann sortieren wir gemeinsam die passende Reihenfolge.