© stokkete / 123RF.com

Hashicorps Terraform bietet Orchestrierung für Multi-Cloud-Umgebungen und unterstützt eine riesige Menge von Zielplattformen. Die kürzlich erschienene Version 1.0 gilt als Meilenstein.

Automation, da sind sich die allermeisten Administratoren einig, ist im Rechenzentrum schon längst kein “nice to have” mehr – sie ist eine unumstößliche Voraussetzung. Allein der allgegenwärtige Fachkräftemangel zwingt Unternehmen dazu, Automation zu nutzen, um so Entwicklungsressourcen freizuschaufeln. Vielerorts würden andererseits schlicht Entwickler und Admins fehlen, um neue Produkte zu entwerfen und auf den Markt zu bringen. Dass man gut ausgebildete Kräfte also besser hippes Zeug bauen lässt, als sie immer wieder mit denselben manuellen Aufgaben auszulasten, liegt auf der Hand.

Die Praxis zeigt aber auch, dass viele Unternehmen und Admins schon beim Begriff Automation unterschiedlichen Definitionen folgen. Klar: Die allermeisten Unternehmen haben ihre Setups vollständig automatisiert – oder glauben das zumindest. Denn während der Vortrag des Admins oft auf einen Grad der Automation von 150 Prozent schließen lässt, sieht die Realität im Alltag dann doch anders aus: Automatisiert sind oft nur einzelne Leuchtturmkomponenten einer Umgebung. Das von sämtlichen Anbietern mittlerweile militant beworbene Bare-Metal-Lifecycle-Management etwa, bei dem Foreman & Co. Servern automatisch per DHCP, PXE und so weiter ein Betriebssystem überbügeln, findet sich in der Realität gar nicht so oft, wie man es erwarten würde.

Cloud-Automation

Das liegt vielleicht auch daran, dass viele Admins sich heute gar nicht mehr mit eigenem Blech herumschlagen. Das blumige Zauberwort lautet einmal mehr Cloud, ein Konzept, das alle Sorgen vergessen machen will. Und doch zeigt gerade die Wolke eindrücklich, dass viele Probleme gar nicht in ihr verschwinden, sondern sich nur anders gestalten.

Schon früh fiel den Cloud-Propheten auf, dass Automation in einer Cloud-Umgebung zwar anders funktionieren muss als auf echtem Blech, aber keinesfalls wegfallen darf. Das belegt schon ein eher einfaches Gedankenexperiment: Gegeben sei eine virtuelle Umgebung in der Cloud in Form eines typischen LAMP-Setups. Zwar wird der Admin gerade in den Public Clouds regelmäßig auf Angebote wie Database as a Service (DBaaS) setzen, doch muss man auch in einer solchen Umgebung die benötigte Datenbank per API erst einmal starten. Zuvor gilt es, ein virtuelles Netz anzulegen, in das man dann auch die anderen Instanzen packt, insbesondere die Webserver. Wer all diese Ressourcen händisch anlegen möchte, klickt sich im Webinterface entweder einen Wolf oder feuert Dutzende API-Befehle ab.

Die Orchestrierung entstand ursprünglich als Sonderform der Automation und als Antwort auf dieses Problem. Hier beschreibt der Admin in einer Template-Datei, wie seine virtuelle Umgebung aussehen soll, und verfüttert diese Anforderung dann an einen speziellen Dienst, der sie auswertet (Abbildung 1). Der Orchestrierer legt dann die benötigten Ressourcen über die anderen Dienste der Cloud völlig automatisch und aufeinander abgestimmt an. Weil in einer solchen Umgebung die gesamte Infrastruktur per Template definiert ist, spricht man auch von Infrastructure as Code, obgleich sich diese Bezeichnung auch auf Bare-Metal-Umgebungen anwenden lässt.

Abbildung 1: Automation gibt es auch in Clouds. Hier heißt sie Orchestration und wird durch Dienste wie AWS CloudFormation in die Praxis umgesetzt. Quelle: LevelUp

Diverse Technik

Das Problem dabei: Jede Cloud-Technik hat ihre ganz eigene Vorstellung von Orchestrierung. AWS-Templates lassen sich in Azure nicht nutzen, und wer Templates in der Syntax des OpenStack-Orchestrierers Heat hat, kann damit bei Kubernetes nichts anfangen. Insbesondere in hybriden Setups mit Multi-Public-Cloud-Ansätzen macht der Admin dieselbe Arbeit also unter Umständen mehrmals.

Hier kommt Terraform ins Spiel: Das Werkzeug von HashiCorp geriert sich seit Jahren als leistungsstarker und vollständig agnostischer Multi-Cloud-Orchestrierer mit eigener Syntax und einer Abstraktionsschicht für die Orchester-APIs der großen Anbieter. Zwar finden sich auch in Terraform eigene Befehle, um Instanzen in AWS, Azure oder GCP zu starten; eine generische Maschine-Ressource gibt es also nicht. Dennoch bietet Terraform aus Sicht des Admins den riesigen Vorteil, nur das Erlernen einer Syntax zu erfordern und nicht das vieler verschiedener Dienste. Zudem lässt sich die gesamte Infrastruktur in einem durchgehenden Verzeichnis definieren, statt mit eigenen Lösungen für Azure, AWS und Konsorten zu hantieren.

Vor ein paar Monaten veröffentlichten die Entwickler die Version 1.0 von Terraform, die sie als Meilenstein in der Geschichte des Projekts beschreiben. Wir nutzen die sich bietende Gelegenheit, um Terraform auf den Zahn zu fühlen: Wie arbeitet das Werkzeug, und hält es in Sachen Cloud-Orchestrierung, was der Anbieter verspricht?

Editionen

Schon wer sich zum ersten Mal mit Terraform beschäftigt, wird beinhart mit der kommerziellen Natur der Lösung konfrontiert. Zwar handelt es sich bei Terraform im Kern um Open-Source-Software, wie man es von HashiCorp kennt. Allerdings bewirbt der Hersteller die grundlegende Community-Variante der Software auf seiner eigenen Website eher zurückhaltend.

Das erscheint umso skurriler, als das Community-Terraform den Kern der anderen Versionen bildet, die der Hersteller feilbietet. Dazu gehören die von HashiCorp für Anwender in der Cloud gehostete Cloud-Variante sowie die Edition mit dem klingenden Namen Enterprise. Letztere richtet sich freilich an solche Firmen, die eine On-Premises-Instanz der gesamten Terraform-Umgebung brauchen und diese nicht in einer Cloud gehostet sehen wollen – auch wenn das Produkt, das der Admin mit Terraform Enterprise bekommt, letztlich eine On-Premises-Installation von Terraform Cloud ist. Entsprechend teilen sich die Lösungen auch das Feature-Set: SSO per SAML steht in Terraform Cloud und Enterprise ebenso zur Verfügung wie die Möglichkeit, ein komplett eigenes Layout für Netze in der Wolke zu hinterlegen.

Mandantenfähigkeit für Multi-Mandanten-SaaS-Angebote fehlt dem klassischen Terraform ebenso wie erweitertes Logging für Audit-Zwecke. Dass Terraform Enterprise dann auch noch ein praktisches GUI für diverse Aufgaben enthält, ist quasi die Kirsche auf der Torte (Abbildung 2). Ob so viel schmückendes Beiwerk überhaupt sein muss, darf man in vielen Umgebungen getrost bezweifeln. Terraform will mit seinen Cloud- und Enterprise-Angeboten offensichtlich Produkten wie Ansible Tower oder Puppet Enterprise Konkurrenz machen.

Abbildung 2: Die Workspaces-Ansicht, über die sich verschiedene Projekte zentral verwalten lassen, bleibt den Terraform-Cloud-Varianten sowie der On-Premises-Version Enterprise vorbehalten. Quelle: HashiCorp

Die blumigen Beschreibungen des Anbieters auf der Website können aber nicht darüber hinwegtäuschen, dass Terraform selbst, also der Kern der Lösung, in Form von Open Source Software eine ganze Menge auf der Pfanne hat und in vielen Umgebungen ausreichen dürfte. Was erwartet Admins, die “nur” zur Open-Source-Variante greifen, und was lässt sich mit dem Produkt anstellen?

Klare Architektur

Beim Blick auf die schematische Darstellung der Terraform-Komponenten fällt auf, dass die Lösung angenehm simpel daherkommt. Sieht man sich im Vergleich dazu die Orchestrierer der großen Clouds an, bekommt man es fast immer mit diversen APIs, unterschiedlichen Daemons und zusätzlichen Komponenten zu tun, die alle unter einen Hut gebracht werden wollen.

Nicht so bei Terraform: Hier gibt es Terraform Core, deckungsgleich mit dem Kommandozeilen-Utility »terraform«. Anders als die Lösungen der Konkurrenz kommt Terraform komplett ohne eigene APIs oder Daemons daher, die sich irgendwelche Zustände merken. Das heißt nicht, dass Terraform komplett zustandslos arbeitet. Um das Verwalten seiner Zustände kümmert Terraform sich allerdings selbst. Den Zustand, den Ressourcen in den unterschiedlichen Clouds haben sollen, beschreibt der Admin in Dateien, die auf ».tf« enden. Diese Zustandsdateien lassen sich wahlweise lokal speichern oder in einem entfernten Speicher etwa auf Basis von Amazons S3 ablegen. Die Remote-Option bietet freilich den Vorteil, dass sich Terraform den Zielzustand dann jederzeit aus dem Netz holen kann, wodurch sich das Programm von beliebigen Hosts aus aufrufen lässt.

Hilfreiche Syntax

Um im Hinblick auf die vielen verschiedenen Zielplattformen vollständig agnostisch zu sein, haben die Terraform-Entwickler sich eine eigene deklarative Konfigurationssprache überlegt. Sie heißt kurz und knapp ebenfalls Terraform und kann sowohl nativ als auch in einer nach JSON konvertierten Form daherkommen.

Im Kern besteht die Sprache aus einer kleinen Menge grundlegender Eintragsarten. Als Block bezeichnet man eine Klammer, die eine oder mehrere Ressourcen und die zu ihnen gehörenden Parameter umfasst. Listing 1 zeigt ein vollständiges Beispiel für einen solchen Block, der auf eine andere Ressource (»aws_network_interface«) verweist. Um aus dem Beispiel ein vollständiges, funktionales Beispiel zu machen, müsste der Admin einen zusätzlichen Block »aws_network_interface« anlegen, der seinerseits wenigstens auf die Ressourcen »aws_vpc« sowie »aws_subnet« verweisen müsste.

resource "aws_instance" "foo" {
  ami           = "ami-005e54dee72cc1d00"
 # us-west-2
 instance_type = "t2.micro"
 network_interface {
 network_interface_id = aws_network_interface.foo.id
 device_index         = 0
 }
 credit_specification {
 cpu_credits = "unlimited"
 }
}

Die Ressourcen in Terraform referenzieren verschachtelt aufeinander, doch gerät die Syntax dabei nicht so komplex, dass sie unbeherrschbar würde. Die beschriebenen Beispiele ermöglichen es zudem, die Syntax eines Blocks in Terraform zu verstehen. Hinter »resource« steht stets die Art von Ressource, auf die sich der jeweilige Eintrag bezieht. Ressourcen erkennt Terraform über seine Provider-Module – dazu später noch mehr. Hinter dem aufzurufenden Ressourcentyp findet sich der Identifier, der grundsätzlich für jede Ressource in Terraform nicht nur festgelegt, sondern auch global einzigartig sein muss.

Die Terraform-Sprache ist nicht so kompliziert, dass man sie nicht relativ schnell erlernen könnte. Genau darin liegt eines der zentralen Verkaufsargumente des Herstellers HashiCorp: Die Lösung lässt sich leicht verstehen und schnell erlernen, zudem ist sie sehr vielseitig. Das wird schnell offensichtlich, wenn man sich mit der zweiten zentralen Komponente von Terraform befasst, den Modulen.

Ressourcen bündeln

Was sich komplex anhört, ist im Grunde relativ simpel. Das Beispiel aus Listing 1 etwa stellt wie erwähnt nur einen Teil der Definitionen dar, die man für das Starten einer virtuellen Instanz in Amazon mit virtuellem Netz per Terraform benötigt. Komplementär braucht der Admin die Ressourcen für das Netz und, falls gewünscht, auch jene für persistenten Speicher. Hier kommen nun Module in Terraform ins Spiel.

Module kombinieren unter der Haube verschiedene API-Aufrufe in den Zielumgebungen miteinander, um den ausführenden Administratoren das Leben zu erleichtern. Oder, um in der Sprache der vorherigen Beschreibung zu bleiben: Ruft der Administrator ein Modul auf, leitet Terraform im Hintergrund daraus eine Reihe von »resource«-Anweisungen ab, die es aufeinander abstimmt.

Ein gutes Beispiel dafür stammt wieder aus der AWS-Welt: Das Modul vpc erstellt ein virtuelles Netzwerk in AWS und ermöglicht es dem Admin, in einfacher Notation dessen Subnetze anzulegen, statt mit »resource«-Statements zu hantieren. Das Modul ec2-instance ruft der Admin in seinen Projekten im Anschluss an das VPC-Modul auf und kann dabei unmittelbar auf das von VPC angelegte Subnetz verweisen. Zudem lassen sich die beiden Ressourcen miteinander verknüpfen.

Provider im Kern

Da stellt sich die Frage: Wenn Module nur Ressourcen bündeln, woher wissen sie, welche sie bündeln müssen? Woher kommt also jener Teil der Terraform-Funktionalität, der aus den Terraform-Skripts am Ende echten Code in EC2, Azure & Co. generiert? An dieser Stelle treten die Provider in Erscheinung: Sie vermitteln zwischen Terraform einerseits und den Zielplattformen andererseits.

Ab Werk bringt Terraform bereits eine riesige Auswahl an Providern mit. Der AWS-Provider, der in diesem Artikel bereits mehrmals zur Sprache kam, ist sicherlich Best of Breed. Auf ähnlich hohem Funktionsniveau arbeiten allerdings auch die Provider für Azure oder Googles GCP. Admins sollten sich aber vom Gedanken verabschieden, dass sich mit Terraform nur Ressourcen in Cloud-Umgebungen manipulieren lassen. Mittlerweile liegt die Abstraktionsfähigkeit von Terraform so hoch, dass auch andere Aufgaben komplett ohne Cloud-Bezug implementiert sind. Nutzt man diese Form von Providern, ähnelt Terraform in gewisser Weise einer Automationslösung wie Puppet oder Chef mit einer Komplexität, die sich mit der von Ansible vergleichen lässt.

Sieht man sich bei Terraform die Liste der Provider [1] an, wird schnell klar, dass der Anbieter nicht kleckert. Er pflegt ein öffentliches Verzeichnis aller verfügbaren Provider in Form der Registry, einer Art öffentlichem Marktplatz (Abbildung 3). Neben den erwähnten Providern für Public Clouds gibt es solche für OpenStack, für Oracles Public Cloud oder für eine Vielzahl von Kubernetes-Distributionen. Direkt aus Terraform heraus lassen sich dann auch Pods in Kubernetes definieren oder Container komplett automatisch über die Knoten eines Flottenverwalters hinweg administrieren.

Abbildung 3: Hersteller HashiCorp betreibt eine Registry für Provider, die im Sinne eines öffentlichen Marktplatzes funktioniert.

Wer CDN-Netze wie Akamai oder Cloudflare nutzt, kann sie ebenfalls aus Terraform heraus manipulieren und steuern. Dasselbe gilt für Datenbanken: Mittels verschiedener Provider lassen sich unmittelbar Handlungen etwa in einer MongoDB oder einer MariaDB ausführen. Dass ein wohl eher aus Spaß entwickelter Provider existiert, mit dem sich aus Terraform heraus beim US-Lieferdienst Domino’s Pizzas bestellen lassen, sei als kleine Anekdote noch erwähnt.

Mit Terraform arbeiten

Neben der verständlichen Konfigurationssprache gefällt bei Terraform die Einfachheit der Bedienung. Außer »terraform« benötigt der Admin nämlich nichts, um mit der Arbeit loszulegen. Wie genau sieht die nun aber aus?

Ein zentraler Begriff der Terraform-Welt ist der Plan, die Abkürzung für Execution Plan. Darin stehen alle Arbeitsschritte, die Terraform erledigen soll. Das Aktivieren eines Plans besteht aus mehreren Schritten, die allerdings denkbar einfach ausfallen und auch in logischer Abfolge zueinander stehen.

Im ersten Schritt legt der Administrator eine ».tf«-Datei an. Sie beschreibt, wie schon erwähnt, den Zustand, den die Installation erreichen soll. In der ».tf«-Datei listet der Administrator auch Module und Provider auf, die zum Einsatz kommen sollen. Zwar finden sich im Netz sehr viele fertige Module für Terraform, doch kann es ja durchaus vorkommen, dass der Admin ein lokales Modul für Spezialfunktionen braucht. Die lassen sich in einer State-Datei nötigenfalls direkt über das lokale Dateisystem einbinden.

Für alle Dateien, die lokal noch nicht vorhanden sind, schafft der Befehl »terraform init« im nächsten Schritt alle von Terraform benötigten Module und Provider heran. Danach bringt das Kommando »terraform apply« Terraform Core auf den Weg, um die in der State-Datei beschriebenen Ressourcen auszurollen. Der Plan gilt danach als ausgeführt, und die Ressourcen laufen.

Terraform 1.0

Wie schon erwähnt, haben die Terraform-Entwickler die Version 1.0 ihrer Software vor Kurzem freigegeben. Wer die Release-Zyklen anderer Lösungen kennt, erwartet an dieser Stelle massenhafte Neuerungen und große Feature-Sprünge. Eben die gibt es in Terraform 1.0 allerdings nicht: Ähnlich wie es Linux-Chef Linus Torvalds bereits öfter praktiziert hat, haben die Terraform-Entwickler irgendwann einfach einem Release des 0.15er-Zweigs die Versionsnummer 1.0 verpasst.

Das verdeutlicht mehrere Dinge: Nach über zehn Jahren Entwicklungszeit hält HashiCorp den eigenen Schützling nun endlich für reif für den produktiven Einsatz. Und: Terraform 1.0 bedingt keine Migration von vorherigen Versionen. Wer 0.15 nutzt, kann auch 1.0 verwenden, ohne Angst haben zu müssen, auf die Nase zu fallen.

Ein paar zentrale Unterschiede zwischen Terraform 0.15 und 1.0 gibt es dann aber doch. So versprechen die Entwickler für Terraform 1.0 deutlich längere Wartungszyklen als für vorherige Versionen. Mindestens 18 Monate soll es demnach für den 1.0er-Zweig Bugfixes und Korrekturen für Probleme in Sachen Sicherheit geben.

CI/CD-Integration

Ein Artikel über Terraform 1.0 wäre nicht vollständig, ohne auf die gut ausgebaute CI/CD-Integration der Lösung einzugehen. Das Thema spielt gerade bei Workloads in Clouds und bei Containern eine Rolle. Wenn der Admin schon Infrastructure as Code implementiert, also die Umgebung in Terraform-Sprache beschreibt, dann möchte er in der Regel auch Tests und ein automatisches Deployment in die Produktion, wenn er eine Änderung an den Git-Verzeichnissen mit der Beschreibung der Umgebung vornimmt. Terraform bietet insbesondere in Form seiner Cloud-Produkte hier Schnittstellen etwa zu Github (Abbildung 4). Eigenbaulösungen mittels Jenkins sind aber auch kein Problem.

Abbildung 4: Kombiniert der Administrator Terraform mit einer Pipeline für CI/CD-Umgebungen wie Jenkins, lösen Git-Commits auf Wunsch unmittelbar Änderungen der laufenden Ressourcen aus. Quelle: Google

Solche Setups erleichtern Admins das Leben elementar: Verändert der Admin die Beschreibung der Infrastruktur im Template, sendet Github zunächst eine entsprechende Information an Terraform. Terraform macht sogleich einen Syntax-Check und überprüft zudem, ob die neue Vorgabe der Ressourcen plausibel und in der Cloud umsetzbar ist. Nach dem erfolgreichen Abarbeiten aller dieser Schritte führt Terraform am Ende der Pipeline ein »apply« für den neuen Plan aus und gleicht damit das Ist ans Soll an. Freilich ist Terraform ab Werk darauf ausgelegt, so wenige Änderungen wie nötig an den laufenden Ressourcen vorzunehmen.

Nimmt der Admin etwa eine Konfigurationsänderung an einer DBaaS-Instanz in AWS vor, räumt Terraform diese im Kontext einer CI/CD-Pipeline nicht weg und legt sie mit neuer Konfiguration an. Stattdessen adaptiert Terraform die Konfiguration der laufenden Instanz so, dass sie wieder den Vorgaben entspricht – oder gibt eine Fehlermeldung aus, falls das nicht klappt.

State Engine nutzen

Eine interne Komponente von Terraform, die viel zu selten Erwähnung findet und die die Systemverwalter oft sträflich vernachlässigen, ist die interne State Engine des Werkzeugs. Zu einer IaC-Lösung gehört nicht nur das Anpassen der Ressourcen in den Clouds an die Vorgaben des Admins. Stattdessen muss Terraform auch mitschreiben, wann es welche Veränderungen auf wessen Geheiß erledigt hat. Mittels des Kommandos »terraform state show« gewährt das Programm unmittelbaren Einblick in die Aufzeichnungen zu einzelnen Ressourcen, die es angelegt hat.

Wer braucht Terraform?

Am Ende dieses Artikels darf eine kurze Einordnung nicht fehlen, für wen sich Terraform nun eigentlich als Lösung eignet. Das Programm ist ja bei Weitem nicht der einzige Orchestrierer für Infrastructure as Code, sicherlich aber einer der vollständigsten.

Wie üblich geht hohe Flexibilität mit zumindest erhöhter Komplexität einher. Wer nur eine einzelne EC2-Instanz auf AWS starten möchte, wird nur eine einzelne, sehr kurze State-Datei für Terraform produzieren. Fakt ist allerdings, dass es sich in diesem Beispiel gar nicht lohnen dürfte, sich mit Terraform zu befassen: Beispiele, wie mit Amazons CloudFormation dieselben Effekte zu erzielen sind, kursieren im Netz zuhauf. Ähnliches gilt für klassische Automatisierer: Eine EC2-Instanz lässt sich etwa auch mit Ansible schnell an den Start bringen.

Meist wird Terraform in großen Umgebungen als Teil einer eher komplexen CI/CD-Pipeline zum Einsatz kommen, die IaC bis ins letzte Detail ausnutzt. Dafür eignet sich das Programm wie kein anderes, das aktuell auf dem Markt verfügbar ist.

Fazit

Die Entwickler haben Terraform 1.0 bewusst nicht als epochales Release mit großer Party und einem Feuerwerk neuer Features bedacht. Der Hersteller HashiCorp wollte stattdessen zum Ausdruck bringen, dass die fast zehnjährige Arbeit an Terraform nun zu einer Version des Programms geführt hat, die die Bezeichnung “reif für den produktiven Einsatz” tatsächlich verdient. Aus Nachrichtensicht gibt Terraform 1.0 damit freilich nicht so viel her. Aus Sicht der bereits mit dem Terraform-Virus infizierten Systemverwalter ist Terraform 1.0 aber ein Segen: Überall dort, wo bisher Terraform 0.15 zum Einsatz kam, funktioniert auch Terraform 1.0.

Auf wirkliche Veränderungen dürfen Nutzer sich aller Voraussicht nach dann im Kontext von Terraform 1.1 wieder freuen. Dessen erster Release Candidate war zu Redaktionsschluss gerade erschienen und legt das Hauptaugenmerk auf die Integrität der ausgerollten Dienste. So prüft Terraform 1.1 anders als sein Vorgänger, ob die Module und Provider, die beim Anlegen eines Plans (»apply«) genutzt wurden, noch den lokal vorhandenen entsprechen. Das vermeidet, dass sich verändernde Module oder Provider-Schnittstellen laufende Ressourcen versehentlich aus dem Weg räumen.

Wer ein gut funktionierendes Werkzeug für Multi-Cloud-Orchestrierung und Infrastructure as Code benötigt, sollte Terraform jedenfalls in seine Überlegungen einbeziehen, zumal potenzielle Alternativen rar gesät sind: Pulumi (Abbildung 5) ist eine [2], Attune (Abbildung 6) eine andere [3]. Wie beschrieben, übernehmen obendrein auch die gängigen Automatisierer Teile der Funktionalität von Terraform. (jcb)

Abbildung 5: Alternativen zu Terraform sind rar gesät: Lediglich Pulumi, das zwingend eine Verbindung in die Cloud benötigt …

Abbildung 6: … sowie Attune stehen zur Verfügung, wobei Attune einen anderen Fokus setzt und deutlich weniger Funktionsumfang bietet. Quelle: Servertribe