Toda aplicación real necesita varios entornos: uno de desarrollo para probar, otro de staging (preproducción) para validar, y el de producción donde están los usuarios reales. En este capítulo veremos cómo gestionar esos entornos con Terraform. Empezamos por una herramienta que el propio Terraform ofrece: los workspaces. Pero, ojo, también veremos por qué tienen limitaciones importantes.

Nunca debes probar cambios directamente en producción: sería como hacer experimentos con los clientes reales mirando. Por eso se separan los entornos:

Cada entorno suele tener la misma estructura de infraestructura (una VPC, unos servidores, una base de datos...), pero con diferencias: producción es más grande y robusta, desarrollo es más pequeño y barato. El reto es: ¿cómo gestiono el mismo código para varios entornos sin duplicarlo todo?

Recuerda el estado de Terraform (Capítulo 11): el archivo que registra qué recursos existen. Un workspace (espacio de trabajo) es, en esencia, un estado separado dentro del mismo código. Cambiando de workspace, Terraform usa un estado distinto, lo que te permite tener varias copias de la misma infraestructura sin que se mezclen.

Los comandos básicos:

Dentro del código, puedes saber en qué workspace estás con terraform.workspace, y adaptar valores en consecuencia:

Analogía: los workspaces son como tener varias partidas guardadas del mismo videojuego. El juego (el código) es el mismo, pero cada partida (workspace) tiene su propio progreso (estado) independiente. Cambias de partida y trabajas sobre otra realidad sin afectar a las demás.

Los workspaces parecen la solución perfecta, pero tienen problemas serios que debes conocer antes de adoptarlos para gestionar entornos. De hecho, la comunidad no recomienda usar workspaces para separar dev/stg/prod. Veamos por qué.

Todos los workspaces comparten el mismo código y el mismo backend (el mismo bucket de estado). Esto significa que la separación entre producción y desarrollo es frágil: un error puede afectar a varios entornos, y no hay una barrera fuerte entre ellos.

Como cambias de entorno con un simple workspace select, es fácil olvidar en cuál estás y aplicar un cambio en el sitio equivocado. Imagina ejecutar un apply pensando que estás en dev cuando en realidad estás en prod. ⚠️ Este error ha causado incidentes reales.

Si tus entornos son muy diferentes (no solo en tamaño, sino en estructura: producción tiene componentes que desarrollo no), forzar todo en un mismo código con condicionales (terraform.workspace == ...) se vuelve enrevesado y difícil de leer.

No es evidente, mirando el código, qué hay en cada entorno. Todo está mezclado y depende de en qué workspace estés, lo que dificulta entender y auditar la infraestructura.

Los workspaces tienen su sitio en casos sencillos:

• Cuando los entornos son casi idénticos y solo cambian detalles menores (un tamaño, un nombre).
• Para crear copias temporales de prueba (por ejemplo, un entorno por cada rama de desarrollo, que creas y destruyes rápido).
• En proyectos pequeños donde la separación fuerte no es crítica.

Para gestionar entornos serios (dev/stg/prod en una empresa), la recomendación general es no usar workspaces, sino una estrategia de directorios separados por entorno, que veremos en el siguiente subcapítulo (19.2). Esa estrategia da una separación mucho más clara, segura y visible.

Conclusión clave: los workspaces existen y son útiles para casos simples, pero no son la mejor herramienta para separar producción de desarrollo en proyectos reales. Conócelos, pero sé consciente de sus límites.

• Toda aplicación real necesita varios entornos (dev, staging, producción) para no experimentar nunca directamente sobre los usuarios reales.
• Un workspace de Terraform es un estado separado dentro del mismo código, lo que permite tener varias copias de la infraestructura (como «partidas guardadas» del mismo juego). Se gestiona con terraform workspace new/select/list.
• Limitaciones importantes: comparten código y backend (separación débil), es fácil equivocarse de entorno (peligroso), se complican si los entornos son muy distintos, y dan poca visibilidad.
• Úsalos para casos sencillos (entornos casi idénticos, copias temporales), pero no como forma principal de separar dev/stg/prod en proyectos serios.
• La alternativa recomendada para entornos serios es la separación por directorios, que veremos a continuación.

En el siguiente subcapítulo veremos esa estrategia recomendada: organizar tu infraestructura en directorios por entorno.