APRENDER. PRATICAR. EVOLUIR.Preparar uma experiência local delimitada
O recurso terraform_data permite observar o ciclo de vida de um objeto gerido através do provider integrado, sem criar uma máquina ou contactar uma cloud. Usa uma pasta nova e apenas o exemplo apresentado; o state local pertence à experiência. O percurso foi exercitado com Terraform 1.12.2, dentro da versão 1.12 indicada para Associate 004. Este laboratório mostra comportamento da CLI e do state, não quotas, redes, permissões cloud ou disponibilidade de aplicações. Antes de cada alteração, escreve a ação que esperas observar. Depois compara a previsão com o plano e explica a diferença antes de prosseguir.
Distinguir planeamento, execução e códigos de saída
Guarda o exemplo em main.tf, executa terraform init e terraform validate, e depois terraform plan -detailed-exitcode -out=initial.tfplan. Na primeira execução local, o código 2 indica sucesso com alterações propostas. O código 0 indica um plano sem diferenças e o código 1 indica erro. Esta convenção depende da opção -detailed-exitcode. Plan não executa as ações propostas. Inspeciona o ficheiro com terraform show initial.tfplan antes de aplicar. Passar um plano guardado a apply executa as decisões nele contidas sem nova confirmação interativa. Esse comportamento da CLI exige que a revisão e autorização reais tenham sido feitas pelo processo adequado.
Ler ações e valores ainda desconhecidos
Depois de aplicar a primeira versão local, um plano igual não propõe alterações. Mudar input de r1 para r2 no terraform_data gera uma atualização no local. Mudar triggers_replace pede substituição. Na representação JSON, ["delete","create"] descreve destruição antes de criação; ["create","delete"] descreve a ordem contrária. Um campo em after_unknown indica um valor ainda não conhecido, não um segredo automaticamente protegido nem um erro de provider. O JSON e os planos podem conter dados sensíveis em configurações reais. Revê ações por endereço e atributo; uma contagem total não revela por si só a perda de dados ou a interrupção possível.
Verificar o que realmente impede uma operação
Uma assertion falsa num check produz um aviso e não deve ser usada como única barreira quando uma condição tem de impedir a operação. No laboratório, uma precondition com approved=false conhecido no plan bloqueia a proposta, enquanto o check correspondente permite continuar com aviso. A validade sintática da configuração não prova que a condição esteja satisfeita. Também prevent_destroy tem um âmbito concreto: com a regra presente, bloqueia planos que exigem destruir o recurso. Se alguém apagar o bloco resource completo, a regra deixa de existir na configuração e o plano pode propor destruição. A revisão deve observar o contexto inteiro da mudança.
Reconhecer quando a aprovação deixou de corresponder ao plano
Guarda um plano para r2, gera e aplica outro para r3 no mesmo state, e tenta aplicar o primeiro. No laboratório, Terraform recusa-o como Saved plan is stale. Não resolves o problema mudando o nome do ficheiro, retirando locking ou editando o serial do state. Recalcula e revê o impacto no contexto atual. Também não podes acrescentar opções de planeamento, como novos valores de variáveis, ao aplicar um plano guardado. Uma nova intenção requer outro plano. Esta recusa específica não significa que Terraform detete antecipadamente toda a mudança externa possível; a equipa continua responsável por contexto, drift e validade da execução.
Retomar mudanças sem assumir rollback
Numa situação cloud fictícia, a rede foi criada mas a instância falhou por quota. O exit code não permite concluir que tudo foi revertido. Inspeciona objetos reais, associações no state e causa do erro; trata a causa e revê um novo plano. A execução cloud desta falha não faz parte do laboratório local. Usar -refresh=false pode esconder mudanças externas; usar -target reduz o âmbito e deve ficar reservado a situações excecionais. O alvo inclui dependências relevantes, mas não garante cobrir trabalho independente. Depois de uma recuperação direcionada, volta a observar um plano completo e verifica critérios funcionais com a equipa de suporte.
terraform {
required_version = "~> 1.12.0"
}
resource "terraform_data" "record" {
input = "r1"
}
Numa pasta nova: init, validate, plan -detailed-exitcode -out=initial.tfplan, show initial.tfplan e apply initial.tfplan. Repete plan sem mudar código; depois muda input para r2 e compara as ações.
Armadilhas comuns
Tratar código 2 como erro; usar check como barreira; presumir que prevent_destroy sobrevive à remoção do bloco; reaplicar um plano antigo ou esperar rollback transacional.
Tópicos relacionados: Workflow e planos · Configuração e segredos
O plano é evidência contextual de ações propostas. Interpreta códigos, validações e estado antes de executar; a conclusão funcional continua a precisar de critérios próprios.
Referência: terraform plan command · 004