Ansible vs Terraform: Der Vergleich für Einsteiger

Die Cloud-Konsole meldet einen laufenden Server. Der Browser zeigt „Verbindung abgelehnt“. Beides kann stimmen: Eine Maschine anzulegen und eine nutzbare Anwendung bereitzustellen sind unterschiedliche Aufgaben.

Ansible vs Terraform wird an dieser Grenze verständlich. Terraform ist meist der bessere Ausgangspunkt für Infrastrukturressourcen. Ansible ist meist der bessere Ausgangspunkt für Systemkonfiguration und koordinierte Betriebsaufgaben. Viele Teams nutzen beide; kleinere Systeme kommen häufig mit einem Werkzeug aus. Entscheidend ist, wer welchen Teil der Arbeit übernimmt.

Ansible vs Terraform: die schnelle Entscheidung

Das ist eine Rangfolge nach Aufgabe, keine Punktewertung. Sobald klar ist, was sich ändern soll und wer es anschließend betreibt, lässt sich „Was ist besser?“ sinnvoll beantworten.

Fünf Grundbegriffe ohne Vorwissen

Infrastructure as Code (IaC) bedeutet, Infrastruktur in versionierten Dateien zu beschreiben, damit Änderungen überprüfbar und wiederholbar werden. Provisionierung erstellt oder verändert Ressourcen wie Netzwerke, virtuelle Maschinen oder Datenbanken. Konfigurationsmanagement bringt ausgewählte Einstellungen eines Systems auf ihren Sollwert: Ein Paket ist installiert, eine Datei hat bestimmten Inhalt, ein Dienst startet automatisch.

Der Sollzustand beschreibt das gewünschte Ergebnis. Drift bezeichnet Abweichungen zwischen dieser Absicht und dem tatsächlichen Zustand. Beide Begriffe helfen bei beiden Werkzeugen; sie gehören nicht exklusiv zu Terraform.

Als Bild eignet sich ein Gebäude: Terraform verwaltet häufig Grundstück, Rohbau und Anschlüsse. Ansible richtet häufig die Ausstattung ein. Die Analogie hat Grenzen: Beide Werkzeuge können APIs ansprechen, und manche Infrastruktur benötigt überhaupt keinen konfigurierbaren Gast.

Was Terraform tatsächlich macht

Du schreibst Konfiguration, üblicherweise in HCL. Provider verbinden Terraform mit den APIs von Cloud- und anderen Diensten. Eine resource beschreibt ein verwaltetes Objekt, eine data-Quelle liest Informationen. Referenzen zwischen Werten stellen Abhängigkeiten her. Terraform kann dadurch Operationen ordnen, ohne dass du jede Reihenfolge als Shell-Skript formulieren musst. Terraform-Einführung

Der typische Ablauf:

terraform init
terraform plan -out=reviewed.tfplan
terraform apply reviewed.tfplan

init bereitet Arbeitsverzeichnis und Provider vor. plan schlägt Änderungen vor. Das Anwenden des gespeicherten Plans führt die geprüften Aktionen aus. Berechtigungen, Quoten, Verfügbarkeit oder veränderte Bedingungen können trotzdem zu Fehlern führen. Prüfe insbesondere Ersetzungen und Löschungen, nicht nur die Gesamtzahl der Änderungen. Plan-Referenz

Hinzu kommt der State. Er verbindet eine Konfigurationsadresse wie aws_instance.web mit der Identität einer tatsächlichen Ressource. Terraform sucht nicht einfach nach einem Objekt mit passendem Anzeigenamen. Der State enthält außerdem Informationen für spätere Operationen und ist deshalb eine betriebliche Abhängigkeit, kein beliebig löschbarer Cache. State-Dokumentation

Nach dem Ende von apply überwacht Terraform CLI deine Cloud nicht dauerhaft. Eine erneute Ausführung, ein geplanter Job oder eine Plattformfunktion muss wieder nach Abweichungen suchen. Der kontinuierliche Abgleich von Argo CD und Flux ist ein anderes Betriebsmodell.

Was Ansible tatsächlich macht

Am Anfang steht ein Inventory: Hosts und Gruppen mit Verbindungsdaten und Variablen. Ein Playbook enthält Plays, die Ziele auswählen und Tasks ausführen. Ein Modul übernimmt eine bestimmte Aktion; Collections bündeln Module und Plugins. Rollen strukturieren wiederverwendbare Automatisierung. Ansible-Grundbegriffe

Für einen Linux-Server könnten die Aufgaben so aussehen:

- name: Ensure nginx is installed
  ansible.builtin.apt:
    name: nginx
    state: present

- name: Ensure nginx runs at boot and now
  ansible.builtin.service:
    name: nginx
    enabled: true
    state: started

Das sind Sollzustandsbeschreibungen, obwohl die Reihenfolge der Tasks ebenfalls relevant ist. Unter der Standardstrategie führt Ansible Aufgaben normalerweise in Playbook-Reihenfolge aus; Strategien und weitere Einstellungen beeinflussen das Verhalten. Playbook-Dokumentation

Agentless bedeutet, dass ein normal verwalteter Linux-Host keinen dauerhaft laufenden Ansible-Daemon benötigt. Eine funktionierende Verbindung, passende Berechtigungen und Modulabhängigkeiten bleiben notwendig, häufig auch Python. Windows, Netzwerkgeräte und API-Module können andere Transportwege oder Ausführungsorte nutzen. Auch der Control Node muss gepflegt werden.

Unterscheide außerdem ansible-core, das Ansible-Community-Paket und Red Hat Ansible Automation Platform. Core enthält Laufzeit und eingebaute Plugins, das Community-Paket ausgewählte Collections. Die Enterprise-Plattform ergänzt eine unterstützte Betriebsumgebung und organisatorische Funktionen. Das sind keine austauschbaren Produktbezeichnungen. Releases und Wartung

Die Unterschiede nach dem ersten Tutorial

Deklarativ gegen imperativ erklärt zu wenig

Eine Terraform-Ressource beschreibt ein gewünschtes Objekt. Ein Ansible-Task mit apt und state: present beschreibt ebenfalls einen Sollzustand. Ein Shell-Aufruf in Ansible kann dagegen beliebige Aktionen ausführen; ihre Sicherheit entsteht nicht durch das YAML-Format.

Idempotenz bedeutet, dass eine wiederholte Operation bei gleichen relevanten Bedingungen das Ergebnis nicht immer weiter verändert. Ein Modul mit festem Dateiinhalt kann idempotent sein. Ein Befehl, der bei jedem Lauf eine Zeile anhängt, wird nicht dadurch idempotent, dass Ansible ihn startet.

Ein leerer Terraform-Plan bedeutet, dass für die verwalteten Ressourcen und Attribute keine Änderungen vorgeschlagen werden. Er beweist weder ein unverändertes Gastbetriebssystem noch eine funktionierende Anwendung.

Automatisierung wird vertrauenswürdiger, wenn ihre Zuständigkeit eindeutiger ist als die Liste ihrer technischen Möglichkeiten.

State und Inventory unterscheiden sich nicht nur im Dateiformat

Terraform-State speichert Ressourcenidentität. Das Ansible-Inventory bestimmt die Ziele. Ein Inventory kann automatisch aus Cloud-APIs entstehen, wird dadurch aber nicht zu Terraform-State. Inventory-Anleitung

Das zeigt sich beim Löschen: Verschwindet eine VM aus einer Ansible-Gruppe, wird sie nicht mehr angesprochen, bleibt aber bestehen. Entfernst du eine Terraform-verwaltete VM aus der Konfiguration, schlägt der nächste Plan normalerweise ihre Zerstörung vor. Löschpläne immer lesen. Lifecycle-Einstellungen und bewusste State-Operationen können dieses Verhalten beeinflussen; zum Experimentieren gehört eine isolierte Umgebung. Lifecycle-Referenz

Vorhandene Ressourcen lassen sich über Import unter Terraform-Verwaltung bringen. Auch dafür braucht es passende Konfiguration und Prüfung. Import macht nicht auf Knopfdruck ein ganzes Cloud-Konto sicher verwaltet. Import-Überblick

Terraform plan und Ansible –check im Vergleich

Terraform plant Ressourcenoperationen anhand von Konfiguration, State und Provider-Abfragen. Manche Werte stehen erst während apply fest. Ein Plan führt keine beliebige Konfiguration innerhalb des Gasts aus.

Ansible --check lässt unterstützte Module Änderungen vorhersagen. --diff zeigt dort, wo es unterstützt wird, Vorher/Nachher-Unterschiede. Abhängigkeiten von Ergebnissen vorheriger Tasks können eine Simulation einschränken. Ein Task kann den Check-Modus außerdem ausdrücklich umgehen. Check- und Diff-Modus

ansible-playbook -i inventory.json site.yml --check --diff

Nutze beide Vorschauen und ergänze Anwendungstests. Ein erfolgreiches Apply und ein Playbook ohne Fehler beweisen noch nicht, dass DNS, TLS, Backend oder Zugriffsrechte richtig funktionieren.

Praxisbeispiel: Terraform erstellt eine VM, Ansible konfiguriert nginx

Das Beispiel verwendet eine private Ubuntu-EC2-Instanz. Terraform besitzt den VM-Lebenszyklus. Ansible verwaltet nginx, eine statische HTML-Datei und den laufenden/aktivierten Dienst. Bestehendes Netzwerk und SSH-Zugang werden als Voraussetzungen bereitgestellt.

Lade main.tf, site.yml, Beispielvariablen und die vollständigen Einrichtungs- und Aufräumhinweise herunter. Die Ausschnitte erklären die wichtigen Stellen; für den Ablauf gehören die vollständigen Dateien zusammen.

1. Voraussetzungen vorbereiten

Verwende ein separates Testkonto oder eine isolierte Laborumgebung. Benötigt werden Terraform, eine unterstützte Ansible/Python-Kombination, AWS-Zugangsdaten, eine freigegebene Ubuntu-amd64-AMI in der gewählten Region, ein vorhandenes Subnetz mit Security Group und ein EC2-Schlüsselpaar. Der private Schlüssel bleibt beim Controller, möglichst im SSH-Agent.

Der Controller benötigt eine Route zur privaten IP, etwa über einen Runner in der VPC, ein VPN oder einen korrekt eingerichteten Bastion-Host. Erlaube SSH nur vom Controller und HTTP nur vom Testclient. Für Pakete braucht die VM kontrollierten DNS-/Repository-Zugriff über vorhandenen Egress oder einen Mirror. Das Beispiel erstellt keine öffentliche IP, kein NAT Gateway, keine VPC und keine Firewallregeln.

Prüfe den SSH-Hostschlüssel über einen vertrauenswürdigen Kanal und pflege known_hosts; schalte die Prüfung nicht ab. Das Image muss Python, apt und passende sudo-Rechte bereitstellen. Warte auf den Abschluss der initialen Image-Einrichtung. Die Cloud-Ressourcen sind kostenpflichtig; dies ist kein versprochenes Free-Tier-Labor.

2. Die VM mit Terraform beschreiben

Die vollständige Datei deklariert Provider und Variablen. Ihre zentrale Ressource:

resource "aws_instance" "web" {
  ami                         = var.ubuntu_ami_id
  instance_type               = "t3.micro"
  subnet_id                   = var.subnet_id
  vpc_security_group_ids       = [var.security_group_id]
  key_name                    = var.ssh_key_name
  associate_public_ip_address = false

  metadata_options {
    http_tokens = "required"
  }
  root_block_device {
    encrypted = true
  }
  tags = {
    Name = "ansible-terraform-demo"
  }
}

Die AMI-ID ist eine explizite Eingabe: Du wählst ein geprüftes Image statt stillschweigend das jeweils neueste. Verschlüsselter Root-Speicher und erforderliche IMDSv2-Tokens ersetzen keine saubere Konto-, Netzwerk- und IAM-Konfiguration. Offizielle AWS-Provider-Dokumentation

Kopiere terraform.tfvars.example nach terraform.tfvars und ersetze sämtliche Platzhalter. Danach:

terraform init
terraform fmt -check
terraform validate
terraform plan -out=demo.tfplan
terraform apply demo.tfplan

State, sensible Variablendateien und gespeicherte Pläne gehören nicht in Git. Die geprüfte .terraform.lock.hcl dagegen schon: Sie hält die Provider-Auswahl für Team und CI fest. Lokaler State genügt hier für das Einpersonen-Labor; gemeinsamer Betrieb braucht ein abgesichertes Backend.

3. Ein Inventory als klare Übergabe exportieren

Terraform gibt nur die Verbindungsdaten aus, die Ansible braucht:

output "ansible_inventory" {
  value = {
    all = {
      children = {
        web = {
          hosts = {
            web1 = { ansible_host = aws_instance.web.private_ip }
          }
          vars = { ansible_user = "ubuntu" }
        }
      }
    }
  }
}

terraform output -json ansible_inventory > inventory.json
ansible-inventory -i inventory.json --graph
ansible web -i inventory.json -m ansible.builtin.wait_for_connection -a 'timeout=180'

Bei einer benannten Ausgabe liefert terraform output -json direkt deren Wert. Das YAML-Inventory-Plugin von Ansible akzeptiert standardmäßig auch .json. Ein privater Schlüssel wird nicht exportiert. Erzeuge das Inventory nach Infrastrukturänderungen neu, damit keine veraltete Adresse zum Ziel wird. Terraform output, Ansible-Inventory-Plugin

Der Verbindungstest wartet auf einen nutzbaren Ansible-Zugang. Eine erfolgreiche EC2-API-Antwort bedeutet noch nicht, dass der Gast bereit ist. Routing und die Prüfung unbekannter SSH-Hostschlüssel richtet der Task nicht ein. wait_for_connection

4. Den Gast mit Ansible konfigurieren

Das vollständige Playbook wählt die Gruppe web und verwendet become: true für privilegierte Paket- und Dienstoperationen. Drei Tasks installieren nginx, veröffentlichen festen Inhalt und starten/aktivieren den Dienst.

- name: Publish a deterministic home page
  ansible.builtin.copy:
    dest: /var/www/html/index.html
    content: "Infrastructure ready. Configuration managed.\n"
    owner: root
    group: root
    mode: "0644"

Explizite Dateirechte vermeiden eine Abhängigkeit von zufälligen Standardwerten. Copy-Modul

ansible-playbook -i inventory.json site.yml --syntax-check
ansible-playbook -i inventory.json site.yml --ask-become-pass
ansible-playbook -i inventory.json site.yml --check --diff --ask-become-pass
ansible-playbook -i inventory.json site.yml --ask-become-pass

Bei passwortlosem sudo entfällt --ask-become-pass. Auf einer frischen VM sollte die echte Installation vor der vollständigen Check-Vorschau stattfinden: Das vom Paket angelegte Webverzeichnis existiert vorher möglicherweise noch nicht.

Der apt-Task nutzt state: present statt eines bedingungslosen Upgrades. cache_valid_time begrenzt Cache-Aktualisierungen; abgelaufene Caches oder Repository-Änderungen können spätere Läufe dennoch beeinflussen. Der Dienst-Task verlangt started, nicht restarted, und fordert damit keinen Neustart bei jeder Ausführung an. Apt-Modul, Service-Modul

Rufe vom berechtigten Testclient http://PRIVATE_IP/ mit curl --fail auf. Die Adresse steht in inventory.json; die Antwort sollte dem verwalteten Text entsprechen. Das ist eine isolierte HTTP-Übung, keine internetfertige TLS-Konfiguration.

5. Wiederholung beobachten und aufräumen

Bei unveränderten Eingaben und stabiler Infrastruktur sollte der nächste Terraform-Plan keine Änderungen vorsehen. Ist der Gast eingerichtet, sollte der nächste Ansible-Lauf keine verwalteten Änderungen melden – abgesehen von Cache-Aktualisierungen oder geänderten äußeren Bedingungen. Das sind selbst zu prüfende Erwartungen, keine hier gemessenen Ergebnisse.

Ändere anschließend nur den Seitentext. Ansible sollte die Datei aktualisieren; Terraform sollte keine Änderung der Gastdatei planen. Dieses kleine Experiment macht die Verantwortungsgrenze sichtbar.

Prüfe zum Abschluss die Löschung im selben isolierten Arbeitsverzeichnis:

terraform plan -destroy -out=destroy.tfplan
terraform apply destroy.tfplan

Unter den Standardeinstellungen des Beispiels verschwinden die VM und ihr verwaltetes Root-Volume. Vorgegebene Netzwerkressourcen und das bestehende Schlüsselpaar liegen außerhalb der Konfiguration. Verbleibenden State und Backups schützen; erzeugte Inventories und Pläne entfernen, sobald sie nicht mehr benötigt werden.

Was passiert bei einem Fehler auf halbem Weg?

Die VM wurde angelegt, aber nginx ließ sich wegen eines unerreichbaren Paketservers nicht installieren. Terraforms Infrastruktur-Erfolg ist damit noch kein Anwendungserfolg. Behebe die Verbindung, prüfe den Host und starte Ansible erneut. Die VM muss nicht automatisch neu erstellt werden.

Keiner der Abläufe ist eine Transaktion über die gesamte Anwendung. Frühere erfolgreiche Schritte können nach einem späteren Fehler bestehen bleiben. Ein Ansible-Rollout kann manche Hosts aktualisiert haben, andere nicht. Eine Terraform-Ersetzung kann abhängige Ressourcen betreffen. Deshalb brauchen beide Wiederherstellungsschritte und Gesundheitstests.

Soll eine Konfigurationsänderung einen Dienst neu laden, nutze einen davon benachrichtigten Handler statt eines Neustarts bei jedem Lauf. Handler koordinieren Aktionen, bieten aber kein automatisches Rollback. Ansible-Handler

Ansible und Terraform gemeinsam einsetzen

Eine klare Aufteilung lautet: Ressourcenlebenszyklus → Verbindungsvertrag → Gastkonfiguration → Gesundheitstest. HashiCorp dokumentiert auch ein umfangreicheres Integrationsmuster mit HCP Terraform und Ansible Automation Platform. Dieses Muster stützt die Grundidee; zum Verständnis der Übergabe benötigst du nicht beide Enterprise-Plattformen. Offizielles Integrationsmuster

Halte die Zuständigkeiten fest:

• Terraform verwaltet Erstellung/Löschung der VM und die in seiner Konfiguration beschriebenen Cloud-Ressourcen.
• Ansible verwaltet ausdrücklich ausgewählte Pakete, Dateien, Konten und Dienste im Gast.
• Eine Pipeline prüft die Übergabe, koordiniert gleichzeitige Ausführungen und protokolliert Ergebnisse.
• Ein Anwendungstest prüft, ob der Dienst tatsächlich funktioniert.

Vermeide einen Ansible-Task, der dasselbe Cloud-Attribut wie Terraform verändert. Ebenso sollten cloud-init und Ansible nicht bei jedem Boot dieselbe Datei überschreiben. Das Problem sind konkurrierende Verantwortlichkeiten, auch wenn jeder einzelne Schreiber zuverlässig funktioniert.

Warum nicht alles aus einem Terraform-Provisioner starten?

local-exec kann Ansible aufrufen. Dadurch werden aber nicht alle Einstellungen im Gast Teil von Terraforms Ressourcenmodell. Konfigurationsfehler werden zusätzlich mit dem Infrastrukturlebenszyklus gekoppelt; Wiederholungen oder Ersetzungen können unerwartet wirken. HashiCorp empfiehlt Provisioner als letzte Option, wenn bessere Mechanismen fehlen. Provisioner-Empfehlungen

Bevorzuge eine separate Pipeline-Stufe, eine geeignete Integration oder einen Image-/Bootstrap-Ablauf. cloud-init passt zu einem kleinen initialen Bootstrap. Image-Building passt, wenn ein vorbereitetes System besser ersetzt als fortlaufend verändert wird. Die Entscheidung gehört zur Architektur; „Alle Befehle passen in eine .tf-Datei“ genügt nicht als Wartungskonzept.

Sicherheit: Beide Werkzeuge besitzen echte Berechtigungen

Terraform-State und gespeicherte Pläne können Geheimnisse enthalten. sensitive = true unterdrückt normale Anzeigen, verschlüsselt den Wert aber nicht automatisch und verhindert nicht grundsätzlich seine Speicherung. Unterstützte ephemere Mechanismen und Write-only-Argumente können die Persistenz in bestimmten Abläufen vermeiden; dafür müssen Terraform und Provider die benötigten Funktionen unterstützen. Sensible Daten, Ephemere Werte

Im Team braucht das Backend Verschlüsselung, Zugriffskontrolle und unterstütztes Locking. Ein Lock schützt State vor gleichzeitigen Schreibern; es koordiniert nicht jedes andere Werkzeug mit Zugriff auf Cloud oder Gast. Backups und ein getesteter Wiederherstellungsablauf bleiben nötig. State-Locking

Auch Ansible-Variablen, Debug-Ausgaben, Diffs und Zugangsdaten können Informationen preisgeben. Ansible Vault verschlüsselt Dateien und Variablen. Entschlüsselungszugriff und Laufzeitprotokolle brauchen trotzdem eigene Kontrollen. Es ist nicht derselbe Dienst wie HashiCorp Vault. Ansible Vault

Nutze möglichst kurzlebige Cloud-Zugangsdaten, prüfe SSH-Hosts, begrenze Rechteausweitung und kontrolliere Provider-/Collection-Abhängigkeiten. Der Runner führt Automatisierung mit den Rechten seiner Zugangsdaten aus. Der GitLab-CI/CD-Härtungsleitfaden behandelt diese Ausführungsgrenze; Workload Identity Federation erklärt die Ablösung langlebiger Cloud-Schlüssel.

Was sollten Einsteiger zuerst lernen?

Beginne mit Ansible, wenn Server bereits existieren. Verwalte eine Datei, ein Paket und einen Dienst und führe das Playbook zweimal aus. Verändere etwas in einer wegwerfbaren Umgebung und beobachte die Reparatur. Lerne Inventory, Variablen, Rechteausweitung und Handler vor einer großen Rollenbibliothek.

Beginne mit Terraform, wenn Infrastruktur fehlt. Erstelle eine kleine isolierte Ressource, lies den Plan und ändere ein Attribut. Sieh dir den State an, ohne ihn manuell zu bearbeiten. Übe den Unterschied zwischen Aktualisierung, Ersetzung und Löschung. Berechtigungen und Backend-Betrieb gehören ebenso zum Lernen wie HCL.

Lerne beide, wenn deine Aufgaben die Grenze überschreiten. Provisioniere eine VM, exportiere ein kleines Inventory und konfiguriere einen Dienst. Trenne die Schritte so, dass ein Konfigurations-Retry keinen Infrastruktur-Neuaufbau erfordert.

Einen allgemeinen Geschwindigkeits- oder Kostensieger gibt es nicht. Provider-APIs, Hostanzahl, Verbindungslatenz, Task-Design und gewählte Plattformen beeinflussen das Ergebnis. Eine Stoppuhr für unterschiedliche Aufgaben wäre kein hilfreicher Vergleich.

Kosten, Lizenzen und benachbarte Werkzeuge

Trenne CLI, Plattform und Cloud-Rechnung. Community-Ansible benötigt kein Automation-Platform-Abonnement. Terraform CLI und kommerzielle HCP-Terraform-Funktionen sind ebenfalls unterschiedliche Fragen. Organisationen sollten die jeweiligen Lizenzen und Bedingungen prüfen; „herunterladbar“ bedeutet nicht „uneingeschränkt“. Ansible-Lizenz, Terraform-Lizenz

Geht es um Terraform-Governance oder Lizenzierung, hilft OpenTofu vs Terraform. Das ist eine Entscheidung innerhalb der Provisionierungsschicht und unabhängig davon, ob Ansible die Gastkonfiguration übernimmt.

Bei Kubernetes kann Terraform die Infrastruktur aufbauen und Ansible Vorbereitung oder Wartung automatisieren. Anwendungen werden möglicherweise bereits durch Helm, Argo CD oder Flux ausgeliefert. Ein kleines Projekt muss nicht jedes Werkzeug einer Ökosystemgrafik einsetzen. Ergänze ein Werkzeug dann, wenn es eine konkrete Verantwortung klarer und besser betreibbar macht.

Erst Zuständigkeiten, dann der Gewinner

Terraform ist ein starker Ausgangspunkt für vorhandene Infrastruktur und ihren Lebenszyklus. Ansible ist ein starker Ausgangspunkt für gewünschte Systemeinstellungen und auszuführende Betriebsaufgaben. Überschneidungen sind möglich, gemeinsame Schreibverantwortung ist deshalb noch lange nicht nötig.

Für Einsteiger reicht zunächst eine kleine vollständige Übung: Maschine anlegen, Dienst konfigurieren, beides wiederholen, eine Sache ändern und aufräumen. Wenn du erklären kannst, welches Werkzeug jede Änderung erkennt und wie du einen Fehler im zweiten Schritt behebst, kannst du eine begründete Wahl treffen.