Cerramos el capítulo de gestión de entornos viendo en detalle cómo se pasan los valores a Terraform: los archivos .tfvars y las variables de entorno. Ya los hemos mencionado de pasada; ahora entenderás bien cómo separar la configuración (los valores que cambian) del código (la lógica que se queda igual). Esta separación es clave para gestionar entornos de forma limpia.

Recuerda las variables del Capítulo 10. Una variable es un «hueco» en tu código que se rellena con un valor desde fuera:

El código usa var.tipo_instancia, pero no fija el valor. ¿De dónde sale ese valor? Hay varias formas de proporcionarlo, y aquí las vemos.

Un archivo .tfvars es un archivo donde asignas valores a las variables. Es la forma más habitual y ordenada de configurar un entorno. Por ejemplo:

Fíjate en la idea clave: el código es el mismo, pero cada archivo .tfvars le da valores distintos. Esto es exactamente lo que permite usar la misma lógica para varios entornos (subcapítulo 19.2).

Le indicas a Terraform qué archivo de valores usar con la opción -var-file:

Caso especial — terraform.tfvars: si nombras un archivo exactamente terraform.tfvars, Terraform lo carga automáticamente sin que tengas que indicarlo. Por eso, en la estrategia de directorios (subcapítulo 19.2), cada carpeta de entorno suele tener su propio terraform.tfvars que se aplica solo.

Analogía: el código Terraform es como una plantilla de carta con huecos («Estimado ___, su pedido ___ está listo»). Los archivos .tfvars son los datos que rellenan los huecos para cada destinatario. Una plantilla, muchas cartas personalizadas. Cambias los datos, no la plantilla.

Otra manera de dar valores a las variables es a través de variables de entorno del sistema operativo, usando el prefijo TF_VAR_:

Terraform lee automáticamente cualquier variable de entorno que empiece por TF_VAR_ y la asigna a la variable correspondiente (aquí, tipo_instancia).

¿Cuándo se usa esto? Sobre todo en dos casos:

• En automatización (CI/CD, Capítulo 22): los sistemas automáticos suelen pasar los valores como variables de entorno, sin archivos.
• Para datos sensibles (secretos): como veremos enseguida, las contraseñas y claves no deben ir en archivos .tfvars que se suben a Git; las variables de entorno son una forma de pasarlas sin escribirlas en ningún archivo del repositorio.

Como hay varias formas de dar valores, Terraform sigue un orden de prioridad si un mismo valor se define en varios sitios (de menor a mayor prioridad, a grandes rasgos):

No hace falta memorizarlo, pero quédate con la idea: si defines un valor en varios sitios, gana el más específico/directo. En la duda, lo que pones en la línea de comandos manda sobre lo demás.

Esto es crítico. Tus archivos .tfvars con la configuración normal (tamaños, nombres) se guardan en Git sin problema. Pero NUNCA debes poner datos sensibles —contraseñas de bases de datos, claves de API, tokens— en archivos .tfvars que subes al repositorio. Si lo haces, esos secretos quedan expuestos en el historial de Git para cualquiera que acceda.

Las formas correctas de manejar secretos:

• Variables de entorno (TF_VAR_password), que no quedan en ningún archivo del repo.
• Gestores de secretos como AWS Secrets Manager o Parameter Store (que veremos en el Capítulo 23): Terraform los lee en el momento, sin que el secreto se escriba nunca en el código.
• Añadir los archivos .tfvars con secretos al .gitignore para que nunca se suban.

Recuerda también (del Capítulo 11) que el propio estado puede contener datos sensibles, por lo que el backend remoto debe estar cifrado y con acceso restringido. La gestión de secretos es un tema serio que retomaremos en profundidad en el Capítulo 23.

• Las variables dejan «huecos» en el código; los valores se proporcionan desde fuera, separando la configuración del código (la misma lógica sirve para varios entornos).
• Los archivos .tfvars son la forma principal de asignar valores; usas -var-file="entorno.tfvars", y un archivo llamado terraform.tfvars se carga automáticamente.
• Las variables de entorno con prefijo TF_VAR_ son otra forma de pasar valores, útil en CI/CD y para secretos.
• Hay un orden de prioridad cuando un valor se define en varios sitios: gana el más directo (línea de comandos > entorno > archivos > default).
• ⚠️ Seguridad crítica: nunca pongas secretos (contraseñas, claves) en .tfvars versionados en Git. Usa variables de entorno, gestores de secretos (Secrets Manager, Capítulo 23) y .gitignore.

¡Has terminado el Capítulo 19! Ya sabes gestionar múltiples entornos de forma limpia y segura. En el Capítulo 20 profundizaremos en uno de los temas más importantes para trabajar en equipo: los backends remotos y el locking del estado.