Pulumi – Infrastructure as Code in gewohnter Sprache

Über Infrastructure-as-Code (IaC) lässt sich Infrastruktur in der Cloud automatisiert und reproduzierbar aufbauen, verwalten und dokumentieren. Als Alternative zum beliebten Terraform bietet der Newcomer Pulumi die Möglichkeit, Cloud-übergreifende Infrastruktur in bekannten Programmiersprachen und damit einen besonders schnellen Einstieg für Entwickler:innen sowie zahlreiche hilfreiche Abstraktionen und Shortcuts. Wir stellen Pulumi vor, ordnen es in den Kontext ähnlicher Tools ein und geben Tipps aus der Praxis für den Einstieg.

Was ist Infrastructure as Code und wofür hilft es?

Eine der wichtigsten Errungenschaft der modernen Cloud-Welt ist die Möglichkeit, IT-Infrastruktur wie Rechenleistung oder Speicherplatz dynamisch und nach sekundengenauem Bedarf anzufordern und zu verwalten. Mit Cloud-Architekturen geht allerdings oft eine hohe Komplexität einher und es stellt sich die Frage, wie Cloud-Ressourcen dokumentiert, reproduzierbar erstellt und wiederhergestellt werden können. Das Konzept der "Infrastructure as Code" (IaC) setzt hier an und beschreibt das Lösungsmuster, Cloud-Ressourcen und Konfiguration in Textdateien entweder mit speziellen Domain Specific Languages (DSLs) oder in bekannten Programmiersprachen zu beschreiben. Die Infrastruktur kann dann mit Unterstützung von darauf abgestimmten Tools automatisiert auf- und abgebaut werden. Die Vorteile einer solchen Vorgehensweise sind zahlreich: Neben der bereits genannten Reproduzierbarkeit ermöglicht dies eine entwicklungsnahe Arbeitsweise sowie die Versionierung des Infrastrukturzustandes in einem Versionskontrollsystem wie Git. Komplexe Konfigurationen müssen so nur einmal durchgeführt werden. Sie lassen sich danach beliebig duplizieren und wiederverwenden.

Welchen Ansatz bietet Pulumi hierfür?

Unter den IaC-Lösungen sticht das vergleichsweise neue Pulumi, das vom gleichnamigen Startup als Open Source entwickelt wird, mit einigen Besonderheiten hervor. Eine besondere Stärke von Pulumi ist, dass sich Cloud-Infrastrukturen mit gewohnten Programmiersprachen wie TypeScript, Java oder Go definieren lassen. Zudem werden alle drei großen Public-Cloud-Anbieter (Amazon AWS, Google Cloud Platform und Microsoft Azure) sowie generische Kubernetes-Cluster unterstützt. In diesen beiden Punkten unterscheidet sich das Tool sowohl von proprietären anbieterspezifischen Lösungen (CloudFormation, CDK) als auch von dem weitverbreiteten Terraform von HashiCorp mit seiner eigenen DSL. Somit lassen sich bekannte und vertraute Programmiermuster (Schleifen, Modulsysteme) auch bei der Definition der Cloud-Infrastruktur nutzen und ermöglichen eine hohe Flexibilität sowie eine flache Lernkurve.

Zur Anbindung an die entsprechenden APIs der Cloud-Provider baut Pulumi im Hintergrund meist auf die verfügbaren Terraform-Provider auf und erreicht hiermit eine nahezu hundertprozentige Abdeckung der providerspezifischen Ressourcen und Features. Parallel entstehen gerade auch native Pulumi-Backends, die direkt die APIs der Cloud-Provider ohne Umweg über Terraform aufrufen – diese befinden sich aktuell in der Entwicklung und haben in unseren Tests noch nicht ganz so zuverlässig funktioniert. Sie verfolgen jedoch einen zukunftsweisenden Ansatz, da Updates der Cloud Provider dann schneller in Pulumi verfügbar werden. Zusätzlich zu der Möglichkeit, einzelne Cloud-Ressourcen fein-granular und mit allen Einstellungsmöglichkeiten anzulegen, bietet Pulumi Module höherer Abstraktionsstufe an, durch die sich wiederkehrende Patterns mit weniger Aufwand und geringerer Code-Komplexität umsetzen lassen. Beispiele hierfür sind etwa Storage-Buckets mit direkt anhängenden Lifecycle-Policies und Berechtigungen oder die unten weiter ausgeführten "Magic Lambdas".

Mithilfe der Pulumi CLI kann die in der gewählten Programmiersprache beschriebene Cloud-Infrastruktur dann als "Stack" angelegt werden - ein Stack ist hier eine konkrete Instanz der beschriebenen Infrastruktur, der beliebig dupliziert werden kann. Zum Beispiel würden verschiedene Infrastrukturumgebungen - wie etwa "Entwicklung", "Test", "Produktion" - in der Pulumi-Terminologie als Stacks bezeichnet.

Wie nutzt man Pulumi im eigenen Projekt?

Pulumi lässt sich mit nur wenigen Handgriffen aufsetzen und eine erste Infrastruktur starten.

Installation

Die Installation funktioniert am einfachsten über eine Linux- oder MacOS-Kommandozeile oder im Windows Subsystem for Linux (WSL) mittels CURL (siehe auch https://www.pulumi.com/docs/get-started/install/):

Als nächstes gilt es die Cloud-Provider-Credentials (z.B. über die AWS Web Console) zu besorgen und für einen programmatischen Zugriff in der Shell, in der Pulumi installiert ist, als Umgebungsvariablen zu hinterlegen:

Zu guter Letzt heißt es noch sich bei Pulumi anzumelden, um loszulegen. Hier nutzen wir das lokale Backend, wodurch der Pulumi-Stack im lokalen Home-Verzeichnis abgelegt wird. Alternativ gibt es die Möglichkeit, den State beim Pulumi-Cloud-Service zentral vorhalten zu lassen, was aber kein Muss ist.

Projekt Setup

Jetzt können wir ein neues Pulumi Projekt auf Basis einer Vorlage erzeugen. Bei den Vorlagen gibt es immer die Wahl zwischen classic und native. Classic basiert auf Terraform, native auf den eingangs beschriebenen Interfaces, die direkt aus den Cloud Provider APIs generiert und somit zeitnaher aktualisiert werden.
Für unseren ersten Test wählen wir das AWS classic Template mit TypeScript ("aws-typescript"):

Das Pulumi Projekt wird initialisiert und einige Angaben interaktiv abgefragt:

• Project Name: Name des Pulumi Projektes.
• Project Description: Eine sprechende Beschreibung.
• Stack Name: Name des Stacks, z.B. "dev".
• Passphrase: Ein Passwort zum Schutz möglicher Secrets in der Pulumi-Konfiguration.

Unser Projekt ist bereit und wir passen die index.ts TypeScript Datei an, um uns ein S3-Bucket und eine Lambda-Function anzulegen, die auf Änderungen in dem Bucket reagiert.

In dem folgenden Beispiel nutzen wir auch direkt ein Pulumi Feature namens "Magic Functions" zur Einbettung einer Function, auf das wir später nochmal eingehen werden.

Jetzt kann Pulumi bereits angewiesen werden, die Infrastruktur in der Cloud zu provisionieren. Hierzu reicht ein Aufruf von "pulumi up":

In der Regel dauert es nur wenige Sekunden und wir können die Ressourcen über die AWS Konsole anschauen.  Dort sollten nun ein S3 Bucket und die Lamda Function zu finden sein. Beim Anlegen einer Datei im S3 Bucket sollten wir auch die zugehörige Log-Ausgaben in Cloud Watch sehen.

Aufräumen

Am Ende unseres Tests sollten wir noch alle Ressourcen aufräumen. Zunächst sollte der S3 Bucket über die AWS Web Konsole geleert werden, denn AWS Buckets können nur gelöscht werden, wenn sie bereits leer sind. Alles weitere kann direkt von Pulumi erledigt werden.
"pulumi destroy" räumt die Ressourcen in der AWS Cloud auf. 
"pulumi stack rm dev" sorgt dafür, dass unser lokaler Stack bereinigt wird.

Pulumi im Entwicklungsprozess

Der Entwicklungsprozess mit Pulumi wird durch die Verwendung einer allgemeinen und typisierten Programmiersprache erleichtert: Bei Verwendung von TypeScript etwa zeigt einem die verwendete IDE automatisch Vorschläge zu verfügbaren Parametern und Optionen an, sodass ein Blick in die (im Allgemeinen gut gepflegte) Online-Dokumentation selten notwendig ist.

Während der Entwicklung will man meist nicht nur von den lokalen Entwicklungsrechnern aus Infrastruktur verwalten und Software deployen, sondern überlässt solche Aufgaben CI-Pipelines, die bei Commits ins Versionsverwaltungssystem automatisch ausgelöst werden. Pulumi lässt sich hier leicht integrieren: Die Infrastrukturbeschreibung liegt entweder in einem eigenen Repository oder auch in einem Unterverzeichnis im gleichen Repository wie die zu deployende Applikation selbst. Die Pulumi CLI wird beim Push in das Repository in der Pipeline aufgerufen. Hierzu müssen die Credentials für einen Service Account beim Cloud Provider mit der Berechtigung zum Anlegen und Löschen der gewünschten Ressourcen als Secrets für die Pipeline hinterlegt werden - entsprechende Funktionalität bieten alle bekannten CI/CD-Systeme an. Für die Verwaltung des States kann ein Storage Bucket verwendet werden, auf den die Pipeline Zugriff hat, oder es wird ein spezieller Pulumi-Account angelegt.

Die Namen von Cloud-Resourcen erhalten von Pulumi automatisch ein Präfix des jeweiligen Stack-Namens. Damit die Ressourcen von unterschiedlichen Umgebungen sich nicht gegenseitig überschreiben, sollte man sich also auf diese automatische Benamung verlassen, statt eigene Bezeichner zu vergeben. Alternativ ist die Ausarbeitung eines detaillierten Umgebungs- und Namenskonzeptes notwendig.

Seit Kurzem bietet Pulumi auch eine Automation API, die insbesondere für die Integration in Pipelines konzipiert wurde.

Pulumis Magic Lambdas/Functions

Pulumi bietet einige praktische Hilfen und Abstraktionen insbesondere zur Umsetzung von Serverless-Architekturen an. Beispielsweise ist das Deployment und die richtige Konfiguration von Serverless Functions (wie z.B. Lambda bei AWS oder Cloud Functions bei Google) samt ihrem zugehörigen Trigger mit den nativen Bordmitteln der Cloud-Provider oft etwas hakelig und vor allem aufwändig. Hierfür haben sich in den letzten Jahren verschiedene Tools und Frameworks herausgebildet, wie z.B. das Serverless Framework und AWS SAM (Serverless Application Model). Pulumi geht hier noch einen Schritt weiter, indem es die Einbettung des Function-Codes direkt in den Infrastruktur-Code ermöglicht.

Pulumi nennt dieses Konzept "Magic Functions". Zum Beispiel erstellt der folgende Code-Block, den wir bereits aus unserem einführenden Beispiel kennen, einen AWS S3-Bucket, der beim Hochladen einer neuen Datei automatisch eine Lambda-Function triggert. Diese schreibt dann den Dateinamen in das Log:

Pulumi kümmert sich im Hintergrund automatisch darum, dass die anonyme innere Callback-Funktion (Zeilen 3-6) für AWS paketiert und in eine neue Lambda-Funktion "onFileUpload" deployt wird. Dabei werden auch Referenzen auf Variablen im äußeren Scope und insbesondere auch etwaige verwendete node_modules korrekt aufgelöst und mit in das Deployment-Archiv gepackt.

Dabei ist es wichtig, sich zu vergewissern, dass der geschriebene Code in so einem Fall zu unterschiedlichen Zeiten ausgeführt wird: Der Infrastruktur-Teil des Codes bei der Ausführung der Pulumi CLI lokal oder in der CI-Pipeline, der eingebettete Function-Code hingegen erst, wenn der der Funktion zugehörige Trigger ausgelöst wird (z.B. ein Storage-Bucket-Event oder ein HTTP-Request). Ein weiterer Nachteil dieses Vorgehens ist die enge Verzahnung des Applikations-Codes mit Pulumi, der die Gefahr des Vendor-Lock-Ins, die bei Nutzung von Functions-as-a-Service (FaaS) sowieso schon gegeben ist, noch verstärkt. Man gewinnt allerdings einen sehr vereinfachten Deployment-Prozess, ohne sich um viele Details (Policies, Trigger Events) des FaaS-Anbieters direkt kümmern zu müssen.

Welche Alternativen gibt es zu Pulumi?

Bei der Evaluierung eines neuen Tools für Infrastructure-as-Code lohnt sich ein Vergleich mit dem Platzhirsch Terraform von HashiCorp. Terraform ist im Moment mit Abstand das Tool mit der höchsten Verbreitung aus dieser Kategorie und auch bei unseren Kunden sehr erfolgreich im produktiven Einsatz. Das Alleinstellungsmerkmal von Pulumi im Vergleich hierzu ist aus unserer Sicht die Verwendung einer allgemeinen Programmiersprache im Gegensatz zur HashiCorp Configuration Language (HCL) bei Terraform. Dies macht es insbesondere bei der Neueinführung eines IaC-Tools interessant, gerade wenn noch wenig IaC-Erfahrung im Entwicklungsteam besteht.

Obwohl Pulumi im Hintergrund standardmäßig die Terraform-Provider verwendet, konnten wir in unseren Projekten bisher sogar weniger Schwierigkeiten mit inkonsistenten State-Files beobachten als dies bei Terraform der Fall ist. Dies ist ein Hinweis darauf, dass das Tool trotz seines im direkten Vergleich jüngeren Alters schon einen gewissen Reifegrad erreicht hat.

Bei Verwendung von Serverless-Architekturen und insbesondere Functions-as-a-Service (FaaS) sind bei Pulumi außerdem die nützlichen Abstraktionen, wie die oben beschriebenen "Magic Lambdas", sehr willkommen. In diesem Bereich existieren aber mit dem Serverless Framework (Anbieter-agnostisch) und AWS SAM (nur für AWS) auch noch weitere ausgereifte Alternativen.

Wann lohnt sich Pulumi?

Die Evaluierung von Pulumi lohnt sich aus unserer Sicht auf jeden Fall in Teams und Projekten, die neu auf den IaC-Zug aufspringen oder in dieser Hinsicht Bedarf bei sich identifiziert haben. Existierendes Know-How in einer der unterstützten Programmiersprachen kann so für den Aufbau der Cloud-Infrastruktur gleich mit genutzt werden, was insbesondere in Teams, die vorher noch nicht mit Terraform in Berührung kamen, praktisch ist. Durch die gute IDE-Unterstützung ergeben sich bei Pulumi Vorteile bei der Dokumentation und Einarbeitung. Es sollte aber auch eine gewisse Bereitschaft bestehen, über den Tellerrand des Platzhirsches zu schauen und Alternativen zu testen.

Unser Cloud-Angebot

Die viadee IT-Unternehmensberatung bietet ein vielfältiges Spektrum an Dienstleistungen und Technologien im Bereich Cloud Plattformen und Architekturen an. Bei allen Fragen zu Pulumi, Infrastructure as Code oder anderen Cloudthemen, sprechen Sie uns gerne an. Oder besuchen sie eines der Seminare unseres Kompetenzbereichs Cloud.