Terraform und Ansible/Chef integrieren: Infrastruktur- und Konfigurationsautomatisierung kombinieren

In der modernen Infrastrukturautomatisierung kombinieren Teams häufig Terraform mit Konfigurationsmanagement-Tools wie Ansible oder Chef, um vollständige Kontrolle über ihre Systeme zu erhalten. Terraform eignet sich hervorragend für das Bereitstellen und Verwalten von Cloud-Ressourcen (Netzwerke, Server, Load Balancer etc.), während Ansible und Chef auf die Konfiguration dieser Ressourcen spezialisiert sind (Installation von Software, Einrichten von Diensten, Durchsetzen von Sicherheitsrichtlinien). Durch den Einsatz von Terraform für das “Day 0”-Provisioning und Ansible/Chef für die “Day 1”-Konfiguration erreichst du eine klare Trennung der Verantwortlichkeiten: Terraform definiert, welche Infrastruktur existiert – Ansible oder Chef definieren, wie jeder Server konfiguriert ist.

Warum beide Tools verwenden: Komplementäre Stärken

• Trennung der Zuständigkeiten: Terraform ist deklaratives Infrastructure-as-Code und ideal zum Erstellen von Ressourcen (VMs, Netzwerke, Container etc.), während Ansible/Chef für nachgelagerte Konfigurationsaufgaben optimiert sind – z. B. Installation von Paketen, Dateiverwaltung, Anwendungs-Deployments. Durch diese Rollentrennung wird dein Code übersichtlicher und wartbarer. Zum Beispiel, eine Terraform-Konfiguration startet einen Server-Cluster, und ein Ansible-Playbook installiert die benötigte Software auf jedem Server.

• Idempotenz und Wiederverwendbarkeit: Beide Tools arbeiten idempotent: Terraform verfolgt den Zustand der Infrastruktur und ändert nur, was nötig ist; Ansible/Chef wenden Konfigurationen so an, dass der Zielzustand erreicht wird – ohne unbeabsichtigte Nebeneffekte. In Kombination erhältst du eine vollständig reproduzierbare Pipeline, die Drift und manuelle Fehler reduziert.

• End-to-End-Automatisierung: Durch die Kombination beider Tools lassen sich vollständig automatisierte Abläufe erstellen. Terraform übernimmt das Anlegen der Ressourcen in der Cloud oder On-Prem, während Ansible/Chef die Konfiguration übernehmen. So beschleunigst du deine Deployments erheblich. Zum Beispiel, nach einem erfolgreichen terraform apply kannst du direkt ein Ansible-Playbook gegen die neuen Server laufen lassen (mit IP-Adressen oder Hostnamen, die Terraform ausgibt), um Setup und Dienste zu installieren.

• Flexibilität und Skalierung: Wenn ein Server neu erstellt werden muss, kann Terraform ihn zerstören und neu bereitstellen, und Ansible/Chef konfigurieren ihn automatisch nach. Du kannst die Infrastruktur per Terraform skalieren, und Ansible/Chef bringen neue Nodes automatisch in den gewünschten Zustand. Die Tools spielen ihre jeweiligen Stärken aus: Terraform mit seinem Abhängigkeits-Graphen für komplexe Infrastruktur – Ansible/Chef mit YAML/Recipes für tiefergehende OS-Änderungen.

Gängige Integrationsmuster

Es gibt mehrere bewährte Methoden, Terraform mit Ansible oder Chef zu kombinieren. Die beste Strategie hängt vom Workflow und den Anforderungen deines Teams ab. Gängige Muster sind:

• Post-Provisioning-Konfiguration (Terraform ⇒ Ansible/Chef): Der direkteste Ansatz ist, zuerst mit Terraform die Infrastruktur bereitzustellen, und anschließend das Konfigurationstool gegen die neu erstellten Server auszuführen. Zum Beispiel kann eine Terraform-Konfiguration drei EC2-Instanzen erstellen und deren IP-Adressen als Output bereitstellen. Danach generierst du ein Ansible-Inventar oder Chef-Node-Definitionen auf Basis dieser Outputs und führst das Playbook bzw. die Run-List aus. Terraform endet mit der Bereitstellung – Ansible/Chef übernimmt die Konfiguration.

  Beispiel: Eine Terraform-Konfiguration erstellt drei Ubuntu-VMs inklusive SSH-Schlüsseln und Public IPs (mittels for_each). Nach terraform apply liegen die IP-Adressen als Outputs vor. Du schreibst dann ein Ansible-Inventar (oder verwendest ein dynamisches Inventarskript), das diese IPs nutzt, und führst ansible-playbook aus, um z. B. nginx zu installieren und Konfigurationsdateien zu kopieren. Diese klare Aufgabentrennung nutzt die jeweiligen Stärken optimal aus.

• Dynamisches Inventar und Zustandsintegration: Um Terraform-Outputs nahtlos mit Ansible zu verbinden, verwenden viele Teams Terraform-Outputs oder -Statefiles als Quelle für das Ansible-Inventar. Eine bewährte Lösung ist das Terraform Collection for Ansible Automation Platform, das einen Inventar-Plugin bereitstellt, welcher das Terraform-Statefile liest und daraus Hosts für Ansible erzeugt. So entfällt das manuelle Inventarmanagement: Terraform-Outputs oder Tags definieren die Gruppierung der Maschinen – und Ansible verwendet diese Gruppen direkt.

• Local-Exec oder Null Resource Trigger: Terraform kann externe Programme direkt über den local-exec-Provisioner oder eine null_resource aufrufen. Zum Beispiel kannst du einen local-exec verwenden, um nach Abschluss der Bereitstellung einen Ansible-Befehl auszuführen. Ein typisches Beispiel verwendet null_resource mit einem triggers-Block, der von deinen Instanzen abhängt. Anschließend führt local-exec den Befehl ansible-playbook -i inventory playbook.yml aus. Dadurch stellt Terraform sicher, dass es auf die Ressourcen wartet und dann lokal Ansible ausführt. Allerdings gilt: mit Vorsicht verwenden – sowohl die Terraform-Dokumentation als auch Experten warnen davor, Provisioner für komplexe Konfigurationsaufgaben zu verwenden, da sie fehleranfällig und unzuverlässig sein können. Sie eignen sich in der Regel besser für einfache Bootstrapping-Aufgaben (z. B. das Kopieren von SSH-Schlüsseln) oder das Ausführen von Skripten, nicht jedoch für vollständige Konfigurationsprozesse. In der Praxis bevorzugen viele Teams eine Entkopplung (siehe nächster Punkt), anstatt lange Ansible-Ausführungen direkt in Terraform einzubetten.

• CI/CD- oder Orchestrierungs-Pipelines: Ein sehr verbreitetes Muster ist die Verwendung eines externen Orchestrators oder CI/CD-Tools (Jenkins, GitLab CI, Spacelift usw.), um Terraform und Ansible nacheinander in separaten Schritten auszuführen. Du könntest zum Beispiel eine Jenkins-Pipeline haben, in der ein Schritt terraform apply zur Bereitstellung der Infrastruktur ausführt und der nächste Schritt dann ansible-playbook auf diese Hosts anwendet, basierend auf einer Inventardatei. Dadurch werden die Werkzeuge sauber voneinander getrennt: Terraform läuft in einem Container/Schritt, Ansible in einem anderen. In der Pipeline ruft beispielsweise die „Provision“-Stufe Terraform auf, und die „Configure“-Stufe startet Ansible mit der Inventardatei. Ähnlich kann auch eine GitOps- oder Workflow-Engine (wie FluxCD, GitHub Actions usw.) ein Ansible-Playbook auslösen, nachdem der Terraform-Code ausgeführt wurde. Dieser Ansatz verzichtet vollständig auf Terraform-Provisioner und erleichtert die Fehlersuche, da CI-Logs klar zwischen Terraform- und Ansible-Schritten unterscheiden.

• Cloud-Init oder User-Data-Skripte: Für einfachere Anwendungsfälle kann cloud-init/user-data (oder den remote-exec-Provisioner mit einem Shell-Skript) verwendet werden, um beim Start einer Instanz Ansible oder den Chef-Agent zu installieren und die Konfiguration von einem zentralen Server abzurufen. Beispielsweise kann ein aws_instance-Ressourcentyp in Terraform ein user_data-Skript enthalten, das yum install ansible und anschließend ansible-pull ausführt. Das kann funktionieren, vermischt jedoch Verantwortlichkeiten (Infrastrukturcode enthält Konfigurationsskripte) und ist weniger transparent als das explizite Ausführen von Ansible/Chef von deiner Steuerungsmaschine aus.

Nutzung von Terraform-Provisionern/-Providern und Packer

Terraform bietet Provisioner wie remote-exec, file und local-exec, mit denen sich Konfigurationen auf erstellten Ressourcen ausführen lassen. Für Ansible ist das oben beschriebene local-exec-Muster im Grunde ein Terraform-Provisioner, der die Ansible-CLI aufruft. Terraform selbst verfügt über keinen „Ansible-Provisioner“, aber es gibt einen Ansible-Provider, mit dem sich Ansible-Inventories, Playbooks und mehr erstellen und verwalten lassen (mehr dazu später).

Für Chef hatte Terraform früher einen Chef-Provisioner, der den Chef-Client auf einer Maschine bootstrappen konnte. Dieser ist jedoch inzwischen veraltet. Laut den Chef-Dokumentationen gilt: „Terraform hat den Chef Provisioner in Version 0.13.4 als veraltet markiert und wird ihn in einer zukünftigen Version entfernen.“ Es gab auch einen Chef-Provider, der inzwischen archiviert wurde. Die aktuelle Empfehlung lautet stattdessen:

• Wenn du den Chef Infra Server (Chef Server) nutzt, kannst du weiterhin Terraform’s remote-exec verwenden, um den Chef-Client auf jedem Node zu installieren und zu konfigurieren, sodass er sich mit dem Server verbindet.
• Wenn du Chef Solo/Workstation nutzt, verwendest du in der Regel ebenfalls remote-exec. Zum Beispiel kann remote-exec verwendet werden, um ein Chef-RPM herunterzuladen, zu installieren, Policy-Dateien zu laden und chef-client -z auszuführen.
• Viele Teams bevorzugen heute das Vorab-Erstellen von Images: Mit Packer und Chef wird ein sogenanntes „Golden Image“ erstellt, das anschließend durch Terraform als Instanz bereitgestellt wird. Packer kann bei jeder Änderung in Chef oder Puppet neue Maschinenimages für mehrere Plattformen erzeugen.

Grundsätzlich sollte man im Hinterkopf behalten: Terraform ist in erster Linie ein Infrastruktur-Tool. Die Best Practices von HashiCorp empfehlen, Provisioner nur sehr sparsam einzusetzen. Sie sollten nur als letzter Ausweg für das Bootstrapping genutzt werden.

Beispiel: Bereitstellung von AWS EC2 mit Terraform und Ansible

Zur Veranschaulichung betrachten wir die Bereitstellung einer kleinen Flotte von EC2-Instanzen und deren Konfiguration. Man kann dabei wie folgt vorgehen:

1. Terraform-Ressourcen definieren. Schreibe HCL-Code, um ein AWS-Schlüsselpaar, eine Sicherheitsgruppe und eine aws_instance-Ressource zu erstellen (ggf. mit for_each oder count, um mehrere Hosts zu erzeugen). Zum Beispiel:

    1resource "aws_key_pair" "ssh_key" {
    2  key_name   = "mykey"
    3  public_key = file(var.public_key)
    4}
    5
    6resource "aws_instance" "web" {
    7  count         = 3
    8  ami           = data.aws_ami.ubuntu.id
    9  instance_type = "t2.micro"
   10  key_name      = aws_key_pair.ssh_key.key_name
   11  associate_public_ip_address = true
   12  tags = {
   13    Role = "webserver"
   14    Name = "web${count.index+1}"
   15  }
   16}
   17
   18output "web_ips" {
   19  value = aws_instance.web[*].public_ip
   20}
   

   Dieser Code erstellt drei Webserver (jeweils mit öffentlicher IP) und gibt deren IP-Adressen als Output aus. Wie im Beispiel gezeigt, lässt sich mit for_each in Terraform einfach auf N Hosts skalieren. Nach dem Ausführen von terraform apply könnte der Output z. B. so aussehen: ["54.1.2.3", "54.4.5.6", "54.7.8.9"].

2. Ansible-Inventar erzeugen. Erstelle eine Ansible-Inventardatei (oder verwende ein dynamisches Inventar-Plugin), das die neuen Hosts unter einer passenden Gruppe aufführt. Du kannst den Terraform-Output direkt verwenden, z. B. durch Schreiben einer lokalen Datei mittels local-exec. Alternativ kannst du ein Plugin oder Skript nutzen, das den Terraform-State liest, oder den Ansible Terraform Provider einsetzen. Ein einfaches statisches Inventar könnte so aussehen:

   [webservers]
   54.1.2.3
   54.4.5.6
   54.7.8.9
   

   Für größere Setups empfiehlt sich ein dynamischer Ansatz (z. B. mit Terraform-Outputs oder dem Ansible Terraform Provider), um diesen Schritt zu automatisieren.

3. Ansible-Playbooks ausführen. Mit einem fertigen Inventar kannst du ansible-playbook -i inventory site.yml ausführen. Dein Playbook (oder deine Rollen) targetieren dann die entsprechende Gruppe, z. B.:

    1- hosts: webservers
    2  become: yes
    3  tasks:
    4    - name: Installiere Nginx
    5      apt:
    6        name: nginx
    7        state: present
    8    - name: Kopiere index.html
    9      copy:
   10        src: index.html
   11        dest: /var/www/html/index.html
   

   Da das Inventar von Terraform stammt, wird Ansible genau die erzeugten Instanzen konfigurieren.

4. (Optional) Automatisierung mit Terraform local-exec. Wenn du möchtest, dass Terraform nach der Ressourcenerstellung automatisch Ansible aufruft, kannst du eine null_resource mit einem local-exec-Provisioner verwenden, der den Ansible-Befehl ausführt. Zum Beispiel:

   1resource "null_resource" "configure" {
   2  depends_on = [aws_instance.web]
   3  provisioner "local-exec" {
   4    command = "ansible-playbook -i inventory site.yml"
   5  }
   6}
   

   Beim Ausführen von terraform apply wartet Terraform auf die EC2-Instanzen und führt anschließend das Playbook aus. Das kann einfache Workflows vereinfachen. Viele Teams bevorzugen es jedoch, Ansible außerhalb von Terraform (z. B. in CI/CD oder manuell) auszuführen, um mehr Kontrolle zu behalten.

Best Practices

• Codebasen trennen. Halte unterschiedliche Repositories oder Verzeichnisse für Terraform- und Ansible/Chef-Code. Dies stärkt die Trennung der Verantwortlichkeiten: Eine Codebasis definiert Cloud-/Netzwerkressourcen, die andere die Maschinenkonfiguration. Zum Beispiel könntest du ein terraform/-Repository (nach Umgebungen organisiert, mit Modulen etc.) und ein ansible/-Repository (mit Playbooks, Rollen und Inventarvorlagen) führen. Die getrennte Versionskontrolle erleichtert Code-Reviews und die Integration in CI/CD.

• Umgebungen sauber isolieren. Verwende nicht dieselben Terraform-Workspaces für „dev“ und „prod“ ohne sorgfältige Überlegung. Best Practice ist die Verwendung separater States (und ggf. separater Terraform-Root-Module) pro Umgebung. So können Änderungen an der Produktionsumgebung nicht versehentlich den Entwicklungsstand beeinflussen, und Zugriffskontrollen lassen sich gezielt anwenden. (Vermeide es, komplett unterschiedliche Umgebungen in einer gemeinsamen State-Datei über Workspaces abzubilden.)

• Terraform-Outputs für Inventare nutzen. Lasse Terraform die für Ansible/Chef benötigten Daten (z. B. IP-Adressen, Hostnamen, usw.) als Outputs bereitstellen. Du kannst daraus Skripte ableiten, die das Inventar generieren, oder diese Outputs direkt ins Konfigurationstool übergeben. Es gibt sogar Terraform-Provider/-Plugins, die Inventare für Ansible erzeugen.

• Terraform-Provisioner nur minimal verwenden. Wie bereits erwähnt: Vermeide den übermäßigen Einsatz von local-exec, remote-exec oder file-Provisionern. Sie funktionieren, können aber zu unvorhersehbarem Verhalten führen (Netzwerkprobleme, Timeouts, unvollständige Konfiguration). Falls Bootstrapping nötig ist, beschränke es auf das Notwendigste (z. B. SSH-Key oder Agent installieren). Für komplexe Konfigurationen ist ein dediziertes Konfigurationstool besser geeignet. HashiCorp selbst weist darauf hin, dass Provisioner nur als „letztes Mittel“ genutzt werden sollten.

• Immutable Infrastructure durch Image-Builds. Wenn möglich, verwende Tools wie Packer, um AMIs oder VM-Images mit vorinstallierter Software (z. B. via Ansible/Chef) zu erstellen. Terraform deployt dann nur noch diese „goldenen Images“. Dadurch entfällt ein Großteil der Konfiguration nach der Bereitstellung. Änderungen erfolgen durch einen neuen Image-Build; Terraform ersetzt dann die Instanzen.

• Idempotente und deklarative Playbooks. Schreibe Ansible-Rollen oder Chef-Recipes so, dass sie idempotent und möglichst deklarativ sind. So lassen sie sich gefahrlos erneut ausführen. Vermeide destruktive, imperative Skripte. Der Einsatz von Rollen und Policies (Ansible Roles, Chef Policyfiles oder Environments) hilft, Konsistenz über mehrere Durchläufe hinweg zu wahren.

• Sichere Authentifizierung. Stelle sicher, dass Terraform und Ansible auf sichere Weise über die benötigten Zugangsdaten verfügen. Gib Terraform z. B. ein IAM-Rollenprofil oder einen Schlüssel zur Instanzerstellung und Ansible Zugriff per SSH (z. B. denselben Schlüssel, den Terraform generiert hat). Nutze die SSH-Schlüssel aus Terraform-Outputs, SSH-Agent-Weiterleitung oder Bastion-Hosts. Niemals sensible Daten hardcodieren – verwende Secrets-Manager oder Umgebungsvariablen.

• Tests und Validierung. Bevor du in Produktion gehst, teste den gesamten Ablauf. Führe terraform plan aus und teste die Anwendung zunächst in einer Testumgebung. Führe Ansible im --check-Modus gegen Testinstanzen aus. Nutze Linter (wie tflint, ansible-lint) und CI-Pipelines, um Syntax und Standards zu prüfen. So erkennst du Probleme frühzeitig.

• Versionen festschreiben (Version Pinning). Fixiere Versionen von Modulen, Providern, Ansible-Rollen und auch von Terraform selbst auf stabile Releases. Versionsdrift kann unerwartetes Verhalten in Terraform oder Ansible verursachen. Halte einen sauberen Audit-Trail durch Tags oder Releases in deinen Repositories.

• Zusammenarbeit mit Tools unterstützen. Nutze Code-Reviews und Pull Requests für alle Änderungen – egal ob in Terraform- oder Ansible-Code. Dokumentiere in der Git-Historie, wie die Komponenten zusammenwirken. Ein Ansible-Playbook sollte z. B. angeben, welche Terraform-Outputs es als Inventar erwartet.

• Monitoring und Auditing. Egal welche Integrationsmethode du nutzt – stelle sicher, dass Logs und Statusdaten aufgezeichnet werden. Terraform führt ein Statefile (Terraform Cloud/Enterprise bietet darüber hinaus Run-Logs). Ansible Tower oder AWX protokolliert Jobs. Wenn du einfache Pipelines nutzt (z. B. Jenkins), speichere die Konsolenausgaben von Terraform- und Ansible-Stufen, um Fehler leichter zurückverfolgen zu können.

Mögliche Fallstricke

• State Drift (Zustandsabweichung). Terraform kennt nur Ressourcen, die es selbst erstellt hat. Wenn Ansible oder ein Benutzer manuell etwas auf einer Maschine ändert (z. B. eine Datei löscht oder ein Paket außerhalb von Ansible installiert), erkennt Terraform diese Abweichung nicht und versucht beim nächsten Lauf möglicherweise, das „zu beheben“. Umgekehrt: Wenn Terraform eine Ressource neu erstellt (z. B. eine Instanz ersetzt), gehen alle Konfigurationen der alten Instanz verloren. Um dies zu vermeiden, sollte Terraform sich auf reine Infrastruktur beschränken, während Ansible bei jedem Lauf den gewünschten Zustand auf Maschinen sicherstellt.

• Überschneidende Zuständigkeiten. Achte darauf, dass Terraform und Ansible/Chef nicht dieselbe Ressource verwalten. Beispiel: Wenn Terraform eine Datenbank erstellt und eine Ansible-Rolle dieselbe Datenbank erneut anlegt, führt das zu doppeltem Aufwand und potenziellen Konflikten. Lege klar fest, welches Tool welche Ressource verwaltet. (Terraform kann über Community-Provider auch Betriebssystem-Ressourcen verwalten, aber in der Regel ist es besser, die In-VM-Konfiguration Ansible/Chef zu überlassen.)

• Fehler bei Provisionern. Wenn du dich auf Terraform-Provisioner (remote-exec, local-exec) verlässt und der Konfigurationsschritt fehlschlägt, kann Terraform Ressourcen in einem inkonsistenten Zustand zurücklassen. Das erschwert die Fehlersuche. Teste Provisioner-Skripte immer separat und verwende ggf. Timeouts und Retry-Logik – oder vermeide Provisioner ganz und nutze externe Orchestrierung.

• Abhängigkeiten und Reihenfolge. Ansible-Playbooks erwarten, dass Hosts erreichbar sind (SSH aktiv und Verbindungen möglich). Wenn Terraform abgeschlossen ist, das Betriebssystem aber noch bootet oder cloud-init noch läuft, kann der erste Ansible-Lauf scheitern. Nutze in Ansible wait_for-Tasks oder in Terraform remote-exec mit connection-Optionen, um sicherzustellen, dass SSH bereit ist – oder füge eine kurze Wartezeit ein.

• Sicherheit und Netzwerk. Stelle sicher, dass die von Terraform erstellten Netzwerkkonfigurationen (ACLs, Security Groups, Firewalls) Verbindungen von Ansible/Chef zulassen (z. B. SSH oder WinRM). Häufiger Fehler: Terraform erstellt ein privates Subnetz ohne Zugriff – und Ansible erreicht die Maschinen nicht. Mögliche Lösungen: Bastion-Host verwenden, temporär eine öffentliche IP zuweisen (wie im obigen Beispiel) oder einen SSH-Proxy nutzen. Plane dein Netzwerk so, dass die Konfiguration erreichbar ist.

Fortgeschrittener Tipp: Der Ansible-Provider für Terraform

Neuere Terraform-Versionen unterstützen einen Community-gepflegten Ansible-Provider, mit dem sich Ansible-Inventare und sogar Tasks direkt in HCL definieren lassen. Mit der Ressource ansible_host kannst du Hosts in einem von Terraform verwalteten Inventar automatisch anlegen. So entfällt die separate Inventardatei – du definierst Hosts und Gruppen direkt in Terraform, und der Ansible-Provider erzeugt daraus eine passende Datei. Ein Beispiel:

 1resource "aws_instance" "web1" { /* ... */ }
 2
 3resource "ansible_host" "web1" {
 4  name   = "web1"
 5  groups = ["aws"]
 6  variables = {
 7    ansible_user = "ubuntu"
 8    ansible_host = aws_instance.web1.public_ip
 9  }
10}

Dies ist ein Ansatz, bei dem alles innerhalb des Terraform-Plans bleibt. Allerdings steigt die Komplexität (man muss die Syntax des Providers gut kennen), daher bevorzugen viele Teams weiterhin den klassischen Ansatz mit separatem Playbook und Inventar.

Fazit

Die Integration von Terraform mit Ansible oder Chef vereint das Beste aus beiden Welten: Terraform sorgt für zuverlässige, zustandsbasierte Bereitstellung der Infrastruktur, während Ansible/Chef eine leistungsfähige Konfigurationsverwaltung bietet. Der Schlüssel zum Erfolg liegt in der klaren Aufgabentrennung (Terraform für Infrastruktur, Ansible/Chef für Software), robuster Orchestrierung (CI/CD oder geskriptete Abläufe) und der Einhaltung bewährter Praktiken (Idempotenz, kleine atomare Änderungen, Versionskontrolle). Wenn du diese Muster und Tipps befolgst (z. B. zuerst provisionieren, dann konfigurieren), erreichst du eine reibungslose Automatisierungspipeline. Teste deine Abläufe regelmäßig und achte auf Drift – dann erhältst du ein zuverlässiges, wiederholbares System, das mit deiner Cloud-Umgebung skaliert.