Pulumi: Infrastructure as Code

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 1 von 10. Was wäre, wenn du deine Cloud-Infrastruktur mit genau derselben Programmiersprache schreiben könntest, die du für deine Anwendung verwendest? Schluss mit dem ständigen Context-Switching zwischen deiner Anwendungslogik und tausenden Zeilen von Custom Markup. Die Folge The Developer's Infrastructure: Why Pulumi? behandelt genau diesen Wandel. Historisch gesehen bedeutete Infrastructure as Code das Schreiben von Domain-Specific Languages oder endlosen YAML-Blöcken. Wenn du eine Datenbank und einen Server deployen wolltest, musstest du eine Syntax lernen, die exklusiv für dieses spezifische Provisioning-Tool war. Du hast das vielfältige Ökosystem des Standard-Software-Engineerings verloren. Du konntest nicht einfach eine Loop schreiben, Standard-Testing-Frameworks integrieren oder Logik über Standard-Package-Registries teilen. Pulumi ändert diese Grundlage. Es ist eine Infrastructure-as-Code-Plattform, mit der du Cloud-Ressourcen mit General-Purpose-Programmiersprachen bauen, deployen und managen kannst. Anstatt eine maßgeschneiderte Konfigurationssprache zu lernen, verwendest du TypeScript, Python, Go, C# oder Java. Stell dir einen Developer vor, der Cloud-Ressourcen mit TypeScript definiert. Mit herkömmlichen Tools musst du ständig den Context wechseln, um YAML-Schemas in einem Webbrowser nachzuschlagen. Mit Pulumi bleibst du in deinem Editor. Du instanziierst eine Resource-Class, tippst einen Punkt, und die Standard-IDE-Auto-Completion zeigt dir genau, welche Properties verfügbar sind. Du bekommst Inline-Type-Checking, bevor du überhaupt ein Deployment ausführst. Wenn du drei identische Storage Buckets brauchst, schreibst du eine Standard-For-Loop. Wenn deine Firma spezifische Security-Regeln für jeden Server vorschreibt, abstrahierst du diese Logik in eine Standard-Function, publishst sie in einer Standard-Package-Registry und lässt andere Teams sie importieren, genau wie jede normale Code-Library. Hier ist der entscheidende Punkt. Weil du diese Infrastruktur in imperativen Sprachen schreibst, könntest du annehmen, Pulumi sei nur ein Automatisierungs-Script, das Cloud-APIs sequenziell aufruft. Es ist aber kein imperatives Execution-Script. Pulumi verwendet im Hintergrund weiterhin ein äußerst robustes deklaratives State-Model. Wenn du dein Pulumi-Programm ausführst, provisioniert es die Ressourcen nicht sofort Zeile für Zeile. Stattdessen läuft dein Code, um den gewünschten End-State deiner Infrastruktur zu konstruieren. Die Pulumi-Engine erfasst diese Resource-Definitions und baut einen strikten Dependency-Graph. Anschließend vergleicht sie diesen Desired-State mit dem aktuellen Actual-State deiner Cloud-Umgebung. Pulumi berechnet die exakte Differenz und führt nur die spezifischen Create-, Update- oder Delete-Operations aus, die nötig sind, damit die Realität deinem Code entspricht. Du schreibst mit dem expressiven Flow einer imperativen Sprache, aber du bekommst die Sicherheit und Vorhersagbarkeit einer deklarativen Deployment-Engine. Durch die Nutzung von General-Purpose-Languages bekommst du Zugriff auf bestehende Linter, Unit-Testing-Frameworks und Continuous-Integration-Pipelines. Pulumi hört einfach auf, Infrastruktur als separate Configuration-Domain zu behandeln, und macht sie zu Standard-Software, die genau derselben Strenge und demselben Tooling unterliegt wie deine Core-Application. Wenn du die Show unterstützen möchtest, findest du uns, indem du auf Patreon nach DevStoriesEU suchst. Ich möchte mir kurz die Zeit nehmen, dir fürs Zuhören zu danken – das hilft uns sehr. Mach's gut!

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 2 von 10. Du instanziierst eine Standard-Python-Klasse in deinem Editor, drückst auf Deploy, und Sekunden später existiert ein Storage Bucket in der Cloud. Wie genau wird ein lokales Objekt im Arbeitsspeicher in eine entfernte physische Ressource umgewandelt? Heute beantworten wir das mit einem Blick unter die Haube: die Architektur von Pulumi. Es gibt ein weit verbreitetes Missverständnis darüber, wie dieses Tool funktioniert. Wenn du ein Deployment-Script schreibst, kommuniziert dein Code nicht mit Cloud-APIs. Die Umgebung, in der dein Python-, Node- oder Go-Code läuft, hat absolut keine Ahnung, wie sie mit Amazon Web Services kommunizieren soll. Stattdessen teilt Pulumi den Deployment-Prozess in drei separate Komponenten auf: den Language Host, die Deployment Engine und die Resource Provider. Es beginnt mit dem Language Host. Diese Komponente evaluiert dein Programm und extrahiert deine Absicht. Stell dir ein Python-Script vor, in dem du einen AWS S3-Bucket deklarierst, indem du ein Bucket-Objekt initialisierst. Der Python Language Host führt dein Script Zeile für Zeile aus. Wenn er auf diese Bucket-Deklaration stößt, macht er keinen Network Request an AWS. Er sendet einfach einen Registration Request an die Deployment Engine. Er teilt der Engine mit, dass ein Bucket mit bestimmten Properties existieren soll. Der Language Host kommuniziert diesen Desired State über eine lokale Verbindung, hält dann an und wartet auf eine Response, bevor er die nächste Codezeile evaluiert. Die Deployment Engine empfängt diesen Registration Request. Diese Komponente ist der Orchestrator. Die Engine weiß nichts über Python-Syntax und sie weiß nichts über die AWS API. Ihre einzige Aufgabe ist State Management. Sie schaut sich den vom Language Host gesendeten Desired State an und vergleicht ihn mit dem letzten bekannten Actual State deiner Infrastruktur. Wenn die Engine sieht, dass genau dieser S3-Bucket im aktuellen State nicht existiert, berechnet sie ein Diff und stellt fest, dass eine Create-Operation erforderlich ist. Um den Bucket tatsächlich zu bauen, übergibt die Engine die Aufgabe an die dritte Komponente, den Resource Provider. Provider sind eigenständige Plugins, die für bestimmte Plattformen wie AWS, Azure oder Kubernetes heruntergeladen werden. Die Deployment Engine sendet eine Anweisung an den AWS Resource Provider und sagt ihm, dass er den Bucket mit den angeforderten Properties erstellen soll. Hier ist der entscheidende Punkt. Der Resource Provider ist die einzige Komponente in dieser gesamten Kette, die weiß, wie man mit der Cloud spricht. Er nimmt den generischen Creation Command von der Engine, übersetzt ihn in die spezifischen REST API Calls, die von AWS benötigt werden, und führt sie über das Netzwerk aus. Sobald AWS den S3-Bucket provisioniert, gibt es eine physische Resource ID zurück. Der Resource Provider fängt diese physische ID ab und gibt sie an die Deployment Engine zurück. Die Engine aktualisiert ihren internen State, um festzuhalten, dass der Bucket nun in der echten Welt existiert. Schließlich signalisiert die Engine dem Language Host zurück, dass die Ressource bereit ist, und reicht dabei alle Output Properties wie den Bucket-Namen oder die URL weiter. Der Language Host setzt die Execution fort, und dein Python-Script geht zur nächsten Anweisung über. Diese strikte Trennung von Language Evaluation, State Orchestration und Cloud Execution ist es, was der Architektur ihre Flexibilität verleiht. Du kannst eine neue Programmiersprache hinzufügen, ohne die Cloud Provider anzufassen, und einen neuen Cloud Provider hinzufügen, ohne die Language Hosts zu modifizieren. Das war's für dieses Mal. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 3 von 10. Früher bedeutete das Aufsetzen eines Cloud-Infrastructure-Projekts stundenlanges Hantieren mit Boilerplate-Files und Ordnerstrukturen, bevor du auch nur eine einzige Zeile Logik schreiben konntest. Heute kannst du eine komplette Umgebung in Sekundenschnelle scaffolden. Wir konzentrieren uns auf Hello Azure: Dein erstes Projekt erstellen, um genau zu sehen, wie das abläuft. Ein weit verbreiteter Irrtum ist, dass das Ausführen des Commands zur Projekterstellung sofort Infrastructure in der Cloud baut. Das stimmt nicht. Der Command, über den wir sprechen, generiert lediglich lokale Files und bereitet dein State Tracking vor. Es werden keine tatsächlichen Azure-Ressourcen erstellt, bis du später explizit einen Deployment-Command ausführst. Um ein neues Projekt zu bootstrappen, nutzt du das Command Line Interface. Zuerst erstellst du ein leeres Verzeichnis und wechselst dorthin. Dann führst du den Command pulumi new aus, gefolgt von einem Template-Namen. Für Azure ist dieses Template normalerweise azure dash und deine bevorzugte Programmiersprache, wie zum Beispiel azure dash typescript oder azure dash python. Wenn du das ausführst, wird das Interface interaktiv. Es führt dich durch eine Reihe von Prompts, um deine Umgebung zu konfigurieren. Zuerst wirst du nach einem Projektnamen gefragt, der standardmäßig deinem Verzeichnisnamen entspricht. Als Nächstes wirst du nach einer Projektbeschreibung gefragt. Danach fragt es nach einem Stack-Namen. Ein Stack ist eine isolierte Instanz deines Projekts, die normalerweise eine Umgebung wie Development oder Production repräsentiert. Der Default-Stack heißt dev. Zu guter Letzt prompten die Azure-Templates nach einer Azure-Location, wie WestUS, die als deine Default-Deployment-Region gespeichert wird. Sobald du die Prompts beantwortet hast, lädt das Tool das Template herunter, installiert die nötigen Language Dependencies und erstellt eine Handvoll Files in deinem Verzeichnis. Hier ist der entscheidende Punkt. Das wichtigste generierte File ist Pulumi dot yaml. Das ist dein Core-Project-File. Es definiert den Projektnamen, die verwendete Runtime und die Beschreibung. Es teilt dem System im Wesentlichen mit, wie dein Code ausgeführt werden soll. Du wirst auch ein File namens Pulumi dot dev dot yaml sehen, wenn du den Default-Stack-Namen akzeptiert hast. Dieses sekundäre File speichert die Konfigurationswerte, die spezifisch für diesen Stack sind, inklusive der Azure-Region, die du gerade ausgewählt hast. Daneben erhältst du deine Standard-Dependency-Files, die je nach gewählter Sprache variieren, und dein Entrypoint-File. Innerhalb des Entrypoint-Files liefert das Default-Azure-Template ein funktionierendes Beispiel für einen Azure Storage Account. Die Code-Logik verläuft in drei klaren Schritten. Erstens importiert sie das Azure Native Package. Zweitens deklariert sie eine neue Azure Resource Group und gibt ihr einen logischen Namen, den das State-File tracken kann. Drittens deklariert sie einen Azure Storage Account. Hier wird es interessant. Anstatt den Resource Group Namen hardzucoden, übernimmt der Storage Account die Name-Property direkt von dem Resource Group Object, das im vorherigen Schritt erstellt wurde. Das erzeugt eine implizite Dependency. Das System weiß nun, dass es die Erstellung der Resource Group abschließen muss, bevor es versucht, den Storage Account zu erstellen. Das Template füllt außerdem automatisch die erforderlichen Arguments für den Storage Account aus, wie den Account Replication Type und das Account Tier. Ganz am Ende des Files exportiert der Code einen Wert. In diesem gescaffoldeten Beispiel exportiert er den Primary Storage Key des neu definierten Storage Accounts. Wenn du schließlich deployest, wird dieser exportierte Wert direkt in deiner Konsole ausgegeben. Das macht es einfach, Connection Strings oder Endpoints abzurufen, ohne dich ins Azure Portal einloggen zu müssen. Du kommst von einem leeren Ordner zu einem komplett verkabelten Infrastructure-Programm, einfach indem du ein paar Prompts beantwortest. Das gibt dir eine solide, syntaxkorrekte Grundlage, um mit dem Bau deiner eigenen Architektur zu beginnen. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 4 von 10. Dein Deployment-Skript läuft perfekt auf deinem Laptop. Du pushst deinen Code, deine automatisierte Pipeline triggert, und der Build schlägt sofort fehl, weil er eine Source-Datei nicht finden kann. Am Code selbst hat sich nichts geändert, aber das Directory, in dem der Command ausgeführt wurde, hat sich leicht verschoben. Das ist eine klassische Pfad-Falle, und um sie zu vermeiden, musst du Projects und Paths verstehen: Structuring Your Code. Im Kern ist ein Pulumi-Project einfach ein Ordner, der eine Datei namens Pulumi.yaml enthält. Diese Datei ist der Anker. Sie teilt dem Command Line Interface mit, dass sich in genau diesem Directory deine Infrastruktur-Logik befindet. In der Pulumi.yaml-Datei deklarierst du Metadaten wie den Projektnamen, eine Description und die Runtime-Sprache. Die Runtime-Property entscheidet darüber, wie dein Code tatsächlich ausgeführt wird. Wenn du Python angibst, sucht die Runtime in diesem Directory nach einer Python-Main-File. Wenn du Node angibst, sucht sie nach dem Entrypoint, der in deiner Package-File definiert ist, was normalerweise eine Index-File ist. Wenn du deinen Source-Code lieber in einem Unterordner statt im Haupt-Project-Directory ablegen möchtest, kannst du dieses Verhalten explizit überschreiben, indem du die Main-Property in deiner Pulumi.yaml-Datei so setzt, dass sie auf genau diesen Unterordner zeigt. Schauen wir uns nun die häufige Verwirrung rund um Dateipfade an. Angenommen, du baust ein Docker-Container-Image als Teil deiner Infrastruktur, und dein Dockerfile liegt in einem Unterverzeichnis namens app, direkt neben deinem Pulumi-Code. Engineers übergeben oft einen absoluten Pfad von ihrer lokalen Maschine, um Pulumi zu sagen, wo das Dockerfile liegt. Aber ein absoluter Pfad enthält dein persönliches User-Directory. Wenn ein Teamkollege den Code pullt und ein Update ausführt, sieht die Engine einen anderen absoluten Pfad auf seiner Maschine. Sie registriert das als strukturelle Änderung an der Ressource, was einen unnötigen Drift in deinem Infrastructure-State erzeugt. Um das zu fixen, wechselst du vielleicht zu einem standardmäßigen relativen Pfad, wie Punkt Slash app. Standardmäßige relative Pfade verlassen sich komplett auf das Current Working Directory des Terminals, das den Code ausführt. Wenn dein Continuous-Integration-System den Command aus einem Directory weiter oben im Repository ausführt, wird der relative Pfad falsch aufgelöst, und das Deployment crasht. Hier ist die wichtigste Erkenntnis. Du brauchst Pfade, die völlig unabhängig von der Maschine sind, auf der sie laufen, und unabhängig davon, wo der User den Execution-Command eingetippt hat. Du brauchst Project-relative Pfade. Pulumi bietet eine Built-in-Funktion, um die genaue Location der Pulumi.yaml-Datei während der Execution abzurufen. Je nach Programmiersprache heißt diese Funktion typischerweise get root directory oder so ähnlich. Wenn du diese Funktion aufrufst, gibt die Runtime den absoluten Pfad zu dem Ordner zurück, der deine Pulumi.yaml-Datei enthält. Anstatt einen Pfad zu deinem Dockerfile hardzucoden, baust du den Pfad dynamisch zusammen. Du nimmst das Ergebnis der Root-Directory-Funktion und hängst dein app-Unterverzeichnis daran an. Weil diese Funktion bei jeder Execution dynamisch evaluiert wird, ist der resultierende Pfad immer perfekt auf das Environment zugeschnitten, das den Code ausführt. Deine lokale Maschine, der Laptop deines Teamkollegen und der Remote-Build-Server werden alle den korrekten absoluten Pfad für ihre spezifischen File-Systems generieren. Der Dateipfad wird jedes Mal konsistent aufgelöst, und die Engine erkennt null Änderungen an der Resource-Definition. Deinem Infrastructure-Code sollte es völlig egal sein, wo er auf einer Festplatte lebt. Verankere deine File-Assets immer an der Pulumi Root-Directory-Funktion, um sicherzustellen, dass dein Project über jedes Environment hinweg komplett portabel bleibt. Das war es für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 5 von 10. Deinen Infrastructure-Code per Copy-Paste zu kopieren, um eine Staging-Umgebung zu erstellen, ist ein Rezept für Drift und Katastrophen. Am Ende pflegst du mehrere Ordner mit fast identischen Dateien, und irgendwann vergisst jemand, Production zu updaten. Die Lösung ist, deine Umgebungen mithilfe von Stacks als isolierte Instanzen einer einzigen Codebase zu behandeln. Bevor wir weitermachen, lass uns ein häufiges Missverständnis klären. Ein Project in Pulumi ist einfach ein Verzeichnis, das deinen Source Code enthält. Es sind einfach nur die Anweisungen. Ein Stack ist eine aktive Deployment-Instanz dieses Codes. Du schreibst das Project einmal und deployst es mehrmals als verschiedene Stacks. Mit Stacks kannst du verschiedene Umgebungen wie Development, Staging und Production verwalten, ohne auch nur ein bisschen Code zu duplizieren. Wenn du ein Pulumi Update ausführst, wendet es den Code in deinem Project auf den Stack an, der gerade aktiv ist. Jeder Stack verwaltet sein eigenes, isoliertes State File, das nur die Ressourcen trackt, die für diese spezifische Umgebung erstellt wurden. Das Managen dieser Umgebungen passiert direkt in deinem Terminal. Du erstellst eine neue Umgebung, indem du den stack initialize Command ausführst und ihr einen Namen wie dev oder prod gibst. Pulumi registriert diese neue Instanz und erstellt einen frischen State dafür. Um den Kontext zu wechseln, benutzt du den stack select Command. Die Pulumi CLI merkt sich, welcher Stack aktiv ist. Wenn du den dev Stack auswählst und ein Update ausführst, schaut sich Pulumi nur den Development State an. Es provisioniert oder modifiziert die Development-Infrastruktur und lässt deine Staging- und Production-Umgebungen komplett unberührt. Damit hätten wir das Deployen isolierter Umgebungen abgedeckt. Aber was passiert, wenn diese Umgebungen miteinander kommunizieren müssen? Manchmal ist ein Stack auf Informationen angewiesen, die von einem anderen generiert werden. Vielleicht hast du ein Project, das die Core-Infrastruktur managt, und ein völlig separates Project, das sich um den Application Code kümmert. Sagen wir mal, du hast ein Infrastructure Project, das einen Kubernetes Cluster provisioniert. Du deployst das als einen Stack namens base-infra-prod. Während des Deployments generiert der Cluster einen dynamischen Connection String. Jetzt hast du ein zweites Project für einen Microservice, der in genau diesen Cluster deployt werden muss. Du willst den Connection String nicht hardcoden, und du willst auch nicht beide Projects in ein einziges, riesiges und langsames State File mergen. Hier wird es interessant. Du kannst diese Deployments sicher mithilfe einer Stack Reference verbinden. Eine Stack Reference erlaubt es einem Stack, die exportierten Outputs eines anderen Stacks zu lesen. Um das aufzusetzen, muss dein Kubernetes Cluster Programm den Connection String am Ende seines Durchlaufs explizit exportieren. Ein Export ist einfach nur eine Variable, die Pulumi speziell im Stack State speichert, damit sie von außen gelesen werden kann. Dann erstellst du drüben in deinem Microservice-Programm ein Stack Reference Objekt. Du übergibst ihm den Namen des Infrastructure Stacks, von dem du lesen möchtest. Als Nächstes rufst du eine get output Methode auf dieser Referenz auf und fragst nach dem Connection String unter seinem exportierten Namen. Dein Microservice kann diesen Wert nun nutzen, um sein Deployment zu konfigurieren. Der Microservice Stack kann den Cluster Stack nicht verändern. Er kann nur die spezifischen Werte lesen, die der Cluster Stack exportiert hat. Das erzwingt eine saubere Trennung. Du kannst deine Core Network Infrastruktur völlig unabhängig von deinen Application Workloads updaten und skalieren, während du die nötigen Connection Details sicher über diese Grenze hinweg weitergibst. Indem du deinen Code von der Environment-Instanz entkoppelst, garantierst du, dass jedes Tier deines Systems durch exakt dieselbe Logik geht, und entfernst so die versteckten Risiken manueller Duplizierung. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 6 von 10. Du deployst deinen Infrastructure Code, die Syntax ist einwandfrei, und es schlägt sofort fehl, weil ein Storage Bucket-Name bereits vergeben ist. Oder noch schlimmer, du aktualisierst eine Datenbank-Instanz, und dein Tool löscht die alte, bevor es die neue erstellt, was einen Hard Outage verursacht. Du kannst beide Probleme lösen, indem du verstehst, wie dein Infrastructure-Tool mit Identitäten umgeht. Genau das behandeln wir heute: Die Bausteine: Pulumi Resources. In Pulumi ist eine Resource ein Objekt, das ein Stück Infrastruktur repräsentiert. Es gibt zwei Haupttypen, mit denen du arbeiten wirst. Der erste ist eine Custom Resource. Diese mappt direkt auf ein physisches Objekt, das von einem Cloud Provider verwaltet wird. Wenn du eine Custom Resource deklarierst, macht Pulumi einen API Call zu Amazon, Azure oder Google Cloud, um genau dieses Objekt zu erstellen, wie eine Virtual Machine oder einen Load Balancer. Der zweite Typ ist eine Component Resource. Eine Component Resource mappt nicht auf ein einzelnes Stück Cloud-Infrastruktur. Stattdessen ist sie ein logischer Container für andere Resources. Du nutzt Component Resources, um Abstraktionen auf höherer Ebene zu bauen. Zum Beispiel könntest du eine einzelne Component Resource namens Secure Web Server erstellen, die intern eine Virtual Machine, eine Security Group und eine IP-Adresse provisioniert. Die Component Resource selbst gruppiert sie einfach in deinem State File, was deinen Code sauberer und einfacher zu verwalten macht. Egal, ob du eine Custom Resource oder eine Component Resource definierst, jede einzelne braucht einen Namen. Das bringt uns zu einer häufigen Frustrationsquelle. Leute tippen einen Namen in ihren Code, deployen ihn und schauen dann in ihre Cloud Console, nur um festzustellen, dass an den Namen ihrer Resource ein zufälliger String angehängt wurde. Das ist kein Bug. Es ist ein Core Feature davon, wie Pulumi funktioniert, und du musst den Unterschied zwischen einem logischen Namen und einem physischen Namen verstehen. Der logische Name ist der Name, den du als Argument in deinen Code eintippst. Pulumi nutzt diesen logischen Namen, um die Resource in seinem State File zu tracken. So weiß Pulumi, dass die Datenbank in deinem Code heute genau dieselbe Datenbank ist, die du gestern deployed hast. Der physische Name ist das, wie der Cloud Provider die Resource in seinem eigenen System tatsächlich nennt. Standardmäßig nimmt Pulumi deinen logischen Namen, fügt ein zufälliges Suffix hinzu und nutzt diesen kombinierten String als physischen Namen. Das nennt man Auto-Naming. Hier ist die wichtigste Erkenntnis. Auto-Naming verhindert globale Naming Collisions und ermöglicht Zero-Downtime Replacements. Denk mal daran, mehrere identische Storage Buckets in einer Loop mit Azure zu provisionieren. Azure verlangt, dass Storage Account-Namen weltweit über alle Kunden hinweg eindeutig sind. Wenn du versuchst, einen strikten physischen Namen zu erzwingen, wird der zweite Bucket in deiner Loop fehlschlagen, weil der Name schon vergeben ist, oder noch schlimmer, jemand anderes auf der Welt könnte ihn bereits besitzen. Mit Auto-Naming kannst du in deiner Loop einfach einen logischen Namen wie archive-bucket verwenden. Pulumi wird jede Iteration logisch tracken und gleichzeitig sicherstellen, dass jeder Bucket in Azure einen mathematisch eindeutigen physischen Namen bekommt. Auto-Naming schützt außerdem deine System Uptime. Wenn du eine Änderung machst, die erzwingt, dass eine Resource ersetzt wird, erstellt Pulumi zuerst die neue Resource, verifiziert, dass sie funktioniert, und löscht erst dann die alte. Wenn du Auto-Naming überschreibst und einen strikten physischen Namen erzwingst, wird der Cloud Provider nicht zulassen, dass zwei Resources zur selben Zeit denselben Namen teilen. Pulumi wäre gezwungen, deine alte Resource zuerst zu löschen, was Downtime verursacht, während die neue provisioniert. Wenn du helfen möchtest, die Show am Laufen zu halten, kannst du auf Patreon nach DevStoriesEU suchen. Halte deine physischen Namen flexibel. Lass das Tool die zufälligen Suffixe managen, denn während dein State File einen logischen Namen braucht, um Ordnung zu halten, verlässt sich deine Production Environment auf physische Flexibilität, um online zu bleiben. Danke fürs Zuhören. Macht's gut, Leute.

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 7 von 10. Ein Datenbankpasswort in deinem Infrastructure-Code zu hardcoden, ist ein garantierter Security-Fail. Aber Environment Variables manuell in jede einzelne Deployment-Pipeline zu injecten, ist fehleranfällig und schwer nachzuverfolgen. Du brauchst eine Möglichkeit, bestimmte, verschlüsselte Werte automatisch an spezifische Environments zu binden. Das ist Keeping Secrets: Configuration Management. Die Kernidee hierbei ist, deinen Code von deiner Configuration zu trennen. Du willst deine Infrastructure-Logik genau einmal schreiben. Wenn du dann auf deinen Development-Stack deployest, provisioniert der Code kleine Instanzen. Wenn du nach Production deployest, provisioniert er große Instanzen und nutzt die Credentials der Production-Datenbank. Pulumi löst das über ein eingebautes Configuration-System. Ein häufiger Grund zur Verwirrung ist, wie diese Werte eigentlich gespeichert werden. Einen Pulumi Configuration-Wert zu setzen, setzt keine lokalen Operating System Environment Variables. Stattdessen speichert es die Werte direkt in einer Datei namens Pulumi dot stack-name dot yaml. Da jeder Stack seine eigene Configuration-Datei bekommt, liegen deine Dev-Configuration und deine Prod-Configuration Seite an Seite in deinem Repository, sauber getrennt durch den Dateinamen. Du fügst dieser Datei Daten über das Pulumi Command Line Interface hinzu. Wenn du den Command pulumi config set frontendPort 8080 ausführst, schreibt Pulumi dieses Key-Value-Pair direkt in die yaml-Datei für deinen aktuell aktiven Stack. Um diesen Wert in deinem Infrastructure-Code zu nutzen, instanziierst du ein Config-Objekt. Dann rufst du eine Methode wie get oder require auf diesem Objekt auf und übergibst den Key-Namen. Der Unterschied ist ganz einfach. Ein Call von get gibt den Wert zurück, wenn er existiert, oder nichts, wenn nicht. Ein Call von require wirft einen Error und stoppt dein Deployment, wenn der Configuration-Key fehlt. Das ist ein großartiger Weg, um sicherzustellen, dass ein Deployment niemals ohne ein obligatorisches Setting weiterläuft. Du bist nicht auf einfache Strings beschränkt. Du kannst strukturierte Daten speichern und abrufen, wie einen JSON-Block, der Scaling-Parameter definiert, und ihn direkt in ein Objekt in deinem Code parsen. Was passiert nun, wenn dieser Configuration-Wert hochsensibel ist? Angenommen, deine Application muss sich mit einer externen Datenbank verbinden, und du musst das Datenbankpasswort an deine Infrastructure übergeben. Du darfst das absolut nicht als Plaintext in deiner yaml-Datei speichern, weil diese Datei in die Version Control committet wird. Hier kommen Pulumi Secrets ins Spiel. Du nutzt genau dasselbe Command Line Interface, aber du hängst ein secret Flag an. Du führst pulumi config set dbPassword dein-passwort dash dash secret aus. Pulumi verschlüsselt den Wert, bevor er in der yaml-Datei gespeichert wird. Wenn sich jemand die Datei in deinem Repository ansieht, sieht er nur einen Ciphertext-String, der vom Encryption Provider deines Stacks sicher verschlüsselt wurde. In deinem Code rufst du das sicher ab, indem du eine spezifische Secret-Methode auf deinem Config-Objekt aufrufst, wie zum Beispiel requireSecret. Hier ist die entscheidende Erkenntnis. Wenn du ein Secret auf diese Weise abrufst, wrappt Pulumi es in einen speziellen Secret-Typ. Während dieser Wert durch deinen Infrastructure-Code fließt und an Resources übergeben wird, trackt die Pulumi-Engine ihn. Sie stellt sicher, dass der Plaintext-Wert während eines Deployments in deinem Console-Output maskiert wird, und sie garantiert, dass der Wert in deiner Pulumi State-Datei verschlüsselt bleibt. Configuration erlaubt es dir, Infrastructure-Code einmal zu schreiben und ihn sicher über Environments hinweg zu promoten. Native Secret Encryption stellt sicher, dass deine sensiblen Credentials diese Deployments steuern, ohne jemals in deine Version Control oder deine State-Dateien zu leaken. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 8 von 10. Du kopierst einen Block Storage- und Networking-Code und fügst ihn zum fünften Mal diese Woche ein. Dein Infrastructure-Code wächst, wird aber nicht smarter. Anstatt jedes Mal identische Cloud-Konfigurationen zu wiederholen, wenn du ein Standard-Setup brauchst, kannst du sie mit einer einzigen logischen Einheit generieren. Genau darum geht es in dieser Folge: Scaling Up: Component Resources on Azure. Wenn du anfängst, Pulumi zu nutzen, deklarierst du Raw Resources. Eine Resource Group hier, ein Storage Account dort. Aber wenn dein System wächst, erfordert das Deployen eines Standard-Architekturbausteins das Provisioning der exakt gleichen Primitives, immer und immer wieder. Das verstößt gegen die Regel, dich nicht selbst zu wiederholen. Component Resources lösen dieses Problem, indem sie es dir ermöglichen, mehrere physische Cloud-Ressourcen in einer wiederverwendbaren Abstraktion zu kapseln. Stell dir eine Component Resource wie eine Custom Class vor, die du in deiner bevorzugten Programmiersprache definierst. Sobald sie definiert ist, instanziierst du sie genau wie eine Built-in Pulumi Resource. Stell dir ein Szenario vor, in dem du häufig statische Websites auf Azure deployest. Ein minimales Setup erfordert eine Azure Resource Group, einen Storage Account, der für Static Website Hosting konfiguriert ist, und ein Blob-Objekt, das als Index-Dokument dient. Anstatt diese drei Definitionen jedes einzelne Mal in deinem Main-Programm zu schreiben, erstellst du eine Azure Static Website Component. Um das zu bauen, definierst du eine neue Klasse, die von der Pulumi Base Class ComponentResource erbt. Dein Klassen-Constructor nimmt einen Namen, ein Set von Arguments zur Anpassung und Standard Resource Options entgegen. Das Allererste, was dein Constructor macht, ist den Base Class Constructor aufzurufen. Du übergibst ihm ein eindeutiges Type Token, wie zum Beispiel custom Doppelpunkt infrastructure Doppelpunkt static website, zusammen mit dem Namen. Dieses Type Token teilt der Engine mit, wie sie deine neue Abstraktion im State File tracken soll. Als Nächstes definierst du die eigentlichen Azure Primitives innerhalb deines Constructors. Du deklarierst die Resource Group. Du deklarierst den Storage Account innerhalb dieser Gruppe. Du lädst den Index-Blob in diesen Account hoch. Hier ist der entscheidende Punkt. Wenn du diese internen Ressourcen erstellst, musst du der Engine explizit mitteilen, dass sie zu deiner neuen Component gehören. Das machst du, indem du die Component Instance selbst in die Resource Options unter der Parent Property übergibst. Viele Engineers vergessen diesen Schritt. Wenn du die Parent Option weglässt, werden die Child Resources zwar erfolgreich provisioniert, aber sie werden als Top-Level Resources behandelt. Dein Command Line Output wird eine flache, verwirrende Liste sein. Indem du die Parent Property auf deine Component Instance setzt, organisiert die Engine den State Tree. Wenn du ein Update ausführst, verschachtelt das Interface die Resource Group, den Storage Account und den Blob visuell direkt unter deiner Custom Website Component. Das hält deinen State managebar und deinen Output lesbar. Schließlich muss dein Main-Programm wahrscheinlich die Webadresse der neu erstellten Site kennen. Innerhalb deiner Component, nach der Definition des Storage Accounts, mappst du seinen Primary Web Endpoint auf eine Public Property deiner Klasse. Dann rufst du eine Methode namens register outputs auf. Das schließt die Initialisierung ab und stellt sicher, dass die finale Adresse für den Rest deines Programms exposed wird und auf der Konsole ausgegeben wird, wenn das Deployment fertig ist. In deinem Main File siehst du nun keinen Boilerplate mehr. Du instanziierst einfach deine Website Component, übergibst ihr ein Index File und deployest. Die zugrunde liegenden Ressourcen werden sicher hinter der Abstraktion verwaltet. Die wahre Power von Infrastructure as Code ist es, Cloud-Architektur wie Software zu behandeln, und Component Resources sind der Weg, wie du eine standardisierte, zuverlässige Library für dein Team baust. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 9 von 10. Du musst nicht Jahre an bestehendem Code wegwerfen, um heute ein neues Infrastruktur-Tool zu nutzen. Der gefürchtete, massive System-Rewrite ist ein riesiges Risiko und zum Glück völlig optional. Die Strategie, die das möglich macht, heißt Friedliche Koexistenz: Terraform State lesen. Ein weit verbreiteter Irrglaube ist, dass der Wechsel zu Pulumi bedeutet, dass du deine gesamte bestehende Infrastruktur auf einmal migrieren musst. Das stimmt nicht. Pulumi kann nativ Ressourcen lesen und von ihnen abhängen, die aktiv von Terraform verwaltet werden. Du kannst neue Tools schrittweise und parallel zu deinen bestehenden Deployment-Pipelines einführen. Stell dir eine typische Enterprise-Umgebung vor. Deine Firma hat eine zentrale AWS Virtual Private Cloud, die von einem zentralen Netzwerk-Team mit Terraform verwaltet wird. Du bist Entwickler, baust eine neue Applikation und möchtest Pulumi nutzen, um Elastic Container Service Tasks zu deployen. Deine Container müssen in genau dieser VPC laufen. Du willst den VPC-Code nicht in Pulumi neu schreiben, und du willst ganz sicher nicht das Management des zugrundeliegenden Netzwerks übernehmen. Um das zu lösen, nutzt du den Pulumi Terraform Provider. Dieser Provider enthält eine spezielle Komponente zum Lesen von State Files, die sogenannte Remote State Reference. Der Prozess basiert darauf, wie Terraform seine Ausführungsdaten speichert. Zuerst muss der Terraform-Code, der das Netzwerk verwaltet, die Daten, die deine neue Applikation braucht, explizit bereitstellen. Das passiert mithilfe von Standard-Terraform Output Blocks. Das Netzwerk-Team konfiguriert seinen Code so, dass er den VPC Identifier und eine Liste von privaten Subnet Identifiers als Output liefert. Wenn Terraform seine Konfiguration anwendet, werden diese Outputs in das Terraform State File geschrieben, das typischerweise remote in einem Backend wie einem AWS S3 Bucket oder der Terraform Cloud gespeichert wird. Als Nächstes wechselst du zu deinem Pulumi-Programm. Du schreibst Code, um die Remote State Reference zu instanziieren. Du übergibst diesem Objekt genau dieselben Backend-Konfigurationsdetails, die Terraform nutzt, um sein State File zu finden. Dazu gehören der Backend-Typ, die Storage Location, die Region und der spezifische State File Key. Wenn du dein Pulumi-Deployment ausführst, verbindet sich die Engine mit diesem Remote-Backend, öffnet das Terraform State File und parst die verfügbaren Outputs. Hier ist der entscheidende Punkt: Pulumi behandelt den Terraform State als strikt read-only. Es modifiziert niemals das Terraform State File und übernimmt keine Ownership für die Netzwerk-Ressourcen. Es fragt einfach nur die aktuellen, bekannten Werte der Infrastruktur ab. Sobald Pulumi die VPC und Subnet Identifiers aus dem State abgerufen hat, behandelst du diese Werte wie jede andere Variable in deinem Code. Du übergibst sie direkt an die Deployment-Logik für deinen neuen Container-Cluster. Pulumi provisioniert deine neuen Container nahtlos in das bestehende Netzwerk. Diese Architektur sorgt für eine strikte Trennung der Verantwortlichkeiten. Das zentrale Team verwaltet den Network Lifecycle weiterhin mit Terraform. Wenn sie eine Route Table updaten oder ein Tag hinzufügen, nutzen sie ihren Standard-Workflow. Wenn sie einen Output modifizieren, wie zum Beispiel beim Erstellen eines neuen Subnets, liest Pulumi beim nächsten Update automatisch das aktualisierte State File und passt dein Container-Deployment entsprechend an. Die Nutzung von Remote State References schafft eine saubere, unidirektionale Dependency-Grenze. Das erlaubt es dir, selbstbewusst neue Systeme mit modernen Features zu bauen, während du dich auf ein stabiles Fundament verlässt, das von Legacy-Code gemanagt wird. Das war’s für diese Folge. Danke fürs Zuhören und viel Spaß beim Entwickeln!

Hallo, hier ist Alex von DEV STORIES DOT EU. Pulumi: Infrastructure as Code, Folge 10 von 10. Das Testen komplexer Infrastrukturlogik ist bekanntermaßen schwierig. Du schreibst Tausende von Konfigurationszeilen, aber die Überprüfung, ob eine bestimmte Kombination von Firewall-Regeln vor dem Deployment tatsächlich wie gewünscht funktioniert, fühlt sich oft wie ein Ratespiel an. Die große Migration: Die Konvertierung von HCL zu Pulumi ist die Lösung dafür. Der Wechsel von Terraform zu Pulumi ist kein einfaches syntaktisches Find-and-Replace. Es geht nicht darum, geschweifte Klammern durch runde zu ersetzen. Es geht darum, statische Konfiguration in ein ausführbares Programm zu transformieren, wodurch du sofortigen Zugriff auf native Loops, Functions und Standard-Testing-Frameworks bekommst. Denk an eine hochkomplexe, sich wiederholende Terraform Security Group Konfiguration. Du hast wahrscheinlich Dutzende von sich überschneidenden Port Ranges, spezifische IP Allowlists und umfangreiche Block Definitions. In HCL erfordert das Managen davon starre Strukturen, und um die Logik zu validieren, musst du einen Plan gegen einen Live Cloud State ausführen. Der Übergang beginnt mit dem pulumi convert Command. Du navigierst zu einem Verzeichnis mit deinen bestehenden Terraform-Dateien und führst diesen Command aus, wobei du deine Zielsprache, zum Beispiel TypeScript oder Python, angibst. Das Tool parst deinen HCL Source Code, liest deine Variables, Main Resources und Outputs und generiert ein äquivalentes Pulumi-Programm. Es übersetzt die deklarative Absicht der HCL in die imperative Struktur deiner gewählten Programmiersprache. Sobald dieser Code generiert ist, werden die strategischen Vorteile der Migration deutlich. Du kannst nun diese riesige Liste von Security Group Rules in ein sauberes Array von Data Objects refactoren oder sie aus einem externen Configuration File ziehen. Du kannst über dieses Array iterieren, um Firewall-Regeln dynamisch mit Standard-TypeScript- oder Python-Loops zu generieren. Hier ist der entscheidende Punkt. Da deine Infrastruktur nun in einer General-Purpose-Language geschrieben ist, kannst du sie genau wie Application Code testen. Du kannst einen Unit Test mit Standard-Frameworks wie Jest oder PyTest schreiben. Du erstellst einen Test Case, der die Pulumi Runtime mockt und sicherstellt, dass deine Security Group Builder Function niemals versehentlich Port zweiundzwanzig für das gesamte Internet freigibt. Du führst diese Tests in Millisekunden komplett offline aus und fängst logische Fehler ab, noch bevor die Infrastructure Plan Phase überhaupt beginnt. Diese Umstellung ermöglicht eine tiefe Language Integration. Dein Infrastructure Code kann Standard Libraries, Validation Logic und Typing Definitions direkt mit deinem Application Code teilen. Du erhältst Zugriff auf die ausgereiften Ökosysteme von Package Managern wie NPM oder pip, wodurch du Infrastructure Patterns genauso einfach packagen und verteilen kannst wie jede andere Software Library. Der Conversion Command übernimmt die Hauptarbeit bei der Übersetzung deines Current States, aber die wahre Migration findet statt, wenn du dein Mindset vom Schreiben von Static Files hin zum Engineering testbarer Systeme verschiebst. Der größte Vorteil bei der Konvertierung deines Codes liegt darin, von der reinen Konfiguration der Infrastruktur zur echten Programmierung überzugehen. Ich empfehle dir dringend, die offizielle Pulumi Documentation zu lesen, dir ein kleines Terraform Module zu schnappen und die Konvertierung selbst auszuführen, um den Output zu sehen. Wenn du Ideen für technische Themen hast, die wir in unserer nächsten Serie behandeln sollten, besuche devstories dot eu und lass es uns wissen. Das war's für diese Folge. Vielen Dank fürs Zuhören und keep building!