State do Terraform: o que armazena, por que é bloqueado e como o drift aparece

O que é

A documentação sobre state (citada) descreve a finalidade principal do state como guardar as associações entre objetos de um sistema remoto e as instâncias de recursos declaradas na configuração: quando o Terraform cria um objeto remoto, ele registra a identidade desse objeto junto ao endereço do recurso, de modo que alterações posteriores atualizem ou removam o mesmo objeto. O state é um arquivo de texto em JSON; por padrão fica local, como terraform.tfstate. A documentação desaconselha guardá-lo em controle de versão ou em qualquer armazenamento sem lock e sem controle de acesso, porque isso pode causar perda de dados ou expor segredos armazenados no arquivo de state.

Lock (citado): se o backend o suportar, o Terraform bloqueia o state, de forma silenciosa, em toda operação que possa gravá-lo, e se recusa a continuar quando não consegue obter o lock. O comando force-unlock existe para um lock deixado por uma execução que falhou e exige o ID do lock como salvaguarda.

Por que importa

Duas pessoas ou dois pipelines que executem apply ao mesmo tempo sem lock podem, cada um, gravar um state que omite os recursos do outro; o plan seguinte passa então a propor recriar ou destruir infraestrutura real. O drift, isto é, uma alteração feita num console ou por outra ferramenta, não é um erro em si, mas fica invisível até o próximo plan; a documentação do plan (citada) alerta que aplicar rotineiramente com -target leva a drift de configuração não detectado.

Como aplicar

• Use um backend remoto com lock e versionamento (armazenamento de objetos mais um mecanismo de lock, ou um backend hospedado) e restrinja o acesso de leitura tão rigorosamente quanto o de escrita, já que o state contém valores de atributos, como senhas geradas.
• Execute terraform plan -refresh-only periodicamente para listar o drift sem propor mudanças na configuração, e decida, para cada achado, se a alteração será incorporada ao código ou revertida.
• Gere os plans com -out no CI e aplique exatamente esse plan salvo após a revisão; use -detailed-exitcode para fazer uma verificação falhar quando houver diferença.
• Mantenha um state por raio de impacto: separe os ambientes e separe as bases de longa duração (redes, identidade) dos serviços alterados com frequência.
• Mova ou renomeie recursos com blocos moved, em vez de editar o state manualmente.

Armadilhas

terraform import e state rm alteram as associações sem tocar na infraestrutura, então o plan seguinte pode parecer surpreendente. Atualizações de provider podem reescrever os schemas do state. A página citada sobre state avisa que o arquivo de state pode conter segredos; marcar uma variável como sensitive a oculta da saída, não do arquivo.