Terraform 24: State local vs remoto para colaborar en equipo
easy⏱ 5 mincourseterraform
State local: un archivo, una máquina
Sin un backend configurado, Terraform escribe terraform.tfstate en tu directorio de trabajo. Funciona, pero el archivo vive solo en tu disco. Un compañero corriendo apply desde su clon tiene un state viejo o vacío, así que Terraform cree que no existe nada e intenta recrear todo — o dos personas aplican a la vez y se pisan los cambios.
# Implicit default — no backend block = local state on disk
# ./terraform.tfstate (current state)
# ./terraform.tfstate.backup (previous state)
#
# Great for a throwaway demo. Never for a shared environment.
State remoto: una copia compartida y bloqueada
Un backend remoto guarda el único state canónico en la nube (por ejemplo un contenedor de Azure Storage). El init de todos apunta al mismo objeto, así que cada plan/apply lee la misma realidad. Los backends remotos además dan locking (un apply a la vez) y cifrado en reposo — obtenés las garantías de colaboración que el state local no puede dar.
Migrar un state existente
Si ya aplicaste con state local y después agregás un bloque de backend, terraform init detecta el cambio y ofrece copiar tu state existente al remoto. Respondé yes (o pasá -migrate-state) para preservar la historia — no empezás de cero.
Elegí el backend
Implementá pickBackend(teamSize) para que devuelva "remote" cuando más de una persona comparte la config (teamSize > 1) y "local" en caso contrario. El starter loguea pickBackend(1) y pickBackend(4).