APRENDER. PRATICAR. EVOLUIR.Workspace muda o state selecionado
Durante o lock do workspace default, um terceiro diretório usa o mesmo backend configurado, cria isolated e consegue planear uma criação nesse state separado. A primeira execução continua ativa. Depois, selecionar default nesse diretório permite ler o recurso partilhado já concluído. A observação mostra a importância de registar o workspace efetivo, juntamente com backend e diretório. Um comando que deixou de encontrar contenção pode ter mudado de destino, em vez de resolver a contenção original. Antes de aplicar, confirma se o plano propõe atualizar o conjunto pretendido ou criar um novo conjunto num state vazio.
Separação de instâncias e separação de acesso
O guião aplica uma configuração simples no workspace isolated depois de libertar o titular. O endereço terraform_data.operation aparece nos dois workspaces, mas os identificadores dos recursos são diferentes. O valor do workspace default permanece intacto. Isto demonstra separação dos states locais ensaiados, não separação de credenciais ou autorização entre equipas. A mesma identidade do sistema operativo executa todos os comandos. Para ambientes com requisitos de acesso distintos, avalia configurações e backends com controlos adequados. A documentação distingue ainda os workspaces CLI dos workspaces HCP Terraform; não transfiras automaticamente garantias de um produto para o outro.
O efeito precede o erro
Um segundo helper escreve uma linha JSON num ficheiro temporário e termina com código 7. O provisioner de criação falha e apply termina em erro. A linha continua no ficheiro, e o recurso fica registado como tainted no state local. O laboratório usa este efeito simples para tornar visível uma questão operacional: um processo pode fazer trabalho antes de comunicar uma falha. O marcador não representa uma transferência financeira real nem um sistema externo. Num bootstrap real, inventaria registos, ficheiros, inscrições ou pedidos emitidos pelo script antes de decidir que ações podem ser repetidas com segurança.
Substituição não apaga a história do script
O plano seguinte propõe delete e create com motivo replace_because_tainted. O guião conserva essa proposta e muda a execução do helper para sucesso numa nova aplicação. O identificador do recurso local muda, mas o ficheiro de efeitos passa a ter duas linhas: a primeira não foi desfeita. A recuperação do ciclo de vida gerido e a reconciliação dos efeitos do script são problemas relacionados, mas distintos. Define uma identidade de operação, verificação do resultado e estratégia de repetição quando o sistema real exigir idempotência. O laboratório não implementa esses mecanismos externos nem comprova uma política universal de compensação.
Continuar após erro muda o resultado observado
Noutro diretório, o mesmo helper falha depois de escrever uma linha, mas o provisioner usa on_failure=continue. Apply termina com código 0 e o recurso não fica tainted. O plano posterior apresenta no-op; o helper falhado não volta a correr nesse planeamento. Portanto, sucesso de apply não prova sucesso de cada passo cujo erro foi explicitamente ignorado. Se o efeito é necessário para disponibilizar o serviço, cria um critério de aceitação que o observe e faça parte da decisão de promoção. Não escondas um requisito obrigatório atrás de continue apenas para obter uma pipeline verde.
Preparar uma decisão de recuperação
Num exercício fictício APS, entrega ao participante o workspace selecionado, os endereços e identificadores, o resultado do provisioner, as linhas de efeitos e o próximo plano. Pede-lhe que separe o que foi criado, o que falhou, o que permanece e o que poderá repetir-se. Uma resposta útil identifica dependências e critérios de aceitação antes de propor nova execução. Os resultados aqui obtidos usam ficheiros temporários e um recurso incorporado, sem credenciais ou infraestrutura remota. Continuam a faltar um provider representativo, permissões de equipas, backend remoto, mecanismo real de idempotência e uma oficina humana com revisão especializada.
# Observe selection before deciding what a plan refers to.
terraform workspace show
terraform plan -input=false -out=review.plan
terraform show -no-color review.plan
# For a failed provisioner, inspect effects and the recovery proposal.
# A no-op plan does not independently verify an ignored script failure.
Um helper acrescenta uma linha e termina em erro; a linha permanece. A recuperação substitui o recurso local e acrescenta outra linha.
Armadilhas comuns
Confundir workspace com permissões separadas; tratar tainted como rollback; aceitar on_failure=continue como prova de sucesso do helper.
Tópicos relacionados: Planos guardados e aprovação · Recuperação após execução parcial
A separação de states não cria uma transação sobre scripts nem uma fronteira de autorização. Desenha e verifica essas garantias explicitamente.
Referência: Provisioner effects, creation failure and continue handling · Terraform v1.16 concepts; official documentation consulted 2026-09-30; provider and backend capabilities must be confirmed