Mit Terraform im Team arbeiten

Foto des Autors
Can Büyükburc

Terraform hält sowohl Vorteile als auch Herausforderungen für die Teamarbeit bereit. In diesem Artikel schauen wir uns die Probleme und Lösungen genauer an.

Einleitung

Da sich der Einsatz von Cloud-Computing in der Tech-Branche etabliert hat, ist Infrastructure-as-Code (IaC) zu einem unverzichtbaren Werkzeug bei der Automatisierung der Verwaltung von Cloud-Infrastrukturen geworden. Im Gegensatz zu anderen Werkzeugen, wie Pulumi, ist Terraform das am weitesten verbreitete Werkzeug. Es ist eines der beliebtesten Infrastructure-as-Code-Tools bei Entwickler:innen und Ingenieur:innen. 

Terraform hält sowohl Vorteile als auch Herausforderungen für die Teamarbeit bereit. In diesem Artikel schauen wir uns sowohl die Probleme als auch die Lösungen an.

Was ist Terraform?

Terraform ist ein Open-Source-IaC-Tool, das von HashiCorp entwickelt wurde. Es ermöglicht, Infrastrukturen in jeder Cloud sicher und vorhersehbar bereitzustellen und zu verwalten. Terraform codiert Cloud-APIs in deklarative Konfigurationsdateien mit einer Hochsprache namens HashiCorp Configuration Language (HCL). 

Der Vorteil von Terraform ist, dass es ClickOps verhindert und dadurch eigentlich manuell ausgeführte Tätigkeiten automatisiert und reproduzierbar macht.

Obwohl oft behauptet wird, dass Terraform Cloud-unabhängig ist, bedeutet dies in Wirklichkeit lediglich, dass Terraform mit mehreren Cloud-Anbietern zusammenarbeiten kann. Es ist jedoch wichtig zu beachten, dass spezifische Konfigurationsdateien für jeden einzelnen Cloud-Anbieter geschrieben werden müssen [1].

Terraform: Herausforderungen für die Arbeit im Team

Arbeitet ein mehrköpfiges Team gemeinsam mit Terraform, kann es zu Herausforderungen kommen. Diese fangen bei der gemeinsamen Nutzung und Sicherung des Statefiles an und führen bis zur Standardisierung der Dokumentation, der Sicherheit und weiteren Themen, die wir im Folgenden besprechen werden. 

Der Terraform-Workflow wird oft als “init-plan-apply” bezeichnet. Das gilt allerdings nur für einzelne Nutzer:innen. Terraform erstellt eine Zustandsdatei namens „terraform.tfstate“. Diese Zustandsdatei enthält alle Details der Ressourcen unseres Terraform-Codes. Wenn man etwas im Code ändert und esauf Cloud-Ebene umsetzt, wird Terraform in die Zustandsdatei schauen und die Änderungen im Code mit der Zustandsdatei vergleichen. Die Änderungen an der Infrastruktur nimmt Terraform auf Grundlage der Zustandsdatei vor [2]. HashiCorp beabsichtigt nicht, die Datei „terraform.tfstate“ zu entfernen: Sie erfüllt viele wichtige Funktionen und bietet wesentliche Fähigkeiten für die Terraform-Sprache. 

1. Herausforderungen durch Backend-Sicherungen

Sobald wir die Quellen erstellt haben, werden sie für eine lange Zeit bestehen bleiben. Sie werden sich jedoch im Laufe der Zeit auf die eine oder andere Weise verändern. Versionen werden etwa von Container-Images oder Datenbanken aktualisiert. Wir werden unsere Repositorys konstant mit den neuen Änderungen aktualisieren, aber dies wird im Laufe der Zeit zu Abweichungen vom Statefile führen. 

Da der Statefile den letzten gewünschten Status der Infrastruktur (einschließlich der Passwörter im Klartext) enthält, ist es sehr wichtig, sie sicher aufzubewahren und zu kontrollieren, wer auf sie zugreifen und sie verändern kann. Änderungen an der Infrastruktur können manuell, aber auch über ein CI/CD vorgenommen werden. 

2. Wachsende Teams und Erweiterung der Umgebung als Hürde

Mit der zunehmenden Erweiterung des Entwickler:innenteams wird die Aufgabe, diese Datei zu pflegen, immer komplexer. Das liegt daran, dass die Datei sensible Informationen enthält, die schwer zugänglich sein sollten. Zudem muss sie stets mit der bestehenden Infrastruktur übereinstimmen. 

Mit der Erweiterung der Infrastruktur wird die Konfigurationsdatei umfangreicher, was zu Schwierigkeiten bei der Durchführung von Änderungen führt. Außerdem kann ein Fehler in der Datei schwerwiegende Folgen haben. Angesichts der Tatsache, dass nun mehrere Personen an der Verwaltung der Infrastruktur beteiligt sind, ist es von größter Bedeutung, sicherzustellen, dass vorhandene Ressourcen verfügbar bleiben. 

3. Herausforderungen durch Branching-Strategy

Um die Entwicklung der Infrastruktur zu erleichtern, nutzen wir Versionskontrollsysteme und Branching-Methodologien. Dies bringt allerdings Herausforderungen mit sich. Ein Beispiel: 

Implementiert ein Branch eine bestimmte Funktion, während es ein anderer Branch nicht tut, kann es zu Problemen kommen: Beim Zusammenführen beider Branches kann die zuvor von dem ersten Branch erstellte Ressource entfernt werden

Wie hier zu sehen ist, haben Branch 1 und Branch 2 bei der Erstellung dieselbe Statusdatei mit einem einzigen S3-Bucket. Ein Team fügt in Branch 1 weitere 2 Buckets hinzu und führt sie zusammen. Das andere Team fügt einen weiteren hinzu und möchte ihn zusammenführen, aber da der dritte Bucket in diesem Statefile nicht vorhanden ist, sieht Terraform ihn als unerwünschte Ressource und entfernt ihn.

Wie können wir diese Herausforderungen bewältigen?

Meiner Meinung nach liegen die Lösungen in zwei verschiedenen Punkten: den Menschen und den Werkzeugen. Im Folgenden gehe ich genauer darauf ein.

1. Standardisierung

Da wir in Teams arbeiten, ist es entscheidend, explizite Standards festzulegen und zu erläutern. Neulinge im Team sollten umfassend in diese Standards eingewiesen werden. Diese können von der Modulorganisation bis hin zur Implementierung einer Merge-Apply-Strategie reichen. 

Terraform erleichtert bereits die Verwendung von Modulen für zahlreiche Ressourcen. Wir können etwa ein standardisiertes Modul erstellen, das mehrere Ressourcen enthält, um unseren Software-Code zu extrahieren, eine Pipeline zu initiieren und Artefakte sicher zu archivieren. Durch die Verwendung dieses standardisierten Moduls müssen wir, wenn unser Unternehmen ein neues Softwareprojekt initiiert, lediglich mehrere Variablen ändern und dieselbe Lösung implementieren. Auf diese Weise stellen wir sicher, dass die festgelegten Standards in der gesamten Infrastruktur eingehalten werden. 

2. Verwendung von Tools

Um einen sauberen, sicherheitsgeprüften und standardisierten Code bereitzustellen, können wir Tools wie „pre-commit“ und dessen Hooks verwenden.  

Auch die Sicherung des Statefiles ist von wesentlicher Wichtigkeit. Daher sollte die Verwendung eines Remote-Backends, das eine Zugriffskontrolle und Versionskontrolle ermöglicht, immer Vorrang haben.  

Es ist empfehlenswert, einen State-Locking-Mechanismus zu verwenden. Dieser stellt sicher, dass zwei Apply-Befehle nicht gleichzeitig auf demselben State ausgeführt werden. 

3. Segmentierung

Wir sollten um jeden Preis vermeiden, eine einzige Datei für die gesamte Infrastruktur zu verwenden, da Probleme mit der State-Datei katastrophale Folgen für unsere Infrastruktur haben könnten. Stattdessen sollten wir unsere Infrastruktur in logische Segmente unterteilen und für jeden Abschnitt einzelne Terraform-Applikationen nutzen. 

Bild zum Blogpost "Mit Terraform im Team arbeiten"

Durch diese Vorgehensweise beschränken sich die Auswirkungen von Komplikationen auf einen einzigen Komponentenbereich.

4. Testing

Testen ist stets von entscheidender Bedeutung. Aufgrund der „stateful“ Natur von Terraform ist es unmöglich, sich zu 100 % auf den Erfolg eines „apply“-Befehls zu verlassen. Daher ist das Testen vor der Bereitstellung im tatsächlichen System wichtig. Diese Tests sollten statische Analysen wie tflint, Checkov und Terraform Plan umfassen. Zusätzlich empfiehlt es sich Tools wie Localstack zu verwenden. Falls möglich, sollte eine Bereitstellung in einer Testumgebung durchgeführt werden, um eine maximale Einsatzbereitschaft für die endgültige Bereitstellung in der Produktionsumgebung zu gewährleisten. 

5. Branching Strategie

Die Ausgabe von „terraform plan“ basiert auf dem letzten Commit im Feature-Branch und dem aktuellen Zustand. Wenn es zwei Feature-Branches gibt, von denen jeder seinen eigenen Pull Request hat, kann die zeitliche Abfolge von zwei Plan-Aktionen zu unterschiedlichen (und oft unerwarteten) Effekten führen [3]. Sobald der erste Pull Request gemerged ist, wird eine Ressource zur Infrastruktur und zum Hauptzweig hinzugefügt. Aber der Plan des zweiten Pull Requests kennt diese hinzugefügte Ressource nicht, sodass er bei der Anwendung diese Ressource entfernen wird. 

Um solche unerwarteten Ergebnisse zu vermeiden, sollten wir eine geeignete Git-Branching-Strategie wie „Trunk-based Development“ verwenden. Hier werden kurze, temporäre Feature-Branches erstellt und Code-Freeze verwendet, um unerwartete Terraform-Plan-Aktionen zu vermeiden [4]

Fazit

Terraform ist ein leistungsstarkes Tool zur Verwaltung von Cloud-Infrastrukturen, das bei der Verwendung im Team jedoch herausforderndsein kann. Durch die Nutzung von Remote-Statemanagement, GitOps und automatisierten Test-Tools können Teams einige der mit Terraform verbundenen Herausforderungen für die Zusammenarbeit bewältigen. Ferner können sie effektiver zusammenarbeiten, um Infrastrukturen zu verwalten und Ausfallzeiten oder andere Probleme zu vermeiden. 

Das könnte Dich auch noch interessieren

Die Anatomie von CQRS in Java

Die Anatomie von CQRS in Java

Aufgrund meiner festen Überzeugung, dass man Patterns am besten lernt, wenn man sie zunächst einmal selbst implementiert hat, erläutere ich ...
Coding Dojos in the time of Corona

Coding Dojos in the time of Corona

The Corona pandemic creates new problems, especially for events. As the organizer of the Conciso Coding Dojo Dortmund I tried ...
Beitragsbild für den Wissensbeitrag Angular Libraries mit Nx - So veröffentlichst Du Deine Komponente

Angular Libraries mit Nx – So veröffentlichst Du Deine Komponente...

npm ist vermutlich das bekannteste Portal für Abhängigkeiten und Bibliotheken für JavaScript/TypeScript und Node.js Applikationen. Die hier veröffentlichten Pakete können ...