Praxishandbuch Terraform - Lessons learned

Als Teil meines Reiseplanes nach China habe ich mich entschieden, einige freie Zeit zu nutzen, um mein Wissen über Infrastructure as Code (IaC) zu vertiefen. Hierzu habe ich das Buch "Terraform up and running" von Yevgeniy Brikman ausgewählt.

Meine Erfahrungen mit RapidStream

Zuvor hatte ich bereits Erfahrungen im Bereich IaC gemacht, insbesondere während der Entwicklung von RapidStream, einem multi-tenanten B2B-SaaS-Dienst in Azure. Hierbei habe ich unsere Umgebungen für das System aufgesetzt und dabei die Methodik "Learning by Doing" angewendet.

Das Buch "Terraform up and running"

Das Buch konzentriert sich im Wesentlichen auf die Automatisierung von Bereitstellungen, um sie effizienter und sicherer zu gestalten. Es beginnt mit den Grundlagen und arbeitet sich durch alle wichtigen Themen bis hin zu einem Produktionsbereitschaften Setup und Testgetriebener Infrastruktur.

Einige meiner Schlüsselerkenntnisse

Während meines Lesens habe ich einige interessante Erkenntnisse gewonnen, die ich gerne mit euch teilen möchte:

• State-Management: Es ist wichtig, sorgfältig darüber nachzudenken, wo und wie das Terraform-State verwaltet wird. Wenn es Remote gespeichert wird, muss sicherstellen werden, dass es verschlüsselt (da geheime Daten in klarem Text gespeichert werden) und versioniert (damit man zurückrollen kann). Es ist jedoch zu beachten, dass das State-File nie in den Repository geschoben werden sollte (weil von geheimen Daten).
• Umgebungen: Es ist ratsam, die Umgebungen nicht über Terraform Workspaces sondern über Dateien zu trennen. Wenn alle Umgebungen in einer Datei zusammengefasst sind, gefährdet man das Produktions-System bei Änderungen an der Staging-Umgebung. Ebenso sollten mehrere Regionen separat verwaltet werden (anstatt Provider Alias zu verwenden). Sollte es bei einer Umgebung oder Region ein Problem geben, möchte man die anderen schnell ändern können. Wenn Terraform Fehler meldet, weil es eine Anwendung aufgrund eines beschädigten Systems nicht anwenden kann, ist nichts gewonnen und man steckt in Schwierigkeiten.
• Refactoring: Alle Code (auch IaC) benötigt Refactoring, um sauber und verständlich zu bleiben. Die Änderungen sollten mit dem plan-Befehl überprüft werden. Man sollte prüfen, ob es notwendig ist, vor der Löschung eine neue Ressource erstellen (z.B. einen neuen Load Balancer erstellen, bevor man den alten löscht). Änderungen sollten mit dem move-Befehl durchgeführt werden, um das System weniger aufheblich zu machen. Beachte jedoch, dass einige Ressourcen unveränderlich sind und daher abgebaut (statt geändert) werden müssen.
• Secret-Management: Es gibt mehrere Optionen hierzu, aber eine Secret Store erscheint gut geeignet als erste Annäherung.

Mein Eindruck

Das Buch hat gute Beispiele für die Punkte aus dem Text. Im Verlauf des Buches wird ein klare Linie gezogen und dabei erläutert, warum es wichtig ist, den nächsten Punkt anzugehen. Besonders im Teil der Produktionsbereitschaft hat mich der Abschnitt über Schätzungen beeindruckt, insbesondere die Erwähnung von "Yak Shaving" nach Seth Godin.

Zusammenfassung

Das Buch gibt eine gute Einführung in den Bereich Infrastructure as Code und ist empfehlenswert für alle, die hiermit anfangen möchten. Der Teil über Schätzungen und die Hinweise auf das Yak-Shaving Problem sind besonders interessant.

Wenn du Hilfe bei der Einrichtung von Infrastructure as Code benötigst oder möchtest, stehe ich gerne zur Verfügung - auch im Namen meiner Firma konzentrik.