En el subcapítulo anterior vimos que los workspaces no son la mejor forma de separar entornos serios. Ahora veremos la estrategia recomendada por la comunidad: organizar la infraestructura en directorios separados por entorno. Es más explícita, más segura y mucho más fácil de entender. Es como gestionan los entornos la mayoría de los equipos profesionales.

En lugar de un mismo código que cambia de comportamiento según el workspace, tienes una carpeta por cada entorno, cada una con su propia configuración y su propio estado:

Cada carpeta de entorno usa los mismos módulos (para no duplicar la lógica), pero les pasa valores distintos. Así, el «qué se construye» está en los módulos (compartido), y el «con qué tamaño y configuración» está en cada entorno (separado).

Aquí es donde brilla todo lo que aprendiste en el Capítulo 18. La lógica de la infraestructura vive una sola vez en los módulos. Cada entorno simplemente llama a esos módulos con sus propios valores:

Mismo módulo servidores, dos entornos, configuraciones distintas. Si mejoras el módulo, ambos entornos se benefician, pero cada uno mantiene su tamaño y configuración propios. No hay duplicación de lógica.

Esta estrategia resuelve los problemas que vimos en el subcapítulo 19.1:

Cada entorno es una carpeta independiente con su propio estado (recuerda configurar un backend distinto por entorno, Capítulo 11 y subcapítulo 20.1). Producción y desarrollo están realmente separados: un error en una carpeta no toca las otras.

Para trabajar en producción, tienes que entrar físicamente en la carpeta prod/ y ejecutar Terraform allí. No es un sutil workspace select que se olvida: es un cambio de directorio evidente. Esto reduce muchísimo el riesgo de aplicar algo en el entorno equivocado.

Mirando la estructura de carpetas, ves de un vistazo qué entornos hay y qué tiene cada uno. Abres entornos/prod/main.tf y sabes exactamente qué hay en producción. Es transparente y fácil de auditar.

Si producción necesita componentes que desarrollo no tiene (por ejemplo, réplicas de base de datos o copias de seguridad extra), simplemente los añades en prod/main.tf sin afectar a los demás entornos. Cada entorno puede divergir lo que necesite, sin condicionales enrevesados.

Analogía: los workspaces eran como tener una sola casa y «cambiar la decoración» según quién la visita. La estrategia de directorios es como tener casas separadas para cada propósito: una para vivir (producción), otra para experimentar (desarrollo). Están físicamente separadas, no te confundes de casa, y puedes reformar una sin tocar la otra.

Habrás visto un archivo terraform.tfvars en cada entorno. Es donde se ponen los valores de las variables específicos de ese entorno (lo veremos a fondo en el subcapítulo 19.4). Así, la configuración de cada entorno (tamaños, nombres, cantidades) queda separada y clara, sin tocar el código.

Esta estrategia tiene un coste: hay cierta repetición en los archivos main.tf de cada entorno (las llamadas a los módulos se parecen). En proyectos con muchos entornos, esa repetición puede volverse molesta. Para eso existe una herramienta llamada Terragrunt, que reduce esa repetición y veremos en el siguiente subcapítulo.

• La estrategia recomendada para entornos serios es separar por directorios: una carpeta por entorno (dev/, stg/, prod/), cada una con su configuración y su estado propio.
• La lógica vive una sola vez en los módulos (Capítulo 18); cada entorno llama a esos módulos con valores distintos (tamaños, cantidades), evitando duplicar la lógica.
• Ventajas frente a los workspaces: separación clara y fuerte, difícil equivocarse de entorno (entras físicamente en la carpeta), visibilidad total y flexibilidad para que cada entorno diverja.
• Como casas separadas para cada propósito, en vez de redecorar la misma casa.
• Inconveniente: algo de repetición entre entornos, que Terragrunt ayuda a reducir (siguiente subcapítulo).

En el siguiente subcapítulo veremos Terragrunt, una herramienta que mantiene tus configuraciones de entorno DRY (sin repetición).