State remoto: migração, contenção de concorrência e recuperação

O backend já foi apresentado; esta aula aprofunda operação segura do state. Migrar não é simplesmente copiar um arquivo para S3: o Terraform precisa passar a usar a localização correta sem criar um segundo inventário independente. Faça a mudança em janela controlada, sem outros plans ou applies.

Prepare o backend antes da migração. O bucket precisa existir com versionamento, bloqueio público, criptografia e acesso restrito. Use uma configuração de bootstrap separada ou infraestrutura corporativa existente; não dependa do backend que ainda está tentando criar.

O lockfile nativo do S3 exige Terraform >= 1.10 e use_lockfile = true. Padronize essa versão em todas as máquinas e pipelines que acessam o state. Uma configuração compatível não protege contra clientes antigos que não adotam o mesmo mecanismo de lock.

As permissões são distintas: a role precisa ler e gravar o objeto de state e listar o prefixo necessário no bucket; no objeto .tflock, precisa também excluir o lock ao terminar. Se houver SSE-KMS, as permissões da chave entram na análise. Não conceda DeleteObject ao state sem necessidade operacional.

Execute init -migrate-state após configurar o backend e confirme a migração solicitada. Não confunda com reconfigure: -reconfigure aceita uma configuração de backend sem migrar o state anterior. Compare inventário antes/depois e só prossiga quando estiver certo de conta, bucket e chave.

Com concorrência legítima, aguarde o lock, não o desative. -lock-timeout=5m dá tempo para outra operação terminar. O lock coordena um state específico; não serializa automaticamente stacks diferentes que alteram o mesmo recurso por desenho incorreto.

Um lock aparentemente preso exige investigação de execução ativa: confira job, operador, horário e logs. Só use force-unlock após confirmar que o dono não está mais escrevendo e preservar evidências. Destravar um apply ainda vivo pode permitir duas gravações concorrentes.

Recuperação é procedimento ensaiado, não restauração impulsiva de versão. Pare os escritores, preserve state atual, identifique a versão boa e reconcilie o que mudou na AWS desde então. Após recuperar sob controle, execute plan e revise; restaurar um state antigo não desfaz recursos já criados ou removidos.