Pytania dotyczące struktury kodu są zdecydowanie najczęściej zadawanymi w społeczności Terraform. W pewnym momencie każdy zaczyna się zastanawiać co dla projektu będzie najlepsze.

Jak powinienem uporządkować moje konfiguracje Terraform?

To jedno z pytań, na które jest wiele odpowiedzi, lecz bardzo trudno jest udzielić uniwersalnych porad, więc postarajmy się zacząć od zrozumienia z czym mamy do czynienia.

• Jaka jest złożoność Twojego projektu?

  • Liczba powiązanych zasobów

  • Liczba użytych dostawców Terraform (uwaga — patrz poniżej na temat „dostawców logicznych” (logical providers))

• Jak często zmienia się Twoja infrastruktura?

  • Zaczynając od raz w miesiącu/tygodniu/codziennie

  • Skończywszy na ciągłym (za każdym razem, gdy pojawia się nowa zmiana (commit))

• Kto lub co zmienia kod? Czy pozwalasz serwerowi CI aktualizować repozytorium po zbudowaniu nowego artefaktu?

  • Tylko programiści mogą wysyłać kod do repozytorium infrastruktury

  • Każdy może proponować zmiany, otwierając pull-requesty (w tym automatyczne zadania uruchomione na serwerze CI)

• Z jakiej platformy lub usługi wdrożeniowej korzystasz?

  • AWS CodeDeploy, Kubernetes czy OpenShift wymagają nieco innych podejść

• Jak grupowane są środowiska?

  • Według środowiska, regionu, projektu

Rozpoczęcie pracy z odpowiednim podejściem do struktury projektu w Terraform

Umieszczenie całego kodu w pliku main.tf jest dobrym pomysłem, jeśli dopiero zaczynasz swoją przygodę z Terraform lub piszesz testowy kod, aby coś zweryfikować. We wszystkich innych przypadkach lepiej będzie mieć kilka plików podzielonych logicznie w następujący sposób:

• main.tf — wywoływanie modułów, zmienny lokalnych i źródeł danych w celu utworzenia wszystkich zasobów

• variables.tf — zawiera deklaracje zmiennych używanych w main.tf

• outputs.tf — zawiera dane wyjściowe z zasobów utworzonych w

Plik terraform.tfvars nie powinien być używany poza .

Jak myśleć o strukturze konfiguracji Terraform?

Popularne wskazówki dotyczące strukturyzowania kodu

• Łatwiej i szybciej pracuje się z mniejszą liczbą zasobów

  • komendy terraform plan i terraform apply wykonują wywołania API, aby zweryfikować status zasobów

  • Jeśli masz całą infrastrukturę w jednej kompozycji, może to zająć trochę czasu

W tej książce przykładowe projekty są pogrupowane według złożoności — od małych do bardzo dużych infrastruktur. Ten podział nie jest ścisły, więc sprawdź, jak robią to inni.

Orkiestracja modułów i kompozycji infrastruktury

Posiadanie małej infrastruktury oznacza, że istnieje niewielka liczba zależności i niewiele zasobów. Wraz z rozwojem projektu pojawia się potrzeba łączenia wykonywania konfiguracji Terraform. Łączenia różnych modułów infrastruktury i przekazywanie wartości w ramach kompozycji staje się oczywistym następstwem.

Istnieje co najmniej 5 odrębnych grup rozwiązań do orkiestracji, z których korzystają programiści_stki:

1. Czysty Terraform. Bardzo proste rozwiązanie. Programiści_stki muszą znać tylko Terraform, aby wykonać zadanie.

2. Terragrunt. Narzędzie, którego można użyć do orkiestracji całej infrastruktury, a także obsługi zależności. Terragrunt działa natywnie z modułami infrastruktury i kompozycjami, dzięki czemu ogranicza powielanie kodu.

3. Skrypty wewnętrzne. Często używane jako punkt startowy do używania orkiestracji oraz przed odkryciem Terragrunt.

Mając to wszystko na uwadze — ta książka zawiera przegląd pierwszych dwóch z struktur projektowych — tylko Terraform i Terragrunt.

Zobacz przykłady struktur kodu dla lub w następnym rozdziale.

Istnieją też warsztaty dla osób, które chcą przećwiczyć niektóre z zagadnień opisanych w tej książce.

Znajdziesz je tutaj: https://github.com/antonbabenko/terraform-best-practices-workshop

Ź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

• Każde środowisko używa tej samej wersji modułów/sieci (modules/network) modułu wewnętrznego, ponieważ pochodzi z katalogu lokalnego.

to dość nowy projekt (jak większość narzędzi DevOps), który zaistniał w 2014 roku.

Terraform jest potężnym (jeśli nie najpotężniejszym) i jednym z najczęściej używanych narzędzi, który umożliwia zarządzanie infrastrukturą jako kodem. Pozwala programistom_ką rozwiązywać wiele różnych problemów infrastrukturalnych tak, aby dało się to dalej łatwo wspierać, integrować i rozwijać.

Niektóre informacje opisane w tej książce mogą wydawać się nieoptymalnymi praktykami. Jestem tego świadom. Czasem zachodzi potrzeba pomocy czytelnikom_czkom w oddzieleniu tego, co jest powszechnie znanymi najlepszymi praktykami, a co jest po prostu kolejnym subiektywnym sposobem robienia rzeczy. Używam wtedy wskazówek, aby zapewnić kontekst oraz ikony, które określają poziom trudności w każdej podsekcji dotyczącej najlepszych praktyk.

Historia tej książki rozpoczęła się w słonecznym Madrycie w 2018 roku i jest dostępna za darmo pod tym linkiem -

Kilka lat później został on zaktualizowany o najnowsze zalecane praktyki dostępne w Terraform 1.0. Ostatecznie — ta książka powinna zawierać większość praktyk i zaleceń dla użytkowników Terraform, które można uznać za bezdyskusyjnie najlepsze.

Struktura kodu Terraform

Struktura kodu Terragrunt

Źródło:

Ten przykład zawiera kod dla strukturyzacji konfiguracji Terraform dla dużego rozmiaru infrastruktury, która zawiera:

• 2 konta AWS

• 2 regiony

Źródło:

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.

Oficjalna dokumentacja Terraforma szczegółowo . Przeczytaj ją uważnie, aby zrozumieć resztę tej sekcji.

Ta sekcja opisuje kluczowe pojęcia, które są używane w książce.

Zasób (resource)

Przykładowe zasoby to aws_vpc, aws_db_instance, itd. Zasób należy do dostawcy (provider), może przyjmować argumenty (parameters) oraz zwracać różne atrybuty (outputs) i ma swój cykl życia (lifecycle). Może on być tworzony, pobierany, aktualizowany i usuwany.

Jakich narzędzi muszę używać?

• - narzędzie do orkiestracji

Użyj zmiennych lokalnych (locals), aby określić jawne zależności między zasobami

Przydatny sposób na wskazanie Terraform, że niektóre zasoby powinny zostać usunięte wcześniej, nawet jeśli nie ma bezpośredniej zależności w konfiguracjach.

https://twitter.com/antonbabenko/lists/terraform-experts - Lista osób, które bardzo aktywnie współpracują z Terraformem i mogą Ci wiele powiedzieć (jeśli ich zapytasz).

https://github.com/shuaibiyy/awesome-terraform - Wyselekcjonowana lista zasobów o Terraform.

http://bit.ly/terraform-youtube - Kanał YouTube Antona Babenko „Twoja Tygodniowa Dawka Terraformu” ("Your Weekly Dose of Terraform"). Na livestreamy z recenzjami, wywiadami, Q&A, kodowaniem na żywo i hackowaniem przy pomocy Terraform.

https://weekly.tf - cotygodniowy biuletyn Terraform. Różne wiadomości ze świata Terraform (projekty, ogłoszenia, dyskusje) zebrane w jednym miejscu przez Antona Babenko.

Dokumentacja

Dokumentacja generowana automatycznie

to framework do zarządzania i utrzymywania różnorodnych narzędzi do sprawdzania kodu przed jego wysłaniem do zdalnego repozytorium. Jest napisanym w Pythonie potężnym narzędziem do automatyzacji żmudnych czynności na maszynie programisty, zanim kod zostanie przekazany do repozytorium git. Zwykle jest używany do uruchamiania linterów i formatowania kodu (zobacz ).

Dzięki konfiguracjom Terraform pre-commit może służyć do formatowania i sprawdzania poprawności kodu, a także do aktualizowania dokumentacji.

Sprawdź . Zapoznaj się z nim oraz istniejącym repozytoriami (np. ), w których jest ono już używane.

terraform-docs

to narzędzie, które generuje dokumentację z modułów Terraform w różnych formatach wyjściowych. Możesz uruchomić go ręcznie (bez pre-commit hooków) lub użyć , aby automatycznie zaktualizować dokumentację.

Źródła

3. Post napisany przez :

Podstawowe zasady

1. Wszędzie używaj _ (podkreślenia) zamiast - (myślnika) (nazwy zasobów, nazwy źródeł danych, nazwy zmiennych, dane wyjściowe itp.).

2. Staraj się używać małych liter i cyfr (nawet jeśli obsługiwany jest kod UTF-8).

Zasoby i źródła danych

1. Nie powtarzaj typu zasobu w nazwie zasobu (ani częściowo, ani całkowicie):

   resource "aws_route_table" "public" {}

Przykładowy kod zasobu (resource)

Użycie count / for_each

Umiejscowienie tags

Warunki w count

Zmienne

1. Nie próbuj na nowo wymyślać koła w modułach zasobów: użyj nazwy (name), opisu (description) i wartości domyślnej (default) dla zmiennych zgodnie z definicją w sekcji „Odniesienie do argumentów” ("Argument Reference") dla zasobu, z którym pracujesz.

2. Obsługa walidacji w zmiennych jest raczej ograniczona (np. brak dostępu do innych zmiennych lub wyszukiwania). Zawczasu planuj odpowiednie użycie, ponieważ w wielu przypadkach funkcja walidacji jest bezużyteczna.

Dane wyjściowe

Spraw, aby dane wyjściowe były spójne i zrozumiałe poza zakresem użycia (scope) (gdy użytkownik korzysta z modułu, powinno być oczywiste, jaki jest typ i atrybut zwracanej wartości).

1. Nazwa danych wyjściowych powinna opisywać właściwość, którą zawiera, i być bardziej ścisła niż standardowo.

2. Dobra struktura nazwy wyjścia wygląda tak: {name}_{type}_{attribute} , gdzie:

   1. {name} to nazwa zasobu lub źródła danych bez prefiksu dostawcy. {name} dla

Przykłady poprawnego output

Zwróć co najwyżej jeden identyfikator security_group:

W przypadku posiadania wielu zasobów tego samego typu, należy unikać this w nazwie wyjścia:

Użyj nazwy w liczbie mnogiej, jeśli wartością zwracaną jest lista