Wie Sie Ihre Infrastruktur strukturieren: Verwendung von umgebungsbasierten Terraform Cloud Workspaces

Nachdem ich nun schon seit einigen Jahren mit Terraform arbeite, habe ich erst vor kurzem begonnen, die Möglichkeiten von Arbeitsbereichen und ihre Rolle bei der Entwicklung zu erkunden. Eine Sache, die mich bei der Arbeit mit Terraform immer frustriert hat, war die Trennung der Konfigurationen nach Umgebungen. Obwohl es eine gut dokumentierte "Best Practice" ist, Konfigurationen nach Umgebungen zu trennen, habe ich dies immer als suboptimalen Ansatz empfunden, denn jedes Mal, wenn etwas aktualisiert oder hinzugefügt werden musste, musste dies manuell in allen Versionen der Konfigurationsdateien der einzelnen Umgebungen vorgenommen werden, was das Risiko von Fehlkonfigurationen durch menschliches Versagen erhöht und damit einen Grundpfeiler von IaC beeinträchtigt.

Mit all den ausgefallenen Funktionen, die uns in Terraform Cloud zur Verfügung stehen, halte ich die Trennungsmethode für überholt. Ich habe eine Methode entwickelt, die meiner Meinung nach die menschliche Fehlertoleranz reduziert, indem sie die Konfigurationsdateien auf nur einen Satz reduziert und einen Großteil der Vorgehensweise automatisiert, um die Entwicklungszeiten zu verkürzen. Also, lassen Sie uns anfangen!

Voraussetzungen:

• Terraform Cloud konfiguriert- Denjenigen, die Terraform Cloud noch nicht kennen, empfehle ich dringend, sich so schnell wie möglich damit vertraut zu machen. Abgesehen von dem, woran wir hier arbeiten, bietet es eine Menge hilfreicher und leistungsstarker Funktionen zur Sicherung und Entwicklung Ihres Codes. Und das Beste daran ist, dass es für die ersten 5 Benutzer in der Organisation völlig kostenlos ist! Also ideal für einzelne Entwickler und kleine Teams.
• Cloud-Anmeldeinformationen - In diesem Beispiel verwende ich GCP, aber es ist auf alle Anbieter anwendbar. Ich werde erläutern, wo diese Anmeldeinformationen im Arbeitsbereich hinzugefügt werden sollten. Es ist jedoch wichtig, dass Sie wissen, wie Sie Anmeldeinformationen für Servicekonto-Benutzer mit den erforderlichen Berechtigungen bei dem von Ihnen gewählten Anbieter, z.B. GCP AWS, erstellen und sammeln.

Einrichtung

Git

Der erste Schritt unserer Einrichtung besteht darin, ein Git-Repository für unsere Terraform-Konfiguration zu erstellen. Terraform Cloud unterstützt alle wichtigen Git-Plattformen, Sie sollten also Ihre bevorzugte verwenden können. Der Name Ihres neuen Projekts muss nicht zwingend mit dem Namen des Arbeitsbereichs in Terraform Cloud übereinstimmen, aber ich finde es hilfreich. In meinem Fall habe ich also den Namen terraform-cloud-workspaces verwendet. Nach der Erstellung erstellen Sie Zweige für jede Umgebung. Also für dieses Beispiel:

• Produktion -> Produktion
• Hauptseite -> Inszenierung
• Funktion -> dev

 

Öffnen Sie dann Ihre bevorzugte IDE und checken Sie Ihren feature Zweig lokal aus.

Für die Dateistruktur gibt es ebenfalls keine vorgeschriebene Struktur, aber um in die Standard-Terraform-Struktur zu passen, lege ich meine Terraform-Konfigurationsdateien in einem terraform/ -Verzeichnis ab und nicht im Stammverzeichnis. Wo auch immer Sie Ihre Dateien ablegen, merken Sie es sich für später, denn es ist wichtig, wenn Sie den Arbeitsbereich verlinken.

terraform-cloud-workspaces
|- README.md
|- terraform/
| |- main.tf
| |- variables.tf

Terraform-Konfiguration

Da es in diesem Beispiel hauptsächlich um die Bereitstellung von Ressourcen geht, werden wir eine sehr einfache Konfiguration verwenden, die nur aus einer VM-Instanz besteht:

main.tf

terraform {
  backend "remote" {
    organization = "myTerraformCloudOrg"
    workspaces {
      prefix = "terraform-cloud-workspaces-"
    }
  }
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 4.73.0"
    }
  }
}
locals {
  region = "europe-west4"
}
provider "google" {
  project = "my-project-id"
  region  = local.region
}
resource "google_compute_instance" "example" {
  name         = "${var.env}-my-server"
  machine_type = var.machine_type
  zone         = "${local.region}-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"
  }
}

Die beiden wichtigsten Dinge, die Sie hier beachten sollten, sind: Die Verwendung von prefix im Block workspaces und die Verwendung eines var im Namen des Ressourcenblocks.

Der Kernpunkt dieser Bereitstellungsmethode ist die Verwendung von prefix im workspace Block. Dadurch können wir die Konfiguration mit mehreren Arbeitsbereichen in der Terraform-Cloud verknüpfen, anstatt direkte 1:1-Verbindungen für jede Umgebung herzustellen. Was wir hier tun, wird hoffentlich später klarer, wenn wir die Arbeitsbereiche in der Cloud einrichten, aber weitere Informationen zum Argument prefix finden Sie hier.

Wenn wir unsere Infrastruktur in jeder Umgebung bereitstellen, müssen wir die Ressourcen irgendwie voneinander unterscheiden. In Anlehnung an bewährte Sicherheitspraktiken würde dies geschehen, indem jede Umgebungskonfiguration in einem eigenen Projekt bereitgestellt wird, um eine Isolierung zu gewährleisten und eine gegenseitige Verunreinigung zu vermeiden. Für dieses Beispiel verwende ich jedoch einfach den Umgebungsnamen, um zu definieren, welche VM bereitgestellt wurde, d.h. am Ende unseres Prozesses sollten wir 3 verschiedene VMs in derselben Projektregion haben:

• dev-my-server
• stg-mein-server
• prd-mein-server

Auch dies sollte im Laufe der Zeit klarer werden, aber im Moment sollten Sie sich darauf konzentrieren, dass umgebungsbasierte Ressourcen irgendwie unterscheidbar sein müssen. Dies kann durch die Verwendung verschiedener Projekte oder Regionen geschehen, aber für unser einfaches Beispiel verwenden wir einfach den Umgebungsnamen im Ressourcennamen.

Variablen.tf

variable "env" {
description = "Environment name"
type = string
}
variable "machine_type" {
description = "Machine type to be used for the VM"
type = string
}

Wie bereits erwähnt, wollen wir den Umgebungsnamen für jeden Arbeitsbereich anpassen, daher wurde eine env Variable hinzugefügt, um dies zu ermöglichen. Ich habe auch eine machine_type Variable hinzugefügt. Diese ist nicht zwingend erforderlich, aber ich habe sie eingefügt, um eine Vorstellung davon zu vermitteln, wie andere, konkretere Ressourceneinstellungen von Umgebung zu Umgebung angepasst werden können. In unserem Beispiel werde ich die Maschinengröße anpassen, die mit zunehmender Annäherung an prod größer wird, aber diese Variable könnte auch etwas anderes sein, das sich auf Ihre Ressource bezieht, sich aber durch die Umgebungen ändert, wie z.B. eine Skalierungsgrenze für Cluster oder Whitelisting-Einstellungen für Sicherheitsgruppen.

Arbeitsbereiche

Übersicht

Jetzt, wo wir unsere Konfiguration haben, können wir unsere Arbeitsbereiche einrichten, die die Bereitstellung in jeder Umgebung erleichtern. Unten sehen Sie ein Diagramm, das zeigt, was wir erreichen wollen:

Workflow-Diagramm Arbeitsbereiche

Wie Sie sehen können, haben wir 2 verschiedene Arten von Arbeitsbereichen in Terraform Cloud:

• CLI-gesteuert
• Version Kontrolliert

Um uns und anderen Entwicklern im Team eine schnelle und effiziente Entwicklung zu ermöglichen, möchten wir, dass unser Entwicklungsarbeitsbereich CLI-gesteuert ist. Mit dieser Methode können wir direkt von der CLI aus bereitstellen, was wir in unserem lokalen Zweig haben. Das bedeutet, dass wir unsere Änderungen schnell bereitstellen und testen können, bevor wir sie weitergeben.

Versionskontrollierte Workspaces blockieren jedoch die Bereitstellung über CLI. Diese Workflows werden ausgelöst, wenn eine Änderung vorgenommen oder eine Merge-Anfrage für einen bestimmten Zweig innerhalb eines Git-Repo geöffnet wird. Das bedeutet, dass sie sich gut in einen CI/CD-Workflow integrieren lassen und die richtigen Prüfungen und Abgleiche für eine erfolgreiche Bereitstellung ermöglichen.

CLI-gesteuert

CLI-gesteuerte Workflows können über die Terraform-Cloud-Benutzeroberfläche hinzugefügt werden. Ich persönlich bevorzuge jedoch die Verwendung der CLI, und da wir die Benutzeroberfläche verwenden werden, um die versionskontrollierten Arbeitsbereiche einzurichten, ist es gut, die CLI-Methode hier zu erkunden (vorausgesetzt, Sie haben Terraform-Cloud konfiguriert und sind über CLI angemeldet).

Führen Sie im Terminal in Ihrem Terraform-Verzeichnis den Befehl aus:

terraform init

Um das Backend zu initialisieren. Dadurch wird das Verzeichnis .terraform/ erstellt, aber es tritt ein Fehler auf:

Error: No existing workspaces.

Um den Arbeitsbereich dev zu erstellen, führen Sie aus:

terraform workspace new dev

Um zu überprüfen, ob der Arbeitsbereich erstellt wurde, gehen Sie zur Web-Benutzeroberfläche, um zu sehen, ob der Arbeitsbereich vorhanden ist:

Jetzt, da wir einen Arbeitsbereich haben, müssen wir die arbeitsbereichsspezifischen Variablen hinzufügen, um ihn korrekt in der gegebenen Umgebung bereitzustellen. Wählen Sie dazu im Arbeitsbereich Variables aus dem linken Menü und fügen Sie die folgende Terraform hinzu (nicht Umgebungs-) Variablen:

Außerdem müssen Sie dem Arbeitsbereich Cloud-Anmeldeinformationen hinzufügen, falls Sie dies noch nicht getan haben. Eine Anleitung dazu finden Sie hier. Wenn Sie häufig dasselbe Servicekonto für die Bereitstellung Ihrer Infrastruktur verwenden, kann es sinnvoll sein, diese als Variablensatz und nicht in jedem Arbeitsbereich festzulegen, damit Sie sie nicht für jeden einzelnen festlegen müssen.

Version Kontrolliert

Jetzt, wo wir unseren Arbeitsbereich dev eingerichtet haben, können wir an unseren Arbeitsbereichen staging und production arbeiten. Versionskontrollierte Arbeitsbereiche müssen Sie über die Terraform Cloud UI einrichten. Klicken Sie dort auf New > Workspace und wählen Sie Version control workflow. Wenn Sie noch keinen VCS-Anbieter verbunden haben, sollten Sie dies jetzt tun. Sobald Sie verbunden sind, wählen Sie das gewünschte VCS aus. Wählen Sie das Repo, in meinem Fall terraform-cloud-workspaces, und die Einstellungen:

Name des Arbeitsbereichs: terraform-cloud-workspaces-stg Erweiterte Optionen ↓ Terraform-Arbeitsverzeichnis: terraform Automatische Anwendung: ✅ Automatische Anwendung von API-, CLI- & VCS-Läufen VCS-Zweig: main

Alles andere können Sie als Standard belassen. HINWEIS: Wenn sich Ihre Terraform-Konfigurationsdateien im Stammverzeichnis oder in einem anderen Verzeichnis als terraform/ befinden, müssen Sie das Terraform-Arbeitsverzeichnis an dieses anpassen.

OPTIONAL: Wenn Sie mit größeren Projekten arbeiten, die mehr als nur eine Terraform-Konfiguration enthalten, möchten Sie vielleicht die Option VCS-Auslöser auf "Only trigger runs when files in specified paths change" und setzen Sie den Pfad auf das Terraform-Konfigurationsverzeichnis. Dies erhöht die Entwicklungsgeschwindigkeit und stellt sicher, dass Terraform-Implementierungen nur dann durchgeführt werden, wenn sich die Konfiguration tatsächlich ändert.

Jetzt, wo Sie den Staging-Arbeitsbereich eingerichtet haben, müssen Sie die Variablen wieder auf die gleiche Weise setzen wie für dev, nur mit folgendem

Vergessen Sie nicht, auch die Anmeldedaten hinzuzufügen, wenn Sie dies pro Arbeitsbereich tun!

Schließlich können wir den Arbeitsbereich production erstellen. Erstellen Sie einen weiteren Arbeitsbereich auf die gleiche Weise wie für staging, aber mit den folgenden Einstellungen:

Arbeitsbereich Name: terraform-cloud-workspaces-prd Erweiterte Optionen ↓ Terraform Arbeitsverzeichnis: terraform Auto apply: Nicht markiert lassen VCSBranch: production

Beachten Sie, dass wir dieses Mal eine "Manuelle Anwendung" verwenden. Das bedeutet, dass wir den Zweig nach der Zusammenführung manuell in der Benutzeroberfläche genehmigen müssen, damit er bereitgestellt werden kann. Wenn Sie sich für die manuelle statt für die automatische Anwendung entscheiden, ist dies ein zusätzlicher Sicherheitsschritt vor der Bereitstellung, aber letztendlich hängt die Entscheidung davon ab, wie Sie Ihre CI/CD-Pipeline gestalten möchten. In diesem Beispiel werden wir beide Methoden ausprobieren.

Sie können nun erneut Variablen zum production Arbeitsbereich hinzufügen (vergessen Sie nicht die Anmeldungsvariablen, falls erforderlich):

Sie sollten nun 3 korrekt konfigurierte Arbeitsbereiche haben

OPTIONAL: Wenn Sie Ihre Arbeitsbereiche etwas aufräumen wollen, können Sie ein New > Project erstellen namens "terraform-cloud-workspaces" erstellen und Ihre Arbeitsbereiche dorthin verschieben:

Deployment

Es war ein langer Weg, aber jetzt sind wir endlich bereit, die neue Methode in Aktion zu sehen! Unten sehen Sie ein Diagramm, das Ihnen zeigt, wie die Einsätze in Verbindung mit Ihrem Entwicklungszyklus funktionieren sollten:

Git-Arbeitsablaufdiagramm

Beachten Sie, dass die Zweige einer darunter liegenden Ebene einen Plan für die darüber liegende Ebene auslösen, wenn die Zusammenführungsanforderung erstellt wird, und dass die Bereitstellung erfolgt, wenn die Zusammenführung akzeptiert wird.

Dev

Die Entwickler haben die volle Kontrolle darüber, wann sie die Infrastruktur planen und bereitstellen möchten. Wir können dies von unserem lokalen feature Zweig aus testen, indem wir ihn ausführen:

terraform apply

Dies sollte einen Plan für uns generieren, bei dem die einzige Ressource, die bereitgestellt werden soll, eine e2-micro VM-Instanz namens dev-my-server ist:

# google_compute_instance.example will be created
    + resource "google_compute_instance" "example" {
    + can_ip_forward = false
    + cpu_platform = (known after apply)
    + current_status = (known after apply)
    + deletion_protection = false
    + guest_accelerator = (known after apply)
    + id = (known after apply)
    + instance_id = (known after apply)
    + label_fingerprint = (known after apply)
    + machine_type = "e2-micro"
    + metadata_fingerprint = (known after apply)
    + min_cpu_platform = (known after apply)
    + name = "dev-my-server"
    + project = (known after apply)
    + self_link = (known after apply)
    + tags_fingerprint = (known after apply)
    + zone = "europe-west4-a"

Nach der Genehmigung wird die Bereitstellung dieser Ressource fortgesetzt. Sie können die Bereitstellung überprüfen, indem Sie zu Ihren Compute-Instanzen in GCP gehen und den Server dort sehen:

Inszenierung

Um die Terraform Cloud-Bereitstellung zunächst zu initialisieren, müssen Sie möglicherweise einen Lauf aus der Benutzeroberfläche für den Arbeitsbereich auslösen, bevor er durch eine Änderung am Git Repo ausgelöst werden kann. Gehen Sie dazu einfach in der Benutzeroberfläche zum Arbeitsbereich, wählen Sie Actions > Start new run und verwenden Sie die folgenden Einstellungen:

Unter der Annahme, dass die Verzweigung noch leer ist, sollte dieser Lauf zu einem Fehler führen, aber er wird die Bereitstellung initialisieren, so dass künftige Änderungen an der Repo Läufe auslösen werden.

Jetzt können wir einen Antrag auf Zusammenführung von unserem Funktionszweig in den Hauptzweig stellen, mit dem unser versionskontrollierter Staging-Arbeitsbereich verknüpft ist. Dies wird einen plan Lauf in unserem Staging-Arbeitsbereich auslösen. Wenn Sie im linken Menü des Arbeitsbereichs zum Abschnitt Runs gehen, können Sie diesen Plan untersuchen und sehen, dass dieses Mal eine Instanz e2-small mit dem Namen stg-my-server bereitgestellt wird:

[caption id="" align="aligncenter" width="700"] Stufenweiser Einsatzplan[/caption]

Wenn hier alles gut aussieht, können Sie die Verzweigung von feature auf main zusammenführen. Da wir diesen Arbeitsbereich auf "Automatisch anwenden" eingestellt haben, wird die Bereitstellung automatisch ausgelöst, sobald Sie die Zusammenführung vornehmen. Auf der Registerkarte Runs im Arbeitsbereich können Sie erneut den Fortschritt überprüfen. Sobald die Zusammenführung abgeschlossen ist, sollten Sie nun 2 Server in Ihrem GCP-Projekt bereitstellen, wobei der Staging-Server eine Nummer größer ist:

Produktion

Schließlich können wir unsere Produktionsinfrastruktur bereitstellen. Wie beim Staging-Arbeitsbereich initialisieren Sie zunächst die Bereitstellung, indem Sie über die Benutzeroberfläche einen reinen Planlauf auslösen. Als Nächstes können wir einen richtigen Lauf auslösen, indem wir in unserem Git-Repository einen Merge-Request von der Verzweigung main nach production auslösen. Dadurch wird erneut ein Planlauf ausgelöst, dieses Mal jedoch mit einer Instanz e2-medium mit dem Namen prd-my-server:

[caption id="" align="aligncenter" width="700"] Produktionseinsatzplan[/caption]

Wenn das alles gut aussieht, können Sie die Zusammenführungsanfrage im Git-Repository genehmigen. Dadurch wird ein weiterer Durchlauf ausgelöst. Anders als in der Staging-Umgebung muss der Durchlauf jedoch in der Benutzeroberfläche genehmigt werden, bevor er von plan auf apply fortgesetzt wird:

Klicken Sie auf Confirm & Apply, um mit der Bereitstellung fortzufahren. Sobald die Bereitstellung abgeschlossen ist, sollten Sie nun 3 Server mit unterschiedlicher Größe haben, je nachdem, wie groß sie sind!

Überprüfung

Also lassen Sie uns zusammenfassen! Obwohl all diese Schritte ein wenig komplex erscheinen, können wir zusammenfassen, was wir getan haben: Mit nur einem Satz Terraform-Konfigurationsdateien haben wir einen Arbeitsablauf erstellt, der einzigartige Ressourcen je nach Umgebung bereitstellt, und ihn in unsere CI/CD-Pipeline integriert

Dies trägt dazu bei, menschliche Fehler zu reduzieren, indem die Anzahl der Konfigurationsdateien verringert wird. Außerdem wird verhindert, dass Staging- und Produktionsdateien ohne angemessene Kontrollen und Abgleiche bereitgestellt werden.

Update

In meinem Blogbeitrag hier finden Sie ein Update zur Definition von Variablen mit dieser Methode.

Zerstörung

Vergessen Sie nicht, Ihre Ressourcen am Ende zu zerstören. Bei staging und production können Sie dies über die Benutzeroberfläche tun, indem Sie in den Arbeitsbereich gehen und unter Settings > Destruction and Deletion einen Zerstörungsplan in die Warteschlange stellen (möglicherweise müssen Sie diesen Durchlauf auf dieselbe Weise bestätigen, wie Sie es bei apply getan haben):

Und für dev können Sie dies lokal tun, indem Sie den Befehl ausführen:

terraform destroy

Überprüfen Sie nach Abschluss der Arbeiten Ihre GCP-Ressourcen, um sicherzustellen, dass alles entfernt wurde.