Typ | Beschreibung | Einsatzbereitschaft |
---|---|---|
Typ | Beschreibung | Einsatzbereitschaft |
---|---|---|
Wenige Ressourcen, keine externen Abhängigkeiten. Ein AWS-Konto. Eine Region. Eine Umgebung.
Ja
Mehrere AWS-Konten und Umgebungen, handelsübliche Infrastrukturmodule mit Terraform.
Ja
Viele AWS-Konten, viele Regionen. Dringender Bedarf, Copy-Paste zu reduzieren, benutzerdefinierte Infrastrukturmodule, starke Nutzung von Compositions. Verwendung von Terraform.
In Arbeit
sehr groß
Mehrere Anbieter (AWS, GCP, Azure). Multi-Cloud-Einsatz. Verwendung von Terraform.
Nein
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
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.
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.
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 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:
Jede Umgebung verwendet eine andere Version des Standard-Infrastrukturmoduls (alb
), das aus der stammt.
Quellcode:
Gut für kleine und lineare Infrastrukturmodule (z.B. )