Pantalla con archivos de configuración de Terraform y plan de cambios resaltado

Bitácora técnica · Terraform

Terraform con estado remoto: cuándo el backend local deja de servir

Bloqueos, concurrencia y trabajo en equipo sobre la misma infraestructura

Mientras una sola persona ejecuta terraform apply, tener el archivo terraform.tfstate en la carpeta del proyecto es cómodo y no molesta a nadie. El problema aparece el día que dos ingenieros tocan la misma infraestructura con unas horas de diferencia: uno aplica un cambio, el otro ya tenía un plan armado sobre el estado anterior y lo aplica encima. El resultado no es un error limpio, es un plan que parece válido pero destruye o recrea recursos que el primero acababa de crear.

Las señales de que el estado local ya no alcanza son bastante reconocibles. Aparecen recursos huérfanos que nadie recuerda haber creado, planes que muestran destrucciones inesperadas de volúmenes o buckets, y mensajes de "resource already exists" al importar algo que en teoría ya estaba gestionado. En equipos chicos suele pasar que alguien copió el archivo de estado a su máquina para "revisar algo" y desde entonces hay dos versiones circulando. Cuando eso ocurre, el estado deja de ser una fuente de verdad y se convierte en un archivo más que se sincroniza a mano.

El backend remoto resuelve dos cosas al mismo tiempo: centraliza el estado en un único lugar y agrega locking, es decir, un bloqueo que impide que dos apply corran en paralelo sobre el mismo estado. La configuración mínima es un bloque backend dentro del terraform block, apuntando a un bucket o a un servicio de almacenamiento con soporte de bloqueo. Antes de mover el archivo hay que hacer una copia, correr terraform init -migrate-state y confirmar que el plan posterior sigue mostrando exactamente los mismos cambios que antes de la migración. Si el plan cambia, algo se leyó mal y conviene detenerse.

Un detalle que se pasa por alto: el locking no reemplaza la disciplina de revisar el plan. Un backend remoto evita que dos personas pisen el mismo estado, pero no evita que alguien aplique un cambio que no revisó. La lista de comprobaciones previa a la migración incluye verificar que no haya un apply en curso, que el estado local esté al día, que las variables sensibles no estén hardcodeadas en el archivo y que el backend elegido tenga versionado habilitado para poder volver atrás si algo sale mal.

Ver más notas de la bitácora Revisión de infraestructura y despliegues

Terraform con estado remoto: cuándo el backend local deja de servir

Estado remoto no es copia de seguridadUn backend remoto guarda el archivo de estado y coordina el locking, pero no reemplaza un respaldo versionado. Si el bucket o la base se corrompe, el plan posterior no reconstruye lo que ya existía. Antes de mover el archivo conviene tener una copia del tfstate actual fuera del repositorio y saber cómo volver a ella.

El locking no evita conflictos de diseñoEl bloqueo impide que dos apply corran a la vez sobre el mismo estado, pero no impide que dos ramas distintas definan el mismo recurso con nombres diferentes. Ese problema se resuelve revisando el plan y la organización de módulos, no cambiando de backend.

Un workspace no es un entornoSeparar entornos por workspace funciona mientras los recursos no compartan identificadores. Cuando producción y staging empiezan a referenciar la misma red o el mismo bucket, el aislamiento se rompe. En ese caso conviene separar por directorio y estado propio, no por workspace.

El plan revisado es la única fuente válidaUn plan que se ve bien en local puede destruir recursos si el estado remoto quedó desactualizado. Después de migrar hay que correr terraform plan contra el backend nuevo y comparar línea por línea con el plan anterior. Si aparecen destroy inesperados, se detiene el apply y se investiga antes de seguir.

Los módulos versionados no garantizan reproducibilidadFijar la versión del módulo ayuda, pero si las variables de entrada se resuelven distinto según el entorno, el resultado cambia igual. Las variables sin default y los outputs sin uso suelen ser la causa de que un módulo funcione en pruebas y falle en producción.

La migración no es un cambio de una sola vezMover el estado a un backend remoto es un cambio operativo que afecta a todo el equipo. Hay que avisar la ventana, congelar applies durante el traslado y verificar el primer plan después del cambio antes de que otra persona toque la infraestructura.

Terraform con estado remoto: cuándo el backend local deja de servir

Buckingham Cloud no firma con nombres inventados. Lo que se publica acá sale de un equipo de ingenieros que trabaja a diario con infraestructura en producción y que prefiere mostrar el fragmento de configuración antes que la promesa. Cuando una entrada habla de migrar el estado de Terraform a un backend remoto, detrás hay alguien que ya rompió un plan por tener el archivo local en dos máquinas a la vez.

La bitácora es independiente y sin patrocinio. No hay perfiles decorativos ni biografías armadas para la ocasión: si un tema se cubre, es porque alguien del equipo lo tocó en un entorno real y anotó lo que falló, lo que hubo que revertir y qué comprobación faltaba antes del apply.

Terraform con estado remoto: cuándo el backend local deja de servir

Antes de mover el archivo de estado conviene reconocer qué señales aparecen en la terminal y en los paneles. Estas capturas ilustran momentos típicos del trabajo con Terraform: planes que se pisan, bloqueos activos, salidas de apply y comparaciones entre un estado local y uno gestionado por un backend remoto. Sirven como referencia visual para ubicar el problema, no como prueba de un caso particular.

Terraform con estado remoto: cuándo el backend local deja de servir