CloudFormation versus Terraform

Cloud ist eine spannende Technologie! Einer der Hauptgründe dafür ist, dass man fast jeden Aspekt davon automatisieren kann. Auch bisher wurden in traditionellen Rechenzentren Infrastrukturaufgaben automatisiert und die Grenzen des Möglichen immer weiter getrieben. Aber die Cloud bringt neue Möglichkeiten mit enormem Potential.

Das Ziel

Hier sind wir also im November 2018, mit einer Cloud-Plattform, die auf Amazon Web Services (AWS) basiert. Wir haben ungefähr 30 Accounts und fünf Anwendungen in Produktion. Als wir mit dem Aufbau der Plattform begonnen haben, war eines unserer zentralen Ziele, die Bereitstellung der Infrastruktur so weit wie möglich zu automatisieren. Um dies zu erreichen, war der Einsatz von AWS CloudFormation am naheliegendsten.

Aishwarya Rajakumar, System Engineer Cloud & Automation

Mit wachsender Erfahrung und der ständigen Nutzung des Tools haben wir uns oft gefragt, ob es andere, effizientere Möglichkeiten gibt, Infrastruktur in AWS bereitzustellen. Was darauf folgte, war unausweichlich: eine Analyse des führenden Infrastructure-as-Code-Tools (IaC), Terraform. Ein wichtiger Aspekt an Terraform ist, dass es mehrere Clouds unterstützt. In Anbetracht unserer bevorstehenden Multi-Cloud-Initiative ist dies ein großer Vorteil!

Im Folgenden beschreiben wir die Ergebnisse unseres Vergleichs von Terraform 0.11 mit CloudFormation im Detail. (Hinweis: 1. Wir haben die Fähigkeiten von Terraform nur im Vergleich mit AWS bewertet. 2. Zum Zeitpunkt des Verfassens dieses Artikels wurde Terraform 0.12 mit HCL 2.0 zwar bereits angekündigt, diese Version wird aber in den nächsten Monaten noch nicht verfügbar sein. Es müssen in Zukunft vielleicht einige der Tool-Eigenschaften neu bewertet werden. Außerdem hat AWS kürzlich einige neue Funktionen für CloudFormation eingeführt. Auf diese können wir hier nur oberflächlich eingehen.)

Der Schlagabtausch

Unterstützung von AWS-Services

CloudFormation unterstützt nahezu alle AWS-Services. Gänzlich neu eingeführte AWS-Services werden oft sofort oder kurz nach deren Veröffentlichung durch CloudFormation unterstützt. Neue Funktionen bereits vorhandener Services bleiben aber oft zu lange liegen.

Auch Terraform unterstützt nahezu alle AWS-Services. Da es durch eine große Open-Source-Gemeinde entwickelt wird und diese Entwickler oft auch persönliche Interessen haben, neue Funktionalitäten zu nutzen, stehen in Terraform gänzlich neue Services als auch Funktionen bestehender Services schnell zur Verfügung. Die Terraform-Community kann gänzlich neue Services aber erst implementieren, nachdem sie von AWS offiziell eingeführt wurden. Daher kommt es vor, dass diese etwas später als durch CloudFormation unterstützt werden.

AWS CloudFormation Console

Nutzererfahrung

AWS CloudFormation bietet eine Benutzeroberfläche, auf der Templates erstellt, modifiziert und die Ressourcen-Abhängigkeiten graphisch angezeigt werden können. Sie bietet außerdem eine Option zur Validierung der Template-Syntax. Die Konsole bietet auch eine Übersicht aller Aktivitäten und viele Informationen, um diese nachzuvollziehen. Dies ist vor allem im Fehlerfall sehr hilfreich.

Terraform fehlt eine Benutzeroberfläche. In der Open-Source-Version wird es ausschließlich über die Kommandozeile gesteuert. Für einen Anfänger kann dies eine Herausforderung sein. Terraform SaaS und Enterprise bieten eine Benutzeroberfläche.

Terraform CLI während einer Änderung der Infrastruktur

Programmiersprache

In CloudFormation erfolgt die Definition der Infrastruktur in JSON- oder YAML-Dateien, den sogenannten CloudFormation-Templates. Bei komplexeren Ressourcen werden diese lang und unübersichtlich. In Bezug auf Bedingungen, Verzweigungen und Schleifen im Code unterstützt CloudFormation explizite „if“- und „and“- Konstrukte, man kann aber keine „for-loop“ oder „if-else“-Konstrukte erstellen.

Terraform besitzt seine eigene domänenspezifische Sprache, die Hashicorp Configuration Language (HCL). Terraform-Templates sind einfach zu lesen und effizient. Im Durchschnitt benötigt man, um dasselbe Ergebnis zu erzielen, weniger Code als mit CloudFormation. Ein Grund dafür ist die Verfügbarkeit des Meta-Parameters „count“. Mit dessen Hilfe lassen sich Konstrukte wie „if“, „if-else“ und „for-loop“ erstellen. Dazu ist aber etwas Kreativität nötig, wie dieser Artikel zeigt: Terraform tips & tricks: loops, if-statements, and gotchas.

Vergleich eines Terraform- und CloudFormation-Template für die Bereitstellung einer IAM-Gruppe

Modularisierung

Terraform-Module unterstützen eine reproduzierbare Infrastruktur, die mit Parametern gesteuert werden kann. Module unterstützen den Export von Template-Werten als Ausgabeparameter, die als Eingabeparameter für ein anderes Modul verwendet werden können.

Des Weiteren bietet Terraform mit „Data Sources“ eine Vielzahl von integrierten Quellen für Eingabeparameter. Steht der gewünschte Parameter nicht als interne Datenquelle zur Verfügung, kann er mit Hilfe von Skripts als „external Data Source“ dynamisch berechnet werden.

Terraform bietet außerdem eine Modul-Registry mit verifizierten Community-Modulen. Eine hilfreiche Funktion der Registry ist, dass man Module ganz gezielt anhand ihrer Versionsnummer aufrufen kann. Damit kann man ungewollte Änderungen vermeiden.

Bei CloudFormation ist die Modularisierung auf die Verwendung von verschachtelten Stacks und Cross-Stack-Referenzen beschränkt. Mit Cross-Stack-Referenzen lassen sich zur Laufzeit generierte Werte aus einem Stack exportieren, die dann als Parameter in nachfolgende Stacks referenziert werden können. Verschachtelte Stacks bestehen aus CloudFormation Templates, mit hierarchischer Abhängigkeit.

CloudFormation bietet auch die Möglichkeit, mit Hilfe von Custom Resources Lambda-Funktionen zu definieren, die dynamische Eingabeparameter liefern.

Es gibt kein AWS-Äquivalent zur Terraform Modul-Registry. Man findet aber online eine Vielzahl von CloudFormation Templates, die aus erster Hand (AWS) und von Anwendern bereitgestellt werden.

Verwaltungsaufwand

Terraform bietet ausgereifte Möglichkeiten für die Erstellung von Infrastruktur, gibt aber keinen Prozess vor. Dieser Prozess sowie alle dafür nötigen Artefakte müssen selbst verwaltet werden. So speichert Terraform zum Beispiel den zuletzt aktualisierten Zustand der Infrastruktur in einer JSON-basierten Datei, die „Statefile“ genannt wird. Diese Datei muss selbst verwaltet werden. Dies kann bei schlechter Verwaltung zu gleichzeitigen parallelen Updates auf dieselbe Infrastruktur führen, worauf im nächsten Punkt eingegangen wird. Außerdem wird die Datei leicht unübersichtlich und es besteht die Gefahr, dass sie durch manuelle Änderungen beschädigt wird. Dies kann dazu führen, dass damit zusammenhängende Ressourcen gelöscht werden.

CloudFormation ist ein durch AWS verwaltetes Service, das den Anwendern einige Entscheidungen und Aufwand rund um dessen Nutzung abnimmt. Dadurch werden zwar auch die Möglichkeiten begrenzt, aber der Verwaltungsaufwand verringert. So verwaltet CloudFormation den aktuellen Zustand im sogenannten „Stack“ direkt im AWS-Account. Er repräsentiert die Infrastruktur, die mit CloudFormation bereitgestellt wurde. Was alles im Stack enthalten ist, kann über die CloudFormation-Konsole übersichtlich und benutzerfreundlich eingesehen werden. Der Stack kann nur durch ein reguläres CloudFormation-Update geändert werden.

Sperrung von Ressourcen zur Vermeidung von paralleler Bearbeitung

Da CloudFormation ein verwalteter AWS-Service ist, besteht keine Gefahr, dass ein Stack mehrfach parallel aktualisiert oder modifiziert wird.

Da Terraform nicht (zwingend) an einer zentralen Stelle verwaltet wird, kann es zu gleichzeitigen parallelen Updates der Infrastruktur kommen. Es müssen selbst Maßnahmen getroffen werden, um dies zu verhindern. Terraform SaaS oder Terraform Enterprise bieten dazu ausgereifte Möglichkeiten.

Importieren von Infrastruktur

Man kann Ressourcen, die außerhalb von Terraform erstellt wurden, leicht in Terraform importieren und daraus ein Template erstellen.

CloudFormation kann nicht verwendet werden, um Ressourcen zu verwalten oder zu integrieren, die nicht mit CloudFormation erstellt wurden.

Zustandsverifizierung, Änderungsübersicht und Änderungsverwaltung

Dies ist vielleicht die wichtigste Funktion. Terraform bietet mit dem „plan“-Befehl die Möglichkeit, den aktuellen Ist-Zustand der Infrastruktur mit dem geplanten neuen Status zu Vergleichen und Abweichungen darzustellen. Dabei werden auch vorhergehende Änderungen an der bestehenden Infrastruktur erkannt, die nicht durch Terraform durchgeführt wurden. Dadurch lassen sich geplante Änderungen überprüfen und bestätigen. Dies erleichtert die Nachvollziehbarkeit von Änderungen und erzeugt ein hohes Vertrauen in deren korrekte Auswirkung.

Terraform wird die Infrastruktur immer auf den im Template definierten Zustand ändern. Dadurch können ungewollte, durch andere vorgenommene Änderungen rückgängig gemacht werden. Auf der anderen Seite bietet Terraform aber keine Möglichkeit, außerhalb von Terraform vorgenommene Änderungen beizubehalten. Je nach Einsatzgebiet benötigt man aber beide Funktionen.

Übersicht der Schritte einer Infrastruktur-Änderung mit Terraform

Die erst kürzlich von AWS vorgestellte Funktion „Drift Status“ vergleicht den Stack mit dem Ist-Zustand der Infrastruktur und erkennt somit Änderungen, die außerhalb von CloudFormation vorgenommen wurden. Drift Status hilft aber nicht, Änderungen rückgängig zu machen.

Bei der Durchführung einer Änderung mit CloudFormation gibt es keine Möglichkeit, gegen den Ist-Zustand der Infrastruktur zu prüfen. Änderungen außerhalb von CloudFormation werden nur dann durch das erneute Ausspielen eines Templates überschrieben, wenn sich Template und Stack unterschieden. Dies hat den Nachteil, dass man externe Änderungen nicht einfach rückgängig machen kann. Auf der anderen Seite hat es den Vorteil, dass es gewissermaßen tolerant gegenüber externen Änderungen ist.

Fehlerbehandlung und Rollback

Tritt ein Fehler bei der Behandlung einer Ressource auf, isoliert Terraform den Fehler auf abhängige Ressourcen. Nicht direkt abhängige Ressourcen werden trotz Fehler weiterhin erstellt, aktualisiert oder zerstört. Dies kann dazu führen, dass sich die Infrastruktur in einem nicht nutzbaren und instabilen Zustand befindet. Will man die gesamte Infrastruktur auf den vorherigen Zustand zurückstellen, muss dies manuell durchgeführt oder selbst automatisiert werden. Hilfreich dabei ist, dass Terraform dazu bei jeder Ausführung eine Zustandssicherung erstellt.

CloudFormation versucht immer (oder zumindest meistens), die Infrastruktur in einem nutzbaren und stabilen Zustand zu belassen. Falls eine Änderung fehlschlägt, rollt CloudFormation die Infrastruktur auf den letzten stabilen Stand zurück. Es gibt einige Situationen, bei denen dies nicht geschieht, aber meistens bleibt dem Anwender trotz Fehler eine funktionierende Infrastruktur.

Rolling Updates von Auto-Scaling-Gruppen

CloudFormation unterstützt Rolling Updates von Auto-Scaling-Gruppen mit Rollback im Fehlerfall.

Terraform unterstützt dies nicht.

Konfiguration von Wartebedingungen

CloudFormation erlaubt es, Wartebedingungen zu definieren. Dies bedeutet, dass alle abhängigen Ressourcen erst behandelt werden, wenn die Ressource mit Wartebedingung erstellt oder aktualisiert wurde. Damit lässt sich zum Beispiel ein Workflow implementieren, der darauf wartet, dass eine bestimmte Software installiert und verfügbar ist, bevor mit den nächsten Schritten weitergemacht wird.

Terraform unterstützt Wartebedingungen nicht inhärent, es gibt aber die Möglichkeit, diese mit externer Datenquelle zu implementieren.

Multi-Cloud-Support

Nach heutigem Stand unterstützt Terraform mehr als 90 Provider. Das bedeutet, dass ein einziges Tool zur Bereitstellung der Infrastrukturen für alle wichtigen Public-Cloud-Provider wie AWS, Azure, Google Cloud Platform und für eine Vielzahl von Cloud-native Tools wie Kubernetes oder Docker verwendet werden kann.

Die Verwendung von CloudFormation ist auf AWS beschränkt.

Eine kleine Auswahl der durch Terraform unterstützten Anbieter

Tool-Support und Lizensierung

AWS CloudFormation ist kostenlos. AWS bietet Support im Rahmen ihrer Support-Pläne.

Terraform steht entweder als kostenloses Open-Source-Tool oder als kostenpflichtiges Unternehmens-Tool zur Verfügung. Die Open-Source-Version hat keine Support-SLA, aber die meisten Anfragen werden im Laufe der Zeit beantwortet.

Terraform Enterprise ist ein integriertes IaC-Tool und verfügt über eine eingebaute Integration mit Code-Repositories, wie etwa Git. Jedes Commit löst den Befehl „plan“ aus, der freigegeben und angewendet werden kann. Es verfügt über ausgereifte Methoden zur Nutzer- und Ressourcen-Statusverwaltung.

Terraform Enterprise gibt es als SaaS-Variante und Premium-Variante, die eine eigenständige, private Installation ist. Bei ersterer erhält man Support von 9 bis 17 Uhr und bei letzterer rund um die Uhr. Die Premium-Version enthält einen freigeschalteten Hashicorp Sentinel, der eine genaue Steuerung der Ressourcen-Bereitstellung ermöglicht. So kann man zum Beispiel vorschreiben, wann und unter welchen Umständen Änderungen vorgenommen werden können.

Terraform hat vor kurzem eine kostenfreie Variante der SaaS-Lösung angekündigt, die kleinen Teams oder Entwicklern zugutekommen kann. Sie bietet eine Lösung zur Verwaltung der Zustandsdatei, zum Sperren des Zustands und stellt auf einer Benutzeroberfläche eine Änderungshistorie zur Verfügung.

Zum Schluss noch eine persönliche Erfahrung

Eine weitere Beobachtung bei Terraform, die vielleicht nur ich gemacht habe, war, dass man irgendwann unbeabsichtigt Ressourcen löscht oder modifiziert. Dies ist nicht auf einen Bug oder mangelnde Dokumentation seitens Terraform zurückzuführen, sondern vielmehr auf meine anfangs mangelnde Erfahrung mit dem Tool. Terraform stellt einen Ressourcen-Typ zur Verfügung, der „aws_iam_policy_attachment“ genannt wird und exklusive Anhänge von IAM-Richtlinien erstellt. Ich habe diese Ressource verwendet, um einem AWS-Nutzer „Administratorrechte“ zu geben. Es dauerte eine Weile, bis ich bemerkte, warum allen anderen AWS-Nutzern ihre Administratorrechte entzogen worden waren: In der Dokumentation werden die Anwendung und die Auswirkungen der Verwendung dieser Art von Ressource klar beschrieben. Das ist keinesfalls ein Mangel oder Problem, sondern nur etwas, an das man denken muss. Denn CloudFormation stellt keine Funktionen bereit, die Exklusivität gewähren, und könnte nachteilig für andere Ressourcen außerhalb des Tools sein.

Schlussfolgerung

Es ist schwer zu sagen, welches Tool besser ist und als Sieger gelten kann. Beide Tools haben ihre Nachteile und gleichzeitig auch Lösungen, um diese zu beheben. Im direkten Vergleich wäre Terraform in unseren Augen die richtige Wahl. Aber wir sind auch der Ansicht, dass wir bei einer Nutzung von Terraform nicht vollständig auf CloudFormation verzichten können. Da wir auch einen OpenShift-Cluster als private Cloud betreiben und dort Ansible, OpenShift Templates und HELM für IaC verwenden, haben wir bereits eine große Palette an Tools für ähnliche Aufgaben im Kubernetes-Umfeld. Diese Vielzahl an Tools stellt eine gewisse Belastung für die jeweiligen Teams dar. Daher müssen wir in einem nächsten Schritt untersuchen, ob wir die Anzahl an Tools reduzieren können. Wir brauchen ein ganzheitliches Automatisierungskonzept für alle Plattformen, das nicht nur die Tools, sondern auch die Teams und deren Fähigkeiten berücksichtigt. Erst wenn wir über eine solche Strategie verfügen, werden wir möglicherweise Terraform einführen.

Günter Schulmeister, unser Product Owner Cloud Services, und Aishwarya beim Abstimmen dieses Beitrags

Aussicht auf coole Tools

Für alle, die der Infrastructure-as-Code aufgrund der Verwendung von JSON, YAML oder HCL skeptisch gegenüber stehen, gibt es Hoffnung. Neu aufkommende Tools wie Pulumi für Terraform und AWS CDK für CloudFormation erlauben es, Infrastruktur mit gängigen Programmiersprachen und objektorientierten Techniken zu definieren. Beide Tools sind neu und haben noch „Kinderkrankheiten“ – sind aber vielversprechend.