Warum wir auf Ansible setzen - und nicht auf Terraform
Ansible vs. Terraform ist keine Glaubensfrage. Für regulierte Plattformen mit Konfigurationstiefe hat die Entscheidung handfeste Gründe.
Die Frage kommt regelmäßig. Meist von jemandem, der Terraform aus dem Cloud-Kontext kennt und wissen will, warum wir bei SPAS nicht denselben Weg gehen. Die kurze Antwort: Weil unsere Arbeit nicht bei der Infrastruktur beginnt, sondern tief in der Konfiguration endet. Und dafür ist Ansible das bessere Werkzeug.
Terraform und Ansible lösen verschiedene Probleme. Wer das versteht, stellt die Frage anders.
Terraform ist ein Provisioning-Tool. Ansible ist ein Konfigurationstool.
Terraform beschreibt Infrastruktur: welche Server existieren, welche Netzwerke, welche Cloud-Ressourcen. Es ist declarativ, zustandsbasiert und gut geeignet, wenn das Ziel lautet: “Diese Infrastruktur soll so aussehen.”
Ansible kann das auch. Aber das ist nicht der Grund, warum wir es nutzen.
Wenn wir JBoss EAP in einer regulierten Umgebung härten, reden wir nicht über VM-Erstellung. Wir reden über Hunderte von Konfigurationsparametern: TLS-Versionen, Cipher Suites, Security-Manager-Einstellungen, Subsystem-Konfigurationen im standalone.xml, Dateirechte, Audit-Logging, JNDI-Einschränkungen. Terraform kennt diese Ebene nicht. Ansible ist genau dafür gebaut.
Idempotente Härtungs-Playbooks als Kontrollinstrument
Ein Härtungs-Playbook läuft nicht einmal und ist dann erledigt. Es läuft regelmäßig - als Drift-Detection, als Nachweis für den nächsten Audit, nach jedem Deployment, nach jedem Patch-Zyklus.
Idempotenz ist dafür keine Nice-to-have-Eigenschaft. Sie ist Voraussetzung. Ein Playbook, das bei zweimaligem Ausführen unterschiedliche Ergebnisse liefert, ist in einem Compliance-Kontext nicht verwendbar. Ansible-Module sind per Design idempotent. Das schließt Dateioperationen, Service-Konfigurationen, Paketmanagement und den JBoss-eigenen CLI-Modus ein.
Bei Terraform müsste man für denselben Kontrollzweck zusätzliche Schichten bauen: Custom Provider, externe Scripts, nachgelagerte Checks. Das ist lösbar, aber es ist gegen den natürlichen Fluss des Tools.
Agentless-Architektur in air-gapped Umgebungen
Viele der Umgebungen, in denen SPAS läuft, haben keine offene Internetanbindung. KRITIS-Systeme, Kernbankplattformen, regulierte Rechenzentren - der Internetzugang ist entweder gefiltert oder nicht vorhanden. Die Anforderungen an zusätzliche Komponenten sind entsprechend streng.
Ansible braucht auf den Zielsystemen keinen Agenten. SSH oder WinRM genügen. Kein separater Daemon, kein offener Port, keine zusätzliche Angriffsfläche, keine Abhängigkeit von einem externen Registry-Endpunkt. In air-gapped Umgebungen ist das kein Detail - es ist eine operative Grundvoraussetzung.
Viele Alternativen, inklusive einiger Configuration-Management-Tools, setzen Agents voraus. Das scheidet sie für diese Umgebungen aus.
Audit-freundliches YAML
Wir arbeiten mit Kunden, die Compliance-Teams haben. Diese Teams prüfen, was auf ihren Systemen passiert. Nicht immer sind das DevOps-Engineers.
Ansible-Playbooks sind in YAML geschrieben. Das ist kein Vorteil gegenüber HCL, wenn man es rein technisch betrachtet - beide sind lesbar. Aber Ansible-YAML beschreibt Aktionen auf Systemebene in einer Sprache, die auch ein erfahrener Linux-Administrator oder ein Sicherheitsbeauftragter lesen und nachvollziehen kann, ohne Terraform-Konzepte zu kennen.
Ein Playbook, das lineinfile verwendet, um eine JVM-Option zu setzen, ist auch für jemanden lesbar, der kein Automatisierungs-Experte ist. Das erleichtert Reviews erheblich und reduziert den Erkläraufwand bei internen Audits.
Was Terraform besser kann
Wir nutzen Terraform nicht, weil wir es für falsch halten. Wenn ein Kunde Cloud-Infrastruktur aufbaut, VMs provisioniert oder Netzwerktopologien verwaltet, ist Terraform das richtige Tool. Es ist dafür ausgelegt. Der State-Management-Mechanismus ist für Infrastruktur-Lebenszyklen gut durchdacht.
Für uns beginnt die Arbeit meist, wenn die Infrastruktur schon steht. Dann übernehmen wir. Ansible passt in diesen Moment.
Warum die Entscheidung kein Dogma ist
SPAS ist kein Argument gegen Terraform. Es ist ein Argument dafür, das richtige Tool für die eigene Aufgabe zu wählen. In unserer Aufgabe - Konfigurationstiefe, Compliance-Automatisierung, regulierte Umgebungen - ist Ansible das klarere Werkzeug.
Was wir ablehnen, ist der Reflex, ein bekanntes Tool zu nehmen, weil man es kennt, nicht weil es passt. Der Unterschied zwischen Provisioning und Configuration ist real. Wer ihn verwischt, baut sich Probleme auf, die erst zwei Jahre später sichtbar werden - meistens kurz vor einem Audit.