Creación de un flujo de implementación multinube dinámico y escalable con GitLab

El equipo de soluciones de Volterra diseña y mantiene numerosos casos de uso potenciales de la plataforma Volterra para demostrar su valor potencial. Estos casos de uso suelen convertirse en guías instructivas que los clientes utilizan para obtener su primera experiencia práctica con Volterra.

El equipo de soluciones quería un método más rápido y automatizado para implementar nuestros casos de uso a pedido de manera interna, con la menor intervención humana posible. Nuestras implementaciones cubrieron un entorno híbrido de múltiples nubes utilizando plataformas IaaS (AWS, Azure y GCP) y entornos de centro de datos privados (VMware vSphere y Vagrant KVM). Queríamos simplificar la gestión de estos entornos proporcionando una única herramienta que pudiera crear implementaciones en cualquier entorno sin necesidad de que los usuarios individuales crearan cuentas de acceso adicionales o administraran credenciales de usuario adicionales para cada plataforma de virtualización o proveedor de IaaS. Esta herramienta también necesitaba escalarse para soportar múltiples usuarios e implementaciones simultáneos.

En resumen, el problema central que queríamos resolver era crear una herramienta automatizada de implementación de casos de uso de soluciones, capaz de escalar y gestionar implementaciones simultáneas en entornos híbridos de múltiples nubes con la menor intervención posible del usuario.

El Proyecto Carbono Alterado (AC)

Para ello, creamos un proyecto llamado Altered-Carbon, a menudo abreviado como AC. El proyecto AC es una canalización dinámica de GitLab capaz de crear más de 20 casos de uso diferentes de la solución Volterra. A través de la automatización de pipelines, creamos “implementaciones con solo presionar un botón” con un solo comando que permite a los usuarios implementar fácilmente múltiples clústeres de casos de uso a pedido o mediante trabajos cron diarios programados.

Como referencia, en AC nos referimos a cada implementación como una PILA y a cada caso de uso único como una FUNDA .

Desarrollo de proyectos

Comenzamos el desarrollo del proyecto AC automatizando el caso de uso hello-cloud en el primer SLEEVE. El caso de uso hello-cloud crea un sitio Volterra en AWS y Azure, luego combina estos sitios en un clúster Volterra VK8s (Kubernetes virtual) e implementa una aplicação de 10 pods en ambos sitios usando los VK8s. Comenzamos el proceso creando plantillas de Terraform adicionales y scripts de shell utilizando la API de Volterra para crear un flujo de trabajo totalmente automatizado en GitLab que las canalizaciones de CI/CD pudieran administrar. Luego nos pusimos a trabajar para hacer que esta metodología de implementación sea reutilizable y escalable.

El siguiente problema que abordamos en nuestro diseño fue agregar convenciones de nombres únicas. Para permitir múltiples implementaciones del caso de uso en un único entorno de inquilino de Volterra, necesitábamos asegurarnos de que nuestros recursos creados en cada PILA tuvieran nombres únicos y no intentaran crear recursos con nombres que duplicaran otras PILAS en el mismo entorno de inquilino de Volterra. Para resolver posibles conflictos de convenciones de nombres, comenzamos a incorporar la idea de variables ambientales únicas proporcionadas por el usuario en los activadores de la canalización que se volverían centrales para el proyecto. Terraform introdujo y utilizó la variable ambiental STACK_NAME para incluir una cadena definida por el usuario en los nombres de todos los recursos asociados con un STACK específico. En lugar de activarse al confirmar, las condiciones de activación de los trabajos de las canalizaciones de AC se configuraron para ejecutarse solo cuando se activan mediante una llamada a la API de usuarios de GitLab mediante un token de activación de CI del proyecto de GitLab, lo que permite que la canalización se controle mediante la entrada humana o llamadas a la API externas. Al usar llamadas API similares al siguiente ejemplo, permitió a los usuarios lograr nuestro objetivo de crear múltiples implementaciones sin conflictos de recursos con un solo comando.

Luego nos esforzamos por crear opciones de implementación adicionales a partir de este modelo. Las implementaciones de hello-cloud en AWS y Azure también fueron casos de uso individuales que queríamos implementar de forma independiente con AC. Esto nos llevó a encontrarnos con nuestro primer problema importante con GitLab. En las canalizaciones CI/CD de GitLab, todos los trabajos en una canalización de proyectos están conectados. Esto era contra-intuitivo, ya que muchos trabajos necesarios en nuestra implementación de hello-cloud no serían necesarios en nuestras implementaciones de sitios de AWS o Azure. Básicamente queríamos que una tubería CI del Proyecto GitLab contuviera múltiples tuberías independientes que pudieran activarse a pedido con conjuntos separados de trabajos de CI cuando fueran necesarios.

Para resolver este problema, introdujimos la variable ambiental SLEEVE en la estructura de la canalización que incorporaba las opciones solo/excepto de GitLab CI/CD. Esto permitió que los trabajos de CI activados en cualquier canalización se limitaran en función del valor de SLEEVE proporcionado en el activador de la canalización. Finalmente, teníamos nuestras 3 opciones iniciales de SLEEVE: simple-aws, simple-azure y hello-cloud. Cada SLEEVE definiría qué caso de uso deseaba un usuario implementar (controlando así los trabajos de CI en una canalización activada) y un STACK_NAME para nombrar los recursos creados por cualquier canalización activada. La siguiente estructura de comando que incorpora ambas variables ambientales sirvió como el comando AC más básico que todavía se utiliza en la actualidad:

La siguiente imagen muestra una visualización de cómo el cambio de la variable ambiental SLEEVE cambiará los trabajos activados en cada ejecución de la tubería de AC.

Tubería SLEEVE “simple-aws”:

Tubería de “hola-nube” de SLEEVE:

También introdujimos trabajos adicionales que se activarían si se proporcionara la variable ambiental DESTROY en cualquier activador de canalización. Esto ofrecería una opción inversa para eliminar los recursos creados por AC. El siguiente es un ejemplo de cómo eliminar los recursos de una pila existente:

Otras variables ambientales se almacenaron en GitLab con valores predeterminados que podrían anularse agregando valores al comando de activación. Por ejemplo, la URL de la API de nuestros entornos de inquilinos de Volterra se almacenó en la variable ambiental VOLTERRA TENANT. Si un usuario agregó la variable ambiental VOLTERRA TENANT a su comando API, esto anularía el valor predeterminado y redirigiría la implementación a la ubicación deseada. Esto resultó ser muy importante para nuestra capacidad de prueba interna, ya que el equipo de soluciones administra docenas de entornos de inquilinos de Volterra y necesita la capacidad de cambiar entre ellos según la tarea en cuestión:

Estas variables de entorno opcionales podrían usarse para agregar un mayor nivel de control a las implementaciones cuando sea necesario, pero permitieron una opción de implementación predeterminada más simplista para los usuarios que no querían administrar esta sobrecarga adicional. También nos permitió cambiar fácilmente entre implementaciones en entornos de preparación y producción, lo que resultaría esencial para nuestro mayor consumidor de AC.

Caso de uso de soluciones: Pruebas de regresión nocturna

Como se mencionó anteriormente, cada SLEEVE en AC representaba un caso de uso de Volterra que a menudo sería la primera interacción de los clientes con el producto. Garantizar que estos casos de uso fueran funcionales y estuvieran libres de errores fue clave para brindar una buena primera impresión del producto. Antes de crear AC, probar los casos de uso para confirmar que fueran funcionales y estuvieran actualizados con las últimas versiones del software y API de Volterra era una tarea que consumía mucho tiempo. Las partes manuales requeridas para cada caso de uso crearon una limitación en las pruebas de regresión, que no se realizaron con la frecuencia suficiente y eran propensas a errores humanos.

Sin embargo, con la automatización de CA, los trabajos programados diariamente podrían usarse para activar una implementación de cualquier caso de uso específico con un SLEEVE y luego eliminar los recursos creados después de que la implementación se haya completado o no se haya podido implementar. Esto se utilizó tanto en entornos de prueba como de producción para probar si los cambios recientes en cualquiera de ellos habían afectado la implementación del caso de uso o habían causado errores en el software Volterra. Entonces podríamos actualizar los errores encontrados en nuestras guías de casos de uso o detectar rápidamente errores del software de Volterra y enviar tickets de resolución.

Creamos un repositorio y una canalización separados con trabajos programados que usarían los comandos de activación de la API de GitLab para generar simultáneamente múltiples pilas usando diferentes SLEEVE. Cada trabajo de prueba de humo comenzaría activando la creación de una pila con una tubería de CA independiente. Luego, el trabajo de prueba de humo obtendría el ID de la tubería desde la salida estándar de la llamada de activación de la tubería y la API de GitLab para monitorear el estado de la tubería que activó. Cuando se completaba la canalización (ya sea con éxito o con un fracaso), se ejecutaba la canalización de destrucción en la misma PILA que creó para eliminar los recursos después de la prueba.

La siguiente imagen detalla este proceso y muestra los trabajos que desencadena en AC para sus comandos de creación y destrucción:

Cuando falló una tubería de prueba de humo, pudimos proporcionar las variables ambientales que podrían usarse en un disparador de CA para reproducir el problema. Esto se podría proporcionar en nuestros tickets de problemas técnicos, lo que permitiría a nuestros desarrolladores recrear fácilmente las implementaciones fallidas. Luego, a medida que se completaron más SLEEVES, agregamos más y más trabajos a las tuberías de CI, lo que permitió una mayor cobertura de pruebas. Para mejorar aún más la visibilidad de estas pruebas, agregamos una integración de Slack e hicimos que los trabajos de prueba de humo enviaran el mensaje de éxito o fracaso de cada ejecución de canalización con enlaces y detalles a las páginas web de CI correspondientes en los proyectos Altered-Carbon y Smoke-Test.

Mantenimiento de registros de pila y navegación por URL web de canalización

La complejidad del proyecto aumentó a medida que AC evolucionó, agregó usuarios adicionales del equipo de soluciones y creó más y más pilas. Esto empezó a generar problemas fundamentales al navegar por la interfaz web de GitLab Pipeline. Usábamos las pipelines de GitLab de una forma muy poco convencional, lo que dificultaba el seguimiento de las ejecuciones individuales de las pipelines relacionadas con los STACKs que creábamos.

Las canalizaciones de GitLab que administran implementaciones a través de flujos de trabajo de GitOps parecen ser más adecuadas cuando se utilizan contra un conjunto definido y estático de clústeres. En este caso, cada ejecución de una canalización de GitLab afectaría a los mismos clústeres y recursos cada vez. En este caso, el historial de implementación de estos clústeres corresponde al historial de la canalización visualizado en la interfaz web de GitLab. Sin embargo, AC es dinámico y gestiona un conjunto de recursos en constante cambio, donde cada ejecución de la canalización puede utilizar un conjunto de trabajos totalmente diferente, gestionando diferentes pilas de recursos en distintos proveedores de virtualización. Esta diferenciación creada por las convenciones SLEEVE y STACK significó que es muy difícil determinar qué canalización corresponde a qué pila. Por ejemplo, podemos echar un vistazo a la interfaz de usuario web de la canalización CI/CD de GitLab para AC:

Desde esta vista, no podemos determinar qué PILA o FUNDA está cambiando cada tubería individual sin ver todas y cada una de las tuberías individualmente. Cuando se ejecutan cientos de canalizaciones por día, puede resultar tedioso encontrar la canalización específica que creó o destruyó una PILA en particular o localizar detalles específicos sobre dicha PILA. Para resolver este problema desde el principio del desarrollo del AC, agregamos un sistema simple de mantenimiento de registros. Un trabajo se ejecutaría antes de cualquier canalización llamada stack-records. Este trabajo recopilaría detalles sobre la pila durante la creación y generaría un archivo json que se cargaría en nuestro depósito de almacenamiento S3 utilizado para almacenar nuestras copias de seguridad de tfstate. A continuación vemos un ejemplo de un registro de pila:

Los archivos stack-record.json incluyen detalles de cada pila como:

• ¿Qué entorno de inquilino de Volterra se utilizó?
• ¿Qué MANGA se utilizó?
• Si la PILA estaba actualmente ejecutándose en el estado “aplicar” o si sus recursos fueron eliminados con el estado “destruir”.
• ¿Qué usuario de GitLab creó la pila?
• Un grupo de trabajo que incluye otros usuarios con acceso para cambiar una PILA.
• Y lo más importante, una matriz de pipelines que incluiría la URL web de cada pipeline que se ejecutó contra la pila, quién activó el pipeline, si el pipeline aplicó o destruyó una pila y cuándo se activó el pipeline.

Esto proporcionó un historial registrado de todas las URL de canalización asociadas con cualquier pila y se creó un script CLI simple que puede acceder a estos archivos a través de llamadas API S3 para simplificar aún más el proceso. Nuestros usuarios que consumen AC podrían usar estos documentos para rastrear el historial de pilas y ver cuándo se modificaron estas pilas al visualizar los registros de pilas.

Los registros de pila también nos permitieron implementar ciertos niveles de control de usuario y detección de errores en las canalizaciones que implementamos. Por ejemplo, un cambio realizado en el software Volterra después de la creación de AC nos obligó a comenzar a limitar los nombres de los grupos de sitios (un valor derivado del valor STACK NAME) utilizados en la creación de sitios Volterra a un límite de 17 caracteres. Por lo tanto, agregamos una verificación en el trabajo de registros de pila que provocaría que las canalizaciones fallaran antes de ejecutar cualquier paso de implementación si el NOMBRE DE LA PILA violaba el límite de caracteres. Se agregaron otros controles personalizados, como la incorporación de niveles de permisos de usuario en AC que limitan qué usuarios tienen acceso para cambiar pilas específicas controladas por AC.

• Permisos de nivel de administrador donde los dos desarrolladores principales de AC tienen la capacidad de crear o destruir cualquier pila para fines de depuración. -El nivel de propietario o creador es para un usuario de GitLab que crea inicialmente una PILA. Su valor de correo electrónico de GitLab se registra en los registros de la pila como creador y tiene la capacidad de crear o destruir una pila.
• Luego tenemos permisos a nivel de grupo de trabajo, el correo electrónico del usuario de GitLab se puede agregar a la matriz del grupo de trabajo del registro de la pila, lo que otorga a otros usuarios además del creador la capacidad de aplicar o destruir una PILA.
• Un usuario sin ninguno de estos niveles de permiso no podrá cambiar una pila. Si un usuario intenta cambiar una pila sobre la cual no tiene permiso, el trabajo de registros de pila fallará antes de que se implementen los recursos.

Uso interno y cobertura de pruebas actual

Hoy en día, AC se ha convertido en un elemento central del equipo de soluciones y proporciona la mayor parte de nuestras pruebas de regresión y automatización. Encontramos que sus principales usos son las pruebas de humo de regresión, pruebas de escala, pruebas de facturación de productos y para implementaciones simplificadas utilizadas en demostraciones de productos.

Las implementaciones automatizadas encontraron su mayor consumidor en nuestras pruebas de regresión nocturna. Cada noche probamos cada uno de nuestros SLEEVES en un entorno de producción y ensayo activando una implementación y luego desmantelando los recursos creados. Cuando se producen cambios, podemos detectarlos rápidamente y enviar informes de errores para actualizar nuestras guías. Nuestra cobertura de pruebas actual incluye:

• Puerta de enlace segura de Kubernetes.
• Seguridad de aplicação web.
• Aplicações de borde de red que implementan nuestra aplicação estándar de 10 pods “hipster-co” y una aplicação de pod único más liviana.
• Hola-Nube.
• Interfaz de red única de nodo único CE para sitios Volterra en AWS, GCP, Azure, VSphere y KVM/Vagrant.
• Interfaz de red doble de nodo único CE para sitios Volterra en AWS, GCP, Azure, VSphere y KVM/Vagrant.
• Se escalaron implementaciones de sitios Volterra con una sola interfaz de red y un solo nodo CE (usando GCP, VSphere y KVM), creando una cantidad de sitios Volterra con una sola interfaz de red y un solo nodo CE para probar las capacidades de escalamiento de Volterra.
• Interfaz de red múltiple de nodo único CE para sitios Volterra en AWS, GCP, Azure, VSphere y KVM/Vagrant.
• Interfaz de red única de múltiples nodos CE para sitios Volterra en AWS, GCP, Azure, VSphere y KVM/Vagrant.
• Interfaz de red múltiple de múltiples nodos CE para sitios Volterra en AWS, GCP, Azure, VSphere y KVM/Vagrant.

También contamos con mangas de prueba de escala especializadas que automatizan el proceso de implementación de hasta 400 sitios a la vez para probar las capacidades de escalamiento del software Volterra y se han probado con GCP, vSphere y KVM.

La rápida implementación automatizada de casos de uso permite a los miembros del equipo de soluciones concentrarse en otras tareas, mejorando la eficiencia interna. El equipo de soluciones a menudo utiliza AC para implementar docenas de sitios KVM, GCP y vSphere para grabar demostraciones de video, lo que nos ahorra tiempo en la creación de sitios Volterra para usar en la creación de infraestructura más compleja, aprovechando la automatización que tenemos implementada. Esto también se utiliza para trabajos cron diarios que prueban las funciones de facturación de la plataforma Volterra al automatizar la implementación de AWS, seguridad de aplicaciones web, puerta de enlace segura de Kubernetes y casos de uso de aplicação de borde de red en un inquilino Volterra especializado que registra información de facturación.

Planes futuros y hoja de ruta

Nuestro uso de CA ya está dando resultados muy exitosos y todavía quedan muchas más características y mejoras por agregar al proyecto en el futuro cercano.

La mayor novedad del proyecto es la incorporación constante de nuevas opciones de SLEEVE para cubrir implementaciones de casos de uso adicionales. Por cada nuevo SLEEVE agregado, agregamos un nuevo trabajo a nuestras pruebas de humo de regresión nocturnas, lo que proporciona más cobertura para los proyectos de implementación de soluciones. La mayoría de las mangas anteriores se centraban en casos de uso de un solo nodo y una sola interfaz de red, pero recientemente hemos ampliado nuestra cobertura SLEEVE a clústeres de sitios Volterra de múltiples nodos y casos de uso de interfaz de múltiples redes en plataformas AWS, Azure, GCP, VMWare y KVM/Vagrant.

También buscamos mejorar nuestro sistema de registro de pilas. Aumentaremos el nivel de detalle en nuestros registros de AC y agregaremos funcionalidades de búsqueda mejoradas con la incorporación de almacenes de bases de datos RDS para nuestros registros. El objetivo es que podamos proporcionar búsquedas más rápidas de nuestro entorno AC y una funcionalidad de búsqueda más selectiva, como búsquedas de pila basadas en el estado de la pila, creadores de pila, etc. El uso de estos registros para construir una interfaz de usuario personalizada para visualizar de manera más eficiente las implementaciones creadas con AC también está en nuestra hoja de ruta.