Azure Terraforming

Azure Terraforming: Die reiferen Leser/innen kennen das Wort «Terraforming» noch aus den Star Trek Filmen (Raumschiff Enterprise). Dort versuchte die Föderation mittels Terraforming auf einem leblosen Planeten eine “Klasse-M” Athomspäre zu erschaffen. Damit sollten neue Kolonien innerhalb des Föderationsgebietes erschlossen werden. Zudem über einen Zeitraum von dreissig Jahren.

Heute sind wir als IT Administratoren zeitlich stets gefordert, wenn es um die zugrundeliegenede Infrastruktur in der Cloud geht. Desweiteren herrscht eine Tendenz zur agilen Entwicklung, sodass immer kürzere Entwicklungszyklen und noch schnellere Umsetzungen von Veränderungen möglich werden. Da bleibt einem leider kein Jahrzent mehr, die Umsetzung muss oft innerhalb von Stunden möglich sein.

Um diese Schnelllebigkeit zu meistern, muss das Cloud Management, soweit als möglich, automatisiert sein. Sprechen wir von Infrastruktur in der Cloud, dann ist damit ein maschinenlesbarer Konfigurationscode gemeint. Die Bezeichnung dafür ist Infrastructure as Code (IaC)«.

Azure Terraforming: Infrastructure as Code

Für Entwicklungsteams ist es relativ üblich, den Quellcode einer Anwendung in einem Quellcode-Repository (wie z. B. GitHub oder Azure Repos) zentral zu verwalten. Somit kann der Code gemeinsam genutzt und Konflikte zwischen Entwicklern, die zum Beispiel an gleichen Modulen arbeiten, sind einfach lösbar. Leider ist dies bei Infrastruktur IT Teams noch nicht überall der Fall.

Aber es ist heute durchaus möglich, genau die gleichen Muster und Praktiken auf eine Cloud Infrastruktur anzuwenden. Dementsprechend beschreibt man diese einfach per Code und behandelt sie auch so. Man beschreibt die geplante Cloud Infrastruktur zuerst deklarativ (deklarativ =  in der Art einer Deklaration) in Code und im Anschluss deployed man den Code. Somit legt man alle Skripte, Konfigurationsdateien und Templates in einem Source-Control-Repository ab, versioniert sie und nutzt den gleichen Lebenszyklus wie bei den Anwendungen, die auf dieser Infrastruktur laufen.

HashiCorp Terraform

Man kann diverse Tools nutzen, die einem beim Erstellen von Code zum Deployment einer Cloud Infrastruktur helfen. Microsoft bietet mit den Azure Resource Manager Templates die Möglichkeit, die gesamte Infrastruktur mit einigen Variablen und Parametern zu beschreiben.

Auch Azure Terraform ist ein Open-Source-Tool, das von HashiCorp entwickelt und gepflegt wird. Es verfolgt genau das gleiche Ziel wie die ARM-Templates: Es hilft, eine Cloud Infrastruktur deklarativ zu beschreiben.

HCL (HashiCorp Configuration Language)

Azure Terraform bietet mit HCL, eine einheitliche Deklarationssprache. Mit dieser lassen sich Cloud Ressourcen „standardisiert“ beschreiben. Statt händisch über das Azure Portal neue Instanzen anzulegen oder dort bestehende Ressourcen anzupassen, werden diese in HCL beschrieben und an Terraform übergeben. Terraform führt die beschriebenen Änderungen über die Azure API automatisch durch. Somit erstellt Terraform eine komplette Cloud Infrastruktur (anlog dem Bild unten).

Plan, Apply und Destroy

Steht der Code einmal bereit, arbeitet man vereinfacht mit den folgenden drei Hauptschritten:

• Plan: der Code wird direkt mit der bestehenden Cloud Umgebung verglichen, allfällige Änderungen die ausgeführt “würden”, werden angezeigt
• Apply: die Differenz zwischen Code und bestehender Cloud Umgebung wird deployed (neu erstellt, geändert, gelöscht)
• Destroy: Alle im Code beschriebenen Ressourcen werden in der Cloud Umgebung gelöscht

terraform plan

Der gesamte Code aller Azure Terraform Dateien im aktuellen Arbeitsverzeichnis wird überprüft und man erhält eine Übersicht über alle Änderungen, die vorgenommen werden würden:

terraform apply

Analog «Plan» werden die Änderungen angezeigt, aber jetzt erhält man die Option um die Änderungen direkt an der Cloud Infrastruktur umsetzen zu lassen. Die Ausgabe zeigt den Fortschritt und die Rückmeldung, wenn die Änderungen abgeschlossen sind.

terraform destroy

Genau wie bei Apply erhält man eine Übersicht über die Elemente, die zerstört werden sollen. Nach der Ausführung sind alle beschriebenen Ressourcen wieder gelöscht:

Wofür nutzen wir Azure Terraforming?

Die Azure Umgebungen unserer KMU Kunden sind im Wesentlichen immer ähnlich aufgebaut. Sie werden von uns deshalb per Terraform erstellt und und auch so verwaltet. Dadurch erhalten diese Umgebungen immer das gleiche Deployment, sowie ein einheitliches Naming aller Azure Objekte. Der Code selbst ist in sich geschlossen und wird pro Kunde abgelegt.

Arbeiten wir in grösseren Kunden oder Enterprise Umgebungen mit Azure Terraforming, sind die einzelnen Terraform Projekte meist untereinander abhängig. Die Terraform Stati müssen zentral abgelegt werden (z.B. auf einem Azure Storage Account) und für andere Projekte zur Verfügung stehen.

Speziell in grösseren Deployments nutzen wir das Microsoft Cloud Adption Framework. Darin werden meist die zentralen Infrastruktur Komponenten als Provider für die Landing-Zones separat zu den eigentlichen Applikationsprojekten generiert und modular verwaltet:

• Der Cloud Perimeter mit Firwall’s, WAF’s und anderen Core Komponenten werden per Code bereitgestellt und der Terraform Status zentral abgelegt
• Landing-Zone deployment werden ebenfalls per Code bereitgestellt, können dann auf den Perimeter Status zugreifen und alle erforderlichen Infos für Peerings, Policies usw. im Code direkt verwenden
• Soll eine weitere Region oder Datacenter hinzugefügt werden, ändern sich nur die Variablen im Code damit ein eine komplette neue Cloud Umgebung erstellt werden kann

Fazit

Mit Azure Terraform kann man eine komplette Cloud Infrastruktur as Code erstellen und diese in Azure deployen, verwalten und auch wieder zerstören.

Dies mit folgenden Vorteilen:

• Cloud Ressourcen erhalten einheitliche Namen und werden nicht dynamisch generiert wie über das Azure Portal
• Die komplette Umgebung kann gelöscht und in kurzer Zeit wieder neu erstellt werden
• Umgebungen können dupliziert werden unter Wiederverwendung des Codes. Sei es für DEV,TEST und PROD Umgebungen oder als komplettes eigenes virtuelles Datacenter in einer anderen Azure Region
• Bei jedem Durchlauf wird der Code, der gespeicherte Status sowie die Echtzeit Umgebung geprüft und verglichen. Änderungen die direkt gemacht wurden und nicht per Code, werden sofort ersichtlich