IaC Multi Cloud
Azure y AWS
Han escuchado hablar de que en el mundo de TI, hay dos vertientes principales para el conocimiento de la infraestructura y el área de desarrollo.
¿Se han preguntado qué pasa si estas vertientes se mezclan?
Parte de este resultado son los Arquitectos de Soluciones y los Ingenieros en DevOps, ambos comparten conocimientos uno más cargado hacia infraestructura, el otro a desarrollo, pero ambos tienen un punto en común, que es una estrategia para manejar cambios que afectan tanto al producto como al ambiente en donde este se ejecutará y la necesidad de soportar esos cambios, de re estructurar los servicios y recursos, de actuar rápidamente, es ahí donde nace la Infraestructura como Código o IaC.
Infrastructure as Code
IaC es un conjunto de scripts, que nos permite ajustar los servicios para que soporten nuevas cargas de trabajo, que añadan servicios adicionales a nuestra infraestructura actual, que re estructuren configuraciones o incrementen las instancias.
Un sinfín de servicios administrativos de infraestructura, que nos servirá para generar el ambiente propicio para que nuestras soluciones se ejecuten de forma correcta.
Existen dos tipos de scripts, declarativos e imperativos, que se basan en Funciones y Procedimientos correspondientemente, al igual existen dos métodos para poder ejecutar estos scripts, tenemos Push y Pull, que consisten el primero en enviar los ajustes a ejecutar al ambiente destino y en el segundo, el ambiente destino obtiene los ajustes que debe ejecutar.
Suele ser un tema extenso, voy a compartirles un par de ligas para la teoría:
IaC Providers
Existen también, muchas formas de ejecutar estos scripts y de crearlos, tenemos las estrategias y motores propios de las nubes y proveedores de servicio, así como Third-parties, de los cuales los más populares son:
· Chef
· Puppet
· Ansible
· Jenkins
No vamos a explorar mucho en los detalles de cada una, pero si quieres saber el proceso para cada una de ellas, deja tu comentario para que nuestro siguiente post sea con esa herramienta.
Hoy vamos a trabajar un escenario típico de DevOps que requiere el despliegue por IaC, para darle más sazón al caldo, utilizaremos un ambiente MultiCloud y el script que se trabajará, se basará en Terraform. Nuestra plataforma de DevOps será Azure DevOps y para los ambientes y servicios en cloud utilizaremos AWS y Azure.
Ten lista una taza de café y pongámonos manos a la obra para este despliegue.
Arquitectura de la solución
La arquitectura está basada en un entorno o proveedor de CI/CD (Tenemos un híbrido usando Github para Repositorio principal y Azure DevOps para los procesos).
El flujo de ejecución está dividido en 3 fases por proveedor una vez se tenga una nueva versión, los pasos son los siguientes para ambas:
1. Se prepara el archivo y la estructura que ejecutaremos para crear los servicios.
2. Se ejecutará el despliegue usando el proveedor de automation para cada nube.
3. Una vez tengamos nuestra infraestructura desplegada, desplegamos el artefacto que le corresponde a cada ambiente.
Bien, tendremos una arquitectura bastante robusta, usaremos diferentes proveedores y por eso haremos uso de PAT, IAM y Service principal, para asegurarnos de implementar las mejores prácticas en nuestros procesos.
Service Connections
En Github utilizaremos un token con permisos para la manipulación de repositorios.
Para Azure, utilizaremos un Service Principal para ejecutar los procesos, debemos limitarlo a los permisos de ejecución y creación de recursos limitados, en este caso AppService.
Para AWS, daremos de alta un usuario IAM para uso desde CLI, debemos limitarlo para la ejecución y no causarnos un riesgo de seguridad, es por eso que pondremos los alcances de Beanstalk y S3 para esta ejecución.
Una vez los tengamos, les daremos de alta en Service Connections para que podamos utilizarlos en el proceso de Azure DevOps.
Build Pipeline (CI)
Para nuestro proceso de continuous integration, lo haremos sencillo, iniciaremos con un template para NetCore App y a partir de ahí crearemos nuestro proceso personalizado, ya que compilaremos NetCore 3.1 para backend y para frontend tendremos una aplicación Anguar, nuestros pasos quedarán de la siguiente manera.
Tendremos la configuración a nuestro repositorio de github y utilizaremos los pasos por default para un proyecto con NetCore, vamos a personalizar para agregar los pasos para nuestra aplicación en Angular, que serán dos únicamente, nuestro infalibre npm install y un comando personalizado, que consta de un build con bandera productiva (ng build — -prod), para poder ejecutar esto, necesitamos el flag en nuestro script en package.json
Notarás 3 pasos extraños para el template que usamos
Esto es debido a que en nuestro artefacto personalizado tendremos una estructura particular, necesitamos incluir nuestros archivos de Terraform, Backend y Frontend en el mismo artefacto, la estructura con los pasos de Copy* quedará de la siguiente manera:
ArtifactXXXXX
| — +backend
| — +frontend
| — +iac
| — — +aws
| — — +azure
Este es el paquete de liberación, finalmente crearemos un archivo en zip y publicaremos el artefacto personalizado.
Tomemos un pequeño break y recarguemos nuestra taza de café.
Release Pipeline (CD)
Este proceso será algo particular, ya que en un mismo pipeline, tendremos nuestro proceso de liberación para ambas nubes, haremos un proceso con dos agentes, el primero llevará la carga de trabajo que se desplegará en Azure y la segunda apuntará hacia Aws, vamos a darle un ojo.
Es una definición bastante entretenida, ya que si observamos tenemos la misma estructura para cada una de las nubes para nuestro despliegue de infraestructura en cada nube objetivo(Azules) y lo que podemos notar diferente es el procedimiento de despliegue de las nuevas versiones de las aplicaciones (Rosas), teniendo un despliegue hacia un AppService en Azure y dos procesos con S3 para el caso de Aws.
Security at High Level
Cuando trabajamos con scripts que necesitan credenciales y detalles para desplegar nuestra infraestructura, debemos considerar el riesgo de que alguien no autorizado va a tener acceso, esto siempre y cuando pasen nuestros sistemas de seguridad, sin embargo, debemos blindar nuestro pipeline, es por eso que usamos el paso de Token Replacement (Morados), aquí nosotros vamos a definir en un lugar seguro estas credenciales para que no queden expuestas, podemos usar las siguientes opciones:
· Variables de pipelines: son seguras por no exponerse, pero si alguien más controla los procesos, puede editarlas y poner en riesgo nuestro proceso.
· Vaults (Azure Key Vault/Hashicorp vault): Estos son los procesos de alta seguridad, para lo que antes de los despliegues, necesitaremos crear estas instancias.
Para este proceso, usaremos las variables, posteriormente agregaremos mejoras de seguridad cuando usemos los diferentes Vaults disponibles en las diferentes nubes y proveedores SecOps.
A continuación, veremos las diferentes variables que se usan en los procesos y son reemplazadas en tiempo de ejecución.
Terraform Files
A continuación se encuentra la definición para los archivos Terraform que se usarán en ambas nubes. Notese que las variables son reemplazadas con la estructura __TOKENNAME__ en ambos archivos.
Azure
Para nuestro despliegue en Azure, configuraremos primer el lugar en donde tendremos nuestro plan para ejecución y la configuración de nuestro proveedor para Infraestructura. Una vez teniendo esa configuración, desplegamos nuestro servidor y nuestra webapp para backend.
Notarán el template, es un script que nos ayudará a configurar nuestro Runtime para NetCore 3.1.
Aws
Ahora para AWS, hacemos lo mismo que en Azure, configuramos nuestro espacio en donde el plan será guardado para ejecutarlo después, configuramos el proveedor Aws y desplegamos los servicios, S3 para nuestro sitio estático y Elastic Beanstalk para nuestros servicios de frontend.
Running Time
Ok, vamos a generar una nueva versión y un nuevo release.
Voilá!
Hemos completado nuestra liberación de manera exitosa.
Azure
Aws
¡Hemos concluido exitosamente el despliegue!
Infrastructure as Code, usualmente suele ser uno de los procesos más complejos y difíciles al principio de nuestro flujo de DevOps o cuando estamos adoptando esta nueva estrategia debido a que nos movemos de sistemas On-Prem hacia la nube, nos migramos hacia diferentes nubes o habilitar nuestros sistemas y servicios en otras regiones (Europa, Asia, Australia, etc).
Mi recomendación es documentación, siempre será nuestro gran aliado en este tipo de scripts, así como tener una referencia, puede ser nuestro mismo equipo de DevOps o un equipo de Arquitectura o Administradores de servicios, sin dejar de lado a nuestros devs, ya que al final, el paquete de nuevas versiones viene de ellos, recordemos el trabajo en equipo es clave para el éxito del negocio.
Les dejo otras ligas para diferentes lecturas, en lo que se sigue preparando más artículos de desarrollo:
Mobile DevOps con Azure DevOps
Puedes encontrar el repositorio de la solución aquí: Github Repo
Keep Reading!
