Die Bereitstellung von Infrastruktur hat eine beachtliche Entwicklung hinter sich. Angefangen hat alles mit der physischen Installation von Hardware. Dank Virtualisierung waren später nur noch ein paar Klicks in einer Oberfläche nötig. Dann begannen Cloud-Anbieter, REST-APIs zur Bereitstellung von Diensten anzubieten. Heute lässt sich der Zielzustand einer Umgebung deklarativ per Code definieren – Infrastructure as Code war geboren. Beispiele dafür sind Terraform, Cloudformation, ARM-Templates und andere.
Die Sache mit Infrastructure as Code
Infrastructure as Code ist hervorragend für die Reproduzierbarkeit. Menschliche Fehler werden minimiert, die Immutability steigt – und ganz nebenbei dient der Code auch noch als Dokumentation. Mit Terraform lässt sich Infrastruktur inkrementell bereitstellen und anpassen, und nach jedem Lauf wird der Ausführungszustand gespeichert. Im harten Enterprise-Alltag zeigen sich allerdings schnell die Schwächen.
Zunächst einmal ist es schwierig, überhaupt Logik in Form von if-Anweisungen einzubauen. Inzwischen unterstützt Terraforms HCL zwar if-Statements und for-Schleifen, doch wirken sie eher nachträglich aufgesetzt als wie vollwertige Sprachelemente. Frameworks für Infrastructure as Code bringen keine nativen Testfunktionen mit. HCL, Cloudformation und Azure-Resource-Manager-Templates haben jeweils ihre eigene Lernkurve – und binden Sie zudem an das jeweilige Ökosystem.
Pulumi ist ein gelungener Kompromiss
Auf der anderen Seite des Spektrums stehen Cloud-SDKs für viele gängige Programmiersprachen. Alle großen Cloud-Anbieter stellen solche SDKs bereit, sogenannte CDKs (Cloud Development Kits). CDKs sind großartig, weil sie alle Vorzüge einer Programmiersprache mitbringen – allerdings kennen sie kein State-Management wie Terraform. Genau dieses State-Management macht inkrementelle Änderungen an der Infrastruktur überhaupt erst handhabbar und vorhersehbar.
Hier kommt Pulumi ins Spiel und vereint beide Welten: eine vollwertige Programmiersprache und State-Management.
So sieht zum Beispiel reiner JavaScript-Code für mehrere if-Bedingungen aus:
switch (ostype){
case 'linux':
Userdata = userdata
break;
case 'windows':
Userdata = windowsuserdata
break;
}
Dieselbe Logik in Terraforms HCL ausgedrückt:
Linux = var.ostype == "linux" ? true : false
Windows = var.ostype == "windows" ? true : false
Wie man sieht, ist die Lesbarkeit mit der vertrauten JavaScript-Syntax deutlich besser als mit Hashicorps HCL. HCL ist eine domänenspezifische Sprache, der die Flexibilität einer Allzwecksprache fehlt. Mit einer Allzwecksprache lässt sich also mehr Logik in Infrastructure as Code abbilden.
Pulumi bringt zudem weitere Vorteile aus dem Software-Lifecycle mit – etwa Test-Driven Development, Continuous Integration, versionierte Releases, Paketmanagement und vieles mehr.
Anwendungs- und Infrastruktursoftware können nun Seite an Seite existieren. Beides lässt sich in derselben Programmiersprache schreiben und in einem gemeinsamen Git-Repo ablegen.
Pulumi-Konzepte
Terraform kennt Konzepte wie Provider, Module, State und so weiter. Auch Pulumi hat diese Konzepte neu gedacht und vereinfacht:
Stacks:
Stacks sind Sammlungen zusammengehöriger Infrastrukturressourcen, die sich dieselben Umgebungsvariablen teilen. Stacks entsprechen Umgebungen (dev, stage, prod), und jeder Stack hat einen eigenen Satz an Umgebungsvariablen. Diese werden ausschließlich in "Pulumi.dev.yaml", "Pulumi.stage.yaml" usw. definiert.
Projects:
Ein Project ist eine logisch isolierte Gruppierung von Infrastrukturressourcen, die mehrere Stacks umfasst. Projects lassen sich auf Teams, Initiativen oder Infrastrukturtypen (Container, Serverless, Networking usw.) abbilden. Welche Art der Gruppierung sinnvoll ist, hängt von der jeweiligen Organisation ab.
Backends:
Backends speichern den Ausführungszustand von Pulumi in einem persistenten Speichersystem. Es gibt sie in verschiedenen Varianten:
1. Service-Backends: Pulumi Cloud (SaaS) oder self-hosted Pulumi. Service-Backends bieten den Vorteil, dass in regelmäßigen Abständen Snapshots der Infrastruktur erstellt werden. Das hilft beim Rollback und beim Wiederherstellen nach schwerwiegenden Fehlern während der Bereitstellung.
2. Selbst verwalteter Object Storage (AWS S3, GCP GCS, Azure Blobs usw.).
Provider
Pulumi kann Infrastruktur und Services auf verschiedensten Plattformen bereitstellen. Aktuell gibt es Provider für AWS, GCP, Azure, Kubernetes, Cloudflare und viele weitere.
Anhang
Vergleichstabelle
Demnächst
In Teil 2 dieses Artikels gehen wir auf fortgeschrittene Pulumi-Funktionen ein, mit denen autonome Teams ihre Infrastruktur gemeinsam mit ihrer Anwendung selbst bereitstellen und betreiben können. Außerdem schauen wir uns eine Codebasis an, mit der sich EKS-Cluster auf AWS bereitstellen lassen – EKS-Cluster, die über ein "Hello World" hinausgehen und schon ein Stück Hardening und Production Readiness mitbringen. Bleiben Sie dran!
Bleiben Sie in Kontakt – folgen Sie uns auf dem DoiT Engineering Blog, dem DoiT LinkedIn Channel und dem DoiT Twitter Channel. Karrieremöglichkeiten finden Sie unter https://careers.doit-intl.com.
Auf der rein technischen Ebene der Sprachsemantik mag der Unterschied zwischen HCL und einer Allzwecksprache nicht gravierend sein. Doch wenn man die Wahl hat zwischen einer ausgereiften, weit verbreiteten Allzwecksprache und einer proprietären, brandneuen domänenspezifischen Deklarationssprache, um dasselbe Ergebnis zu erzielen – warum sollte man zur weniger bekannten Variante greifen? Beide erfüllen ihren Zweck zuverlässig. Doch angesichts der etablierten Ökosysteme rund um Allzwecksprachen und der am Markt verfügbaren Talente spricht vieles dafür, ein Framework wie Pulumi statt Terraform einzusetzen.