Convenções de nomenclatura
Last updated
Last updated
Utilize _
(subtraço) ao invés do -
(traço) em todo o lugar (nomes de recursos, nomes de fontes de dados, nomes de variáveis, outputs, etc.).
Prefira usar letras minúsculas e números (mesmo que o UTF-8 seja suportado).
Não repita a categoria de recurso no nome do recurso (não parcialmente, nem completamente):
resource "aws_route_table" "public" {}
resource "aws_route_table" "public_route_table" {}
resource "aws_route_table" "public_aws_route_table" {}
O nome do recurso deve ser nomeado this
se não houver mais um nome descritivo e geral disponível ou se o módulo de recurso criar um único recurso desse tipo (por exemplo, no módulo há um único recurso do tipo aws_nat_gateway
e vários recursos do tupoaws_route_table
, então aws_nat_gateway
deve ser nomeado this
e aws_route_table
deve ter nomes mais descritivos - como private
, public
, database
).
Sempre utilize substantivos singulares para nomes.
Utilize -
em valores de argumentos e em locais onde o valor será exposto a um humano (por exemplo, no nome de DNS da instância RDS).
Inclua o(s) argumento(s) count
/ for_each
no bloco de recurso ou fonte de dados como o primeiro argumento na parte superior e separe por uma nova linha depois dele.
Inclua o argumento tags,
se suportadas pelo recurso, como o último argumento real, seguido por depends_on
e lifecycle
, se necessário. Estes devem ser separados por uma única linha vazia.
Ao utilizar condições em um argumento count
/ for_each
, prefira valores boleanos (true
/ false
) em vez de usar length
ou outras expressões.
resource
count
/ for_each
tags
count
Não reinvente a roda em módulos de recursos: use name
, description
, e valor default
para variáveis conforme definido na seção “Referência de argumento” para o recurso com o qual você está trabalhando.
O suporte para validação em variáveis é bastante limitado (por exemplo, não pode acessar outras variáveis ou fazer pesquisas). Planeje de acordo porque em muitos casos esse recurso é inútil.
Use a forma plural em um nome de variável quando o tipo for list(...)
ou map(...)
.
Chaves de ordem em um bloco variável como: description
, type
, default
, validation
.
Sempre inclua description
em todas as variáveis, mesmo que você julgue ser óbvio (você precisará disso, no futuro).
Prefira usar tipos simples (number
, string
, list(...)
, map(...)
, any
) sobre tipos específicos como object()
, a menos que você precise ter restrições estritas em cada chave.
Use tipos específicos como map(map(string))
se todos os elementos do mapa tiverem o mesmo tipo (ex. string
) ou podem ser convertidos para ele (ex. number
pode ser convertido para string
).
Use tipo any
para desabilitar a validação de tipo a partir de uma determinada profundidade ou quando vários tipos devem ser suportados.
O valor {}
às vezes é um mapa, mas às vezes é um objeto. Use tomap(...)
para criar um mapa porque não há como criar um objeto.
Torne os outputs consistentes e compreensíveis fora de seu escopo (quando um usuário está usando um módulo, deve ser óbvio que tipo e atributo do valor ele retorna).
O nome do output deve descrever a propriedade que ela contém e ser menos livre do que você normalmente desejaria.
Uma boa estrutura para o nome do output parece com {name}_{type}_{attribute}
, onde:
{name}
um nome de recurso ou fonte de dados sem um prefixo de provedor. O {name}
do aws_subnet
é subnet
, para oaws_vpc
é vpc
.
{type}
é um tipo de fontes de recursos.
{attribute}
é um atributo retornado pelo output.
Sempre inclua description
para todos os outputs mesmo que você julgue que ser óbvio.
Evite definir o argumento sensitive
, a menos que você controle totalmente o uso desse output em todos os locais em todos os módulos.
Prefira try()
(disponível desde o Terraform 0.13) ao invés de element(concat(...))
(abordagem herdada para a versão anterior a 0.13).
output
Retorne no máximo um ID do security-group
:
Quando há vários recursos do mesmo tipo, this
deve ser omisso no nome do output:
.
Se o output estiver retornando um valor com funções de interpolação e vários recursos, {name}
e {type}
devem ser o mais genéricos possível (this
como prefixo deve ser omisso). .
Se o valor retornado for uma lista, deve ter um nome no plural. .