Terraform-Module, die andere wirklich benutzen wollen.

Jedes Plattformteam baut schließlich ein Set interner Terraform-Module. Eine Standardmethode, um eine Datenbank, einen Eimer, ein Netzwerk, einen Cluster zu erstellen. Die Idee ist großartig: Die besten Praktiken des Unternehmens einmal zu kodieren und alle wiederverwenden zu lassen.

In der Praxis werden viele interne Module entweder ignoriert (Teams kopieren stattdessen Ressourcen) oder gehasst (so viele Optionen, dass sie niemand versteht). Hier ist, was ein Modul macht, das die Leute wirklich benutzen wollen.

Beginnen Sie mit einem klaren Ziel

Ein gutes Modul macht eine Sache gut, mit einer Meinung. Nicht "ein Umschlag um jedes Argument von aws_db_instance" , aber "eine PostgreSQL-Datenbank konfiguriert, wie wir Datenbanken hier laufen": verschlüsselt, gesichert, überwacht, im richtigen Netzwerk, mit den richtigen Tags.

Wenn das Modul nur jedes Argument der zugrunde liegenden Ressource durchläuft, fügt es keinen Wert hinzu. Die Teams könnten die Ressource genauso gut direkt nutzen.

Ein gutes Modul entfernt Entscheidungen. Ein schlechtes Modul verlegt sie einfach in eine andere Datei.

Eine saubere Struktur

modules/rds-postgres/
  main.tf
  variables.tf
  outputs.tf
  versions.tf
  README.md
  examples/
    basic/
      main.tf
  tests/
    defaults.tftest.hcl

• versions.tf Sie müssen die erforderliche Terraform-Version und die Anbieterversionen festlegen.
• examples/ zeigt den tatsächlichen Gebrauch und dient als Testgerät.
• tests/ mit terraform test - Die Akten.

Eingaben, Ausgänge und Validierung

Wenige erforderliche Eingaben, gute Standards für den Rest. Das Grundbeispiel sollte nur eine Handvoll Zeilen benötigen:

module "orders_db" {
  source      = "git::https://github.com/acme/terraform-modules.git//rds-postgres?ref=v2.3.0"
  name        = "orders"
  environment = "production"
  size        = "medium"
}

Validieren von Eingaben Also scheitern Fehler früh mit einer klaren Botschaft:

variable "size" {
  description = "Database size: small, medium or large."
  type        = string
  default     = "small"

  validation {
    condition     = contains(["small", "medium", "large"], var.size)
    error_message = "size must be one of: small, medium, large."
  }
}

Übersetzungen size = "medium" In eine bestimmte Instanzklasse innerhalb des Moduls zu integrieren bedeutet auch, dass Sie den zugrunde liegenden Instanztyp später ändern können, ohne dass jedes Team seinen Code ändert.

Nützliche Ergebnisse: IDs, Endpunkte, ARNs, Sicherheitsgruppen-IDs, Name der geheimen Anmeldeinformationen. Denken Sie darüber nach, was die nächste Ressource braucht.

Genaue Typen verwenden: object({...}) mit optionalen Attributen anstelle eines generischen map(any).

Versionssteuerung und Privatregister

Die Module wechseln. Benutzer brauchen Stabilität. Also ...

• Tag-Veröffentlichungen mit semantischen Versionen: v1.4.0, v2.0.0.
• Immer auf eine Version verweisen (?ref=v2.3.0 für Git oder version = "~> 2.3" für ein Register). Niemals auf main.
• Schreiben Sie ein Changelog, und die Veränderungen bei der Brechung deutlich markieren. Eine umfassende Änderung bedeutet eine neue große Version.
• Veröffentlichen in einem privaten Register Wenn Sie können: HCP Terraform, GitLab, Artifactory, Spacelift und andere bieten sie an. Es gibt Ihnen Versionenbeschränkungen, Entdeckung und Dokumentation an einem Ort.
• Let Renovate aktualisiert Modulversionen in Verbrauchsrepositorien.

Dokumente, die sich selbst schreiben

Niemand möchte einen README manuell pflegen. Terrafform-Dokumente erzeugt die Eingabe- und Ausgabetabellen aus Ihrem Code:

terraform-docs markdown table --output-file README.md --output-mode inject .

Führen Sie es in einem Pre-Commit-Hook oder CI durch, und die Dokumentation bleibt synchron. Fügen Sie oben einen kurzen, von Menschen geschriebenen Abschnitt hinzu: wofür das Modul dient, was es standardmäßig tut und ein minimales Beispiel.

Prüfmodule

Selbst ein paar Tests helfen sehr:

• Planbasierte Prüfungen mit terraform test um Standardvorgaben zu überprüfen: Verschlüsselung eingeschaltet, Löschschutz eingeschaltete, Tags vorhanden.
• Validierungstests Die Prüfung der Fehler wird abgelehnt.
• Ein Prüfverfahren in einem Sandbox-Konto für kritische Module, die bei der Freigabe statt bei jedem Commit ausgeführt werden.
• Statische Kontrollen (Tflint, Checkov) auf dem Modul selbst.

Wann man aufhört zu abstrahieren

Der häufigste Fehler, den ich sehe: Module, die Module mit Dutzenden von Variablen verpacken, mit Flaggen für jeden möglichen Anwendungsfall und count Überall sind Tricks.

Anzeichen, dass du zu weit gegangen bist:

• Das Modul hat mehr Variablen als die Ressourcen, die es erstellt, Argumente haben.
• Niemand kann erklären, was passiert, wenn man eine bestimmte Flagge aufstellt.
• Die Teams bichten das Modul, weil es zu beängstigend ist, es zu ändern.

Es ist in Ordnung, wenn ein Modul nein sagt. Wenn ein Team einen wirklich ungewöhnlichen Bedarf hat, kann es die Ressource direkt nutzen oder Sie können ein zweites, separates Modul erstellen. Nicht jeder Anwendungsfall gehört in den gleichen.

Was macht ein großartiges Modul aus?

Eine klare Meinung, wenige erforderliche Eingaben, validierte Variablen, nützliche Ausgänge, generierte Dokumente, echte Versionen und ein paar Tests. Gebaut für den allgemeinen Fall, mit der Demut, nicht alles zu decken.

Meine Meinung: Bauen Sie Module, die den richtigen Weg kurz und offensichtlich machen. Wenn die Leute stattdessen Ressourcen kopieren, hilft ihnen das Modul noch nicht.

Desly