Flujo de trabajo de CI/CD mediante GitOps (Flux v2)

Las implementaciones modernas de Kubernetes contienen múltiples aplicaciones, clústeres y entornos. Con GitOps, puede administrar estas configuraciones complejas más fácilmente, con un seguimiento del estado deseado de los entornos de Kubernetes mediante declaración con Git. Con las herramientas comunes de Git para declarar el estado del clúster, puede aumentar la responsabilidad, facilitar la investigación de errores y habilitar la automatización para administrar entornos.

En este artículo se describe cómo GitOps encaja en el ciclo de vida completo del cambio de aplicación mediante Azure Arc, Azure Repos y Azure Pipelines. También proporciona un ejemplo de un único cambio de aplicación en entornos de Kubernetes controlados por GitOps.

Architecture

En este diagrama se muestra el flujo de trabajo de CI/CD para una aplicación implementada en uno o varios entornos de Kubernetes.

Repositorio de código de la aplicación

El repositorio de aplicaciones contiene el código de aplicación en el que trabajan los desarrolladores durante su bucle interno. Las plantillas de implementación de la aplicación residen en este repositorio de forma genérica, como Helm o Kustomize. No se almacenan los valores específicos del entorno.

Los cambios en este repositorio invocan una canalización de PR o CI que inicia el proceso de implementación.

Registro de contenedor

El registro de contenedor contiene todas las imágenes propias y de terceros que se usan en los entornos de Kubernetes. Las imágenes de aplicación de primera entidad se etiquetan con etiquetas legibles y la confirmación de Git que se usa para compilar la imagen. Las imágenes de terceros se pueden almacenar en caché para ayudar con la seguridad, la velocidad y la resistencia. Establezca un plan para las pruebas y la integración oportunas de las actualizaciones de seguridad.

Para obtener más información, consulte Consumo y mantenimiento de contenido público con Azure Container Registry Tasks.

Canalización de PR

Las solicitudes de incorporación de cambios de los desarrolladores realizadas en el repositorio de aplicaciones se registran en una ejecución correcta de la canalización de PR. Esta canalización ejecuta las pruebas de calidad básicas, como el proceso de linting y las pruebas unitarias en el código de la aplicación. La canalización prueba la aplicación y aplica procesos de linting en los archivos de Docker y las plantillas de Helm utilizados para realizar implementaciones en un entorno de Kubernetes. Las imágenes de Docker se deben compilar y probar, pero no se pueden insertar. Mantenga una duración de la canalización relativamente corta para permitir una iteración rápida.

Canalización de CI

La canalización de CI de la aplicación ejecuta todos los pasos de canalización de PR, ampliando las comprobaciones de prueba e implementación. La canalización se puede ejecutar para cada confirmación en main o puede ejecutarse con una cadencia regular con un grupo de confirmaciones.

En esta fase, se pueden realizar pruebas de aplicación que consumen demasiado para la canalización de PR, entre las que se incluyen:

• Inserción de imágenes en el registro de contenedor
• Creación, linting y prueba de imágenes
• Generación de plantillas de archivos YAML sin formato

Al final de la compilación de CI, se generan artefactos. El paso de CD puede usar estos artefactos para usarlos como preparación para la implementación.

Extensión de clúster de Flux

Flux es un agente que se ejecuta en cada clúster como una extensión de clúster. Esta extensión de clúster de Flux es responsable de mantener el estado deseado. El agente sondea el repositorio de GitOps en un intervalo definido por el usuario y, a continuación, reconcilia el estado del clúster con el estado declarado en el repositorio de Git.

Para obtener más información, consulte Tutorial: Implementación de aplicaciones con GitOps con Flux v2.

Canalización de CD

La canalización de CD se desencadena automáticamente mediante compilaciones de CI correctas. En este entorno de canalización, los valores específicos del entorno se sustituyen en las plantillas publicadas anteriormente y se genera una nueva solicitud de incorporación de cambios en el repositorio de GitOps con estos valores. Esta solicitud de incorporación de cambios contiene los cambios propuestos en el estado deseado de uno o varios clústeres de Kubernetes. Los administradores de clústeres revisan la solicitud y aprueban la combinación en el repositorio de GitOps. La canalización espera a que se combine la solicitud de incorporación de cambios, después de lo cual Flux se sincroniza y aplica los cambios de estado.

Repositorio de GitOps

El repositorio de GitOps representa el estado deseado actual de todos los entornos de los clústeres. El servicio Flux recoge cualquier cambio en este repositorio en cada clúster y lo implementa. Los cambios en el estado deseado de los clústeres se presentan como solicitudes de incorporación de cambios, que luego se revisan y, por último, se combinan tras la aprobación de los cambios. Estas solicitudes contienen cambios en las plantillas de implementación y los manifiestos de Kubernetes representados resultantes. Los manifiestos representados de bajo nivel permiten una inspección más minuciosa de los cambios que normalmente no se muestran en el nivel de plantilla.

GitOps Connector

GitOps Connector crea una conexión entre el agente de Flux y la canalización del repositorio de GitOps/CD. Mientras se aplican cambios al clúster, Flux notifica al conector de GitOps de cada cambio de fase y comprobación de estado realizada. Este componente hace las veces de adaptador. Comprende cómo comunicarse con un repositorio de Git y actualiza el estado de confirmación de Git para que el progreso de la sincronización sea visible en el repositorio de GitOps. Cuando finaliza la implementación (tanto si se realiza correctamente como si se produce un error), el conector notifica a la canalización de CD que continúe para que esta pueda realizar actividades posteriores a la implementación, como las pruebas de integración.

Clústeres de Kubernetes

Al menos un clúster de Kubernetes habilitado para Azure Arc de Azure Kubernetes Service (AKS) presta servicio a los distintos entornos que necesita la aplicación. Por ejemplo, un único clúster puede atender a un entorno de desarrollo y QA a través de espacios de nombres diferentes. Un segundo clúster puede proporcionar una separación más sencilla de los entornos y un control más preciso.

Flujo de trabajo de ejemplo

Como desarrolladora de aplicaciones, Alice:

• Escribe el código de la aplicación.
• Determina cómo ejecutar la aplicación en un contenedor de Docker.
• Define las plantillas que ejecutan el contenedor y los servicios dependientes en un clúster de Kubernetes.

Alice quiere asegurarse de que la aplicación tiene la capacidad de ejecutarse en varios entornos, pero no conoce la configuración específica de cada entorno.

Suponga que Alice desea hacer un cambio en la aplicación que modifique la imagen de Docker que se usa en la plantilla de implementación de la aplicación.

1. Alice cambia la plantilla de implementación, la inserta en una rama remota denominada alice en el repositorio de aplicaciones y abre una solicitud de incorporación de cambios para revisarla con relación a la rama main.

2. Alice pide a su equipo que revise el cambio.

   • La canalización de PR ejecuta la validación.
   • Después de una ejecución correcta de la canalización de PR y la aprobación del equipo, el cambio se combina.

3. A continuación, la canalización de CI aplica y valida el cambio de Alice y se completa correctamente.

   • Es seguro implementar el cambio en el clúster, y los artefactos se guardan en la ejecución de la canalización de CI.

4. La ejecución correcta de la canalización de CI desencadena la canalización de CD.

   • La canalización de CD detecta los artefactos almacenados por la ejecución de la canalización de CI de Alice.
   • La canalización de CD sustituye las plantillas por valores específicos del entorno y realiza los cambios con respecto al estado del clúster existente en el repositorio de GitOps.
   • La canalización de CD crea una solicitud de incorporación de cambios en la rama de producción del repositorio de GitOps con los cambios deseados en el estado del clúster.

5. El equipo de Alice revisa y aprueba su solicitud.

   • El cambio se combina en la rama de destino correspondiente al entorno.

6. En cuestión de minutos, Flux observa un cambio en el repositorio de GitOps e incorpora el cambio de Alice.

   • Debido al cambio de imagen de Docker, el pod de aplicación requiere una actualización.
   • Flux aplica el cambio al clúster.
   • Flux informa del estado de implementación al repositorio de GitOps a través de GitOps Connector.

7. La canalización de CD ejecuta pruebas automatizadas para comprobar que la nueva implementación se ha completado correctamente y funciona según lo previsto.

   Nota:

   Para proporcionar entornos adicionales destinados a la implementación, la canalización de CD se itera creando una solicitud de incorporación de cambios para el siguiente entorno y repite los pasos del 4 al 7. El proceso puede necesitar una aprobación adicional para implementaciones o entornos de más riesgo, como un cambio relacionado con la seguridad o un entorno de producción.

8. Cuando todos los entornos han recibido implementaciones correctas, la canalización se completa.

Pasos siguientes

• Recorra nuestro tutorial de para implementar CI/CD con GitOps.
• Obtenga información sobre cómo crear conexiones entre el clúster y un repositorio de Git con configuraciones de Flux.