APRENDER. PRATICAR. EVOLUIR.Observar a identidade em vez de contar objetos
O exemplo desta aula usa um mapa com reports e payments como chaves. Cada chave identifica uma instância terraform_data distinta no state. Depois de aplicar numa pasta nova, remove apenas reports e revê o plano. payments conserva o mesmo endereço e valor; reports fica proposto para remoção. Esta observação é específica dos atributos do exemplo. Uma alteração posterior ao valor de payments pode ainda provocar atualização ou substituição, conforme o tipo de recurso. Uma chave estável evita deslocações de identidade provocadas pela posição, mas não impede alterações funcionais nem substitui a leitura dos atributos propostos.
Comparar count, for_each e transformações de coleções
Com count e uma lista [reports,payments,funds], cada instância usa um índice. Se input depende de local.names[count.index], retirar reports desloca os valores dos índices zero e um, enquanto o índice dois desaparece. No laboratório terraform_data, isso produz duas atualizações e uma remoção. Não generalizes para todos os providers: certos atributos podem exigir substituição. for_each aceita mapas ou sets de strings e identifica instâncias pelas chaves ou elementos. toset elimina duplicados e não conserva a ordem da lista. Se duas entradas representam objetos diferentes, não as colapses acidentalmente numa única string ao escolher a identidade.
Separar chaves conhecidas de valores pendentes
Terraform precisa de identificar as instâncias durante o planeamento. Um set construído com um ID que só será criado no apply não fornece essa identidade antecipada. No laboratório, for_each=toset([terraform_data.upstream.id]) falha. Um mapa com chave primary conhecida e o ID como valor permite planear o endereço dependente; o valor continua pendente até poder ser obtido. Valores desconhecidos não são automaticamente inválidos em todos os argumentos. Distingue a identidade necessária para expandir o grafo do dado consumido mais tarde. Além disso, não uses passwords como chaves: os identificadores aparecem na apresentação dos endereços e precisam de ser não secretos.
Declarar uma mudança de endereço
Se reports passar a reporting, Terraform vê endereços diferentes. Quando a intenção é conservar o mesmo objeto, declara um moved entre os endereços antigo e novo e inspeciona o plano. No laboratório, renomear legacy para current com a declaração adequada mantém o objeto e atualiza a associação após apply. Outras alterações ao mesmo recurso continuam sujeitas às suas semânticas; moved não anula toda a mudança funcional. Em módulos publicados, conserva percursos de migração necessários a consumidores que saltam versões. Remover um moved cedo demais pode retirar a informação necessária à atualização de um state antigo e provocar criação e destruição não pretendidas.
Interfaces de módulos e dependências proporcionais
Um módulo filho publica um resultado através de output. O root pode consumi-lo como module.service.endpoint e expô-lo novamente num output próprio. Os locals internos do filho não ficam automaticamente acessíveis ao chamador. Referências úteis também expressam relações no grafo. Um depends_on aplicado a um módulo inteiro pode tornar mais valores desconhecidos durante o plano quando existe uma alteração a montante. Antes de adicionar ou retirar a relação, identifica a dependência real: referências específicas são preferíveis quando representam corretamente a necessidade. Remover dependências para obter um plano visualmente mais simples pode permitir uma ordem de execução incorreta.
Distinguir remoção, destruição e transferência de gestão
Um removed com destroy=false pede que Terraform deixe de gerir o objeto nesse state sem solicitar destruição. No laboratório, a ação aparece como forget e a associação local desaparece depois de apply. Como terraform_data não representa uma infraestrutura remota, esse teste não demonstra sobrevivência de um servidor ou migração para outra equipa. Numa transferência real, identifica destino, responsável, método de adoção, dependências e momento de passagem. Evita dois states a tentar gerir o mesmo objeto em simultâneo ou uma lacuna sem responsável. Retirar uma associação não cria automaticamente outra, e um backup de state não substitui uma cópia dos dados da aplicação.
terraform {
required_version = "~> 1.12.0"
}
locals {
records = {
reports = "r"
payments = "p"
}
}
resource "terraform_data" "entry" {
for_each = local.records
input = each.value
}
Aplica o mapa numa pasta nova, remove reports e observa payments sem alteração. Depois renomeia payments para settlement e compara planos com e sem moved entre os endereços completos.
Armadilhas comuns
Usar posição como identidade duradoura sem avaliar deslocações; escolher IDs desconhecidos como chaves; expor segredos em endereços; retirar moved cedo; confundir forget com migração concluída.
Tópicos relacionados: Módulos e contratos · Gestão de state
Uma mudança de nome, de posição e de gestão tem efeitos diferentes. Preserva a correspondência entre intenção, endereço e objeto, e confirma cada passagem com um plano revisto.
Referência: Refactor modules · 004