Terraform vs Ansible

Workflow:

1. terraform apply: Erstellt EC2 Instanz. Output: ip = 1.2.3.4.
2. Terraform ruft Ansible auf (local-exec) oder du machst es manuell.
3. ansible-playbook -i 1.2.3.4 site.yml: Installiert Docker und startet die App.

Trend (Immutable Infrastructure): Man nutzt Terraform, um ein fertiges Image (AMI) zu starten, das mit Packer gebaut wurde. Ansible wird dann gar nicht mehr auf dem Server ausgeführt ("No SSH needed"). Ansible wird nur noch genutzt, um das Image vorher zu bauen.

1. Declarative vs Procedural

• Terraform (Deklarativ): "Ich will 5 Server." (Wenn schon 2 da sind, baut es 3 dazu). State File ist zwingend.
• Ansible (Prozedural):* "Führe Schritt 1, 2, 3 aus." (Es hat Module, die idempotent sind, aber du schreibst oft imperativen Code). Kein State File.

2. State Management

Das Killer-Argument für Terraform. Da Terraform den State hat, kann es Ressourcen löschen. Wenn du im Code eine Ressource entfernst, killt Terraform sie in echt. Ansible hat keinen State. Wenn du eine Task "Installiere Apache" löschst, bleibt Apache auf dem Server installiert. Ansible kann Infrastruktur nur schwer "aufräumen".

3. Agentless Architecture

Ansible gewinnt hier. Es braucht nichts auf dem Zielserver (nur SSH + Python). Andere Tools (Chef, Puppet) brauchen einen Agenten. Terraform braucht nur API-Zugriff zur Cloud (AWS), keinen Zugriff auf den Server selbst.

1. Push vs. Pull Architektur

Der technische Unterschied liegt im Verbindungsaufbau:

• Ansible (Push): Der Admin-Rechner "pusht" Befehle aktiv per SSH an die Server. Vorteil: Keine Infrastruktur auf den Servern nötig. Nachteil: Wenn ein Server während des Pushs offline ist, verpasst er die Änderung.
• Alternative Pull (Chef/Puppet): Ein Agent auf dem Server fragt regelmäßig beim Master: "Gibt es neue Befehle?" (Pull). Terraform ist hier ein Sonderfall: Es "pusht" API-Calls an den Cloud-Provider (AWS), aber es verbindet sich (meistens) nicht direkt mit dem Betriebssystem der Server.

2. State vs. No-State Design

Ansible ist statuslos. Es vertraut auf die Idempotenz seiner Module. Ein Modul wie apt: name=nginx state=present prüft erst: "Ist Nginx da?". Wenn ja, tut es nichts. Terraform hingegen vertraut seinem State File. Wenn darin steht, dass eine Firewall-Regel existiert, aber du sie manuell im AWS-Dashboard löschst, merkt Terraform das beim nächsten plan (Drift Detection). Es sieht, dass der Ist-Zustand (AWS) nicht mehr zum Soll-Zustand (State) passt, und bietet an, die Regel wiederherzustellen. Ansible merkt einen solchen "Drift" oft erst, wenn eine Task fehlschlägt.

3. Orchestrierung vs. Konfiguration

In modernen Pipelines nutzt man oft den "Infrastructure Life Cycle":

• Phase 1 (Day 0): Terraform baut das Fundament (VPC, Subnetze, IAM Rollen).
• Phase 2 (Day 1): Ansible (oder Tools wie Cloud-Init) konfiguriert die Software auf den Instanzen. Häufiger Trend: Terraform Only. Man nutzt Terraform, um einen Kubernetes-Cluster zu bauen. Die Konfiguration der Software übernimmt dann kein Ansible mehr, sondern K8s-native Tools wie Helm oder ArgoCD. Ansible wird in der Cloud-Native Welt zunehmend in den Bereich "Wartung von Legacy-Linux-Servern" verdrängt.