Creación de una canalización de CI/CD para aplicaciones de AKS mediante Azure Pipelines

Importante

En este artículo se describe una versión de la arquitectura de línea base de integración continua e implementación continua (CI/CD). Se centra específicamente en la implementación de aplicaciones de Azure Kubernetes Service (AKS) mediante Azure Pipelines.

Azure Pipelines organiza las actividades de implementación en AKS como parte de un plan de entrega de aplicaciones repetible. Puede integrar los procesos de compilación y versión en una canalización para reducir el riesgo de error humano, acelerar los ciclos de versión y mejorar la calidad general del software. En este artículo se describe cómo usar Azure Pipelines para implementar CI/CD e insertar actualizaciones de aplicaciones en clústeres de AKS.

Architecture

Diagrama de arquitectura de una canalización de CI/CD de AKS que usa Azure Pipelines.

El flujo va de izquierda a derecha. Comienza con el paso 1, donde un ingeniero envía los cambios de código a un repositorio Git de Azure Repos y se activa una canalización de PR de Azure Pipelines. Esta canalización incluye las siguientes tareas: Restauración, compilación, pruebas unitarias, revisión de PR y análisis de código que incluye lint, examen de seguridad y otras herramientas. En el paso 2, se desencadena una CI pipeline de Azure Pipelines. Esta canalización incluye las siguientes tareas: Recuperar secretos, análisis de código, restaurar, compilar, pruebas unitarias, pruebas de integración, publicar los artefactos de compilación y las imágenes de contenedor. En el paso 3, una imagen de contenedor se publica en un registro de contenedor de Azure que no es de producción. En el paso 4, se desencadena una canalización de CD de Azure Pipelines. Esta canalización incluye las siguientes tareas: Implementación en ensayo, pruebas de aceptación, promoción de la imagen de contenedor, intervención manual opcional y versión. En el paso 5, la canalización de CD se implementa en un entorno de ensayo que incluye Azure Kubernetes Service (AKS). En el paso 6, se promueve la imagen de contenedor al registro de contenedores de Azure para producción. En el paso 7, el pipeline de CD se publica en un entorno de producción que incluye AKS. En el paso 8, el servicio administrado de Azure Monitor para Prometheus reenvía la telemetría a Azure Monitor. El paso 9 se representa mediante una sección que incluye un operador, Azure Monitor, servicio administrado de Azure Monitor para Prometheus, un área de trabajo de Log Analytics, Seguridad de Microsoft DevOps, almacenes de claves, Azure Managed Grafana y Defender for Cloud. Una línea discontinua conecta el paso 1 con Seguridad de Microsoft DevOps en el diagrama. Varias líneas discontinuas van del paso 2, el paso 4 y de la línea que conecta el paso 4 con los entornos de ensayo y producción al ingeniero.

Descargue un archivo de Visio de esta arquitectura.

Flujo de datos

El siguiente flujo de datos corresponde al diagrama anterior:

  1. Una solicitud de incorporación de cambios (PR) a un repositorio de Git de Azure Repos o a un repositorio de GitHub desencadena una canalización de PR.

    Esta canalización ejecuta comprobaciones de calidad, incluidas las siguientes operaciones:

    • Compilación de código, que puede requerir la extracción de dependencias de un sistema de administración de dependencias
    • Uso de herramientas para analizar el código, como análisis estático de código, linting y análisis de seguridad
    • Realización de pruebas unitarias

    Si se produce un error en alguna comprobación, la ejecución de la canalización finaliza y el desarrollador debe realizar los cambios necesarios. Si se pasan todas las comprobaciones, el pipeline requiere una revisión de PR. Si se produce un error en la revisión de PR, la tubería finaliza y el desarrollador debe realizar los cambios necesarios. Una ejecución de canalización exitosa da como resultado una fusión exitosa de PR.

  2. Una combinación con Git de Azure Repos desencadena una canalización de CI. Esta canalización ejecuta las mismas tareas que la canalización de pr y agrega pruebas de integración.

    Si las pruebas de integración requieren secretos, la canalización las obtiene de Azure Key Vault, un recurso dedicado a la canalización de CI de este entorno.

    Si se produce un error en las comprobaciones, la canalización finaliza y el desarrollador debe realizar los cambios necesarios.

  3. Una ejecución correcta de la canalización de CI crea y publica una imagen de contenedor en un registro de contenedor de Azure que no es de producción. Defender for Containers examina las imágenes de contenedor cuando se insertan en Azure Container Registry e informa de las vulnerabilidades de la imagen a Microsoft Defender para la nube. Opcionalmente, es posible que las imágenes de contenedor estén firmadas para garantizar la integridad de la imagen de contenedor.

  4. La finalización de la canalización de CI desencadena la canalización de CD.

  5. La canalización de CD implementa una plantilla YAML en el entorno de AKS provisional que incluye un agente de Defender. Esta implementación usa un modelo de inserción y se ejecuta a través de kubectl o Helm. La plantilla hace referencia a la imagen de contenedor del registro no de producción.

    La tubería realiza pruebas de aceptación en el entorno de preproducción para validar la implementación. Si las pruebas son exitosas, el pipeline podría incluir una tarea de validación manual para validar la implementación y retomar el pipeline. Algunas cargas de trabajo se implementan automáticamente. Si se produce un error en las comprobaciones, la canalización finaliza y el desarrollador debe realizar los cambios necesarios.

  6. Cuando una persona reanuda la intervención manual, el flujo de trabajo de CD promueve la imagen desde el registro de contenedores de Azure no productivo al registro de producción. Defender for Containers examina las imágenes de contenedor cuando se insertan en Container Registry e informa de las vulnerabilidades de imagen a Microsoft Defender para la nube.

  7. La canalización de CD implementa una plantilla YAML en el entorno de AKS de producción que incluye un agente de Defender. La plantilla especifica la imagen de contenedor del registro de producción.

  8. El servicio administrado de Azure Monitor para Prometheus reenvía periódicamente las métricas de rendimiento, los datos de inventario y la información de estado de mantenimiento de los hosts de contenedor y los contenedores a Azure Monitor.

  9. Un área de trabajo de Log Analytics almacena todos los datos. Azure Monitor proporciona varias herramientas para analizar los datos recopilados por otras características. Varios paneles de Grafana combinan diferentes conjuntos de datos de telemetría de Kubernetes. Application Insights recopila datos de supervisión específicos de la aplicación, como trazas.

    Defender for Containers realiza exámenes periódicos de contenedores que se ejecutan en AKS y de imágenes de contenedor almacenadas en Container Registry. Defender for Containers también proporciona protección contra amenazas en tiempo real para entornos en contenedores admitidos y genera alertas para actividades sospechosas. Esta información ayuda a identificar problemas de seguridad y a mejorar la seguridad de los contenedores.

Components

  • Azure Pipelines es un componente de Azure DevOps que compila, prueba e implementa código automáticamente en su destino de proceso. En esta arquitectura, crea y prueba imágenes de contenedor, las carga en Container Registry e las implementa en AKS.

  • El servicio administrado de Azure Monitor para Prometheus es una característica de Azure que proporciona supervisión para entornos en contenedores. En esta arquitectura, recopila métricas de rendimiento, registros y datos de mantenimiento de contenedores y reenvía estos datos de observabilidad a Azure Monitor para el análisis y las alertas.

  • Key Vault es un servicio en la nube para almacenar y acceder a secretos, como claves de API, contraseñas, certificados o claves criptográficas. En esta arquitectura, la canalización obtiene secretos necesarios para probar el código de Key Vault.

  • Azure Monitor es una solución de supervisión que recopila, analiza y responde a la telemetría de entornos locales y en la nube. En esta arquitectura, actúa como la plataforma de observabilidad central que proporciona monitorización y alertas para los clústeres de AKS y las operaciones de canalización de CI/CD.

  • Container Registry es un servicio de registro de contenedor privado administrado en Azure. Container Registry almacena imágenes de contenedor privadas. En esta arquitectura, la plataforma de computación extrae la imagen de contenedor de la aplicación del Registro de Contenedores.

  • AKS es un servicio de Kubernetes administrado en el que Azure controla tareas críticas, como la supervisión y el mantenimiento del estado. En esta arquitectura, actúa como plataforma de proceso para la aplicación.

  • La extensión de Seguridad de Microsoft DevOps para Azure DevOps permite integrar el análisis de seguridad directamente en sus flujos de trabajo CI/CD. En esta arquitectura, Seguridad de Microsoft DevOps realiza análisis estáticos y proporciona visibilidad de las posturas de seguridad en varias canalizaciones en el desarrollo e implementación de AKS. Seguridad de Microsoft DevOps forma parte de la seguridad de Microsoft Defender para la nube DevOps, que proporciona visibilidad completa, administración de posturas y protección contra amenazas en entornos multinube.

Alternatives

Cosider las siguientes alternativas para la implementación.

Modelo basado en pull (GitOps)

En este escenario se muestra un modelo de empuje para la implementación de recursos en AKS. Las implementaciones basadas en envío funcionan mejor cuando necesita actualizaciones deterministas en sus clústeres. Las canalizaciones inician activamente implementaciones, supervisan su éxito y realizan acciones directas si se produce un error en las implementaciones. Este enfoque suele ser una característica importante de las prácticas de implementación seguras en las cargas de trabajo. Las implementaciones push también se adaptan a varios objetivos de implementación, como entornos azul-verde, con un patrón de despliegue altamente controlado dentro de un único clúster o entre clústeres.

Alternativamente, las implementaciones basadas en extracción dependen de clusters para obtener y aplicar actualizaciones. Este patrón desacopla la lógica de implementación de la canalización, lo que permite que los clústeres individuales se concilien con un estado deseado almacenado en una ubicación central, como un repositorio de Git en flujos de trabajo de GitOps o un registro de artefactos. Las implementaciones basadas en extracción funcionan mejor en entornos que priorizan la coherencia, la auditabilidad y la autorrecuperación. El origen de la verdad reside externamente, a menudo en sistemas controlados por versiones, por lo que los clústeres supervisan y aplican continuamente actualizaciones para que coincidan con este estado deseado. Este enfoque reduce el riesgo de desfase. Si un clúster experimenta un error o deja de estar disponible, puede recuperarse automáticamente después de volver a estar en línea sin necesidad de volver a implementar desde una tubería central.

El modelo de extracción de GitOps también elimina la necesidad de que las canalizaciones accedan a clústeres directamente o usen credenciales de implementación asociadas, lo que elimina un vector de ataque. Los clústeres solo necesitan acceso de solo lectura al repositorio de origen. Para más información, consulte GitOps para AKS.

Flujo de CI/CD creado con Acciones de GitHub

Puede reemplazar Azure Pipelines por Acciones de GitHub para AKS. Acciones de GitHub es una plataforma de CI/CD que puede usar para automatizar su pipeline de construcción, prueba y despliegue. Considere la posibilidad de usar un flujo de trabajo de inicio para AKS y personalizarlo según sus requisitos de CI/CD.

Pasos siguientes