4 consejos para administrar varias versiones de Terraform

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

Hay muchas razones por las que podrías necesitar usar varias versiones de Terraform de forma local, como trabajar con distintos entornos (implementaciones estructuradas) que usan versiones diferentes, trabajar en varios proyectos para distintos clientes, garantizar la compatibilidad retroactiva de tu código al ejecutarlo con varias versiones, etc. Aquí tienes algunos consejos muy básicos para mantener ordenadas varias versiones de Terraform.

Empieza por usar localmente un administrador de entornos y versiones de Terraform

Usar un administrador de versiones hace mucho más fácil trabajar con varias versiones de Terraform de forma local y te asegura que:

• Cambiar de proyecto sea rápido

• El entorno de desarrollo sea lo más parecido posible al de producción.

tfenv es una buena opción, inspirada en rbenv. Básicamente, tfenv te permite instalar una versión específica de Terraform y usarla como predeterminada. También te permite ver y llevar un registro de todas las versiones de Terraform instaladas en tu laptop. Además, incluye algunos comandos útiles, como tfenv install min-required, que recorre de forma recursiva tus archivos de Terraform para determinar la versión mínima requerida.

Especifica tus versiones de Terraform de forma explícita

Cuando ocurren, las actualizaciones de Terraform pueden causar problemas. Y causan aún más problemas cuando aparece una excepción inesperada que no entiendes y descubres que se debe a que estás usando una versión incorrecta de Terraform en esa máquina.

Si especificas explícitamente la versión de Terraform requerida, recibirás un error claro y preciso si intentas ejecutar un apply en el entorno equivocado.

1terraform {
2required_version = "0.12.10"
3}

Especifica también las versiones de los módulos

Los elementos cambiantes son uno de los peores enemigos de los programadores, y esto también se aplica a la infraestructura como código. Los módulos de Terraform ofrecen mucha reutilización y capacidad de composición, pero también pueden volverse difíciles de manejar.

Especificar las versiones de los módulos facilita controlar qué parte de tu infraestructura cambiará y cuándo, si se actualiza un módulo. Así tienes la garantía de que, para un commit determinado en tu base de código, siempre implementarás lo mismo.

1module “blabla” {
2source = “module_name”
3version = “1.2.3”
4}

También te permite implementar las actualizaciones de módulos de forma gradual: puedes mantener la versión anterior en producción, crear una rama de desarrollo donde actualices el módulo, probarlo en tu entorno de desarrollo y, si supera las pruebas, fusionar los cambios en la rama principal.

Cuantos más módulos uses, más probable será que alguno cause un problema en algún momento. Por eso, esto se vuelve cada vez más importante a medida que crece tu base de código.

Evita ejecutar apply de forma local y desalienta los commits en la rama principal

¡No olvides tu flujo de trabajo! Ejecutar apply de forma local puede ser peligroso cuando dos usuarios colaboran en el mismo archivo de Terraform: si se realizan dos actualizaciones con poca diferencia de tiempo, la segunda puede sobrescribir la primera. Además, nunca sabes qué puede pasar en tu laptop, y hemos escuchado historias de grandes archivos de estado que se dañaron por perder la conexión Wi-Fi.

Por eso, un flujo de trabajo más adecuado para producción recomienda ejecutar apply solo desde un sistema centralizado y con control de versiones, como un proceso de CI/CD.

El siguiente paso es incorporar ese comportamiento al proceso. Por ejemplo, los permisos de acceso de los usuarios no les permitirán hacer cambios directamente en producción. Solo las claves de CI/CD tendrán permiso para hacerlo.

Del mismo modo, es muy tentador fusionar cambios en la rama principal, aunque sabemos que no es una buena práctica. Bloquear la rama principal animará a los usuarios a seguir un proceso mejor y más seguro: crear una solicitud de cambios y luego revisarla. A menos que seas sobrehumano, leas siempre el plan de Terraform y nunca cometas errores.

Algunos equipos agregan otros pasos, como ejecutar un linter o verificar si hay actualizaciones de la documentación, que requieren poco esfuerzo y ayudan a mantener el código limpio a largo plazo.

Protege tu código de Terraform

Snyk IaC protege tus configuraciones de Terraform (¡y tus plantillas de Kubernetes, CloudFormation y ARM!) mientras programas, con correcciones guiadas para que puedas fusionar 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 provocar daños irreparables. Regístrate y empieza a proteger tus configuraciones a continuación.