Skip to main content

Administra varios entornos de Terraform

Escrito por
Headshot of Stephane Jourdan

Stephane Jourdan

feature synk iac terraform blue

30 de junio de 2020

0 minutos de lectura

Nota del editor: Esta publicación apareció originalmente en CloudSkiff.com. CloudSkiff se unió a Snyk en octubre de 2021.

¿Cómo se administra la complejidad de tener varios entornos de Terraform? Con varios entornos y posiblemente varios equipos, las cosas pueden complicarse. Aquí te explicaré cómo empezar a administrar varios entornos de Terraform como todo un profesional.

Cómo empezar con archivos TF

Si necesitas administrar varios entornos de Terraform, hay muchas formas de mejorar tu enfoque y empezar.

Empezar paso a paso con archivos .tf independientes puede resultar abrumador, ya que al principio es difícil conocer todas las buenas prácticas. Además, es posible que termines distraído o incluso desalentado. Por eso, puedes empezar de forma muy sencilla con un solo TFState. Crea un archivo simple de Terraform, llámalo production.tf y escribe en él tus VPC, máquinas virtuales o lo que necesites. Muy pronto podrás crear otro entorno. Llamémoslo staging.tf. Seguirá siendo un único archivo de estado de TF, lo cual no está mal, pero no podrá escalar. Aun así, es una forma de empezar paso a paso.

Usa los espacios de trabajo de Terraform

HashiCorp recomienda usar lo que ahora llama espacios de trabajo. workspaces es un subcomando de Terraform. Antes se llamaba environments.

El objetivo de los espacios de trabajo es separar un archivo de estado de TF por entorno. Por ejemplo, si tienes entornos de QA, staging y producción, el subcomando de espacios de trabajo de Terraform permite cambiar entre los estados de TF. Esa es la forma recomendada por HashiCorp, pero eso no significa que tengas que hacerlo exactamente así.

Organiza tu repositorio de Git con carpetas

Otra forma de hacerlo es separar los archivos de estado con carpetas, en lugar de usar espacios de trabajo. Solo crea carpetas en tu repositorio de Git y asígnales nombres, como staging y production. Luego, genera archivos de estado de TF distintos a partir de esas carpetas. Es muy fácil y así ya tienes los entornos separados en cuanto a sus estados de TF.

Módulos: una forma común de administrar entornos de Terraform

El uso de módulos se está convirtiendo en una práctica estándar. Es un poco avanzado, pero básicamente los módulos funcionan al inyectarles variables, como cadenas de texto, entre otras. Son una función muy útil de Terraform.

Los módulos contienen código genérico. Tomemos como ejemplo una VPC estándar. Esta VPC puede aceptar varios valores, como la subred y un nombre. Puedes crear dos carpetas, una para cada entorno. En tu primer archivo de Terraform, especificarás el espacio de direcciones de la VPC de staging; en el otro, definirás un espacio de direcciones distinto. Así resuelves el problema con solo inyectar valores diferentes en los módulos.

Esa sería la principal forma en que recomendaría usar los entornos.

Empieza de forma sencilla y nativa con un solo TFState; crea carpetas distintas, separa los estados por carpeta e inyecta distintos tipos de valores en los módulos. O, simplemente, sigue las recomendaciones de HashiCorp y usa espacios de trabajo.

Organiza tus recursos y define la estructura de directorios

Lo último que debes considerar es cómo organizarás tus recursos y la estructura de directorios. ¿Usarás uno o varios repositorios?

No hay una única respuesta, pero una configuración común consiste en administrar los módulos por separado y llamarlos desde un solo repositorio. Veamos un ejemplo: si tienes un módulo que sabe configurar correctamente una VPC a partir de dos variables, ya tienes código de Terraform bien estructurado. Puedes guardar este código en un repositorio de Git de Terraform independiente, y administrarlo, versionarlo y publicarlo como cualquier otro proyecto. Sin embargo, no puedes usarlo tal cual. Aún necesitas que tu repositorio de infraestructura llame a este módulo, de forma similar a como usarías una biblioteca estándar en ingeniería.

Para algunas personas, la jerarquía de carpetas también es importante. Es muy común tener carpetas de prueba para todas las pruebas, carpetas separadas para los módulos y también otras carpetas para los entornos.

Otro patrón común que se me ocurre es usar archivos de variables con todos los distintos tipos de valores que puedes tener, para que los entornos se envíen a la ejecución mediante esas variables de entorno.

Protege tu código de Terraform

Snyk IaC protege tus configuraciones de Terraform (¡y también tus plantillas de Kubernetes, CloudFormation y ARM!) mientras programas, con correcciones guiadas para que puedas integrar los cambios y seguir adelante. Puedes hacer pruebas mientras escribes, monitorear los cambios en tus repositorios de Git y automatizar las pruebas en tus pipelines de compilación antes de la implementación. Empezar con un plan gratuito toma solo unos minutos, mientras que una brecha causada por una configuración incorrecta de IaC puede tener consecuencias para toda la vida. Regístrate y empieza a proteger tus configuraciones a continuación.

Protege la infraestructura desde el origen

Snyk automatiza la seguridad y el cumplimiento de IaC en los flujos de trabajo, y detecta recursos con desviaciones de configuración y recursos faltantes.

Leer más

feature insights context
Blog

Los ataques autónomos ya están aquí. La defensa debe estar a su altura.

Los atacantes autónomos están reduciendo el tiempo disponible para defenderse. Descubre cómo el descubrimiento, la corrección, la validación y la prevención continuos pueden ayudar a los equipos de seguridad a seguirles el ritmo.

Blog

Evo ADS Govern Agent Behavior ya está disponible: controla el uso de MCP

Evo ADS Govern Agent Behavior ya está disponible, comenzando con MCP Governance. Descubre, aprueba, monitorea, registra y bloquea el uso de servidores MCP en los principales agentes de programación con IA.

illustration hero ai
Blog

¿Qué es Agentic AppSec?

Descubre cómo Agentic AppSec usa agentes de IA con contexto, límites definidos y verificación independiente para ejecutar el ciclo de seguridad de aplicaciones.