GitOps es un modelo operativo para aplicaciones nativas de la nube que almacena código de infraestructura declarativa y aplicación en Git que se va a usar como origen de la verdad para la entrega continua automatizada. Con GitOps, describe el estado deseado de todo el sistema en un repositorio git y un operador de GitOps lo implementa en el entorno, que suele ser un clúster de Kubernetes. Para más información sobre GitOps para Kubernetes en Azure, visite GitOps para Azure Kubernetes Service o CI/CD y materias de GitOps con Kubernetes habilitado para Azure Arc.
El escenario de ejemplo de este artículo es aplicable a las empresas que quieran modernizar el desarrollo de aplicaciones de un extremo a otro mediante contenedores, integración continua (CI) para la compilación y GitOps para la implementación continua (CD). En este escenario, se usa una aplicación de Flask como ejemplo. Esta aplicación web consta de un front-end escrito mediante Python y el marco de Flask.
Architecture
En las siguientes opciones se exploran los enfoques de CI/CD basados en inserción y de extracción.
Opción 1: CI/CD basado en inserción
Arquitectura basada en inserción con Acciones de GitHub para CI y CD.
Descargue un archivo Visio de esta arquitectura.
Flujo de datos
En este escenario se trata una canalización de DevOps basada en inserción para una aplicación web de dos niveles, con un componente web front-end y un back-end que usa Redis. Esta canalización usa Acciones de GitHub para compilar e implementar. Los datos fluyen por el escenario de la siguiente manera:
- Se desarrolla el código de la aplicación.
- El código de la aplicación se confirma en un repositorio git de GitHub.
- Acciones de GitHub compila una imagen de contenedor desde el código de la aplicación e inserta la imagen de contenedor en Azure Container Registry.
- Un trabajo de Acciones de GitHub implementa (o inserta) la aplicación, como se describe en los archivos de manifiesto, en el clúster de Azure Kubernetes Service (AKS) mediante kubectl o la acción Implementar en clúster de Kubernetes.
Opción 2: CI/CD basado en extracción (GitOps)
Arquitectura basada en extracción con Acciones de GitHub para CI y Argo CD para CD.
Descargue un archivo Visio de esta arquitectura.
Flujo de datos
En este escenario se trata una canalización de DevOps basada en extracción para una aplicación web de dos niveles, con un componente web front-end y un back-end que usa Redis. Esta canalización usa Acciones de GitHub para compilar. Para la implementación, usa Argo CD como operador de GitOps para extraer o sincronizar la aplicación. Los datos fluyen por el escenario de la siguiente manera:
- Se desarrolla el código de la aplicación.
- El código de la aplicación se confirma en un repositorio de GitHub.
- Acciones de GitHub compila una imagen de contenedor desde el código de la aplicación e inserta la imagen de contenedor en Azure Container Registry.
- Acciones de GitHub actualiza un archivo de implementación de manifiestos de Kubernetes con la versión de imagen actual en función del número de versión de la imagen de contenedor en Azure Container Registry.
- Argo CD se sincroniza con, o extrae, el repositorio de Git.
- Argo CD implementa la aplicación en el clúster de AKS.
Componentes
- Acciones de GitHub es una solución de automatización que se puede integrar con los servicios de Azure para la integración continua (CI). En este escenario, las Acciones de GitHub orquestan la creación de nuevas imágenes de contenedores basándose en las confirmaciones al control de fuentes, empujan esas imágenes al Registro de Contenedores de Azure y luego actualizan los archivos de manifiesto de Kubernetes en el repositorio de GitHub.
- Azure Kubernetes Service (AKS) es una plataforma Kubernetes administrada que le permite implementar y administrar aplicaciones en contenedores sin necesidad de tener experiencia en la orquestación de contenedores. Como servicio hospedado de Kubernetes, Azure maneja tareas críticas como la supervisión del estado y el mantenimiento para usted.
- Azure Container Registry almacena y administra las imágenes de contenedor que usa el clúster de Azure Kubernetes Service. Las imágenes se almacenan de forma segura y se pueden replicar en otras regiones mediante la plataforma Azure, para acelerar los tiempos de implementación.
- GitHub es un sistema de control de código fuente basado en web que se ejecuta en Git y lo usan los desarrolladores para almacenar y versionar su código de aplicación. En este escenario, GitHub se usa para almacenar el código fuente en un repositorio de Git y, a continuación, se usa Acciones de GitHub para realizar la compilación e inserción de la imagen de contenedor en Azure Container Registry en el enfoque basado en inserción.
- Argo CD es un operador de GitOps de código abierto que se integra con GitHub y AKS. Argo CD admite la implementación continua (CD). Flux podría haberse usado para este propósito, pero Argo CD muestra cómo un equipo de aplicaciones podría elegir una herramienta independiente para sus preocupaciones específicas del ciclo de vida de la aplicación, en comparación con el uso de la misma herramienta que usan los operadores de clúster para la administración de clústeres.
- Azure Monitor le ayuda a realizar un seguimiento del rendimiento, a mantener la seguridad y a identificar las tendencias. Las métricas obtenidas por el Azure Monitor se pueden usar en otros recursos y herramientas, como Grafana.
Alternativas
- Azure Pipelines le ayuda a implementar una canalización de CI/DC y de pruebas para cualquier aplicación.
- Jenkins es un servidor de automatización de código abierto que puede integrarse con los servicios de Azure para CI/CD.
- Flux se puede usar como operador de GitOps. Puede realizar las mismas tareas que Argo CD y funciona de la misma manera con AKS.
Detalles del escenario
En este escenario, la compilación e implementación automatizadas de la aplicación usa varias tecnologías. El código se desarrolla en VS Code y se almacena en un repositorio de GitHub. Acciones de GitHub se usa para compilar la aplicación como contenedor y, a continuación, insertar la imagen de contenedor en una instancia de Azure Container Registry. Acciones de GitHub se usa para actualizar el archivo de implementación de manifiesto de Kubernetes necesario, que también se almacena en el repositorio de Git, mientras que el Argo CD del operador de GitOps recoge los archivos de manifiesto de Kubernetes desde allí e implementa la aplicación en el clúster de AKS.
Otros ejemplos son la provisión de un entorno de desarrollo automatizado, la validación de nuevas confirmaciones de código y la inserción de nuevas implementaciones en entornos de ensayo o producción. Tradicionalmente, las empresas tenían que crear y compilar las aplicaciones y actualizaciones manualmente, y mantener una base de código grande y rígida. Con un enfoque moderno para el desarrollo de aplicaciones que utiliza CI y GitOps para CD, puede crear, probar e implementar servicios más rápidamente. Este enfoque moderno permite lanzar aplicaciones y actualizaciones a los clientes más rápidamente y responder a las cambiantes demandas del negocio de manera más ágil.
Al utilizar los servicios de Azure y GitHub, como AKS, Container Registry, GitHub y GitHub Actions, las empresas pueden utilizar las últimas técnicas y herramientas de desarrollo de aplicaciones para simplificar el proceso de implementación de la alta disponibilidad. Además, mediante tecnologías de código abierto, como Flux o Argo CD para GitOps, las empresas simplifican la implementación y aplican el estado deseado de las aplicaciones.
Posibles casos de uso
Otros casos de uso pertinentes incluyen:
- Modernice las prácticas de desarrollo de aplicaciones adoptando un enfoque basado en contenedores y microservicios.
- Acelere el desarrollo de aplicaciones y los ciclos de vida de implementación.
- Automatice las implantaciones en entornos de prueba o de aceptación para su validación.
- Asegúrese de que las configuraciones y el estado deseado de la aplicación.
- Automatice la gestión del ciclo de vida del clúster.
Opciones de CI/CD
En este documento se muestra el uso de GitOps para un enfoque moderno para controlar la implementación continua en una canalización de CI/CD. Sin embargo, cada organización es diferente. Al implementar aplicaciones en clústeres de Kubernetes a través de canalizaciones de entrega automatizadas, es importante comprender las distintas formas de hacerlo.
Las dos opciones de CI/CD más comunes para implementar una aplicación en un clúster de AKS son basadas en inserción y basadas en extracción. La opción de inserción utiliza Acciones de GitHub para la implementación continua y la opción de extracción utiliza GitOps para la implementación continua.
Opción 1: Arquitectura basada en inserción con Acciones de GitHub para CI y CD
En este enfoque, el código comienza con la parte de CI de la canalización trabajando para los cambios que se insertan como implementaciones en el clúster de Kubernetes. Las implementaciones se basan en un desencadenador. Hay varios desencadenadores que pueden iniciar la implementación, por ejemplo, confirmaciones en el repositorio o un desencadenador desde otra canalización de CI. Con este enfoque, el sistema de canalización tiene acceso al clúster de Kubernetes. El módulo basado en inserción es el modelo más común que usan hoy las herramientas de CI/CD.
Motivos para usar un enfoque basado en inserción:
Flexibilidad: la mayoría de los operadores de GitOps actualmente solo se ejecutan en Kubernetes. Si su organización quiere implementar aplicaciones en algo distinto de Kubernetes, deberá insertar la aplicación en ese entorno a través de otras herramientas de CI/CD, como con Acciones de GitHub.
Eficiencia: un enfoque estandarizado para implementar las aplicaciones nativas y tradicionales de la nube es más eficaz. Actualmente, GitOps es más adecuado para aplicaciones nativas de nube que se ejecutan en Kubernetes.
Simplicidad: CI/CD basado en inserción es conocido entre el conjunto más amplio de ingenieros de muchas organizaciones. Un enfoque basado en inserción podría ser más sencillo que una combinación de enfoques de CI/CD basados en inserción y basados en extracción.
Estructura: es posible que la estructura del repositorio actual que se usa para la aplicación no sea adecuada para GitOps, lo que significa que sería necesario planear y reestructurar considerablemente para GitOps.
Opción 2: Arquitectura basada en extracción con Acciones de GitHub para CI y el operador De GitOps Argo CD para CD
Este enfoque se centra en aplicar los cambios desde dentro de un clúster de Kubernetes. El clúster de Kubernetes incluye un operador que examina un repositorio de Git para el estado deseado del clúster, seleccionando y aplicando los cambios que se deben realizar. En este modelo, ningún cliente externo tiene credenciales de nivel de administrador en el clúster de Kubernetes. El modelo de extracción no es nuevo, pero no ha sido ampliamente utilizado por las herramientas de CI/CD. Recientemente, con la introducción de GitOps, el modelo de extracción ha ganado la adopción. Muchas organizaciones han estado usando GitOps para facilitar la implementación continua en sus canalizaciones de CD/CD.
Motivos para usar un enfoque basado en extracción:
Coherencia: con GitOps, un operador compara el estado de los clústeres de Kubernetes con el estado deseado de la configuración y las aplicaciones en un repositorio git. Si hay algún desfase en la configuración o las aplicaciones, el operador de GitOps devuelve el clúster de Kubernetes al estado deseado automáticamente.
Seguridad: un enfoque basado en extracción de CI/CD con GitOps permite cambiar las credenciales de seguridad al clúster de Kubernetes, lo que reduce la seguridad y la superficie de riesgo mediante la eliminación de credenciales que se almacenan en las herramientas de CI externas. También podrá reducir las conexiones entrantes permitidas y limitar el acceso de nivel de administrador a los clústeres de Kubernetes.
Control de versiones: dado que GitOps usa un repositorio de Git como origen de verdad, la implementación continua tiene inherentemente funcionalidades de control de versiones, reversión y auditoría.
Multiinquilino: un enfoque basado en extracción con GitOps es adecuado para equipos distribuidos o multiinquilino. Con GitOps, puede usar repositorios de Git independientes, derechos de acceso independientes y distribuir implementaciones en distintos espacios de nombres.
Nativo de la nube: se están modernizando o compilando más aplicaciones para que sean nativas de la nube. Para cualquier organización que tenga la mayoría de sus aplicaciones ejecutadas en Kubernetes, utilizar un operador de GitOps para la implementación continua es más sencillo y eficiente que un enfoque tradicional de CI/CD basado en inserción.
Consideraciones
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Confiabilidad
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.
Para supervisar el rendimiento de su aplicación e informar de los problemas, este escenario utiliza Azure Monitor. Le permite supervisar y solucionar los problemas de rendimiento que puedan requerir actualizaciones de código, que luego pueden implementarse con la canalización CI/CD.
Como parte del clúster de AKS, un equilibrador de carga distribuye el tráfico de aplicación a uno o varios contenedores o pods que ejecutan la aplicación. Este método para ejecutar aplicaciones en contenedor en Kubernetes proporciona una infraestructura de alta disponibilidad para sus clientes.
Nota
En este artículo no se aborda directamente la alta disponibilidad de la canalización de CI/CD. Para más información, visite Alta disponibilidad para Acciones de GitHub y GitOps CD declarativo de Argo CD para Kubernetes.
Los componentes de resistencia están integrados en Kubernetes. Estos componentes supervisan y reinician contenedores, o pods, si hay un problema. Cuando se combinan varios nodos Kubernetes, su aplicación puede tolerar que un pod o nodo no esté disponible.
Para obtener instrucciones generales sobre el diseño de soluciones resistentes, consulte Diseño de aplicaciones resistentes de Azure.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.
Para separar las credenciales y los permisos, en este escenario se usa una entidad de servicio dedicada de Microsoft Entra. Las credenciales para este principal de servicio se almacenan como un objeto de credenciales seguro en GitHub, como Secretos de Acciones de GitHub, para que no estén directamente expuestos y visibles dentro de los scripts o la canalización de construcción.
Para obtener instrucciones generales sobre cómo proteger aplicaciones en clústeres de AKS, consulte Conceptos de seguridad para aplicaciones y clústeres en AKS.
Para separar los problemas, la guía consiste en separar el proceso que ejecuta la aplicación empresarial de los agentes de CD o el operador de GitOps mediante la ejecución de la aplicación empresarial y el operador de GitOps en espacios de nombres independientes en el clúster de Kubernetes. Para una mayor separación de problemas, el operador de GitOps se puede ejecutar en un clúster de Kubernetes dedicado a la instancia de GitOps independiente del clúster de Kubernetes de producción que ejecuta la aplicación empresarial.
Nota
En este artículo no se aborda directamente cómo proteger una canalización de CI/CD.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.
AKS permite escalar el número de nodos del clúster para satisfacer la demanda de sus aplicaciones. A medida que aumenta la aplicación, puede escalar verticalmente el número de nodos de Kubernetes que ejecutan el servicio.
Con Acciones de GitHub, el proveedor de nube escala automáticamente el número de ejecutores. Si se usan ejecutores autohospedados, el host del ejecutor será responsable de escalarlos según sea necesario.
Para otros temas de escalabilidad, consulte la lista de comprobación de la eficiencia del rendimiento.
Implementación de este escenario
Siga los pasos descritos en la implementación de referencia de AKS-baseline-automation para implementar el escenario. El repositorio de implementación de referencia tiene tutoriales guiados para el escenario de CI/CD basado en inserción y el escenario de CI/CD basado en extracción (GitOps).
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- Steve Buchanan | Administrador de programas principal
Otros colaboradores:
- Ayobami Ayodeji | Jefe de programas sénior
- Bahram Rushenas | Arquitecto sénior
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
Este escenario utiliza Azure Container Registry y AKS para almacenar y ejecutar las aplicaciones basadas en contenedores. También se puede usar Azure Container Apps o Azure Container Instances para ejecutar aplicaciones basadas en contenedores, sin tener que aprovisionar componentes de orquestación. Para más información, consulte Introducción a Azure Container Instances e Introducción a Azure Container Apps.
Documentación del producto:
- Azure Kubernetes Service
- Introducción a Azure Monitor
- Máquinas virtuales Linux en Azure
- Registros de contenedores privados de Docker en Azure
- Conceptos de seguridad de las aplicaciones y los clústeres en Azure Kubernetes Service en AKS
- Acelerador de zona de aterrizaje de AKS
Módulos de Microsoft Learn:
- Compilación de una aplicación web en contenedores con Docker
- Implementación de una aplicación en contenedores en Azure Kubernetes Service
- Implementación de Azure Kubernetes Service (AKS)
- Supervisión del uso, el rendimiento y la disponibilidad de los recursos con Azure Monitor
Recursos relacionados
- Arquitectura de línea de base para un clúster de AKS
- Plano técnico de GitOps para el Azure Kubernetes Service
- CI/CD para arquitecturas de microservicios
- Canalización de CI/CD para cargas de trabajo basadas en contenedores
- Creación de una canalización de CI/CD para microservicios en Kubernetes
- Arquitectura de microservicios avanzada de Azure Kubernetes Service (AKS)