Última

Top 3 Terraform Qué hacer y qué no hacer

Compartir esta entrada

A faire et ne pas faire avec Terraform

Cuando se trabaja con un software de aprovisionamiento tan avanzado como Terraform, es fácil sentirse abrumado. ¿Cuáles son las mejores prácticas a seguir? ¿Qué errores debo evitar? Por eso, el equipo de expertos de Iguana Solutions ha recopilado los Top 3 Terraform Qué hacer y qué no hacer para ayudar a las organizaciones a adoptar esta increíble herramienta de código abierto Infrastructure As Code creada por HashiCorp.

Terraform: Las 3 mejores prácticas

Logo Terraform IaC

Empecemos por lo básico, que son las 3 mejores prácticas que siempre hay que seguir cuando se trabaja con Terraform.

1. Lea la documentación de Terraform

Leer la documentación es, sin duda, la práctica más infravalorada a la hora de trabajar con Terraform. Uno de los aspectos que diferencian a Terraform de otros proyectos es el increíble trabajo que HashiCorp ha realizado con la documentación oficial. En Iguana Solutions, no dudamos en calificar la documentación de Terraform como una de las fuentes de conocimiento y recursos más valiosas que se pueden encontrar en línea.

Si tiene preguntas sobre la sintaxis HCL, la configuración de Terraform , la API, la integración VCS o los espacios de trabajo de Terraform , la documentación oficial debería ser su punto de partida. Esto le ahorrará muchas horas de investigación e incluso puede evitar que cometa errores al utilizar configuraciones o consejos que ya no son válidos en las versiones más recientes de Terraform.

En otras palabras, leyendo la documentación oficial de Terraform , te beneficias de:

  • Utilizar los recursos más recientes
  • Evitar el uso de "buenas prácticas" que ya no se recomiendan
  • Evitar cometer errores o introducir discrepancias al utilizar código que ya no es válido.
  • Mejore la seguridad de su código

2. Diseñe módulos que sean "Genéricos".

Es casi una constante en todos los lenguajes de programación promover el uso de "código reutilizable". Después de todo, ¿no es esa una de las ventajas de utilizar un lenguaje de programación estructurado en primer lugar?

Pues bien, por obvio que parezca, muchos desarrolladores caen en la trampa de no diseñar módulos para que sean genéricos; en su lugar, crean módulos para resolver requisitos individuales en un entorno. Lo que suele ocurrir en estos casos es que, a medida que crece la infraestructura de la organización (y, por tanto, el número de requisitos y entornos), habrá que reescribir buena parte del código. Peor aún, el código se complicará más de lo debido debido debido a las innumerables versiones y modificaciones de cada módulo.

Quizá se pregunte cómo puede evitarse esta situación. La respuesta es sencilla: asegurándose de que los módulos sean lo más genéricos posible. Puede saber si un módulo es genérico fijándose en sus características. Normalmente, los módulos genéricos comparten las siguientes características:

  • Son reutilizables; de ahí que se llamen "genéricos".
  • Generalmente realizan un único trabajo.
  • Están bien documentados para que puedan modificarse fácilmente.

Para ilustrar este concepto, considere un módulo responsable de importar un archivo de clave pública SSH en AWS. Este sería un módulo reutilizable, ya que se puede utilizar en cualquier entorno (desarrollo, producción, staging, etc). Además de eso, sólo hace un trabajo (importar un archivo de clave pública SSH en AWS) por lo que sería muy fácil documentarlo adecuadamente.

3. Automatizar todo

La automatización de procesos es uno de los principios básicos de DevOps. De hecho, en uno de nuestros artículos anteriores, 4 maneras en que Terraform puede mejorar la adopción de DevOps, ya mencionamos cómo Terraform permite automatizar el aprovisionamiento de infraestructura. En esta ocasión, vamos a reforzar este concepto haciéndonos eco de la documentación oficial "Terraform Prácticas recomendadas," donde se habla en profundidad de este proceso.

No es casualidad que la automatización sea un concepto tan importante como para ser considerada una Buena Práctica. Utilizar la línea de comandos o scripts personalizados para editar su infraestructura no es una solución viable a largo plazo. Los resultados no siempre son reproducibles, por no hablar del error humano que supone realizar todos estos complejos procesos manualmente.

Para profundizar, es importante considerar IaC como cualquier otro proceso de desarrollo y debe incluir IaC en sus conductos habituales de CI/CD. Es la clave para un despliegue seguro de la infraestructura. Las canalizaciones de CI/CD facilitan el trabajo colaborativo entre los distintos equipos. Proporciona herramientas para establecer normas de buenas prácticas para la comprobación del código y la revisión por pares. Y lo más importante, es la garantía de trabajar en la misma versión del IaC stack y compartir el estado actual de sus despliegues. Te permite definir varios entornos para validar tu trabajo antes de pasar a Producción. 

Los principios de DevOps nos dicen que la infraestructura moderna debe ser escalable y no debe depender de procesos manuales. En otras palabras, si vas a utilizar Terraform, entonces debes sacarle el máximo partido automatizando todos tus aprovisionamientos. En Iguana Solutions sabemos que esto no es fácil. Aún así, es la única manera de seguir las directrices DevOps y las prácticas fundamentales que hacen que la Infraestructura Como Código (IaC) sea tan útil.

Si está interesado en migrar de una provisión manual a un proceso semiautomático o migrar de un procedimiento semiautomático a uno que cumpla con los principios de IaC, en Iguana Solutions estaremos encantados de ayudarle.

Terraform: Los 3 principales errores que hay que evitar

Terraform DONTs

Tan importantes como las mejores prácticas son los errores que hay que evitar. En esta sección vamos a hablar de los más comunes entre los desarrolladores.

1. Almacenar secretos en texto plano

Podría decirse que uno de los errores más comunes al utilizar Terraform es almacenar información sensible en texto plano. Este error es común tanto en novatos como en desarrolladores experimentados. ¿La razón? Olvidan que cualquiera con acceso al repositorio podría obtener estos secretos.

Afortunadamente, solucionar este fallo de seguridad es relativamente sencillo.

  • Excluir todos los archivos propensos a almacenar datos sensibles (.tfstate, crash.log, * override.tf *, .terraformrc, terraform.rc). Github ofrece un archivo .gitignore que puede ser muy útil en este sentido
  • Cifre todos los secretos que almacene en su sistema de control de versiones. Para ello, puedes utilizar herramientas como Git-crypt, BlackBox, SOPS o Transcrypt. Dependiendo de tu entorno de desarrollo, algunas de ellas pueden ser más adecuadas que otras, por lo que recomendamos profundizar en las herramientas de gestión de secretos para el cifrado de Git.
  • Otra alternativa válida es utilizar un gestor de secretos externo. En Iguana Solutions, nuestros favoritos son AWS Secrets Manager y Bóveda desarrollados por HashiCorp, la misma empresa que está detrás de Terraform.

2. No documentar el código

Como con cualquier otro lenguaje de programación documentar el código se considera una buena práctica. ¿Por qué? Muy sencillo. A medida que la infraestructura crece, se introducen nuevas configuraciones en los componentes existentes, se añaden nuevos servicios, más nodos y otros cambios que, poco a poco, aumentan exponencialmente la complejidad de los archivos tfstate.

Tenga en cuenta otro aspecto importante. En la mayoría de los casos, no es una persona sino varias las que añaden o modifican el código. En otras palabras, distintos desarrolladores, con distintas visiones de cómo resolver un problema, aplican sus propias soluciones basándose en su experiencia.

Para cada uno de estos desarrolladores, su código tiene sentido, pero ¿qué pasa con los demás? Dado que se puede obtener el mismo resultado utilizando caminos diferentes, es habitual que dos personas no estén de acuerdo o simplemente no entiendan por qué se realiza un cambio concreto en el código.

La solución más sencilla a este problema es establecer una política clara respecto a la documentación del código. Por ello, los expertos de Iguana Solutions sugieren documentar cada cambio introducido en el código utilizando las políticas de su empresa. Esta recomendación es válida independientemente del lenguaje de codificación. Tanto si prefieres utilizar el Lenguaje de Configuración de HashiCorp (HCL) o JSON, el objetivo es el mismo, hacer el código lo más fácil de entender posible.

Por último, documentar el código facilitará enormemente su depuración, lo que mejorará la eficacia del ciclo de desarrollo.

3. Utilizar una estructura de directorios o repositorios incorrecta

Este es posiblemente uno de los puntos más controvertidos, ya que tiene mucho que ver con la forma "recomendada" de estructurar los archivos y configuraciones de Terraform. Aunque Terraform es flexible a la hora de utilizar cualquier método de organización para sus archivos, en nuestra experiencia, ciertas estructuras de directorios y repositorios pueden causar potencialmente muchos inconvenientes a la hora de escalar tu infraestructura.

Pero, ¿qué significa esto en la práctica? Bueno, según la documentación oficial de Terraform , la mejor manera de organizar tu código y la estructura de tus repositorios es utilizar una organización que favorezca el aislamiento de dependencias y la modularidad.

De hecho, la documentación de Terraform propone una solución sencilla: "... Si su organización no tiene una preferencia fuerte, recomendamos utilizar repositorios separados para cada configuración y utilizar el registro privado de módulos para compartir módulos. Esto permite un desarrollo de módulos más rápido ya que no tienes que actualizar cada configuración que consume un módulo al mismo tiempo que el propio módulo ..."

En pocas palabras, para evitar dolores de cabeza innecesarios a medida que su organización crece, nuestra sugerencia es evitar a toda costa el uso del enfoque "monorepo" y en su lugar favor de mantener cada configuración de Terraform en un repositorio separado.

En Soluciones Iguana nos gusta tanto Terraform que nuestro increíble equipo ha desarrollado el proveedor oficial de OpenNebula que ya está disponible en OpenNebula github y listado en la lista oficial de Terraform lista de proveedores¡!

¿Necesita ayuda o asesoramiento para su próximo proyecto en Terraform? Póngase en contacto con nosotros¡!

Compartir en Facebook

Soluciones Iguane

Redactor de contenidos, Iguana Solutions

"El saber hacer de Iguana Solutions nos permitió ser pertinentes en nuestras elecciones técnicas desde el principio del proyecto, al tiempo que aplicábamos una eficiencia económica excepcional."

Jean-David Blanc

CEO, Molotov.tv (adquirida por Fubo.tv)

Últimas actualizaciones

Manténgase informado con nuestras últimas entradas de blog y perspectivas del sector.