Konwencje nazewnictwa
Podstawowe zasady
Nie ma powodu, aby nie przestrzegać przynajmniej poniższych zasad :)
Pamiętaj, że rzeczywiste zasoby często mają ograniczenia w dopuszczalnym nazewnictwie. Niektóre zasoby, na przykład nie mogą zawierać myślników. Inne zaś muszą być napisane z wykorzystaniem camelCase. Konwencje zawarte w tej książce odnoszą się tylko do samych nazw Terraform.
Wszędzie używaj
_
(podkreślenia) zamiast-
(myślnika) (nazwy zasobów, nazwy źródeł danych, nazwy zmiennych, dane wyjściowe itp.).Staraj się używać małych liter i cyfr (nawet jeśli obsługiwany jest kod UTF-8).
Zasoby i źródła danych
Nie powtarzaj typu zasobu w nazwie zasobu (ani częściowo, ani całkowicie):
resource "aws_route_table" "public" {}
resource "aws_route_table" "public_route_table" {}
resource "aws_route_table" "public_aws_route_table" {}
Nazwa zasobu powinna nazywać się
this
, jeśli nie ma bardziej opisowej i ogólnej nazwy, lub jeśli moduł zasobów tworzy pojedynczy zasób tego typu (np. w module AWS VPC jest pojedynczy zasób typuaws_nat_gateway
i wiele zasobów typuaws_route_table
, więcaws_nat_gateway
powinien nazywać sięthis
, aaws_route_table
powinny być nazwane opisowe - jakprivate
,public
,database
.Nazwy zawsze powinny być rzeczownikami w liczbie pojedynczej.
Używaj
-
wewnątrz wartości argumentów oraz w miejscach, w których wartość będą odczytywane przez człowiekowa (np. wewnątrz nazwy DNS instancji RDS).Argumenty
count
lubfor_each
umieszczaj wewnątrz bloku zasobu lub źródła danych jako pierwszy argument u góry i oddzielaj go znakiem nowej linii.Argument
tags
, jeśli jest obsługiwany przez zasób, umieszczaj jako ostatni , po którym następujedepend_on
ilifecycle
, jeśli to konieczne. Wszystkie te elementy powinny być oddzielone pojedynczym pustym wierszem.Używając warunków logicznych przy argumencie
count
lubfor_each
stosuj wartości logiczne zamiast porównywania długości ciągu czy innych wyrażeń.
Przykładowy kod zasobu (resource
)
resource
)Użycie count
/ for_each
count
/ for_each
Umiejscowienie tags
tags
Warunki w count
count
Zmienne
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.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.
Używaj liczby mnogiej w nazwie zmiennej, gdy jest ona listą (
list(...)
) lub mapą (map(...)
) .Uporządkuj klucze w bloku zmiennych w następujący sposób: opis (
description
), typ (type
), wartość domyślna (default
), walidacja (validation
).Zawsze dołączaj opis (
description
) do wszystkich zmiennych, nawet jeśli uważasz, że jest to oczywiste (przyda się w przyszłości).Używaj prostych typów (
number
,string
,list(...)
,map(...)
,any
) zamiast określonego typu, takiego jakobject()
, chyba że musisz mieć ścisłą kontrolę nad każdym elementem.Użyj określonych typów, np.
map(map(string))
jeśli wszystkie elementy mapy mają ten sam typ (np.string
) lub mogą być na niego przekonwertowane (np. typnumber
można przekonwertować nastring
).Użyj
any
, aby ominąć walidację typu, gdy chcesz obsłużyć różne typy..Wartość
{}
to czasami mapa, a czasami obiekt. Użyjtomap(...)
, aby stworzyć mapę, ponieważ nie ma możliwości stworzenia obiektu.
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).
Nazwa danych wyjściowych powinna opisywać właściwość, którą zawiera, i być bardziej ścisła niż standardowo.
Dobra struktura nazwy wyjścia wygląda tak:
{name}_{type}_{attribute}
, gdzie:{name}
to nazwa zasobu lub źródła danych bez prefiksu dostawcy.{name}
dlaaws_subnet
tosubnet
, a dlaaws_vpc
tovpc
.{type}
to rodzaj źródła zasobów.{attribute}
to zwracany atrybut
Jeśli zwracana jest wartość z funkcjami interpolacji i wieloma zasobami,
{name}
i{type}
powinny być jak najbardziej ogólne (należy unikać prefiksuthis
). Zobacz przykłady.Jeśli zwracana wartość jest listą, powinna mieć nazwę w liczbie mnogiej. Zobacz przykłady.
Zawsze dołączaj opis (
description
) danych wyjściowych, nawet jeśli uważasz, że jest to oczywiste.Unikaj użycia
sensitive
, chyba że w pełni kontrolujesz użycie tego wyjścia (danych wyjściowych) we wszystkich miejscach i we wszystkich modułach.Stosuj
try()
(dostępne od Terraform 0.13) zamiastelement(concat(...))
(podejście starsze dla wersji przed 0.13)
Przykłady poprawnego output
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
Last updated