Terraform vs. Ansible: Welches Tool brauchst du wirklich?

Menschen, die neu im Bereich Infrastructure as Code sind, stellen diese Frage normalerweise auf eine von zwei Arten: "Welches Tool sollte ich zuerst lernen" oder "Warum nutzen Teams beide Tools." Die kurze Antwort ist, dass Terraform und Ansible verschiedene Probleme lösen, und die meisten Production-Setups nutzen sie zusammen, anstatt sich für eines zu entscheiden.

Wofür Terraform wirklich da ist

Terraform ist ein Provisioning-Tool. Es deklariert, welche Infrastruktur existieren sollte: eine VPC, drei EC2-Instanzen, eine RDS-Datenbank, einen S3-Bucket mit einer bestimmten Policy. Du schreibst HCL, das den Endzustand beschreibt, führst terraform plan aus, um zu sehen, was sich ändert, und dann terraform apply, um es umzusetzen. Terraform führt eine State-Datei (lokal oder in einem Backend wie einem S3-Bucket mit DynamoDB-Locking), die deine Konfiguration auf echte Ressourcen-IDs beim Cloud-Provider abbildet.

Die Stärke liegt hier in der Dependency-Auflösung über Provider hinweg. Wenn du Terraform anweist, eine Security Group zu erstellen und diese dann an eine EC2-Instanz zu attach, berechnet es die Reihenfolge automatisch. Es funktioniert auch über AWS, Azure, GCP, Cloudflare, Datadog und Dutzende andere Provider mit demselben Workflow, was relevant wird, wenn deine Infrastruktur mehrere Anbieter umfasst.

Terraform ist schlecht bei allem, was innerhalb der Maschine passiert, nachdem sie existiert. Es installiert keine Pakete, bearbeitet keine Config-Dateien und startet Services nicht auf sinnvolle, laufende Art neu. Provisioner wie remote-exec existieren, aber HashiCorp selbst empfiehlt, sie für alles über das Bootstrapping hinaus zu vermeiden.

Wofür Ansible wirklich da ist

Ansible ist ein Configuration-Management-Tool. Es verbindet sich über SSH (oder WinRM für Windows) und führt Tasks auf Maschinen aus, die bereits existieren: nginx installieren, eine Config-Datei templaten, einen User anlegen, einen Service neu starten, sicherstellen, dass ein Cron-Job vorhanden ist. Playbooks sind YAML, und Module sind von Design her idempotent, also sollte das zweimalige Ausführen desselben Playbooks nichts mehr ändern, wenn das System bereits den gewünschten Zustand hat.

Ansible benötigt keine Agents auf den Ziel-Hosts, nur Python und SSH-Zugang, was es einfach macht, es auf bestehende Infrastruktur zu aufzusetzen. Es ist auch gut für Orchestrations-Tasks, die nicht streng "Provisioning" sind — Rolling Restarts über eine Fleet, Blue-Green-Deploy-Schritte, Datenmigration auf einem Host ausführen und dann einen Load Balancer aktualisieren.

Wo sie sich überlappen und wo Verwirrtheit entsteht

Beiden Tools können technisch ein bisschen von der Aufgabe des anderen übernehmen. Ansible hat Cloud-Module (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine), die Infrastruktur hochfahren können. Terraform hat Provisioner, die Shell-Befehle auf einer neuen Instanz ausführen können. Aber Ansible für Provisioning zu nutzen bedeutet, Terraforms State-Tracking und Plan/Diff-Workflow aufzugeben, und Terraform-Provisioner für Configuration zu nutzen bedeutet, auf idempotentes, wiederholbares Configuration Management zu verzichten.

Die praktische Aufteilung, bei der die meisten Teams landen:

• Terraform baut die Infrastruktur: Netzwerke, Compute-Instanzen, Load Balancer, verwaltete Datenbanken, IAM-Rollen.
• Ansible konfiguriert, was obendrauf kommt: Software-Installationen, User, Config-Dateien, Service-Status, Application-Deployment-Schritte.

Ein konkretes Beispiel der Übergabe

Sagen wir, du stellst drei Web-Server hinter einem Load Balancer auf AWS auf.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform erstellt die Instanzen und gibt ihre IPs aus. Du kannst diese Ausgabe in ein dynamisches Ansible-Inventory einspeisen (das amazon.aws.aws_ec2-Inventory-Plugin liest EC2-Tags direkt, kein manuelles Copy-Paste nötig) und dann ausführen:

ansible-playbook -i aws_ec2.yml site.yml

wobei site.yml nginx installiert, die App-Config einfügt und den Service startet. Terraform berührt nginx nie. Ansible berührt die VPC nie. Jedes Tool bleibt in seiner Spur, und jedes hat sein eigenes State/Idempotenz-Modell, das nicht mit dem des anderen konflikt.

Häufige Fehler, die es zu vermeiden gilt

Terraform-State in git zu speichern ist der häufigste frühe Fehler — State-Dateien können Secrets im Klartext enthalten und verursachen Merge Conflicts, die dein Infrastruktur-Modell beschädigen. Nutze ein Remote Backend von Anfang an.

Bei Ansible ist der Fehler, Playbooks zu schreiben, die nicht wirklich idempotent sind — shell- oder command-Module für Dinge zu nutzen, die ein ordentliches Modul haben (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd), das die Check-Then-Act-Logik bereits korrekt handhabt.

Wenn du entscheidest, was du zuerst lernen sollst: Lerne Terraform, wenn du Cloud-Provisioning und Multi-Environment-Setups machst, lerne Ansible, wenn du Config Drift auf Servern managst, die du bereits hast. Die meisten DevOps-Rollen erwarten Vertrautheit mit beiden innerhalb des ersten Jahres.

Mehr zum State Management, dynamischen Inventories und zum Aufbau einer vollständigen CI/CD-Pipeline rund um diese Tools findest du in den verwandten DevOps- und Cloud-Segmenten auf Korra Studio.