Źródło: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
Ten przykład zawiera kod dla strukturyzacji konfiguracji Terraform dla średniego rozmiaru infrastruktury, która zawiera:
2 konta AWS
2 oddzielne środowiska (prod
i stage
, które nic ze sobą nie dzielą). Każde środowisko funkcjonuje na osobnym koncie AWS
Każde środowisko korzysta z innej wersji gotowego modułu infrastruktury (alb
) pochodzącego z Terraform Registry
Każde środowisko używa tej samej wersji modułów/sieci (modules/network
) modułu wewnętrznego, ponieważ pochodzi z katalogu lokalnego.
Idealny dla projektów, w których infrastruktura jest logicznie odseparowana (osobne konta AWS)
Dobre, gdy nie ma potrzeby modyfikowania zasobów współdzielonych między kontami AWS (jedno środowisko = jedno konto AWS = jeden plik stanu)
Dobre, gdy nie ma potrzeby organizowania zmian między środowiskami
Dobre, gdy zasoby infrastruktury są celowo różne w zależności od środowiska i nie można ich uogólniać (np. niektóre zasoby są nieobecne w jednym środowisku lub w niektórych regionach)
W miarę rozwoju projektu coraz trudniej będzie zapewnić wzajemną aktualność tych środowisk. Rozważ użycie modułów infrastruktury (gotowych lub wewnętrznych) do powtarzalnych zadań.
Źródło: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
Ten przykład zawiera kod dla strukturyzacji konfiguracji Terraform dla małego rozmiaru infrastruktury, w której nie są używane zależności zewnętrzne.
Idealny na początek i gdy refaktoryzacja na bieżąco jest możliwa
Idealny do modułów z małymi zasobami
Dobry dla małych i liniowych modułów infrastruktury (np. terraform-aws-atlantis)
Dobry dla małej liczby zasobów (mniej niż 20-30)
Plik jednego stanu dla wszystkich zasobów może spowolnić proces pracy z Terraform. Jeśli liczba zasobów rośnie, rozważ użycie argumentu -target
, aby je ograniczyć.
Ten przykład zawiera kod dla strukturyzacji konfiguracji Terraform dla dużego rozmiaru infrastruktury, która zawiera:
2 konta AWS
2 regiony
2 oddzielne środowiska (prod
i stage
, które nic ze sobą nie dzielą). Każde środowisko funkcjonuje na osobnym koncie AWS
Każde środowisko używa tej samej wersji modułów/sieci (modules/network
) modułu wewnętrznego, ponieważ pochodzi z katalogu lokalnego.
Idealny dla projektów, w których infrastruktura jest logicznie odseparowana (osobne konta AWS)
Dobre, gdy nie ma potrzeby modyfikowania zasobów współdzielonych między kontami AWS (jedno środowisko = jedno konto AWS = jeden plik stanu)
Dobre, gdy nie ma potrzeby organizowania zmian między środowiskami
Dobre, gdy zasoby infrastruktury są celowo różne w zależności od środowiska i nie można ich uogólniać (np. niektóre zasoby są nieobecne w jednym środowisku lub w niektórych regionach)
W miarę rozwoju projektu coraz trudniej będzie zapewnić wzajemną aktualność tych środowisk. Rozważ użycie modułów infrastruktury (gotowych lub wewnętrznych) do powtarzalnych zadań.
Źródło:
Każde środowisko korzysta z innej wersji gotowego modułu infrastruktury (alb
) pochodzącego z
W dużych projektach, takich jak przedstawiono tutaj, korzyści z użycia Terragrunt stają się bardzo widoczne. Spójrz na .
Type | Description | Gotowość |
---|---|---|
Typ | Opis | Gotowość |
---|---|---|
Mało zasobów, żadnych zewnętrznych zależności. Pojedyncze konto AWS. Tylko jeden region. Jedno środowisko.
Tak
Kilka kont i środowisk AWS. Korzystanie z gotowych modułów infrastruktury Terraform. Wykorzystanie Terraform.
Tak
Wiele kont AWS, wiele regionów, pilna potrzeba ograniczenia kopiowania i wklejania, niestandardowe moduły infrastruktury, intensywne użycie kompozycji. Wykorzystanie Terraform.
WIP
bardzo duża
Kilku dostawców (AWS, GCP, Azure). Wdrożenia w wielu chmurach. Wykorzystanie Terraform.
Nie
średnia
Kilka kont i środowisk AWS. Korzystanie z gotowych modułów infrastruktury. Wykorzystanie Terragrunt.
Nie
duża
Wiele kont AWS, wiele regionów, pilna potrzeba ograniczenia kopiowania i wklejania, niestandardowe moduły infrastruktury, intensywne użycie kompozycji. Wykorzystanie Terragrunt.
Nie
bardzo duża
Kilku dostawców (AWS, GCP, Azure). Wdrożenia w wielu chmurach. Wykorzystanie Terragrunt.
Nie