Konwencje nazewnictwa
Podstawowe zasady
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_gatewayi wiele zasobów typuaws_route_table, więcaws_nat_gatewaypowinien nazywać sięthis, aaws_route_tablepowinny 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
countlubfor_eachumieszczaj 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_onilifecycle, jeśli to konieczne. Wszystkie te elementy powinny być oddzielone pojedynczym pustym wierszem.Używając warunków logicznych przy argumencie
countlubfor_eachstosuj 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_eachresource "aws_route_table" "public" {
count = 2
vpc_id = "vpc-12345678"
# ... w celu uproszczenia pomijamy pozostałe argumenty
}
resource "aws_route_table" "private" {
for_each = toset(["one", "two"])
vpc_id = "vpc-12345678"
# ... w celu uproszczenia pomijamy pozostałe argumenty
}resource "aws_route_table" "public" {
vpc_id = "vpc-12345678"
count = 2
# ... w celu uproszczenia pomijamy pozostałe argumenty
}Umiejscowienie tags
tagsresource "aws_nat_gateway" "this" {
count = 2
allocation_id = "..."
subnet_id = "..."
tags = {
Name = "..."
}
depends_on = [aws_internet_gateway.this]
lifecycle {
create_before_destroy = true
}
} resource "aws_nat_gateway" "this" {
count = 2
tags = "..."
depends_on = [aws_internet_gateway.this]
lifecycle {
create_before_destroy = true
}
allocation_id = "..."
subnet_id = "..."
}Warunki w count
countresource "aws_nat_gateway" "that" { # Best
count = var.create_public_subnets ? 1 : 0
}
resource "aws_nat_gateway" "this" { # Good
count = length(var.public_subnets) > 0 ? 1 : 0
}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. typnumbermoż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_subnettosubnet, a dlaaws_vpctovpc.{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
outputZwróć co najwyżej jeden identyfikator security_group:
output "security_group_id" {
description = "The ID of the security group"
value = try(aws_security_group.this[0].id, aws_security_group.name_prefix[0].id, "")
}W przypadku posiadania wielu zasobów tego samego typu, należy unikać this w nazwie wyjścia:
output "this_security_group_id" {
description = "The ID of the security group"
value = element(concat(coalescelist(aws_security_group.this.*.id, aws_security_group.web.*.id), [""]), 0)
}Użyj nazwy w liczbie mnogiej, jeśli wartością zwracaną jest lista
output "rds_cluster_instance_endpoints" {
description = "A list of all cluster instance endpoints"
value = aws_rds_cluster_instance.this.*.endpoint
}Last updated