Flujos de trabajo GitOps con acciones GitHub en Vonage

Recientemente hemos rediseñado un proceso clave de creación e implementación para nuestra plataforma Vonage Contact Center. Aprovechamos la oportunidad para trasladar esta canalización a un diseño GitOps compatible con la seguridad. En esta entrada del blog, explicaré qué se entiende por GitOps y cómo se rediseñó nuestra canalización para beneficiarse de este concepto.

Concepts de Gitops: ¿Qué es GitOps?

En términos generales, GitOps es una colaboración de las mejores prácticas de DevOps y Seguridad. La principal diferencia entre DevOps y GitOps es la incorporación de IaC (Infrastructure as Code), que se almacena junto con el código del proyecto en SCM (Source Code Management), normalmente Git.

GitOps es un marco más que un paquete de software o una herramienta individual. En mi opinión, este es uno de sus puntos fuertes. Con GitOps tienes la libertad y la flexibilidad de adaptar la aplicación para que se adapte mejor a tu organización y mejore tus procesos.

GitOps se compone de tres conceptos distintos:

1. Infraestructura como código (IaC)

Las herramientas de IaC permiten diseñar y configurar la infraestructura una vez y desplegarla de forma repetible, con funciones de gestión de estados que evitan que los recursos activos se desvíen de su configuración original. Una vez definidos, estos datos de configuración pueden mantenerse bajo control de origen, lo que permite mantener una única fuente de verdad para la infraestructura (así como los permisos y políticas de seguridad asociados).

Además, con una estructura de repositorio bien diseñada, los conceptos de Seguridad de Mínimo Privilegio y Separación de Funciones se logran fácilmente para estos datos.

2. Solicitudes de extracción (PR)

Todos los cambios de código deben controlarse mediante PR. Esta protección se aplica tanto al código de la aplicación como al código IaC que describe la infraestructura de apoyo.

Los desarrolladores deben tener permiso para fusionar código a través de PR en el repositorio de aplicaciones, pero no deben tener permisos directos para realizar actualizaciones en el canal de GitOps o en los repositorios de infraestructura.

3. Integración continua / Entrega continua (CI/CD)

GitOps automatiza los procesos de CI/CD mediante la integración y entrega continuas. La integración continua se activa mediante un push a la rama principal. El despliegue se activa manual o automáticamente tras la finalización satisfactoria de las comprobaciones de calidad.

Las pruebas de seguridad pueden integrarse en el SDLC (ciclo de vida del desarrollo de software) mucho más fácilmente con GitOps. Además, como el ciclo de iteración es mucho más rápido, esto significa más facilidad y menos fricción en la adopción de la Seguridad. Esto fomenta un enfoque en la prevención en lugar de la detección, lo que comúnmente se conoce como "desplazamiento a la izquierda".

Cómo implantamos GitOps

Contexto

Nuestro objetivo era construir un pipeline GitOps CI/CD para la entrega de componentes Micro-FrontEnd en los entornos alojados en la nube de Vonage Contact Centre. El canal es un reemplazo de una versión anterior y, como tal, se requería un diseño que redujera significativamente la fricción del desarrollo y los tiempos de despliegue, mejorara la seguridad y, como consecuencia, mejorara la DevEx (experiencia del desarrollador).

Investigación y requisitos

Dado que esta fue nuestra primera exposición práctica a GitOps, llevamos a cabo una investigación inicial sobre el marco de GitOps y realizamos un pico para probar algunos enfoques diferentes. Dada la naturaleza de nuestros requisitos y las inevitables limitaciones en el trabajo, optamos por adoptar el modelo basado en eventos de GitHub Actions con una combinación de herramientas CLI nativas de la nube, para permitirnos controlar las actualizaciones en la infraestructura alojada en la nube (en este caso, CDN, funciones de código sin servidor y una base de datos NoSQL). En nuestra arquitectura GitOps sólo necesitamos un evento. El despliegue de Applications se activa mediante un evento GitHub repository_dispatch que se origina en el repositorio de Applications y se dirige al repositorio de GitOps, donde se activa el despliegue automáticamente.

Una vez que estuvimos seguros de que GitOps era una solución viable, refinamos nuestros requisitos:

• Mejorar la postura de seguridad mediante la adhesión a los principios de Mínimo Privilegio y Separación de Funciones.

• Proporcionar a los desarrolladores información oportuna sobre el despliegue

• Reducir las fricciones de despliegue y mejorar así los tiempos de despliegue y DevEx.

• Métricas de despliegue de apoyo

• Utilizar canalizaciones GitOps CI/CD mantenibles

• Escalabilidad horizontal (integración sin fisuras de nuevas aplicaciones en el pipeline de GitOps).

• Aprovechar y mejorar las herramientas internas cuando sea necesario.

Arquitectura GitOps

Repositorios de infraestructuras

Terraform fue nuestra herramienta elegida para el despliegue y la gestión de la infraestructura en la nube en la que se alojarían los componentes de MFE. Este enfoque de IaC es útil para controlar infraestructuras que no cambian con frecuencia.

Cada uno de los recursos necesarios para alojar los componentes MFE se capturó en módulos Terraform, junto con los objetos de seguridad y permisos de apoyo necesarios. Para mantener estos componentes se utiliza una canalización CI/CD de Terraform preexistente.

Repositorios de Applications

Los desarrolladores (y el propio repositorio de aplicaciones MFE) tienen permisos limitados para las herramientas y sistemas de desarrollo. Por lo tanto, un flujo de trabajo de CI definido mediante acciones de Github se encarga de estas responsabilidades, proporcionando funciones clásicas de construcción y calidad en un proceso automatizado y planificado. Los artefactos de construcción producidos por este proceso se envían a un repositorio de paquetes (jFrog Artifactory).

Application CI Workflow

Un flujo de trabajo de CD en el mismo repositorio ofrece al desarrollador la posibilidad de desplegar la aplicación. En concreto, se trata de un evento de GitHub repository_dispatch al repositorio GitOps de destino, seguido de un paso de espera de finalización.

Ejemplo de acción de GitHub que activa el despliegue de aplicaciones:

- name: Deploy MFE ${{ env.MFE_NAME }} version ${{ env.MFE_VERSION }} to ${{ env.MFE_ENVIRONMENT }}
  uses: peter-evans/repository-dispatch@11ba7d3f32dc7cc919d1c43f1fec1c05260c26b5 # v2.0.0
  with:
    token: ${{ secrets.GITOPS_GITHUB_TOKEN }}
    repository: ${{ env.GITOPS_REPOSITORY }}
    event-type: deploy-mfe-trigger
    client-payload: '{
                        "type": "deploy-mfe-trigger",
                        "timestamp": "${{ env.DATEANDTIME }}",
                        "user": "${{ github.actor }}",
                        "mfe": "${{ env.MFE_NAME }}",
                        "version": "${{ env.MFE_VERSION }}",
                        "environment": "${{ env.ENVIRONMENT }}",
                        "cache_invalidation_keys": "${{ env.CACHE_INVALIDATION_KEYS }}",
                        "repository": "${{ github.repository }}",
                        "ref": "${{ github.ref }}",
                        "sha": "${{ github.sha }}"
                    }'

Application CD GitOps Workflow

Repositorio GitOps IaC

Este repositorio constituye la base de nuestro marco GitOps. Tiene los permisos necesarios para desplegarse en un proveedor de nube determinado. Tenga en cuenta que está separado de los repositorios de aplicaciones MFE, adhiriéndose así a los principios de Seguridad de Mínimo Privilegio y Separación de Funciones (así como desplazar la Seguridad hacia la izquierda).

Los eventos de despliegue se reciben del flujo de trabajo de CD de la aplicación y se procesan automáticamente. En esencia, hay tres pasos distintos en el proceso de GitOps:

1. Proceso GitHub repository_dispatch eventos

   1. aceptar/rechazar

   2. actualización de la configuración IaC basada en metadatos de eventos

   3. aumentar las relaciones públicas

2. Fusionar PR automáticamente

   1. realizar controles de calidad

   2. fusionar PR si se superan los controles de calidad

3. Despliegue de la aplicación

   1. copiar el artefacto de construcción en el almacenamiento en la nube

   2. actualizar tabla BD

   3. invalidar caché CDN

GitOps Operations Deployment Workflow

Herramienta de despliegue de infraestructuras en nube

Hemos creado una herramienta CLI que interactúa con nuestro proveedor de nube y permite implantar aplicaciones sin problemas.

Abstraer la lógica de despliegue en este nuevo proyecto CLI nos ha permitido gestionar los detalles de la lógica de despliegue al tiempo que nos aseguramos de que las nuevas funciones se prueban antes de pasar a la cadena de producción.

Marco del proyecto Micro-FrontEnd CLI

Se trata de una herramienta interna que proporciona un marco CI/CD para el desarrollo en varios lenguajes. Utilizamos esta herramienta para acortar la parte "complicada" de la creación y actualización de nuestros proyectos de software, ya que proporciona elementos como un esqueleto de código de componentes, opciones de configuración comunes y plantillas de canalización de CI/CD. Es compatible con diversos tiempos de ejecución de lenguajes y tipos de componentes.

Desde el principio decidimos mejorar la herramienta para que fuera compatible con el nuevo marco de GitOps para los MFE, para mejorar la experiencia de los desarrolladores al crear nuevos MFE y también para ayudar a migrar los componentes MFE existentes al nuevo canal de CI/CD. Nuestros cambios en esta herramienta significan que creará automáticamente los flujos de trabajo CI/CD GitOps necesarios para los proyectos Micro-FrontEnd.

Para adoptar el pipeline GitOps en un proyecto nuevo o ya existente, deberá renderizar el proyecto con la herramienta CLI.

¿Adónde iríamos después?

Este proyecto nos ha dado una gran oportunidad de familiarizarnos con los Concepts de GitOps y nos ha permitido conocer las áreas en las que podríamos mejorar aún más. Estas son algunas de las cosas que podríamos emprender a continuación:

• Trabaja estrechamente con los equipos de Seguridad de Vonage para definir los requisitos de Cumplimiento de Seguridad como configuración (YAML, Terraform, ...). Cuando esto forma parte del SDLC (y es parte de los ciclos continuos de revisión/refinamiento), entonces estás seguro de cumplir con la conformidad y tienes la capacidad de proporcionar pruebas de cumplimiento.

• Considerar la posibilidad de utilizar ejecutores autoalojados de GitHub Actions, para tener más control sobre el escalado, la configuración y los costes. Este paso debe considerarse cuidadosamente, ya que introduce un equilibrio entre la seguridad de los ejecutores, el coste y la facilidad de mantenimiento.

• Crear/adoptar una GitOps GitHub App similar a las operaciones disponibles para K8s.

Reflexiones finales

Espero que este blog haya sido informativo y haya demostrado algunas de las ventajas de adoptar GitOps en su proceso de desarrollo.

Asegúrese de seguirnos en Twitter y únete a nuestro canal de Slack para obtener más información.

Gracias por leerme.