Ich habe letzten Monat die Terraform-Konfiguration eines Kunden zum ersten Mal geöffnet. Eine einzelne main.tf-Datei mit 1.847 Zeilen. Darin waren ein VPC, drei EC2-Instanzen, eine RDS-Datenbank, zwei S3-Buckets, eine CloudFront-Distribution, eine Route-53-Zone mit 14 Records, eine IAM-Rolle mit Inline-Policy und ein Elastic-Load-Balancer.
Alles in einer Datei. Kein Remote-State. Keine Module. Fest kodierte AMI-IDs, Instanz-Typen und IP-Bereiche in den Ressourcenblöcken. Das State-File lag im Home-Verzeichnis des CTO auf seinem Laptop. Er war die einzige Person, die Terraform ausführen konnte, und er tat es, indem er terraform apply ohne Plan laufen ließ.
Das ist kein Ausreißer. Acht von zehn Startups, die ich auditiere, haben drei oder mehr dieser Muster. Jemand hat die Infrastruktur einmal eingerichtet, als das Unternehmen drei Leute hatte. Niemand hat sie überarbeitet.
1. Monolithischer State
Die 1.847-Zeilen-Datei meines Kunden hat ein einziges State-File produziert, das jede Ressource in ihrer gesamten Infrastruktur verfolgt. Wenn sie die DNS-Records aktualisieren wollten, betrachtete Terraform jede einzelne Ressource, auch die Datenbank, auch den Load Balancer, auch die EC2-Instanzen.
Die Planausführung dauerte 4 Minuten. Jede Änderung, egal wie klein, erzeugte einen Plan, der die gesamte Infrastruktur abdeckte. Die Blast-Radius einer falschen terraform apply war alles. Ein Tippfehler in einer Sicherheitsgruppe konnte die Datenbank betreffen, weil alles im selben State lag.
Aufteilen nach Schicht. Netzwerk in einem State. Compute in einem zweiten. Datenbank in einem dritten. DNS in einem vierten. Jeder State hat seinen eigenen Blast-Radius.
2. Lokaler State
Das State-File enthält sensible Daten. Datenbank-Passwörter, API-Keys, Verbindungsstrings. Alles im Klartext. Wenn das State-File auf dem Laptop eines Entwicklers liegt, sind diese Secrets genau so sicher wie dieser Laptop. Wenn der Laptop gestohlen wird, verloren geht oder einfach von jemand anderem genutzt wird, sind deine Infrastruktur-Secrets kompromittiert.
Remote State mit einem S3-Backend und DynamoDB-Locking behebt das. Das State-File liegt in einem verschlüsselten Bucket. DynamoDB verhindert gleichzeitige Änderungen. Mehrere Entwickler können Terraform ausführen, ohne sich gegenseitig die Änderungen zu überschreiben.
Die Einrichtung dauert 30 Minuten. Die Migration vom lokalen zum Remote State ist ein einzelner terraform init -migrate-state-Befehl. Bester ROI aller Fixes in diesem Artikel.
3. Keine Module
Wenn du drei EC2-Instanzen hast und jede 45 Zeilen kopierter Konfiguration hat, hast du drei Stellen, an denen du Änderungen vornehmen musst, wenn sich der Instanztyp ändert. Wenn du die zweite aktualisierst, aber die dritte vergisst, weichen deine Instanzen voneinander ab, ohne dass jemand es merkt.
Module lösen das. Ein Modul definiert ein Muster (eine EC2-Instanz mit Sicherheitsgruppe, EBS-Volume und Tags), du rufst es dreimal mit unterschiedlichen Parametern auf, und wenn sich der Instanztyp ändert, änderst du ihn einmal im Modul. Eine Stelle statt drei. Kein Drift zwischen den Instanzen, kein Vergessen der dritten Kopie um 17:30 am Freitag.
Die Versuchung ist, sofort ein riesiges Modulverzeichnis zu bauen. Mach das nicht. Fang mit dem Pattern an, das du am häufigsten kopierst. Für die meisten Startups ist das eine "Webservice"-Modulgruppe: EC2 oder ECS-Taskdefinition, Security Group, Target Group, ALB-Listener-Rule. Refaktoriere ein existierendes Beispiel in ein Modul und ersetze die Kopien.
4. Fest kodierte Werte
AMI-IDs, Instanztypen, CIDR-Blöcke, Kontonummern, direkt in den Ressourcenblöcken. Das funktioniert, bis du eine zweite Umgebung brauchst. Dann kopierst du alles, änderst die fest kodierten Werte, verpasst zwei, und deine Staging-Umgebung hat denselben CIDR-Block wie Produktion.
Variablen mit umgebungsspezifischen .tfvars-Dateien lösen das. variables.tf definiert, was konfigurierbar ist. prod.tfvars und staging.tfvars liefern die umgebungsspezifischen Werte. Der Terraform-Code selbst ist identisch für beide Umgebungen.
Unveränderliche Werte (AWS-Region, Standard-Tags) in locals. Umgebungsspezifische Werte (Instanzgröße, Replikaanzahl, Domain) als Variablen.
5. Keine Drift-Erkennung
Du hast alles in Terraform definiert. Aber am Mittwoch hat jemand die Sicherheitsgruppe manuell in der AWS-Konsole geändert, weil ein Debugging-Issue Zugriff auf einen bestimmten Port brauchte. Sie haben vergessen, es nach dem Debugging zurückzusetzen. Jetzt stimmt dein Terraform-State nicht mehr mit der Realität überein.
Führe terraform plan in einem wöchentlichen CI-Cronjob aus. Wenn der Plan Änderungen zeigt, die niemand erwartet, hat jemand etwas manuell geändert. Untersuche und bringe den Code mit der Realität in Einklang (entweder die manuelle Änderung in Terraform übernehmen oder die manuelle Änderung rückgängig machen).
Fünf Minuten pro Woche. Verhindert das Szenario, in dem ein terraform apply drei manuelle Änderungen rückgängig macht, die niemand dokumentiert hat, und einen Ausfall in der Produktion verursacht, der den gesamten Freitagnachmittag ruiniert.
Der gemeinsame Nenner
Alle fünf sind Probleme des Infrastrukturmanagements, keine Terraform-Probleme. Terraform ist nicht opinionated genug, um sie zu verhindern, also passieren sie standardmäßig bei jedem Unternehmen, das schneller wächst als seine Infrastruktur-Praktiken reifen.
Alle fünf in einer bestehenden Codebase zu fixen dauert ein bis zwei Wochen fokussierte Arbeit. Sie in einem neuen Projekt zu verhindern dauert ungefähr zwei Stunden initialen Setup. Der Unterschied in den laufenden Wartungskosten ist enorm.
Basierend auf Infrastruktur-Audits bei verschiedenen Startups und Engineering-Teams.
Hast du eine technische Herausforderung?
Ich helfe Startups und Teams bei Webanwendungen, KI-Integrationen und Entwicklungs-Workflows. Lass uns über dein Projekt sprechen.