"Versionierung? Ach, ich nehme einfach immer die neueste Version - was soll schon schiefgehen?"
Genau diese Einstellung ist einer der Gründe, warum manche Engineers um 3 Uhr nachts aus dem Bett geklingelt werden. Und warum am nächsten Morgen im Daily Stand-up betreten auf die Schuhe gestarrt wird.
Lassen Sie uns im letzten Teil unserer Serie "Terraform @ Scale" kurz darüber reden, bevor es auch Ihnen passiert.
Weiterlesen: Terraform @ Scale - Teil 7: Best Practices bei der Modulversionierung
"Zur Hölle mit der Sichtbarkeit - Hauptsache es läuft!"
Das ist die Einstellung, mit der sich die meisten Platform-Engineering-Teams ins Verderben stürzen. Wie beim Kochen mit verbundenen Augen in einer fremden Küche: Es geht eine Zeit lang gut, aber wenn's anbrennt, dann richtig.
Und nichts ist schlimmer als der Blick in ratlose Gesichter, wenn die Hütte brennt.
In den beiden vorhergegangenen Teilen waren Abhängigkeits-Schmerzen unser Hauptthema. Schauen wir uns heute an, welche Möglichkeiten wir haben, ein in den Brunnen gefallenes Kind noch lebend herauszufischen.
Weiterlesen: Terraform @ Scale - Teil 6c: Modulabhängigkeiten für Fortgeschrittene (und Masochisten)
Im letzten Artikel haben wir die versteckte Komplexität verschachtelter Module und den Ripple-Effect betrachtet, und dabei ist uns zunehmend bewusst geworden, welche unangenehmen Konsequenzen sich daraus im operativen Betrieb und Lifecycle-Management ergeben können. Man kann solchen Problemen das Einfallstor sperrangelweit öffnen, indem man Anfängerfehler begeht – vor allem den Fehler, mehrere oder gar alle Terraform-Module in ein gemeinsames Git-Repository zu stopfen. Ebenso kann man mit ein wenig Seniorität und sauberer Planung derartige Probleme aber von vornherein minimieren.
Lassen Sie uns in diesem Teil einen Blick darauf werfen, wie man in der Praxis mit solchen Abhängigkeiten umgehen kann, ohne dass die Schmerzen überhandnehmen.
Weiterlesen: Terraform @ Scale - Teil 6b: Praktischer Umgang mit verschachtelten Modulen
Wenn ein einziges Modul-Update 47 Teams lahmlegt...
Es ist Montagmorgen, 10:30 Uhr. Das Platform-Engineering-Team eines großen Anbieters für Managed Cloud Services hat gerade ein "harmloses" Update des Basismoduls für VM-Instanzen von v1.3.2 auf v1.4.0 veröffentlicht. Die Änderung? Ein neues, aber obligatorisches Freeform-Tag zur Kostenstellenzuordnung von Ressourcen.
Was niemand auf dem Radar hat: Den Senior Engineer, der einst als Entscheidungsträger vehement darauf bestand, sämtliche Terraform-Module in einem einzigen Git-Repository abzulegen. “Versionierung ist zuviel Micromanagement. So ist es aufgeräumter. Und macht weniger Arbeit”, hat er damals gesagt.
Der gleiche Montag, 15:00 Uhr nachmittags: 47 Teams von unterschiedlichen Kunden melden bisher, dass ihre CI/CD-Pipelines fehlschlagen. Der Grund? Ihre Root-Module referenzieren die vom Anbieter bereitgestellten, aktualisierten Module, aber niemand hat die neuen Parameter in den eigenen Root-Modulen implementiert. Die Compliance-Prüfung des Anbieters ist aktiv und lehnt die Terraform-Runs wegen fehlender obligatorischer Tags ab. Was als Verbesserung geplant war, hat sich in einen organisationsweiten Stillstand mit massiver Außenwirkung auf Hostingkunden verwandelt.
Willkommen in der Welt der Modulabhängigkeiten bei Terraform @ Scale.
Weiterlesen: Terraform @ Scale - Teil 6a: Verstehen und Verwalten von verschachtelten Modulen
Im vorherigen Artikel 5a haben wir gesehen, wie schnell große Terraform‑Rollouts an API‑Limits prallen, etwa wenn DR‑Tests hunderte Ressourcen parallel erstellen und 429‑Fehler lawinenartig Retries auslösen. Diese Fortsetzung schließt jetzt dort an und zeigt, wie Sie mit dem API Gateway von Oracle Cloud Infrastructure und Amazon API Gateway Limits bewusst managen, sauber observieren und per „Policy as Code“ betriebsfest machen.