Quellcode: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
Dieses Beispiel enthält Code als Beispiel für die Strukturierung von Terraform-Konfigurationen für eine kleine Infrastruktur, in der keine externen Abhängigkeiten verwendet werden.
Perfekt für den Einstieg und zum Refactoring im laufenden Betrieb
Perfekt für kleine Ressourcenmodule
Gut für kleine und lineare Infrastrukturmodule (z.B. terraform-aws-atlantis)
Gut geeignet für eine kleine Anzahl von Ressourcen (weniger als 20-30)
Eine einzige Statusdatei für alle Ressourcen kann den Arbeitsprozess mit Terraform verlangsamen, wenn die Anzahl der Ressourcen wächst (erwägen Sie die Verwendung des Arguments -target
, um die Anzahl der Ressourcen zu begrenzen)
Quellcode: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
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 eine andere Version des Standard-Infrastrukturmoduls (alb
), das aus der Terraform-Registry stammt.
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.
Quellcode: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
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 eine andere Version des Standard-Infrastrukturmoduls (alb
), das aus der Terraform-Registry stammt.
Jede Umgebung verwendet die gleiche Version eines internen Moduls modules/network
, da es aus einem lokalen Verzeichnis stammt.
In einem großen Projekt wie dem hier beschriebenen werden die Vorteile der Verwendung von Terragrunt sehr deutlich. Siehe Beispiele für Code-Strukturen mit Terragrunt.
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.