Terraform Fundamentals

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 1 von 13. Früher bedeutete das Provisioning von Servern, ein Helpdesk-Ticket zu erstellen und zwei Wochen zu warten, bis sich jemand durch eine Cloud Console klickt. Heute ist genau derselbe Prozess ein einfacher Pull Request, der innerhalb von Minuten sicher deployt wird. Dieser Wandel wird komplett vom Infrastructure as Code Paradigma angetrieben, und HashiCorp Terraform ist die wichtigste Engine dahinter. Infrastructure as Code ist genau das, wonach es klingt. Du managst deine Datenbanken, virtuellen Netzwerke und Compute Instances mit einfachen Textdateien statt mit manuellen Klicks. Diese Dateien können versioniert, von Kollegen gereviewt und automatisch getestet werden. Um zu verstehen, warum das so mächtig ist, stell dir einen Systemadministrator vor, der eine neue Azure Virtual Machine braucht. Mit einem imperativen Workflow würde er vielleicht ein komplexes PowerShell-Skript schreiben. Dieses Skript muss jede Aktion explizit in der richtigen Reihenfolge definieren. Es weist das System an, sich einzuloggen, zu prüfen, ob ein Netzwerk existiert, es zu erstellen, falls nicht, eine Public IP zuzuweisen und schließlich den Server zu booten. Wenn das Skript bei Schritt vier fehlschlägt, hast du am Ende eine unvollständige Infrastruktur. Das Skript ein zweites Mal auszuführen, führt oft zu Fehlern, weil einige Ressourcen bereits existieren. Terraform nutzt stattdessen einen deklarativen Ansatz. Du schreibst nicht die genaue Abfolge der Schritte. Du definierst einfach nur den gewünschten Endzustand. Du schreibst ein Configuration File, in dem steht, dass du eine Azure Virtual Machine haben willst, die an ein bestimmtes Netzwerk angebunden ist. Terraform vergleicht deinen angeforderten State mit dem, was aktuell in der Cloud existiert. Dann berechnet es die exakte Reihenfolge der API Calls, die nötig sind, um diese Lücke zu schließen. Wenn das Netzwerk schon existiert, lässt Terraform es in Ruhe und baut nur den Server. Hier ist die wichtigste Erkenntnis: Viele Engineers verwechseln Infrastructure Provisioning Tools wie Terraform mit Configuration Management Tools wie Chef, Puppet oder Ansible. Das ist nicht dasselbe. Terraform baut das Haus. Configuration Management Tools stellen die Möbel auf. Terraform provisioniert die rohen Cloud-Ressourcen, wie die Load Balancer und die Virtual Machines. Ansible oder Chef loggen sich dann auf diesen Machines ein, um Softwarepakete zu installieren und Background Services zu starten. Configuration Management Tools wurden ursprünglich für Mutable Infrastructure entwickelt. Sie gehen davon aus, dass ein Server lange lebt und ständig gepatcht und getweakt wird. Terraform drängt dich in Richtung Immutable Infrastructure. Wenn ein Environment eine andere OS-Version braucht, loggt sich Terraform nicht ein und führt ein Upgrade-Skript aus. Es zerstört den alten Server und provisioniert einen brandneuen mit dem richtigen Image. Dieser strikte Ansatz garantiert, dass dein Code immer der Realität entspricht, und eliminiert Configuration Drift komplett. Dieser Workflow ist besonders wertvoll, weil er plattformagnostisch ist. Ein Enterprise nutzt selten nur einen Vendor. Vielleicht laufen deine primären Workloads auf Azure, du machst dein DNS über Cloudflare und managst Incident Routing in PagerDuty. Terraform managt all das über ein Provider-Modell. Ein Provider ist einfach ein Plugin, das eine spezifische Vendor API versteht. Indem du mehrere Provider nutzt, kannst du eine einzige Configuration bauen, die gleichzeitig eine Azure-Datenbank hochfährt, die nötigen DNS Records konfiguriert und die Monitoring Alerts einrichtet. Die zugrunde liegenden API Calls ändern sich, aber dein Workflow bleibt exakt gleich. Wenn du dabei helfen willst, dass weitere Episoden kommen, kannst du auf Patreon nach DevStoriesEU suchen, um die Show zu unterstützen. Ein Tool, das einfach nur Tasks automatisiert, macht dich schneller, aber ein Tool, das einen deklarativen State erzwingt, macht dein komplettes System vorhersehbar. Ich möchte mir kurz einen Moment nehmen, um dir fürs Zuhören zu danken – das hilft uns extrem weiter. Mach's gut!

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 2 von 13. Du klickst auf Deploy, beobachtest die Konsole und drückst die Daumen in der Hoffnung, dass du nicht gerade die Production-Umgebung lahmgelegt hast. Dieser blinde Sprung ins Ungewisse ist ein massives Risiko, und genau das eliminiert der Core-Terraform-Workflow. Der Workflow besteht aus drei strikten Schritten: write, plan und apply. Jeder Schritt arbeitet unabhängig, um deine Requirements in laufende Resources umzusetzen. Du beginnst mit der write-Phase. Du erstellst Configuration Files, die exakt die Infrastruktur deklarieren, die du haben willst. Du schreibst kein prozedurales Script, das Schritt für Schritt sagt, wie man einen Server baut. Du beschreibst den finalen, gewünschten State deiner Umgebung. Du speicherst diese Files, und dein Code wird zur Single Source of Truth für das, was existieren soll. Neue User denken manchmal, der nächste Schritt sei einfach, diese Files sequenziell von oben nach unten auszuführen. Aber so funktioniert dieses Tool nicht. Es führt Commands nicht blind aus. Stattdessen geht es in die plan-Phase über. Die plan-Phase ist die absolute Superpower dieses Workflows. Wenn du den plan-Command ausführst, evaluiert das Tool deine neue Configuration gegen den aktuellen, tatsächlichen State deiner Infrastruktur. Es berechnet ein präzises Diff zwischen der Realität und deinem gewünschten Code. Hier ist die wichtigste Erkenntnis. Das Tool liest dieses Diff und generiert einen extrem detaillierten Dry Run von jeder einzelnen Aktion, die es durchführen will. Stell dir einen Engineer vor, der einen Azure Load Balancer zu einem Live-Environment hinzufügen muss. Er updatet seine Configuration Files und führt den plan-Command aus. Das System verbindet sich mit dem Cloud Provider, checkt den aktiven State und gibt eine strikte Summary aus. Der Engineer liest den Output und sieht eine Resource zum Hinzufügen, null zum Ändern und null zum Zerstören. Der Output detailliert die exakten Properties des neuen Load Balancers. Der Engineer validiert diesen Dry Run. Er weiß, dass die Änderung sicher ist, bevor auch nur ein einziger API Call die reale Infrastruktur modifiziert. Es gibt kein Rätselraten. Nachdem du den Output validiert hast, gehst du zur apply-Phase über. Das ist der Moment der Execution. Das Tool nimmt das exakte Diff, das während der plan-Phase berechnet wurde, und baut einen strikten Execution Graph. Es mappt alle Dependencies. Wenn dein neuer Load Balancer eine dedizierte Public IP benötigt, stellt der Execution Graph sicher, dass die IP zuerst provisioniert wird. Das System wartet, bis die IP verfügbar ist, schnappt sich die neue Adresse und erstellt erst dann den Load Balancer. Es kümmert sich automatisch um das Timing und die Reihenfolge. Weil die apply-Phase strikt dem freigegebenen Execution Plan folgt, hast du niemals Resources, die in der falschen Reihenfolge hochfahren, oder löschst versehentlich existierende Datenbanken wegen eines Tippfehlers. Der Workflow zwingt dich dazu, die Intention von der Execution zu trennen. Der mächtigste Aspekt dieses Prozesses ist nicht das automatisierte Provisioning selbst. Es ist die komplette Eliminierung von Operational Anxiety durch vorhersagbare, überprüfbare Dry Runs. Das war es für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 3 von 13. Out of the box weiß die Core Terraform Application eigentlich gar nicht, wie man eine Azure Virtual Machine baut oder eine Datenbank erstellt. Sie ist schlichtweg eine Engine, die Code evaluiert, Dependencies ermittelt und den State managed. Für die eigentliche Arbeit ist sie auf Tausende von herunterladbaren Translation-Plugins angewiesen. Das bringt uns zu den Providern und dazu, wie du deinen Code mit Azure verbindest. Ein häufiges Missverständnis ist die Annahme, dass die Terraform Application selbst die Logik für jede Cloud-Plattform enthält. Das tut sie nicht. Das Binary, das du auf deinem Rechner installierst, ist komplett infrastructure-agnostic. Es versteht die Configuration Language und den Deployment Workflow, hat aber null hardcodiertes Wissen über irgendeine spezifische Cloud API. Stattdessen nutzt Terraform Plugins, sogenannte Provider. Ein Provider ist ein eigenständiges Stück Software, das die Endpoints, Authentication Methods und das Resource Behavior für eine bestimmte Plattform versteht. Es gibt einen Provider für Microsoft Azure, einen für Amazon Web Services und weitere für Software-as-a-Service-Plattformen wie GitHub oder Datadog. Diese Plugins werden in einem zentralen Directory, der sogenannten Terraform Registry, veröffentlicht und gehostet. Wenn du ein neues Infrastructure-Projekt startest, musst du explizit deklarieren, welche Provider dein Code nutzen wird. Außerdem spezifizierst du die genaue Version des Providers, die du haben willst. Eine Version zu locken, ist eine extrem wichtige Praxis. Das stellt sicher, dass dein Deployment nicht unerwartet bricht, falls sich die Cloud API ändert oder das Provider Plugin morgen ein Major Update erhält. Du kontrollierst ganz genau, wann du upgradest. Den Provider einfach nur in deinem Textfile zu deklarieren, installiert ihn noch nicht. Du musst einen Initialization Command in deinem Terminal ausführen. Dieser Initialization Step greift aktiv auf die Terraform Registry zu, lädt die benötigten Provider Plugins herunter und cached sie in einem versteckten lokalen Directory. Bis du diesen Schritt ausführst, kann dein Terraform-Projekt nicht mit externen Systemen interagieren. Schauen wir uns das Setup für ein neues Projekt an, das sich mit einer Enterprise Azure Subscription verbindet. Dafür nutzt du den offiziellen Azure Resource Manager Provider, auch azurerm genannt. Nachdem du die benötigte Version deklariert hast, musst du das spezifische Verhalten des Providers konfigurieren. Jeder Provider hat seine eigenen Configuration Requirements, basierend auf der zugrunde liegenden API. Bei Azure verlangt das Plugin von dir, explizit zu deklarieren, wie es bestimmte Resource Behaviors handhaben soll. Zum Beispiel musst du dem Provider mitteilen, ob er attached Storage Disks permanent löschen soll, wenn eine Virtual Machine destroyed wird. Der Provider verlangt diese Configuration im Voraus, damit destruktive Aktionen immer beabsichtigt sind. Sobald er initialized und configured ist, fungiert der Provider als Plug-and-Play Translation Layer. Wenn du deinen Code ausführst, berechnet die Core Terraform Engine die Differenz zwischen deiner aktuellen Infrastructure und deinem Desired State. Anschließend übergibt sie diese generischen Instructions an das Azure Provider Plugin. Das Plugin übernimmt und übersetzt deine Absicht in authentifizierte HTTP Requests, die direkt an die Azure Resource Manager API gesendet werden. Das Plugin wartet, bis Azure mit dem Erstellen oder Modifizieren der Resources fertig ist, übersetzt die API Response zurück in ein Format, das Terraform versteht, und übergibt die finalen Daten zurück an die Core Engine. Terraform selbst kommuniziert niemals direkt mit deiner Cloud-Umgebung; es delegiert jeden einzelnen API Call an das Provider Plugin. Dadurch wird der Provider zur eigentlichen Brücke zwischen deinem Code und deiner Live Infrastructure. Das war's für diese Folge. Vielen Dank fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 4 von 13. Du schaust dir deinen Code an und siehst eine Datenbank mit dem Label primary. Aber wenn du dich in deine Cloud Console einloggst, heißt genau dieselbe Datenbank völlig anders, zum Beispiel db-cluster-node-one. Wenn du willst, dass etwas physisch in deiner Cloud-Umgebung existiert, musst du es über das wichtigste Terraform-Konstrukt anfordern. Du musst aber auch verstehen, wie Terraform Dinge benennt. Heute sprechen wir darüber, wie man Infrastruktur mit Resources deklariert. Resources sind die grundlegenden Komponenten deiner Infrastruktur. Jedes Mal, wenn du ein Objekt erstellen, updaten oder löschen willst, schreibst du einen Resource Block. Dieses Objekt kann eine physische Komponente wie eine Compute Instance oder ein Storage Drive sein, oder ein logisches Konstrukt wie ein DNS Record oder ein Role Assignment. Der Resource Block übersetzt die Idee einer Infrastrukturkomponente in einen API Request, den dein Cloud Provider auch wirklich versteht. Wenn du einen Resource Block deklarierst, definierst du seine Identität über zwei verschiedene Labels. Zuerst deklarierst du den Resource Type. Das sagt Terraform genau, welche Art von Objekt du bauen willst und welcher Provider es bauen soll. Der Type beginnt immer mit dem Provider Namespace, wie Azure oder AWS, gefolgt von dem spezifischen Service. Im Grunde sagst du Terraform damit, dass du eine Azure Resource Group oder einen AWS Storage Bucket brauchst. Direkt nach dem Resource Type definierst du den Local Identifier. Das ist einfach nur ein Spitzname. Er existiert nur innerhalb deiner Terraform-Konfiguration. Du benutzt diesen Spitznamen, um aus anderen Teilen deines Codes auf das Objekt zu referenzieren. Er hat absolut keine Auswirkungen darauf, was dein Cloud Provider sieht. Das bringt uns zum Configuration Block selbst. Sobald du den Type und den lokalen Spitznamen deklariert hast, definierst du die Arguments für diese Resource. Arguments sind die spezifischen Einstellungen und Werte, die das Objekt konfigurieren. Hier übergibst du die eigentlichen Parameter, die von der Cloud Provider API benötigt werden. Um das Ganze zusammenzufassen: Stell dir vor, du deployst eine Azure Resource Group. Du deklarierst den Resource Type für eine Azure Resource Group und gibst ihr einen lokalen Spitznamen wie main. Innerhalb des Configuration Blocks gibst du die eigentlichen Arguments an. Du definierst ein name Argument und setzt es auf rg-enterprise-prod, und du definierst ein location Argument und setzt es auf eine bestimmte Region. Wenn du dein Deployment ausführst, nutzt Terraform den Resource Type, um zu wissen, welche Provider API aufgerufen werden muss. Es nutzt deine Arguments, um der API genau zu sagen, wie die Resource konfiguriert werden soll. Im Azure Portal wird deine Resource Group als rg-enterprise-prod angezeigt. Azure weiß absolut nichts von dem Spitznamen main. Aber zurück in deinem Code: Jedes Mal, wenn du die ID oder die Location dieser Resource Group abrufen musst, um sie an eine Virtual Machine oder eine Datenbank zu übergeben, fragst du Terraform einfach nach den Daten der lokalen Resource mit dem Namen main. Jeder Resource Type hat sein eigenes, einzigartiges Set an Arguments. Einige sind Pflicht, wie die Location für eine Resource Group oder die Instance Size für einen Virtual Server. Andere sind optional, wie Tagging oder spezifische Routing Rules. Die Provider Documentation gibt genau vor, welche Arguments du verwenden kannst. Du mappst einfach die Values, die du brauchst, in den Resource Block, und Terraform übernimmt die Übersetzung in die API Calls, die deine Infrastruktur dann tatsächlich provisionieren. Dein Local Identifier gehört Terraform, um deinen Code lesbar zu halten, aber deine Arguments gehören der Cloud, um die Realität zu definieren. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 5 von 13. Wenn eine Database existieren muss, bevor ein Web Server sich mit ihr verbinden kann, wie weiß ein Infrastructure Tool dann, was es zuerst bauen soll, ohne Sequential Scripts? Wenn du aus einem imperativen Scripting-Hintergrund wie Bash oder Python kommst, suchst du vielleicht nach Möglichkeiten, die Execution Zeile für Zeile zu erzwingen. Aber in Terraform spielt die Reihenfolge der Zeilen in deinem File überhaupt keine Rolle. Das Einzige, was zählt, sind Resource Relationships und Dependencies. Terraform ist eine hochintelligente Execution Engine. Bevor es irgendetwas erstellt, analysiert es deine Configuration und baut einen Directed Acyclic Graph. Dieser Graph bildet exakt ab, wie jeder Teil der Infrastructure mit den anderen verbunden ist. Es nutzt diese Map, um die effizienteste Reihenfolge für die Erstellung zu bestimmen. Dabei baut es unabhängige Resources parallel und sequenziert diejenigen, die voneinander abhängen. Du musst nie manuelle Wait- oder Sleep-Scripts schreiben. Meistens findet Terraform dieses Sequencing automatisch durch Implicit Dependencies heraus. Eine Implicit Dependency entsteht, wenn eine Resource ein Attribute einer anderen Resource referenziert. Stell dir ein Szenario vor, in dem du ein Azure Virtual Network und ein Subnet erstellst. Ein Subnet kann nicht ohne ein Virtual Network existieren. In deiner Configuration definierst du den Virtual Network Block und danach den Subnet Block. Innerhalb des Subnet Blocks setzt du das Virtual Network Name Argument so, dass es direkt auf das Name Attribute der Virtual Network Resource zeigt, die du gerade definiert hast. Wenn Terraform das parst, sieht es die Verbindung. Es weiß automatisch, dass es das Virtual Network fertigstellen und seinen generierten Namen fetchen muss, bevor es überhaupt anfangen kann, das Subnet zu bauen. Du musst ihm nicht sagen, was es tun soll. Du übergibst einfach die Daten, und Terraform kümmert sich um das Timing. Das ist der Teil, der zählt. Nutze immer Implicit Dependencies, wenn du kannst. Indem du Attributes direkt referenzierst, gibst du Terraform genau die Informationen, die es braucht, um deine Deployments sicher zu optimieren. Manchmal ist die Beziehung zwischen zwei Resources im Code nicht sichtbar. Du hast vielleicht eine Situation, in der eine Resource eine andere Resource braucht, um vollständig aktiv zu sein, aber sie muss eigentlich keine Daten von ihr pullen. Stell dir vor, du deployest eine Virtual Machine, auf der eine Application läuft, und provisionierst gleichzeitig eine Managed Database. Die Application erfordert, dass die Database komplett gebootet ist, bevor sie starten kann. Allerdings referenziert die Virtual Machine Configuration keine Attributes von der Database Resource. Weil es keinen Data Link gibt, geht Terraform davon aus, dass diese beiden Resources völlig unabhängig voneinander sind, und wird versuchen, sie gleichzeitig zu bauen. Die Application wird booten, nach einer Database suchen, die noch nicht existiert, und failen. Um das zu fixen, nutzt du Explicit Dependencies. Terraform bietet ein Meta-Argument namens depends on. Du fügst dieses Argument zum Virtual Machine Block hinzu und übergibst ihm eine List, die die Database Resource enthält. Das sagt Terraform explizit, dass es die Erstellung der Virtual Machine pausieren soll, bis die Database komplett fertig provisioniert ist. Du solltest Explicit Dependencies als letzten Ausweg betrachten. Sie zwingen Terraform dazu, bei seiner Execution konservativer zu sein, was deine Deployments verlangsamt. Sie können es mit der Zeit auch schwerer machen, deine Configuration zu maintainen, da der eigentliche Grund für die Dependency für den nächsten Engineer, der das File liest, nicht immer offensichtlich ist. Den Execution Graph die schwere Arbeit machen zu lassen, ist das, was Declarative Infrastructure von Procedural Scripts unterscheidet. Hör also auf zu versuchen, die Execution Order zu mikromanagen, und lass den Data Flow die Sequence diktieren. 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. Terraform Fundamentals, Folge 6 von 13. Du schreibst deinen Infrastructure-Code, führst ein Apply aus, und deine Server starten perfekt. Aber wenn du fünf Minuten später nochmal ein Apply ausführst, passiert nichts. Terraform weiß, dass der Job schon erledigt ist. Im Gegensatz zu einfachen Automatisierungs-Skripten, die Befehle blind ausführen, hat Terraform ein Gedächtnis. Ohne das wäre es völlig blind für die Infrastruktur, die es gerade erst gebaut hat. Dieses Gedächtnis nennt man Terraform State. Wenn du Terraform ausführst, erstellt es eine lokale Datei namens terraform dot tfstate. Viele Entwickler empfinden diese Datei anfangs als lästig. Sie wirkt wie ein zusätzliches Artefakt, das man verwalten und absichern muss. Aber diese Datei ist das Herzstück davon, wie Terraform funktioniert. Terraform braucht einen Mechanismus, um die logischen Resources, die in deinen Konfigurationsdateien definiert sind, auf die physischen Remote-Objekte in deiner Cloud-Umgebung zu mappen. Ein häufiges Missverständnis ist, dass Terraform einfach nur auf Cloud-Provider-Tags schaut, um herauszufinden, was es verwaltet. Du denkst vielleicht, es taggt einen Server bei der Erstellung und sucht später in der Cloud nach genau diesem Tag, um zu wissen, was geupdatet werden muss. Dieser Ansatz stößt aber schnell an seine Grenzen. Nicht alle Cloud-Resources unterstützen Tags. Außerdem könnte jemand ein Tag manuell bearbeiten oder löschen und so die Verbindung kappen. Und zu guter Letzt wäre es unglaublich langsam, bei jedem Plan-Durchlauf einen riesigen Enterprise-Cloud-Account nach bestimmten Tags zu durchsuchen. Weil Tags unzuverlässig sind, nutzt Terraform ein dediziertes, hochstrukturiertes State File. Das State File dient als private Mapping-Datenbank. Wenn du eine Resource in deinem Code deklarierst, erstellt Terraform sie über die Provider-API. Der Provider gibt einen eindeutigen physischen Identifier für dieses neu erstellte Objekt zurück. Terraform nimmt deinen logischen Resource-Namen aus dem Code, verknüpft ihn mit dieser eindeutigen Cloud-ID und schreibt das Paar in das State File. Nehmen wir ein praktisches Szenario. Du beschließt, die Größe einer Azure Virtual Machine in deinem Code zu ändern. Wenn du ein Apply ausführst, rät Terraform nicht, welche Maschine es ändern soll. Es checkt das State File, sucht deinen logischen Resource-Namen und ruft die exakte Azure Instance ID ab. Dann sendet es einen Update Request genau an diese spezifische ID. Ohne das State File wüsste Terraform nicht, ob es eine bestehende Maschine updaten oder einfach ein Duplikat erstellen soll. Neben dem Mapping übernimmt der State auch das Metadaten-Tracking. Terraform muss die genaue Reihenfolge kennen, in der Resources erstellt wurden, damit es sie sicher updaten oder löschen kann. Wenn ein Webserver eine Datenbank braucht, steht diese Dependency in deinem Code. Wenn du aber diesen gesamten Code-Block löschst, um die Umgebung abzubauen, kann Terraform den Code nicht mehr lesen, um die Dependency zu finden. Das State File behält eine Kopie dieser historischen Metadaten und stellt so sicher, dass Terraform den Webserver vor der Datenbank löscht. Der State sorgt außerdem für wichtiges Performance-Caching. Die API eines Cloud-Providers abzufragen, um den aktuellen Status von tausenden Network Rules, Storage Buckets und Compute Nodes zu sammeln, kostet extrem viel Zeit. Cloud-Provider haben außerdem strenge API Rate Limits. Das State File fungiert als Cache für deine Infrastruktur-Attribute. Indem es auf diesen Cache zugreift, minimiert Terraform die Anzahl langsamer, teurer API Calls, die nötig sind, um einen Plan zu berechnen. Hier ist die wichtigste Erkenntnis. Deine Konfiguration beschreibt, was du willst, der Cloud-Provider hat das, was tatsächlich existiert, und das State File ist die einzige definitive Brücke, die beides verbindet. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 7 von 13. Werte zu hardcoden ist für einen schnellen Test in Ordnung, aber was passiert, wenn du genau dasselbe Setup sowohl in einer Development-Umgebung als auch in Production deployen musst? Du kannst deinen Code nicht für jedes neue Deployment duplizieren und neu schreiben. Der Mechanismus, der das löst, ist die Parametrisierung mit Input Variables. Input Variables dienen als Parameter für ein Terraform-Modul. Sie ermöglichen es dir, Aspekte deiner Infrastruktur anzupassen, ohne den zugrunde liegenden Source Code zu verändern. Genau in diesem Schritt wird dein Code vom Proof of Concept zu einem production-ready Template. Durch die Verwendung von Variablen schreibst du die Konfiguration nur einmal und kannst sie überall wiederverwenden. Bevor wir uns mit den Details befassen, müssen wir ein häufiges Missverständnis ausräumen. Es gibt einen strikten Unterschied zwischen dem Deklarieren einer Variable und dem Zuweisen eines Wertes. Das Deklarieren einer Variable teilt Terraform lediglich mit, dass ein Parameter existiert, und definiert seine Regeln. Das Zuweisen eines Wertes ist der Vorgang, bei dem der Variable während eines Deployments tatsächlich Daten übergeben werden. Du deklarierst eine Variable mithilfe eines variable-Blocks, gefolgt von einem eindeutigen Namen. Innerhalb dieses Blocks definierst du den erwarteten Datentyp. Terraform unterstützt verschiedene Typen. Ein String ist einfach ganz normaler Text. Eine List ist eine geordnete Sequenz von Werten, wie zum Beispiel mehrere Availability Zones. Eine Map ist eine Sammlung von Key-Value-Paaren, was perfekt ist, um Standard-Resource-Tags anzuwenden. Innerhalb des variable-Blocks kannst du auch einen Default-Wert festlegen. Wenn du einen Default angibst, wird die Variable optional. Wenn der User während des Deployments keinen Wert angibt, verwendet Terraform einfach den Default. Wenn du keinen Default festlegst, zwingt Terraform den User dazu, einen Wert anzugeben, bevor es weitermacht. Machen wir das an einem praktischen Szenario fest. Angenommen, du hast ein Azure-Deployment. Aktuell fordert deine Konfiguration explizit eine kleine Virtual Machine-Größe namens Standard B2s an und hardcodet ein Environment-Tag als dev. Um das wiederverwendbar zu machen, ersetzt du diesen hardcodierten Text durch eine Referenz. In Terraform referenzierst du eine Input Variable, indem du var Punkt gefolgt vom Variablennamen tippst. Anstatt also Standard B2s zu schreiben, schreibst du var Punkt vm size. Anstatt dev schreibst du var Punkt environment. Jetzt ist dein Code flexibel, aber Terraform muss immer noch wissen, welche Werte es verwenden soll, wenn es tatsächlich ausgeführt wird. Hier kommen Variable Definition Files ins Spiel. Das sind Dateien, die auf Punkt tfvars enden. Ein tfvars-File ist einfach eine Liste von Variablennamen und ihren entsprechenden Werten. Für dein Production-Deployment erstellst du ein File namens prod Punkt tfvars. Darin setzt du die environment-Variable auf prod und die vm size-Variable auf eine größere Instanz, wie Standard D4s. Wenn du Terraform ausführst, verweist du auf dieses File. Terraform liest das tfvars-File, fügt diese Werte in deine var Punkt-Referenzen ein und provisioniert die Production-Umgebung. Morgen kannst du genau denselben Terraform-Code auf ein dev Punkt tfvars-File verweisen lassen, um eine kleine Testing-Umgebung hochzufahren. Hier ist die wichtigste Erkenntnis. Deine Logik komplett von deinen umgebungsspezifischen Daten getrennt zu halten, ist das, was Infrastruktur wirklich wiederholbar macht. Wenn du diese Episoden hilfreich findest und die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 8 von 13. Deine Cloud-Infrastruktur wurde perfekt deployt, aber du hast noch ein großes Problem: Du musst ihre Public IP-Adresse kennen, um dich tatsächlich damit zu verbinden. Das Durchsuchen von Cloud-Provider-Dashboards widerspricht dem Sinn der Automatisierung. Du brauchst einen Weg, genau diese Daten direkt aus Terraform zu extrahieren. Hier kommt das Exposing von Daten mit Output Values ins Spiel. Output Values sind im Grunde die Return Values einer Terraform-Konfiguration. Wenn du eine Resource definierst und erstellst, generiert der Cloud-Provider bestimmte Attribute dynamisch. Das sind Dinge, die du vor dem Deployment nicht wissen kannst, wie eine zugewiesene IP-Adresse, ein generiertes Datenbank-Passwort oder ein bestimmter Domain-Name. Du nutzt Output-Blöcke, um diese dynamisch generierten Attribute einzufangen und sie nach außen zu exposen. Um einen zu definieren, schreibst du einen Output-Block, gefolgt von einem Label. Dieses Label ist einfach der Name, den du dem Output geben willst. Innerhalb des Blocks definierst du ein einziges erforderliches Argument namens value. Dieses Argument zeigt auf die spezifischen Daten, die du extrahieren möchtest. Wenn du zum Beispiel eine Virtual Machine erstellst, könntest du das value-Argument so setzen, dass es direkt auf das Public-IP-Attribut genau dieser Machine-Resource zeigt. Nehmen wir ein konkretes Szenario. Du hast eine automatisierte Pipeline, die einen neuen Azure Kubernetes Service Cluster deployt. Wenn das Deployment fertig ist, brauchen deine Entwickler den automatisch generierten, rohen Kubernetes-Endpoint, um ihre lokalen Connection-Tools zu konfigurieren. Ohne einen Output müsste sich jemand ins Cloud-Portal einloggen, den Cluster suchen und die URL manuell kopieren. Stattdessen schreibst du einen Output-Block namens cluster endpoint. Du setzt seinen value so, dass er auf das Fully Qualified Domain Name Attribut des neu gebauten Kubernetes-Clusters referenziert. Wenn Terraform das Apply deiner Konfiguration abschließt, sammelt es alle definierten Output Values und gibt sie direkt im Command Line Interface aus. Deine Automatisierungs-Pipeline kann diesen Text dann lesen und den Endpoint direkt an die Entwickler weitergeben. Du kannst diese Werte auch später abrufen, ohne ein neues Deployment auszuführen. Du führst einfach den Terraform output Command in deinem Terminal aus. Für Automatisierungs-Skripte kannst du diesem Command sogar sagen, dass er die Daten als Raw Text oder im JSON-Format zurückgeben soll, was das Parsen für andere Software-Tools einfach macht. Manchmal sind die Daten, die du als Output brauchst, vertraulich, wie ein Datenbank-Passwort oder ein Private Key. Du willst nicht, dass diese Strings über einen geteilten Terminal-Screen scrollen oder dauerhaft in deinen Continuous Integration Build Logs liegen. Um das zu verhindern, fügst du das sensitive-Argument innerhalb des Output-Blocks hinzu und setzt es auf true. Terraform versteckt dann den tatsächlichen value in der Konsolenanzeige und ersetzt ihn durch ein Placeholder-Tag, das anzeigt, dass der value sensitive ist. Hier ist die wichtigste Erkenntnis. Einen Output auf sensitive zu setzen, unterdrückt ihn nur in der Terminal-Anzeige. Es verschlüsselt oder versteckt die Daten nicht innerhalb der Terraform State File. Das Passwort oder der Key wird weiterhin im Plain Text in deinen State-Daten auf der Disk oder in deinem Remote Backend gespeichert. Das sensitive-Flag ist rein ein Display-Filter für das Command Line Interface, kein Sicherheitsmechanismus für deinen Storage. Output Values fungieren letztendlich als deine Konfigurations-API. Sie sind der strukturierte, vorhersehbare Weg, wie du kritische Informationen an Menschen oder Automatisierungs-Tools zurückgibst, in dem Moment, in dem ein Run abschließt. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 9 von 13. Nicht jede Infrastrukturkomponente in deiner Cloud-Umgebung wurde von dem Terraform-Code erstellt, den du gerade schreibst. Trotzdem braucht dein Code einen Weg, sich sicher mit diesen bestehenden Systemen zu verbinden, ohne sie versehentlich zu verändern. Abfragen mit Data Sources sind genau die Lösung dafür. Was beim Lernen von Terraform oft für Verwirrung sorgt, ist der Unterschied zwischen einem Resource Block und einem Data Block. Lass uns das gleich mal klären. Ein Resource Block sagt Terraform, dass es ein Infrastrukturobjekt erstellen, updaten und verwalten soll. Ein Data Block führt nur einen Read-Only-Lookup durch. Er bittet die Provider-API, ein existierendes Objekt zu finden und dessen Details zurückzugeben, damit deine Konfiguration diese Details lesen kann. Diese Read-Only-Fähigkeit ist das Fundament einer entkoppelten Infrastrukturarchitektur. Stell dir ein typisches Enterprise-Setup vor. Ein zentrales Netzwerkteam baut und managt das Virtual Network des Unternehmens. Als Application Developer musst du eine Azure Virtual Machine deployen und sie an genau dieses Netzwerk anhängen. Der Netzwerk-Code gehört dir nicht. Du solltest die eindeutige ID des Netzwerks auch nicht in deinen Terraform-Files hardcoden, denn hardcodierte IDs gehen schnell kaputt, wenn Environments jemals neu erstellt werden. Stattdessen fragst du das Netzwerk einfach ab. Das machst du, indem du einen Data Block definierst. Die Syntax sieht einem Resource Block sehr ähnlich. Du beginnst mit dem Keyword data. Als Nächstes gibst du den Data Source Type an, zum Beispiel azurerm virtual network. Dann gibst du ihm einen lokalen Namen, wie corporate, mit dem du ihn später in deinem Code referenzierst. Innerhalb des Blocks definierst du die Suchargumente. Diese wirken als strenge Filter. Du übergibst vielleicht den menschenlesbaren Namen des Virtual Networks und die Resource Group, zu der es gehört. Terraform nutzt diese Argumente, um eine Query zu bauen. Wenn du einen Terraform plan ausführst, fragt Terraform die Azure API an und sucht nach einem Virtual Network, das zu deinen Filtern passt. Wenn die API genau einen Treffer zurückgibt, lädt Terraform die Properties dieses Netzwerks in den Arbeitsspeicher. Wenn die Query null Treffer zurückgibt, oder wenn die Filter zu locker sind und mehrere Treffer liefern, stoppt Terraform sofort und wirft einen Error. Diese Strenge ist absolute Absicht. Sie verhindert, dass du deine Application versehentlich in das falsche Subnet oder Environment deployst. Sobald die Data Source die Informationen erfolgreich abgerufen hat, kannst du jedes exportierte Attribut daraus extrahieren. Die Syntax, um eine Data Source zu referenzieren, ist stark strukturiert. Du beginnst mit dem Wort data, gefolgt von einem Punkt, dem Data Source Type, einem Punkt, deinem lokalen Namen und schließlich dem spezifischen Attribut, das du brauchst. In unserem Szenario würdest du tippen: data Punkt azurerm virtual network Punkt corporate Punkt id. Diesen spezifischen String übergibst du direkt in den Resource Block deiner Virtual Machine und umgehst so komplett die Notwendigkeit, einen statischen Wert zu hardcoden. Hier ist der entscheidende Punkt. Data Sources erlauben es dir, deine umgebende Infrastruktur als dynamischen Service zu behandeln. Du musst das Environment nicht bauen, um damit zu interagieren, und du kannst unabhängige Workspaces sicher miteinander verknüpfen, indem du einfach zur Runtime die genauen Identifier abfragst, die du brauchst. Danke fürs Dabeisein. Ich hoffe, du hast etwas Neues mitgenommen.

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 10 von 13. Wenn du fünfzig identische Webserver deployen musst, willst du bestimmt nicht denselben Codeblock fünfzig Mal kopieren und einfügen. Vielleicht suchst du nach einer klassischen While-Loop oder For-Loop, aber Terraform funktioniert so nicht. Stattdessen managst du die Skalierung auf Blockebene mit count und for each. Standardmäßig konfiguriert ein Resource-Block genau ein Infrastruktur-Objekt. Um mehrere Objekte zu provisionieren, fügst du das Meta-Argument count innerhalb dieses Blocks hinzu. Es akzeptiert eine ganze Zahl. Wenn du count auf drei setzt, provisioniert Terraform drei Objekte aus diesem einen Konfigurationsblock. In der Praxis können diese Objekte normalerweise nicht exakt identisch sein. Sie brauchen eindeutige Namen oder IP-Adressen. Um das zu handhaben, bietet Terraform das Objekt count dot index. Das ist eine spezielle Variable, die nur innerhalb von Blöcken verfügbar ist, die ein count-Argument haben. Angenommen, du deployst drei Azure Virtual Machines. Du schreibst einen Resource-Block für die Virtual Machine und setzt count auf drei. Innerhalb des Blocks weist du den Maschinennamen zu, indem du das Wort web, einen Bindestrich und den Wert von count dot index kombinierst. Weil der Index bei null beginnt, evaluiert Terraform diesen Block und gibt drei separate Maschinen mit den Namen web-zero, web-one und web-two aus. Das Hinzufügen von count ändert, wie Terraform die Resource intern trackt. Eine einzelne Resource wird einfach über ihren Typ und den vergebenen Namen adressiert. Sobald du count hinzufügst, wird diese Adresse zu einem Array. Du referenzierst jetzt spezifische Instanzen woanders in deinem Code über ihre Indexnummern in eckigen Klammern. Count ist hocheffizient, hat aber ein spezifisches mechanisches Risiko, das mit der Listenreihenfolge zusammenhängt. Hier ist die wichtigste Erkenntnis: Count identifiziert Resources ausschließlich anhand ihrer Integer-Position. Wenn du eine Liste von Werten verwendest, um einen Block mit count zu konfigurieren, ist die Indexposition das Einzige, was Terraform interessiert. Wenn du drei Items hast und den count auf zwei änderst, destroyt Terraform das letzte Item im Array, also Index zwei. Wenn du einen neuen String in die Mitte deiner Source-Liste einfügst, verschieben sich alle nachfolgenden Indexpositionen nach unten. Terraform wird bemerken, dass sich die Konfiguration für Index eins geändert hat, Index zwei sich geändert hat, und so weiter. Es wird wahrscheinlich völlig intakte Infrastruktur destroyen und neu erstellen, nur weil sich die Reihenfolge der Source-Liste verschoben hat. Um diese Schwachstelle zu beheben, verwendest du stattdessen das Meta-Argument for each. Während count eine ganze Zahl nimmt, akzeptiert for each eine Map oder ein Set von Strings. Anstatt ein Array von Objekten zu erstellen, die durch fortlaufende Nummern indiziert sind, erzeugt for each eine Map von Objekten, die durch explizite String-Keys getrackt werden. Wenn du ihm ein Set übergibst, das die Strings frontend und backend enthält, erstellt Terraform Resources, die genau unter diesen Namen adressiert werden. Wenn du später einen neuen String hinzufügst oder einen entfernst, fügt Terraform nur diese spezifische Resource hinzu oder destroyt sie. Der Rest bleibt unberührt, weil ihre Identifier feste String-Keys sind und keine fragilen numerischen Positionen. Verwende count, wenn die Infrastruktur-Objekte wirklich austauschbar sind, aber wechsle zu for each, sobald diese Objekte eindeutige Identitäten brauchen, die Änderungen an deiner Konfigurationsliste überleben müssen. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 11 von 13. Deine einzelne Terraform-Konfigurationsdatei war für einen einfachen Webserver völlig in Ordnung, aber wenn deine Infrastruktur wächst, wird sie schnell zu einem unübersichtlichen, schwer lesbaren Monolithen. Du kopierst dieselben Resource Blocks immer wieder und fügst sie ein, nur um einen einzigen Name String oder ein Environment Tag zu ändern. Es ist an der Zeit, dich nicht mehr zu wiederholen und stattdessen wiederverwendbare Komponenten mit Modulen zu bauen. Ein Modul ist ein Container für mehrere Resources, die zusammen verwendet werden. Wenn du dich mit Programmiersprachen auskennst, kannst du dir ein Modul wie eine Funktion vorstellen. Du schreibst die komplexe Logik einmal, kapselst sie und rufst sie dann von woanders mehrmals auf. In Terraform hat jede Konfiguration bereits mindestens ein Modul. Die Dateien in deinem Hauptarbeitsverzeichnis bilden das sogenannte Root Module. Wenn dein Root Module auf ein anderes Set von Konfigurationsdateien verweist, wird dieses zweite Set als Child Module bezeichnet. Stell dir ein konkretes Szenario vor. Ein zentrales DevOps-Team möchte sicherstellen, dass jeder Storage Account, der im Unternehmen erstellt wird, standardmäßig sicher ist – mit strikt erzwungener Verschlüsselung, Private Endpoints und Diagnostic Logging. Anstatt darauf zu vertrauen, dass jeder App-Entwickler zehn verschiedene, komplexe Resources richtig konfiguriert, erstellt das DevOps-Team ein standardisiertes Secure Azure Storage Module. Wenn ein App-Team Storage braucht, schreibt es keinen riesigen Block von Resource-Definitionen. Es schreibt einfach einen Module Block in seine Root Configuration. Innerhalb dieses Module Blocks definieren sie als allererstes ein Source Argument. Die Source sagt Terraform genau, wo die Dateien des Child Modules zu finden sind – egal, ob das ein lokaler Verzeichnispfad oder ein Remote Repository ist. Unter der Source übergibt das App-Team dann Arguments. Genau wie bei der Übergabe von Arguments an eine Funktion, liefern sie die spezifischen Daten, die das Child Module zum Ausführen braucht, wie zum Beispiel einen eindeutigen App-Namen oder einen Environment Identifier. Diese Arguments mappen direkt auf die Input Variables, die im Child Module definiert sind. Das Child Module nimmt diese Inputs, führt die zugrunde liegenden Resource Configurations aus und baut die Infrastruktur. Das App-Team bekommt automatisch einen konformen Storage, komplett isoliert von der zugrunde liegenden Komplexität. Hier ist der entscheidende Punkt. Die Leute sind oft verwirrt darüber, wie Terraform den Scope zwischen diesen Modulen handhabt. Wenn du ein Child Module aufrufst, sind die Resources darin streng gekapselt. Dein Root Module kann eine IP-Adresse, einen Connection String oder eine Storage ID, die innerhalb dieses Child Modules generiert wurde, nicht direkt lesen. Das Child Module ist eine Blackbox. Wenn dein Root Module Daten braucht, die innerhalb des Child Modules generiert wurden, muss das Child Module diese explizit über einen Output Block exportieren. Variables fungieren als Input-Parameter und Outputs als Return Values. Sie bilden ein striktes Interface. Sobald das Child Module diese Daten als Output exportiert, kann das Root Module sie endlich lesen. Du greifst auf diese Daten zu, indem du das Wort module referenzierst, gefolgt von dem spezifischen Namen, den du deinem Module Block gegeben hast, und dann dem Namen des Outputs. Wenn das Child Module eine generierte Storage Account ID als Output liefert, kann dein Root Module sie mit dieser Syntax abgreifen und an eine Datenbank oder eine Virtual Machine weitergeben, die sich damit verbinden muss. Die wahre Stärke von Modulen ist nicht nur das Einsparen von Codezeilen. Es ist die Fähigkeit, einen Architekturstandard einmalig zu definieren, die Komplexität wegzusperren und dem Rest deiner Organisation ein sauberes, berechenbares Interface zu präsentieren. Danke fürs Zuhören. Macht's gut, Leute.

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 12 von 13. Ein lokales State File auf deiner Festplatte funktioniert perfekt, wenn du alleine baust. Aber in dem Moment, in dem zwei Engineers versuchen, dieselbe Infrastruktur in genau derselben Sekunde zu updaten, ist eine kaputte Umgebung vorprogrammiert. Das ist die Schwelle zwischen individuellem Experimentieren und Team-Zusammenarbeit, und das bringt uns zur Enterprise Readiness: Remote State und Locking. Standardmäßig schreibt Terraform seine aktuelle Sicht auf deine Infrastruktur in ein lokales File namens terraform dot tfstate. Dieses File ist die kritische Source of Truth, die deinen Configuration Code auf reale Ressourcen mappt. Das Problem entsteht, wenn du mehr Leute zu deinem Projekt hinzufügst. Wenn dein Kollege eine Änderung von seiner Maschine aus macht, hat dein Laptop keine Ahnung, dass sich das Environment gerade verändert hat. Du arbeitest mit veralteten Informationen. Manchmal versuchen Teams das zu lösen, indem sie das State File in ihr Version Control System committen. Das ist ein extremes Sicherheitsrisiko. State Files speichern routinemäßig sensible Daten wie Datenbank-Passwörter oder Private Keys im Plaintext. Der richtige Ansatz ist die Konfiguration eines Remote Backends. Anstatt das State File auf einer lokalen Maschine zu speichern, liest und schreibt Terraform diese Daten aus einem sicheren, zentralisierten Data Store. Das ist typischerweise ein Object Storage Service wie ein Amazon S3 Bucket, ein Azure Blob Storage Container oder ein Google Cloud Storage Bucket. Wenn du ein Remote Backend nutzt, fragt Terraform jedes Mal, wenn jemand einen Command ausführt, diesen zentralen Storage ab, um das genaueste und aktuellste Bild der Infrastruktur abzurufen. Um auf dieses Setup umzusteigen, musst du einen Backend Configuration Block zu deinem Code hinzufügen, der definiert, wo der State leben soll. Pass an dieser Stelle gut auf. Ein sehr häufiger Fehler ist es, diese Configuration zu schreiben, das File zu speichern und anzunehmen, dass der State jetzt remote ist. Ist er nicht. Nach dem Hinzufügen des Backend Blocks musst du terraform init erneut ausführen. Das Ausführen dieses Initialization Commands ist der Trigger, der Terraform anweist, dein existierendes lokales State File physisch zu kopieren und in das Cloud Backend zu migrieren. Das Verschieben des State Files an eine Shared Location löst das Visibility-Problem, aber es setzt dich Concurrent Modifications aus. Wenn zwei Deployment Pipelines gleichzeitig ein Update triggern, könnten beide auf einmal versuchen, in das Remote State File zu schreiben und es komplett zu korrumpieren. Genau deshalb unterstützen Remote Backends State Locking. Stell dir ein Environment vor, das Azure Blob Storage für seinen Remote State nutzt. Zwei Engineers arbeiten an unterschiedlichen Updates. Engineer A führt ein Apply aus. Bevor irgendwelche Änderungen an den eigentlichen Cloud-Ressourcen gemacht werden, greift Terraform auf den Azure Storage Container zu und setzt ein Lock auf das Remote State File. Den Bruchteil einer Sekunde später versucht Engineer B, sein eigenes Apply auszuführen. Terraform checkt das Remote Backend, erkennt das aktive Lock und fängt den Run von Engineer B sofort ab. Anstatt zu kollidieren, stoppt Terraform sicher und gibt einen Error zurück, der erklärt, dass ein anderer Prozess gerade das Lock hält. Sobald der erste Run erfolgreich abgeschlossen ist, gibt Terraform das Lock automatisch wieder frei. Die Implementierung eines gelockten Remote Backends ist der entscheidende Schritt für Enterprise Infrastructure as Code. Es sichert deine sensiblen Daten und eliminiert gefährliche Race Conditions. Remote State stellt sicher, dass, egal wer den Code ausführt oder von wo, dein gesamtes Team fest in exakt derselben Realität verankert ist. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. Terraform Fundamentals, Folge 13 von 13. Du hast deine Konfiguration geschrieben, lokal getestet und deine Ressourcen deployed. Aber Infrastrukturänderungen von einem Entwickler-Laptop aus auszuführen, ist ein Flaschenhals, keine Strategie. Manuelle Applies führen zu conflicting States, unreviewed Changes und Sicherheitsrisiken. Echte Automatisierung läuft sicher in einer Pipeline, die automatisch durch die Version Control getriggert wird. Das bringt uns zu Enterprise Workflows und CI/CD. Wenn du vom Einzelkämpfer zum Team wechselst, verlagert sich der zentrale Write-, Plan- und Apply-Workflow komplett von deiner lokalen Maschine. Die Version Control wird zur absoluten Source of Truth. Du führst Commands nicht mehr direkt aus, sondern lässt Continuous Integration Pipelines die State-Änderungen orchestrieren. Hier ist die entscheidende Erkenntnis: Die Pipeline unterteilt die traditionelle Plan-Phase in zwei unterschiedliche Konzepte: Speculative Plans und Concrete Plans. Diesen Unterschied zu verstehen, ist für das Pipeline-Design extrem wichtig. Stell dir einen Entwickler vor, der die Größe einer Azure Virtual Machine erhöhen muss. Er aktualisiert die Instance Size in der Konfiguration, committet den Code und öffnet einen Pull Request. Genau in diesem Moment triggert die Pipeline automatisch einen Speculative Plan. Ein Speculative Plan zeigt einfach nur, was Terraform vorhat zu tun. Er gleicht den vorgeschlagenen Code mit dem Remote State ab, um das Delta zu berechnen, aber er ist strikt Read-Only. Er kann unter keinen Umständen applied werden. Die Pipeline nimmt den Output dieses Speculative Plans und postet ihn direkt als Textkommentar in den Pull Request. Wenn ein Senior Engineer den Code reviewed, sieht er nicht nur die Syntax-Änderung. Er sieht den genauen Impact auf die Infrastruktur. Er weiß genau, welche Azure-Ressourcen modifiziert, erstellt oder destroyed werden, bevor er das Approval erteilt. Sobald der Pull Request approved und in den Main Branch gemerged wurde, triggert die Pipeline die zweite Phase. Sie generiert einen Concrete Plan gegen diesen Main Branch. Das ist ein ausführbares Plan File. Weil der Main Branch die vertrauenswürdige Source of Truth ist, nimmt die Pipeline diesen Concrete Plan und applied ihn sofort. Die Live-Infrastruktur wird automatisch vom Bot aktualisiert, nicht vom Menschen. Terraform in der Automatisierung auszuführen, öffnet die Tür für erweiterte Enterprise Controls. Policy-as-Code, mit Frameworks wie Sentinel, integriert sich direkt in diese Pipeline. Sentinel evaluiert den Plan, bevor der Apply überhaupt stattfindet. Wenn ein Entwickler versehentlich eine Database Instance anfordert, die gegen Kostenbeschränkungen oder Compliance-Regeln verstößt, flaggt die Policy Engine das und stoppt die Pipeline sofort. Dieser automatisierte Workflow ermöglicht ein Self-Service-Infrastrukturmodell. Platform Engineers bauen und testen wiederverwendbare Module, während Application Developers einfach einen Pull Request einreichen, um die benötigten Ressourcen anzufordern. Die Pipeline plant den Change, Policy-as-Code verifiziert die Compliance, und ein Peer reviewed die Absicht. Das Application Team bekommt seine Infrastruktur schnell, und das Platform Team setzt die Sicherheit durch, ohne als manueller Roadblock zu agieren. Damit ist unsere Fundamentals-Serie abgeschlossen. Du weißt jetzt, wie Terraform von einem einzelnen lokalen Command zu einer automatisierten Enterprise Engine skaliert. Am besten festigst du dieses Wissen, indem du selbst etwas baust, die offizielle Dokumentation liest und selbst mit diesen Pipelines experimentierst. Wenn du Ideen für zukünftige Themen hast, besuche devstories dot eu. Ich möchte mir kurz die Zeit nehmen, dir fürs Zuhören zu danken – das hilft uns sehr. Hab einen schönen Tag!