Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Dieses Dokument ist ein Versuch, die besten Praktiken bei der Verwendung von Terraform systematisch zu beschreiben und Empfehlungen für die häufigsten Probleme zu geben.
Terraform ist ein relativ neues Projekt (wie die meisten DevOps-Tools), das 2014 gestartet wurde.
Terraform ist leistungsfähig (wenn nicht sogar das leistungsfähigste, das es derzeit gibt) und eines der am häufigsten verwendeten Tools, das die Verwaltung der Infrastruktur als Code ermöglicht. Es erlaubt Entwicklern eine Menge Dinge zu tun und schränkt sie nicht ein, Dinge zu tun, die schwer zu unterstützen oder zu integrieren sind.
Einige der in diesem Buch beschriebenen Informationen mögen nicht als die besten Praktiken erscheinen. Ich weiß das, und um den Lesern zu helfen, zu unterscheiden, was bewährte Praktiken sind und was nur eine andere Art ist, Dinge zu tun, verwende ich manchmal Hinweise, um etwas Kontext zu liefern, und Symbole, um den Reifegrad jedes Unterabschnitts in Bezug auf bewährte Praktiken anzugeben.
Das Buch ist 2018 im sonnigen Madrid entstanden und ist hier kostenlos erhältlich - https://www.terraform-best-practices.com/ .
Ein paar Jahre später wurde es mit mehr aktuellen Best Practices aktualisiert, die mit Terraform 1.0 verfügbar waren. Letztendlich sollte dieses Buch die meisten der unbestrittenen besten Praktiken und Empfehlungen für Terraform-Nutzer enthalten.
Please contact me if you want to become a sponsor.
Kontaktieren Sie mich, wenn Sie bei der Übersetzung dieses Buches in andere Sprachen helfen wollen.
Ich möchte immer Rückmeldungen erhalten und dieses Buch aktualisieren, wenn die Gemeinschaft reift und neue Ideen umgesetzt und überprüft werden.
Wenn Sie an bestimmten Themen interessiert sind, eröffnen Sie bitte ein Issue oder bewerten Sie ein Issue mit einem Daumen-hoch, von dem Sie möchten, dass es am meisten behandelt werden soll. Wenn Sie das Gefühl haben, dass Sie Inhalte haben und einen Beitrag leisten wollen, schreiben Sie einen Entwurf und reichen Sie einen Pull Request ein (machen Sie sich zu diesem Zeitpunkt keine Sorgen über einen guten Textstil!)
Dieses Buch wird von Anton Babenko mit Hilfe verschiedener Mitwirkender und Übersetzer gepflegt.
Dieses Projekt steht unter der Apache-2-Lizenz. Siehe LICENSE für weitere Details.
Die Autoren und Mitwirkenden an diesem Inhalt können die Gültigkeit der hier gefundenen Informationen nicht garantieren. Bitte vergewissern Sie sich, dass Sie verstehen, dass die hier zur Verfügung gestellten Informationen frei zur Verfügung gestellt werden und dass keine Art von Vereinbarung oder Vertrag zwischen Ihnen und Personen, die mit diesem Inhalt oder Projekt in Verbindung stehen, entsteht. Die Autoren und Mitwirkenden übernehmen keine Haftung für Verluste, Schäden oder Störungen, die durch Fehler oder Auslassungen in den Informationen verursacht werden, die in diesem Inhalt enthalten sind, mit ihm in Verbindung stehen oder mit ihm verlinkt sind, unabhängig davon, ob solche Fehler oder Auslassungen auf Fahrlässigkeit, Unfälle oder andere Ursachen zurückzuführen sind.
Copyright © 2018-2023 Anton Babenko.
Fragen, die sich auf die Terraform-Code-Struktur beziehen, sind mit Abstand die häufigsten in der Community. Jeder hat sich irgendwann einmal Gedanken über die beste Codestruktur für das Projekt gemacht.
Dies ist eine der Fragen, für die es viele Lösungen gibt, und es ist sehr schwer, allgemeingültige Ratschläge zu erteilen, also sollten wir zunächst einmal verstehen, womit wir es zu tun haben.
Wie komplex ist Ihr Projekt?
Anzahl der zugehörigen Ressourcen
Anzahl der Terraform-Provider (siehe Hinweis unten über "logische Provider")
Wie oft ändert sich Ihre Infrastruktur?
Von einmal pro Monat/Woche/Tag
Bis kontinuierlich (jedes Mal, wenn es einen neuen Commit gibt)
Initiatoren von Codeänderungen? Lassen Sie den CI-Server das Repository aktualisieren, wenn ein neues Artefakt erstellt wird?
Nur Entwickler können Änderungen am Infrastruktur-Repository vornehmen.
Jeder kann eine Änderung vorschlagen, indem er einen PR öffnet (einschließlich automatisierter Aufgaben, die auf dem CI-Server laufen)
Welche Einsatzplattform oder welchen Einsatzdienst verwenden Sie?
AWS CodeDeploy, Kubernetes oder OpenShift erfordern einen etwas anderen Ansatz
Wie sind die Umgebungen gruppiert?
Nach Umgebung, Region, Projekt
Es ist eine gute Idee, den gesamten Code in die Datei main.tf
zu packen, wenn Sie gerade erst anfangen oder einen Beispielcode schreiben. In allen anderen Fällen ist es besser, mehrere Dateien zu haben, die logisch aufgeteilt sind, wie hier:
main.tf
- ruft Module, lokale Variablen und Datenquellen auf, um alle Ressourcen zu erstellen
variables.tf
- enthält die Deklarationen der in main.tf
verwendeten Variablen
outputs.tf
- enthält die Ausgaben der in main.tf
erstellten Ressourcen
versions.tf
- enthält die Versionsanforderungen für Terraform und Provider
Es ist einfacher und schneller, mit einer kleineren Anzahl von Ressourcen zu arbeiten
terraform plan
und terraform apply
machen beide Cloud-API-Aufrufe, um den Status der Ressourcen zu überprüfen
Wenn Sie Ihre gesamte Infrastruktur in einer einzigen Komposition haben, kann dies einige Zeit dauern
Der Blast-Radius ("Explosionsradius") ist kleiner mit weniger Ressourcen
Die Isolierung nicht zusammenhängender Ressourcen voneinander, indem sie in getrennten Kompositionen untergebracht werden, verringert das Risiko, wenn etwas schief geht.
Beginnen Sie Ihr Projekt mit einem Remote-Status, denn:
Ihr Laptop ist kein Ort für Ihre Infrastruktur als "Quelle der Wahrheit"
Die Verwaltung einer tfstate
-Datei in Git ist ein Alptraum
Später, wenn die Infrastrukturebenen in verschiedene Richtungen wachsen (Anzahl der Abhängigkeiten oder Ressourcen), wird es einfacher sein, die Dinge unter Kontrolle zu halten
Wie prozeduraler Code sollte auch Terraform-Code so geschrieben werden, dass ihn Entwickler gut lesen können; Konsistenz ist hilfreich, wenn sechs Monaten später Änderungen vorgenommen werden müssen
Es ist möglich, Ressourcen innerhalb der Terraform-Statusdatei zu verschieben, aber es kann schwieriger sein, wenn Sie eine inkonsistente Struktur und Namenskonvention haben
Halten Sie die Ressourcenmodule so einfach wie möglich
Geben Sie keine Werte fest ein, die als Variablen übergeben oder über Datenquellen ermittelt werden können
Verwenden Sie Datenquellen und terraform_remote_state
speziell als Verbindung zwischen Infrastrukturmodulen innerhalb der Komposition
In diesem Buch sind die Beispielprojekte nach Komplexität gruppiert - von kleinen bis zu sehr großen Infrastrukturen. Diese Trennung ist nicht strikt, probieren Sie daher auch Strukturen.
Eine kleine Infrastruktur bedeutet, dass es nur eine geringe Anzahl von Abhängigkeiten und wenige Ressourcen gibt. Wenn das Projekt wächst, wird die Notwendigkeit deutlich, die Ausführung von Terraform-Konfigurationen zu verketten, verschiedene Infrastrukturmodule zu verbinden und Werte innerhalb einer Komposition zu übergeben.
Es gibt mindestens 5 verschiedene Gruppen von Orchestrierungslösungen, die Entwickler verwenden:
Nur Terraform. Sehr einfach, Entwickler müssen nur Terraform kennen, um die Arbeit zu erledigen.
Terragrunt. Ein reines Orchestrierungstool, mit dem die gesamte Infrastruktur orchestriert und Abhängigkeiten gehandhabt werden können. Terragrunt arbeitet nativ mit Infrastrukturmodulen und Kompositionen und reduziert so die Duplizierung von Code.
Interne Skripte. Dies geschieht oft als Ausgangspunkt für die Orchestrierung und bevor Terragrunt entdeckt wird.
Ansible oder ein ähnliches Allzweck-Automatisierungswerkzeug. Wird normalerweise verwendet, wenn Terraform nach Ansible eingeführt wird oder wenn die Ansible UI aktiv genutzt wird.
Vor diesem Hintergrund werden in diesem Buch die ersten beiden dieser Projektstrukturen, Terraform only und Terragrunt, vorgestellt.
Dieses Beispiel enthält Code als Beispiel für die Strukturierung von Terraform-Konfigurationen für eine groß angelegte Infrastruktur, dazu werden verwendet:
2 AWS-Konten
2 Regionen
2 separate Umgebungen (prod
und stage
, die sich nichts teilen). Jede Umgebung befindet sich in einem separaten AWS-Konto und verteilt die Ressourcen auf 2 Regionen.
Jede Umgebung verwendet die gleiche Version eines internen Moduls modules/network
, da es aus einem lokalen Verzeichnis stammt.
Perfekt für Projekte, bei denen die Infrastruktur logisch getrennt ist (separate AWS-Konten)
Gut, wenn keine Notwendigkeit besteht, zwischen AWS-Konten geteilte Ressourcen zu ändern (eine Umgebung = ein AWS-Konto = eine Statusdatei)
Gut, wenn kein Bedarf an der Orchestrierung von Änderungen zwischen den Umgebungen besteht
Gut, wenn die Infrastrukturressourcen pro Umgebung absichtlich unterschiedlich sind und nicht verallgemeinert werden können (z. B. sind einige Ressourcen in einer Umgebung oder in einigen Regionen nicht vorhanden)
Je größer das Projekt wird, desto schwieriger wird es, diese Umgebungen untereinander auf dem neuesten Stand zu halten. Erwägen Sie den Einsatz von Infrastrukturmodulen (von der Stange oder intern) für wiederholbare Aufgaben.
Dieses Beispiel enthält Code als Beispiel für die Strukturierung von Terraform-Konfigurationen für eine mittelgroße Infrastruktur, dazu werden verwendet:
2 AWS-Konten
2 separate Umgebungen (prod
und stage
, die sich nichts teilen). Jede Umgebung befindet sich in einem separaten AWS-Konto.
Jede Umgebung verwendet die gleiche Version eines internen Moduls modules/network
, da es aus einem lokalen Verzeichnis stammt.
Perfekt für Projekte, bei denen die Infrastruktur logisch getrennt ist (separate AWS-Konten)
Gut, wenn keine Notwendigkeit besteht, zwischen AWS-Konten geteilte Ressourcen zu ändern (eine Umgebung = ein AWS-Konto = eine Statusdatei)
Gut, wenn kein Bedarf an der Orchestrierung von Änderungen zwischen den Umgebungen besteht
Gut, wenn die Infrastrukturressourcen pro Umgebung absichtlich unterschiedlich sind und nicht verallgemeinert werden können (z. B. sind einige Ressourcen in einer Umgebung oder in einigen Regionen nicht vorhanden)
Je größer das Projekt wird, desto schwieriger wird es, diese Umgebungen untereinander auf dem neuesten Stand zu halten. Erwägen Sie den Einsatz von Infrastrukturmodulen (von der Stange oder intern) für wiederholbare Aufgaben.
Logische Provider arbeiten vollständig innerhalb der Terraform-Logik und interagieren sehr oft nicht mit anderen Diensten, so dass wir ihre Komplexität als O(1) betrachten können. Zu den häufigsten logischen Providern gehören , , , und .
terraform.tfvars
sollte nur in der verwendet werden.
Vergewissern Sie sich, dass Sie die grundlegenden Konzepte - , und - verstehen, da sie in den folgenden Beispielen verwendet werden.
Achten Sie auf eine einheitliche Struktur und :
und andere Kubernetes-inspirierte Lösungen. Manchmal ist es sinnvoll, das Kubernetes-Ökosystem zu nutzen und eine Reconciliation-Schleife einzusetzen, um den gewünschten Zustand Ihrer Terraform-Konfigurationen zu erreichen. Sehen Sie sich das Video für weitere Informationen an.
Beispiele für Codestrukturen für oder finden Sie im nächsten Kapitel.
Typ | Beschreibung | Einsatzbereitschaft |
---|
Typ | Beschreibung | Einsatzbereitschaft |
---|
Quellcode:
Jede Umgebung verwendet eine andere Version des Standard-Infrastrukturmoduls (alb
), das aus der stammt.
In einem großen Projekt wie dem hier beschriebenen werden die Vorteile der Verwendung von Terragrunt sehr deutlich. Siehe .
Quellcode:
Jede Umgebung verwendet eine andere Version des Standard-Infrastrukturmoduls (alb
), das aus der stammt.
mittel | Mehrere AWS-Konten und Umgebungen, handelsübliche Infrastrukturmodule, Kompositionsmuster mit Terragrunt. | Nein |
groß | Many AWS accounts, many regions, urgent need to reduce copy-paste, custom infrastructure modules, heavy usage of compositions. Using Terragrunt. Viele AWS-Konten, viele Regionen. Dringender Bedarf, Copy-Paste zu reduzieren, benutzerdefinierte Infrastrukturmodule, starke Nutzung von Kompositionen. Verwendung von Terragrunt. | Nein |
sehr groß | Mehrere Anbieter (AWS, GCP, Azure). Multi-Cloud-Einsätze. Verwendung von Terragrunt. | Nein |
Beispiele und Terraform-Module sollten eine Dokumentation enthalten, in der die Funktionen und deren Verwendung erklärt werden.
Alle Links in README.md-Dateien sollten absolut sein, damit die Terraform Registry Website sie korrekt anzeigt.
Die Dokumentation kann mit mermaid erstellte Diagramme und mit cloudcraft.co erstellte Blueprints enthalten.
Verwenden Sie Terraform Pre-Commit Hooks, um sicherzustellen, dass der Code gültig, richtig formatiert und automatisch dokumentiert ist, bevor er nach Git gepusht und von Menschen überprüft wird.
pre-commit ist ein Framework für die Verwaltung und Pflege von Pre-Commit-Hooks für mehrere Programmiersprachen. Es ist in Python geschrieben und ist ein leistungsfähiges Werkzeug, um auf dem Rechner eines Entwicklers automatisch etwas zu tun, bevor der Code in ein Git-Repository übertragen wird. Normalerweise wird es verwendet, um Linter auszuführen und Code zu formatieren (siehe unterstützte Hooks).
Mit Terraform-Konfigurationen kann pre-commit
verwendet werden, um Code zu formatieren und zu validieren, sowie um die Dokumentation zu aktualisieren.
Schauen Sie sich das pre-commit-terraform Repository an, um sich damit vertraut zu machen, sowie bestehende Repositories (z.B. terraform-aws-vpc), in denen dies bereits verwendet wird.
terraform-docs ist ein Werkzeug, das die Dokumentation von Terraform-Modulen in verschiedenen Ausgabeformaten erzeugt. Sie können es manuell ausführen (ohne pre-commit hooks), oder pre-commit-terraform hooks verwenden, um die Dokumentation automatisch zu aktualisieren.
@todo: Document module versions, release, GH actions
CAST AI — Cut your Kubernetes costs by 60%+ on average. First cluster optimization FREE!
Speakeasy — Terraform Providers, SDKs and docs for your API. Make your API enterprise-ready!
Wenige Ressourcen, keine externen Abhängigkeiten. Ein AWS-Konto. Eine Region. Eine Umgebung. | Ja |