Wie ich Terraform-Projekte strukturiere

Jedes Terraform-Projekt beginnt sauber. Ein Ordner, ein main.tf, ein paar Ressourcen. Dann kommt eine zweite Umgebung. Dann ein paar weitere Dienste, ein gemeinsames Netzwerk, eine zweite Region. Zwei Jahre später gibt es eine 3000-Zeile main.tfEine Staatsakte, die niemand anfassen darf, und ein Plan, der zehn Minuten dauert.

Struktur macht den Unterschied zwischen Infrastrukturcode, der reibungslos wächst und Code, der zum am wenigsten bevorzugten Teil des Repos wird. Das ist das Layout, das ich immer benutze. (Alles hier funktioniert auch für OpenTofu.)

Die Grundsätze

1. Kleine Staatsakten. Infrastruktur in unabhängige Teile aufteilen, jede mit ihrem eigenen Zustand. Kleiner Sprengradius, schnellerer Planung, weniger Leute, die sich blockieren.
2. Nach Lebenszyklus getrennt. Dinge, die sich selten ändern (Netzwerke, Konten) sollten ihren Zustand nicht mit Dingen teilen, die sich täglich ändern (App-Ressourcen).
3. Die Umgebung sieht gleich aus. Inszenierung und Produktion sollten denselben Code mit verschiedenen Eingaben verwenden, nicht kopierte Ordner, die langsam auseinanderdriften.
4. Mehrfachverwendbare Logik lebt in Modulen.

Ein Layout, das funktioniert

infrastructure/
  modules/
    network/
    eks-cluster/
    rds-postgres/
  live/
    staging/
      network/
        main.tf
        backend.tf
        terraform.tfvars
      cluster/
      databases/
    production/
      network/
      cluster/
      databases/

• modules/ enthält wiederverwendbare Bausteine ohne umweltspezifische Werte.
• live/ enthält die tatsächlichen Einsätze. Jeder Ordner ist eine Zustanddatei, die Module mit umweltspezifischen Eingaben aufruft.
• Jeder Live-Ordner ist klein und fokussiert: das Netzwerk, der Cluster, die Datenbanken.

Spätere Komponenten können Ausgänge von früheren Komponenten mit terraform_remote_state oder, besser, durch Suche nach Ressourcen mit Datenquellen oder einem gemeinsamen Parameterspeicher.

Ordner vs. Arbeitsbereiche

Terraform hat Arbeitsplätze, die eine Konfiguration mehrere Zustände haben lassen. Es ist verlockend, sie für Umgebungen zu verwenden: terraform workspace select production.

Ich bevorzuge separate Ordner für Umgebungen:

• Es ist im Code sichtbar, an welcher Umgebung Sie arbeiten.
• Die Produktion kann ein eigenes Backend, eigene Berechtigungen und eine eigene Pipeline haben.
• Die versehentliche Bewerbung auf den falschen Arbeitsplatz ist ein klassischer und schmerzhafter Fehler.

Arbeitsbereiche sind immer noch praktisch, um viele identische Kopien derselben Sache zu erstellen, wie ein Stapel für jeden Kunden oder für Vorschaumöglichkeiten.

Wenn Sie einen Befehl ausführen müssen, um herauszufinden, welche Umgebung Sie ändern möchten, dann arbeitet die Struktur gegen Sie.

Fernzustand und Verriegelung

Behalte nie einen Zustand auf einem Laptop. Verwenden Sie ein Remote-Backend mit Sperrung:

terraform {
  backend "s3" {
    bucket       = "acme-terraform-state"
    key          = "production/network/terraform.tfstate"
    region       = "eu-central-1"
    encrypt      = true
    use_lockfile = true
  }
}

Das S3-Backend unterstützt nun native Sperrungen mit einer Sperrdatei, so dass die separate DynamoDB-Tabelle nicht mehr erforderlich ist. Azure Storage und Google Cloud Storage Backends sind ebenfalls nativ gesperrt.

Schützen Sie den Staateschutz: Versionssicherung eingeschaltet, Verschlüsselung eingeschlossen, Zugriff auf die Personen und Pipelines beschränkt, die ihn benötigen. Der Staat enthält oft Geheimnisse.

Terragrunt oder Stacks?

Das oben stehende Ordnerlayout hat einen lästigen Nebenwirkung: viele wiederholte Boilerplate. Jeder Ordner braucht seine Backend-Konfiguration und Provider-Konfigurationen.

Hilfreiche Hilfsmittel:

• Erdbeeren (von Gruntwork) hält die Konfigurationen DRY: Backend- und Provider-Einstellungen werden einmal definiert und vererbt, und Sie können Befehle über viele Ordner mit Abhängigkeiten zwischen ihnen ausführen. Sehr beliebt für genau dieses Layout.
• Terraform-Stapeln (HashiCorp, mit HCP Terraform) ist die offizielle Antwort für die Zusammenführung vieler Komponenten und Einsätze.
• Die frühe Variable-Evaluierung von OpenTofu Die Datenbank kann in der Verknüpfung mit dem System für die Datenübertragung und die Datenübermittlung verwendet werden.
• Plattformen für die Automatisierung der Infrastruktur (Spacelift, env0, Scalr, HCP Terraform) verwalten Stacks und Abhängigkeiten auf ihre eigene Weise.

Für ein kleines Team sind einfache Ordner mit ein wenig Wiederholung in Ordnung. Sobald du Dutzende Komponenten hast, zahlt sich Terragrunt oder eine Plattform aus.

Benennung und Kennzeichnung

Kleine Dinge , die viel Verwirrung ersparen:

• Konsistente Ressourcennamen: <env>-<service>-<purpose>Wie ... prod-shop-db.
• Standard-Tags in den Provider-Block, so dass jede Ressource sie automatisch bekommt:

provider "aws" {
  region = "eu-central-1"
  default_tags {
    tags = {
      environment = "production"
      owner       = "team-platform"
      managed_by  = "terraform"
      repository  = "acme/infrastructure"
    }
  }
}

• Anbieter von Pin-Pins und Modulversionen, und verpflichten die .terraform.lock.hcl - Ich habe eine Akte.
• Formatieren und validieren in der Gemeinschaft (terraform fmt -check, terraform validate(Siehe auch:

Was ist das Wichtigste?

Die Zustandsdateien sind klein und nach Lebenszyklus und Umgebung getrennt. Fast jedes andere Problem, langsame Pläne, beängstigende Anwendungen, Konflikte, Menschen, die sich blockieren, wird einfacher, wenn man das hat.

Ich denke, Sie bauen Ihre Terraform für die Person aus, die nächstes Jahr eintritt. Wenn sie sich zurechtfinden, hast du es richtig gemacht.

Desly