Automating Deployments with Terraform

Mit HashiCorp Terraform lässt sich Infrastruktur als einfacher, menschlich lesbarer Code darstellen.

So lautet frei übersetzt die Beschreibung zu Terraform im Web.

Aber warum brauche ich Infrastructure as Code? Und ist Terraform wirklich das Tool, mit dem wir in der Zukunft arbeiten werden?

Auf genau diese Fragen werde ich eine Antwort geben – aber beginnen wir zunächst mit den Basics:

Was ist “Infrastructure As Code”?

Die Grundidee ist simpel:

Bei der Programmierung wird eine Lösung explizit beschrieben. Wenn ein Programm also eine bestimmte Aufgabe erfüllen soll, dann wird dabei genau definiert, wie die Eingabe in das Programm sowie die darauffolgende Ausgabe aussieht.

Will man also eine simple Rechnung durchführen:

1+2=3

Dann definiert man Zahlen und ein Ergebnis, welches die Summe beider Zahlen ergibt:

X+Y=Z

Infrastructure as Code versucht diese Grundidee auf die benötigten Ressourcen auszuweiten:

Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.

Das bedeutet, dass sich die Infrastruktur dem Programm anpasst. Im Gegensatz dazu bestimmte bisher der Server und dessen Hardware, welches Programm verwendet werden kann.

Damit dies funktioniert, ist eine gewisse „Flexibilität der Ressourcen“ (also eine große Menge Hardware) notwendig. Und genau diese findet man in der Cloud.

Es wird ein System benötigt, das die Verwaltung dieser Ressourcen behandelt wie einen einzigen programmierbaren Computer. Sobald das System als Ganzes „programmiert“ werden soll, ist eine Liste der Abhängigkeiten und deren Zusammenspiel erforderlich.

Der Ansatz von IaC nimmt sich die Konfigurationsverwaltung als Vorbild. Dabei werden Methoden und Prozesse im Lebenslauf eines (klassischen, physischen) Produktes automatisiert. Dadurch werden die Systeme auch in ihren Übergangszuständen verwaltet und untereinander koordiniert. Von einem System im Übergangszustand sprechen wir, wenn zum Beispiel ein Server „gerade erstellt“ wird und zwischen den Status „Auftrag zur Erstellung“ und „bereit zum Arbeiten“ festhängt.

Bei Konfigurationsverwaltungssoftware wird zwischen zwei grundlegenden Varianten unterschieden:

• Deklarative Systeme: Diese definieren den Endzustand der Infrastruktur vollständig. Das System muss somit einen Ablaufplan der Vorgänge haben, um den als Endergebnis definierten Zustand zu erreichen.

Ein Deklaratives System lässt sich anhand von Excel veranschaulichen.

Setzt man beispielsweise in einem Excel-Feld folgenden Code ein

=SUMME(X1;X2)

dann addiert Excel

Feld X1 und Feld X2.

Das „Ergebnisfeld“ muss nicht angepasst werden, solange nur Feld X1 und X2 zusammengerechnet werden sollen. Diese Formel greift also unter bestimmten Voraussetzungen „immer“.

• Imperative Systeme: Diese zeichnen Anweisungen auf, die gemäß den Vorgaben für die Systeme erforderlich sind. Der Endzustand der Infrastruktur ist dann das Ergebnis der aneinandergereihten Anweisungen.

Ein Imperatives System mit einer Rechnung zu veranschaulichen ist komplex. Wohingegen eine LEGO Bauanleitung einen guten Vergleich darstellt. Sowohl bei imperativen Systemen als auch bei LEGO-Bauwerke wird Teil für Teil aufeinander gesteckt und bei korrekter Befolgung der Anleitung erhält man das gewünschte Konstrukt.

In der IT werden je nach System fertig automatisierte Abläufe -also imperative Anweisungen-abgearbeitet (z.B. in Chef). Alternativ dazu wird ein finaler Stand an ein System/Ziel gebunden und dieser mit verschiedenen Modulen „aufgebaut“ (Puppet, Ansible, Terraform).

Da Cloudlösungen mitunter sehr komplex werden und aus Dutzenden oder Hunderten von ineinandergreifenden Ressourcen bestehen, ist eine Automatisierung der Lösung zwingend notwendig. Nur damit kann sichergestellt werden, dass die Lösungen zuverlässig und wiederholt bereitgestellt werden können.

Sind Skripte nicht dasselbe?

Eine Möglichkeit diese Ziele zu erreichen ist die Erstellung von Skripten, beispielsweise in Bash, PowerShell oder gar in einer Programmiersprache wie Python.

Doch Skripte zu erweitern und so flexibel zu halten, dass sie sich den ständig wachsenden und verändernden Gegebenheiten anpassen können, bedeutet viel Arbeit.

Eine Konfigurationsverwaltungssoftware wie Terraform übernimmt diese Arbeit, indem diverse Anbieter APIs in einem Programm abgedeckt werden.

Alle diese Plugins werden über die einfach lesbare Terraform Syntax angesprochen. Dies vereinheitlicht das Deployment – egal welcher Cloudanbieter genutzt wird.

Da Terraform für alle APIs die Grundfunktionalität jedes Services mitbringt, braucht es „nur noch“ eine Deklaration der fertigen Infrastruktur und die Konfigurationsfiles für Terraform können bereitgestellt werden.

Für diverse Konfigurationen bestimmter Teile der Azure Infrastruktur gibt es bereits fertige Beispielbibliotheken Link.

Diese bestehen immer aus einem „main.tf“ sowie diversen Variablen „variables.tf“.

Wie benutze ich Terraform?

So weit, so gut…

Wenn man Terraform nun einsetzen möchte, um selbst eine Infrastruktur in Azure zu erstellen und zu nutzen, dann gibt es diverse Möglichkeiten:

• Die Terraform Binary gibt es als kostenfreien Download unter:

https://developer.hashicorp.com/terraform/install (Übrigens lizensiert unter MPL2)

Damit kann auf der lokalen Maschine des Administrators gestartet werden – Vorausgesetzt ist der Login in den korrekten Tennant in Azure, sowie die korrekte Subscription.

• Noch einfacher geht es in der Cloudshell von Azure, für die lediglich ein Storage Account mit 5GB Speicher zu buchen ist: Dokumentation

Hier wird Terraform direkt neben den Ressourcen, die verwaltet werden sollen platziert und ist bereits komplett vorkonfiguriert. Alle Features, die lokal über die Installation der Terraform Dateien abrufen werden können, sind in der Cloudshell bereits hinterlegt.

Die Cloudshell macht es darüber hinaus möglich, im Storage Account geteilte Daten verschiedener Administratoren zu verwalten. Somit können alle, die Terraform einsetzen im selben Verzeichnis arbeiten.

Wirklich charmant wird Terraform jedoch erst, wenn man es mit einer Versionskontrolle wie z.B. Git oder AzureDevOps kombiniert und je nach Version der bereitgestellten APP auch die Infrastruktur versioniert.

Außerdem vereinfachen diese Systeme das Testen und das Arbeiten am Code, gerade mit größeren Teilnehmerzahlen.

Somit bleibt nur noch herauszufinden, wie die finale Lösung passend zu den Vorstellungen des Kunden aussehen soll:

In diesem Sinne:

Viel Spaß beim Ausprobieren.