Wie man Terraform im großen Maßstab betreibt

(benchling.engineering)

6 Punkte von GN⁺ 2025-03-12 | Noch keine Kommentare. | Auf WhatsApp teilen

Verwaltung von mehr als 165.000 Cloud-Ressourcen in 625 Terraform-Workspaces und 38 AWS-Konten
- Von 170 Engineers sind 40 auf Infrastruktur spezialisiert
- Täglich werden 225 Infrastruktur-Releases (terraform apply) und 723 Plans (terraform plan) ausgeführt
Dafür wurde Terraform Cloud eingeführt, um den Infrastruktur-Release-Prozess zu automatisieren und manuellen Aufwand sowie Fehler der Entwickler zu reduzieren

Probleme vor der Einführung von Terraform Cloud

Erforderliche hohe AWS-Berechtigungen: Das Infrastrukturteam musste weitreichende AWS-Zugriffsrechte besitzen
Zeitaufwendige Arbeitsschritte: In jedem Verzeichnis mussten terraform apply-Befehle ausgeführt und Reviews sowie Freigaben wiederholt werden; eine einzelne Änderung konnte sich auf mehr als 120 Workspaces auswirken
Infrastructure Drift: Unerwartete Änderungen sammelten sich an, sodass bei der Anwendung zusätzliche Prüfungen und Maßnahmen nötig waren

Drift beseitigt → Infrastructure Drift wurde eliminiert, wodurch Risiken und die Belastung für Entwickler verringert wurden
Zeitersparnis für Entwickler → Einsparung von rund 8.000 Stunden Entwicklerzeit pro Jahr (entspricht der Arbeitslast von 4 Entwicklern)
Änderungen nachvollziehbar → Änderungen lassen sich über Audit-Logs nachverfolgen, was Debugging erleichtert
Unterstützung für speculative plans → Änderungen können automatisch getestet und die Ergebnisse direkt in GitHub CI eingesehen werden

Self-Hosting: Terraform Cloud for Business wird selbst betrieben, und TFC-Agents laufen in einem ECS-Cluster innerhalb der AWS-Konten
Aufbau der Agent-Pools: 120 Agents sind in Entwicklungsumgebung (40) und Produktionsumgebung (80) aufgeteilt, um eine hohe Parallelität aufrechtzuerhalten

Erschöpfung von Agents und Parallelitätsgrenzen → Bei Agent-Knappheit wird der On-Call-Verantwortliche benachrichtigt
Plan-Dauer → Wenn die Plan-Dauer in der Entwicklungsumgebung 4 Minuten überschreitet, wird das Team benachrichtigt
Infrastructure Drift → Wird derzeit nicht gemessen (da Drift kaum noch auftritt)

Entwicklung einer TFC-CLI: Änderungen über mehrere Workspaces hinweg können per CLI automatisch geprüft und freigegeben werden
Aufbau eines Benachrichtigungssystems: Über Slack-Benachrichtigungen wird automatisiert sichergestellt, dass keine Terraform-Anwendung übersehen wird
Automatisches Workspace-Management: Mit Terraform werden 625 Workspaces verwaltet und per Tags den verantwortlichen Teams zugeordnet
Analyse der Terraform-Cloud-Nutzung: Mithilfe der TFC-API werden State-Version-Daten erfasst, um Ressourcennutzung und Wachstumstrends zu verstehen
Backup des Terraform State: State-Dateien werden automatisch in S3-Buckets gesichert, damit im Störungsfall eine Wiederherstellung möglich ist
Verwaltung von Workspace-Abhängigkeiten: Durch einen Modul-Abhängigkeitsbaum werden Verzeichnisse, die ein Workspace überwachen muss, automatisch festgelegt
Automatisierung von Provider-Upgrades: Mit Dependabot werden Provider monatlich aktualisiert, um den Verwaltungsaufwand durch Automatisierung zu reduzieren

Schrittweiser Rollout: Statt Releases auf Basis des main-Branches soll auf mehrstufige Deployments (Entwicklung → Staging → Produktion) umgestellt werden
Aufteilung großer Workspaces: Die derzeit 625 Workspaces sollen auf über 1500 weiter unterteilt werden, um Plan- und Apply-Zeiten zu verkürzen und den Umfang der Auswirkungen von Änderungen zu reduzieren
Verbesserung der Benachrichtigungsfunktionen: Erweiterung der Slack-Benachrichtigungen um Reassignment-Funktionen sowie Einführung einer automatischen Generierung des Befehls tfc review
Automatische Skalierung der Agents: Geplant ist die Einführung eines auf EKS basierenden Auto-Scaling-Systems, um variable Workloads effizient zu verarbeiten
Open-Source-Veröffentlichung selbst entwickelter Tools: Verschiedene intern entwickelte Tools sollen als Open Source veröffentlicht werden, damit auch andere Teams sie nutzen können