APRENDER. PRATICAR. EVOLUIR.Preparar uma experiência delimitada
A tarefa desta aula é reorganizar a configuração de um serviço fictício de liquidação sem perder a associação com o objeto gerido. Antes de discutir comandos, escreve três invariantes: o objeto pretendido mantém a identidade, o plano não inclui uma substituição não autorizada e existe um único responsável pela operação. O laboratório usa Terraform 1.16.5, o recurso integrado terraform_data e state local num diretório temporário novo. Não existem providers externos, cloud, provisioners ou credenciais. O recurso guarda valores para observar o ciclo de vida; não representa uma base de dados ou um serviço disponível. Esta escolha permite observar endereços e ações sem introduzir efeitos sobre infraestrutura real.
Observar o plano antes de corrigir
Começa com resource "terraform_data" "ledger" { input = "settlement-v1" }. No diretório isolado, executa init, validate e apply. Regista o endereço e o ID através de show -json, sem publicar o state completo. Depois muda apenas ledger para settlement e guarda um plano com plan -out=rename.plan. O laboratório observou delete para terraform_data.ledger e create para terraform_data.settlement. Não aplicou esse plano. Explica a um colega por que motivo o mesmo input não demonstra que Terraform deve conservar a identidade: faltou comunicar a relação entre endereços. Este exercício negativo é útil porque mostra o efeito antes de acrescentar o mecanismo de correção.
Mapear e confirmar a identidade
Acrescenta um bloco moved com from = terraform_data.ledger e to = terraform_data.settlement. Gera um novo plano, move.plan, e analisa-o com show -json move.plan. No laboratório, previous_address identificou ledger e actions apresentou no-op para settlement. Depois de aplicar exatamente move.plan, o endereço mudou e o ID permaneceu igual. São duas observações diferentes: o plano descreve a proposta; o state posterior confirma a aplicação neste exemplo. Numa mudança real, revê também atributos que podem exigir substituição. Um moved correto não aprova alterações físicas adicionais. Se uma refatorização e um upgrade forem misturados, considera separá-los para tornar a decisão operacional compreensível.
Construir uma tabela de correspondência
Para passar de count a for_each, prepara uma tabela antes de editar código: endereço antigo, objeto observado, chave pretendida e responsável pela confirmação. No exercício, worker[0] corresponde a Lisboa e worker[1] a Paris; as novas chaves são lisbon e paris. A ordem alfabética das cidades não é prova da associação antiga. Confirma a correspondência e escreve os mapeamentos de cada instância. Se versões anteriores usavam a, depois b e agora c, inclui consumidores que saltam versões na revisão do histórico. Uma equipa que já está em b pode atualizar corretamente enquanto outra ainda em a fica sem caminho. A matriz de consumidores evita validar apenas o ambiente mais recente.
Retirar a gestão e organizar o handover
O segundo objetivo é deixar de gerir um objeto, mantendo-o sob responsabilidade definida. No laboratório, o resource foi substituído por removed com from = terraform_data.settlement e lifecycle { destroy = false }. O plano apresentou forget; após aplicação, a entrada desapareceu do state. Como terraform_data não cria um objeto remoto, este teste não comprova sobrevivência de armazenamento cloud. Num handover real, o plano da origem é apenas parte da evidência. Confirma quem pode aplicar, o identificador do objeto, o plano de adoção do destino, dependências, retenção e custos. Se o destino importa uma configuração diferente, pode propor alterações adicionais. Não encerres a tarefa só porque a origem deixou de mostrar o recurso.
Entregar evidência útil à operação
Prepara uma nota curta para a reunião de mudança: revisão de código, endereços antes e depois, ações propostas, plano efetivamente aprovado, confirmação posterior e pendências do destinatário. Partilha apenas campos necessários: show -json pode expor valores sensíveis. Para reproduzir os resultados locais, o repositório inclui content/labs/terraform-state/run.py; executa-o com o caminho absoluto de um CLI 1.16.5. O runner cria e remove os seus diretórios temporários e verifica seis grupos de observações. O arquivo usado nesta revisão foi comparado com o SHA256 publicado; não foi feita validação de assinatura. Resumo: identidade, ação física e responsabilidade são três perguntas distintas. Relaciona esta aula com módulos, locking, importação e recuperação parcial.
ledger→settlement sem moved propõe delete/create; com moved, o laboratório preservou o ID.
Armadilhas comuns
Igualar nomes a identidade; ignorar substituições adicionais; confundir forget com adoção pelo destino.
Tópicos relacionados: Planos e validação · Módulos e identidade · Adoção e recuperação
Confirma o mapeamento, lê as ações completas e fecha o circuito de responsabilidade.
Referência: Refactor modules · Terraform v1.16 concepts; official documentation consulted 2026-09-30; provider and backend capabilities must be confirmed