4 Tipps für den Umgang mit mehreren Terraform-Versionen

Hinweis der Redaktion: Dieser Beitrag erschien ursprünglich auf CloudSkiff.com. CloudSkiff ist im Oktober 2021 zu Snyk gestoßen.

Es gibt viele Gründe, warum Sie lokal mehrere Terraform-Versionen benötigen könnten: etwa unterschiedliche Umgebungen (strukturierte Deployments) mit separaten Versionen, die Arbeit an mehreren Projekten für verschiedene Kunden oder die Sicherstellung der Abwärtskompatibilität Ihres Codes durch Tests mit mehreren Versionen. Hier finden Sie einige ganz grundlegende Tipps, um mehrere Terraform-Versionen übersichtlich und sauber zu verwalten.

Verwenden Sie lokal einen Umgebungs- bzw. Terraform-Versionsmanager

Mit einem Versionsmanager ist der Umgang mit mehreren Terraform-Versionen lokal deutlich einfacher. Außerdem stellt er Folgendes sicher:

• Sie können schnell zwischen Projekten wechseln

• Die Entwicklungsumgebung entspricht der Produktionsumgebung so weit wie möglich.

tfenv ist eine gute Wahl und wurde von rbenv inspiriert. Mit tfenv können Sie eine bestimmte Terraform-Version installieren und standardmäßig zu dieser wechseln. Außerdem können Sie alle auf Ihrem Laptop installierten Terraform-Versionen auflisten und nachverfolgen. Darüber hinaus gibt es einige praktische Befehle wie tfenv install min-required, mit dem Ihre Terraform-Dateien rekursiv durchsucht werden, um die minimal erforderliche Version zu ermitteln.

Legen Sie Ihre Terraform-Versionen ausdrücklich fest

Terraform-Upgrades können unangenehme Folgen haben. Noch problematischer wird es, wenn eine unerklärliche Ausnahme auftritt und Sie feststellen, dass sie darauf zurückzuführen ist, dass auf dem betreffenden Computer die falsche Terraform-Version läuft.

Wenn Sie die erforderliche Terraform-Version ausdrücklich festlegen, erhalten Sie eine klare Fehlermeldung, wenn Sie versuchen, apply in der falschen Umgebung auszuführen.

1terraform {
2required_version = "0.12.10"
3}

Legen Sie auch Modulversionen fest

Veränderliche Komponenten gehören zu den größten Herausforderungen für Programmierer – das gilt auch für Infrastructure as Code. Terraform-Module bieten viel Wiederverwendbarkeit und Kombinierbarkeit, können aber auch unübersichtlich werden.

Wenn Sie Modulversionen festlegen, können Sie besser steuern, wann und welche Teile Ihrer Infrastruktur sich durch ein Modul-Upgrade ändern. So ist sichergestellt, dass Sie bei einem bestimmten Commit in Ihrer Codebasis immer dasselbe bereitstellen.

1module “blabla” {
2source = “module_name”
3version = “1.2.3”
4}

So können Sie Modul-Upgrades auch schrittweise einführen: In der Produktionsumgebung bleibt zunächst die alte Version aktiv. Erstellen Sie einen Dev-Branch, aktualisieren Sie dort das Modul und testen Sie es in Ihrer Entwicklungsumgebung. Wenn die Tests erfolgreich sind, können Sie die Änderungen in den Master-Branch übernehmen.

Je mehr Module Sie verwenden, desto größer ist die Wahrscheinlichkeit, dass eines davon irgendwann Probleme verursacht. Mit wachsender Codebasis wird dieser Punkt also immer wichtiger.

Lokale apply-Ausführungen verhindern und Commits auf Master vermeiden

Vergessen Sie Ihren Workflow nicht! apply lokal auszuführen, kann gefährlich sein, sobald zwei Benutzer gemeinsam an derselben Terraform-Datei arbeiten: Wenn kurz nacheinander zwei Änderungen vorgenommen werden, kann die zweite die erste überschreiben. Außerdem wissen Sie nie, was auf Ihrem Laptop passieren kann. Wir haben schon von Fällen gehört, in denen große State-Dateien durch eine unterbrochene WLAN-Verbindung beschädigt wurden.

Deshalb sieht ein produktionsreiferer Workflow vor, apply nur über ein zentrales, versioniertes System auszuführen, beispielsweise über eine CI/CD-Pipeline.

Im nächsten Schritt integrieren Sie dieses Verhalten in den Prozess. So erhält ein Benutzer beispielsweise keine Zugriffsrechte, mit denen er direkt Änderungen in der Produktionsumgebung vornehmen kann. Nur die CI/CD-Schlüssel verfügen über die dafür nötigen Rechte.

Ebenso ist es verlockend, Änderungen direkt in den Master-Branch zu übernehmen, obwohl wir wissen, dass das keine Best Practice ist. Wenn Sie den Master-Branch sperren, halten Sie Benutzer dazu an, den besseren und sichereren Prozess aus Pull Request und anschließendem Review einzuhalten. Es sei denn, Sie sind übermenschlich, lesen immer den Terraform-Plan und machen niemals Fehler.

Manche Teams fügen an dieser Stelle weitere Schritte hinzu, etwa Linting oder die Prüfung auf aktualisierte Dokumentation. Diese kleinen Investitionen tragen langfristig dazu bei, den Code sauber zu halten.

Schützen Sie Ihren Terraform-Code

Snyk IaC schützt Ihre Terraform-Konfigurationen (sowie Kubernetes-, CloudFormation- und ARM-Vorlagen!) während der Entwicklung und bietet angeleitete Korrekturen, damit Sie Änderungen zusammenführen und weitermachen können. Testen Sie bereits beim Schreiben, überwachen Sie Änderungen in Ihren Git-Repositories und automatisieren Sie Tests in Ihren Build-Pipelines vor dem Deployment. Mit einem kostenlosen Tarif können Sie in wenigen Minuten loslegen – während eine Sicherheitsverletzung aufgrund einer IaC-Fehlkonfiguration lebenslange Folgen haben kann. Melden Sie sich an und schützen Sie Ihre Konfigurationen noch heute.