Recientemente se han popularizado herramientas de infraestructura como código, como Terraform (véase Infrastructure as code | Technology Radar). Una de las principales promesas de estas herramientas es la automatización. Aún así, rara vez vemos implementada la Entrega Continua para el código de infraestructura. Este artículo aboga por el uso de pipelines de Entrega Continua para el aprovisionamiento de infraestructura (ver Pipelines for infrastructure as code | Technology Radar) y proporciona algunas buenas prácticas sobre cómo empezar. Nuestro grupo objetivo son los desarrolladores que, como nosotros, adoran la automatización.
¿Por qué?
Los accidentes ocurren
Esta cita ligeramente adaptada muestra cómo pequeños cambios en un flujo de trabajo pueden tener efectos dramáticos cuando se trata de código de infraestructura. Por lo tanto, deberíamos reflexionar sobre por qué queremos tener automatización en primer lugar. La automatización:
- Mantiene las cosas reproducibles
- Reduce el tiempo dedicado a documentar los pasos manuales
- Proporciona procesos fiables
- Los equipos se centran en el cambio real en lugar de en los pasos para aplicarlos
- Mejora la trazabilidad de los cambios
Nuestro objetivo debería ser automatizar por completo el proceso de aplicación de cambios en la infraestructura. El mundo del desarrollo de aplicaciones vio el paso a la construcción automatizada y la entrega de tuberías hace unos años (Automated deployment pipeline | Technology Radar), ahora el mundo de la infraestructura se está poniendo al día :)
¡El código de la infraestructura es CÓDIGO!
Una buena forma de automatizar el código de la infraestructura es tratarlo de la misma manera que el código de la aplicación. Por lo tanto, son necesarios algunos pasos antes de automatizar y llegar al flujo de trabajo familiar de: escribir código, confirmar, empujar y activar el pipeline.
Prepara el código de tu infraestructura para la automatización
Antes de empezar a construir pipelines de infraestructura, asegúrate de que el código de tu infraestructura está preparado para la automatización. Para ello, hemos incluido una pequeña lista de comprobación en el apéndice de este artículo. He aquí una visión general.
✔ Mantenlo en control de versiones: Los cambios en la base de código serán el desencadenante de todos los pasos posteriores en tus pipelines.
✔ Modulariza el código de tu infraestructura: Construir el código de tu infraestructura en pequeños módulos reutilizables permite la reutilización del código y facilita las pruebas.
✔ Adapta el código de tu infraestructura a tus aplicaciones: Mantener tu código de infraestructura junto con el código de tus aplicaciones te ayuda en la construcción de bloques más pequeños que están relacionados con las aplicaciones y los cambios en cualquiera de las partes del código serán fácilmente gestionados.
✔ Pruebas: Las pruebas son la red de seguridad en cualquier automatización.
✔ Puesta en escena: Tener los mismos pasos de construcción a través de múltiples entornos, asegura que cuando los cambios se promueven a la producción, se comportan como se esperaba.
✔ Infraestructura inmutable: Si tienes la opción, trata de usar recursos de infraestructura inmutables - hacerlo viene con la seguridad de que la infraestructura reconstruida siempre será la misma.
✔ Tu código de infra debe ser idempotente, no importa cuantas veces apliques el mismo código, no debe haber cambios más allá del resultado de la aplicación inicial.
Automating your infrastructure provisioning
Ahora que el código de la infraestructura está listo: ¿Cómo empezamos con los pipelines? En general, podemos seguir los mismos pasos que utilizamos para canalizar el código de la aplicación:
Diseña tu pipeline de infraestructura
Con el diseño de un pipeline de aplicaciones en mente, ya podemos empezar a diseñar un pipeline de infraestructura. Esperamos que nuestro pipeline sea:
- Fiabilidad: un proceso reproducible para aprovisionar nuestra infraestructura.
- Rápido: ciclos rápidos de información sobre el éxito o el fracaso del proceso.
- Específico: información concreta sobre lo que ha fallado cuando se producen errores.
Para alcanzar estos objetivos, nuestra infraestructura debe ser algo parecido a esto:
Etapa de preparación
En esta etapa queremos validar el código de nuestra infraestructura. El resultado de la etapa es un paquete que contiene todos los artefactos que necesitamos para aplicar nuestros cambios de infraestructura, por ejemplo, el código de infraestructura validado.
Etapa de preproducción
El objetivo de esta etapa es aprovisionar nuestra infraestructura en un entorno similar al de producción. Por lo tanto, generamos un informe de los cambios que se realizarán en nuestra infraestructura, después aplicamos estos cambios y, por último, podemos probar nuestra (nueva) infraestructura.
Fase de producción
Repetimos exactamente los mismos pasos que hemos ejecutado en la etapa anterior, pero en nuestro entorno de producción, con la seguridad añadida de haberlos ejecutado en preproducción.
Consideraciones
Separe el código de su infraestructura en repositorios más pequeños. Ejecutar pipelines para porciones más pequeñas de su infraestructura proporciona ciclos de retroalimentación más rápidos y reduce el radio de explosión cuando los despliegues van mal.
Almacene y reutilice cualquier artefacto que vuelva a ser relevante en pasos posteriores, por ejemplo, los proveedores de terraformación y el plan de terraformación.
No debe haber secretos en el código de su infraestructura.
Un sistema CI/CD que puede ejecutar cambios en la infraestructura es una entidad muy poderosa, asegúrese de que sólo las personas adecuadas pueden acceder a él y de que se gestiona de forma segura. Aplica los principios de mínimo privilegio a los roles que ejecutan tu pipeline.
Asegúrate de no probar cosas que tu herramienta de infraestructura como código ya "prueba" implícitamente. No sirve de nada comprobar si un recurso se ha creado después de que la aplicación haya tenido éxito.
Linting y validar su código le ayuda a tener una forma de código coherente.
Quieres mantener tu pirámide de pruebas equilibrada, así que aquí tienes una pista de cómo podría ser un buen conjunto de pruebas:
- Pruebas unitarias: prueba la(s) pequeña(s) pieza(s) de lógica que tienes en tu código declarativo (por ejemplo, el uso de variables y condiciones).
- Pruebas de integración: prueba un módulo Terraform de forma aislada. Pon en marcha la infraestructura del módulo, comprueba que hace lo que se espera de él y vuelve a desmontarlo.
- Pruebas de extremo a extremo: Después de la compilación, puedes probar que, una vez que tu infraestructura está preparada, hace lo que se esperaba de ella. Por ejemplo, "¿puedo acceder a mi base de datos con un usuario recién preparado y las credenciales almacenadas en una bóveda?”
Resumen y perspectivas
Esperamos haberte convencido de que automatizar el aprovisionamiento de tu infraestructura es una buena idea. Esperamos haberte ayudado a dar forma a una buena base de cómo puede ser un pipeline para tu código de infraestructura y pipelines. Hemos visto los beneficios de utilizar pipelines para ejecutar código de infraestructura, hemos descrito cómo dar forma a tu código para que esté listo para la automatización y hemos proporcionado una estructura de ejemplo para pipelines de infraestructura.
Tus próximos pasos podrían ser empezar con un pipeline para desplegar una pequeña parte de tu infraestructura y replicarlo para otras partes que necesiten aprovisionamiento dependiendo de cómo hayas dividido el código de tu infraestructura.
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.