GitOps en el Edge
En los últimos años, hemos visto que cada vez más empresas adoptan GitOps, un paradigma de DevOps que utiliza Git como repositorio.
GitOps existe desde hace algunos años, pero ha ganado terreno recientemente debido a los contenedores y a la complejidad que rodea a la implementación y gestión coherentes de los entornos de tiempo de ejecución de contenedores.
¿Cuál es el problema que GitOps intenta resolver? Pues bien, automatiza las operaciones de software para que las empresas puedan mejorar en ingeniería de software. Permite a los equipos de aplicaciones lanzar con mayor frecuencia y operar aplicaciones nativas de la nube de manera más efectiva.
Este blog explorará si GitOps se puede aplicar a topologías edge, especialmente creando pipelines CI/CD que puedan implementar aplicaciones en dispositivos edge lejanos. Para reiterar, edge abarca los dispositivos de edge lejano hasta la nube, pasando por el edge empresarial y el edge de red.
GitOps es una práctica de DevOps que utiliza Git como única fuente fiable donde se almacena el estado de configuración deseado. La atención se centra en la automatización de operaciones, impulsada desde repositorios Git. Aunque está en el título, Git no es el único repositorio que se puede utilizar. Son las interfaces proporcionadas por Git las que automatizan las operaciones. GitOps termina utilizando la información extraída de los metadatos de compilación para determinar qué paquetes compilar desencadenados por un cambio de código en particular:
En esencia, el modelo GitOps utiliza el patrón de controlador. Esto se ve reforzado por el patrón de operador desde una perspectiva de Kubernetes u OpenShift, en la que los operadores son extensiones de software que utilizan recursos personalizados para gestionar aplicaciones y sus componentes.
No podemos dejar de mencionar Argo CD, una herramienta GitOps que ayuda con los flujos de trabajo GitOps. Argo CD es una herramienta declarativa de código abierto para la integración continua y la implementación continua (CI/CD) de aplicaciones. Implementado como un controlador de Kubernetes, Argo CD monitoriza continuamente las definiciones y configuraciones de aplicaciones en ejecución, comparando el estado actual en vivo en el clúster con el estado deseado definido en un repositorio Git.
Pero GitOps no es un único producto, complemento o plataforma. Los flujos de trabajo de GitOps ayudan a los equipos a gestionar la infraestructura de TI a través de procesos que ya utilizan en el desarrollo de aplicaciones. Según un blog de GitLab, GitOps requiere tres componentes principales: GitOps = IaC + PR o MR + CI/CD
- IaC: la infraestructura como código (IaC) es la práctica de mantener toda la configuración de la infraestructura almacenada como código. GitOps utiliza un repositorio Git como única fuente fiable para las definiciones de infraestructura. Git realiza un seguimiento de todos los cambios en la gestión del código.
- PR o MR: GitOps utiliza solicitudes de extracción (PR) o solicitudes de fusión (MR) como mecanismo de cambio para todas las actualizaciones de infraestructura. Aquí es donde los equipos pueden colaborar a través de revisiones y comentarios y donde tienen lugar las aprobaciones formales.
- CI/CD: GitOps automatiza las actualizaciones de infraestructura mediante un flujo de trabajo Git con integración continua (CI) y entrega continua (CD). Cuando se fusiona código nuevo, el pipeline de CI/CD promulga el cambio en el entorno. Cualquier desviación en la configuración, como cambios manuales o errores, se sobrescribe mediante la automatización de GitOps, de modo que el entorno converge en el estado deseado definido en Git, lo que proporciona operaciones continuas (CO):
Los operadores de Red Hat OpenShift simplifican la instalación y la orquestación automatizada de cargas de trabajo complejas. Ayudan a codificar la lógica operativa humana para gestionar los servicios que se ejecutan como aplicaciones nativas de Kubernetes, lo que facilita las operaciones del día 2. El operador es una pieza de software que se ejecuta en un pod en el clúster, interactuando con el servidor API de Kubernetes. Un operador OpenShift es esencialmente un controlador personalizado y puede ser, de hecho, un controlador específico de la aplicación.
Red Hat OpenShift facilita a los desarrolladores que deseen utilizar GitOps al proporcionar los operadores necesarios. Una vez implementados, se pueden ver en la sección operadores instalados en la consola de OpenShift. El operador Red Hat OpenShift GitOps es el operador ascendente de ArgoCD, y el operador Red Hat OpenShift Pipelines, que también se implementa, es el operador ascendente de Tekton. Véase la Figura 3:
Los operadores y las API relacionadas se pueden utilizar para iniciar una o más pipelines de GitOps que pueden implementarse en diferentes entornos extrayendo el resultado de configuración deseado de Git. Los entornos pueden ser los habituales de desarrollo, prueba y producción, pero también pueden abarcar entornos geográficos como la nube empresarial, la red de telecomunicaciones o los nodos de edge computing.
Los recursos de implementación se clasifican en tres áreas: infraestructura, servicios y aplicaciones. Estas áreas facilitan la separación y la gestión de la implementación de los recursos relacionados:
- La infraestructura es donde se definen los espacios de nombres y las unidades de almacenamiento necesarios.
- Los servicios es donde se describen los distintos operadores necesarios para configurar las instancias.
- Las aplicaciones es donde se enumeran las aplicaciones que se van a implementar.
En un blog anterior, hablamos de DevOps en el dominio del edge computing; aquí, analizamos cómo se puede aplicar GitOps al edge computing. Hemos aludido a los tres edges del edge domputing:
- Edge empresarial
- Edge de red
- Edge de dispositivo (o edge lejano)
También está la nube o el centro de datos empresarial. Echemos un vistazo en profundidad a estas áreas. Junto con los entornos edge, la Figura 4 también muestra las tres áreas de GitOps: infraestructura, servicios y aplicaciones.
Centro de datos empresarial/en la nube
El edge computing está viendo la proliferación de clústeres de OpenShift o Kubernetes en la mayoría de los centros de TI. Tiene el potencial de alcanzar una escala masiva de cientos a miles de implementaciones por cliente. El resultado es que los departamentos de TI de las empresas deben gestionar varios clústeres de tiempo de ejecución de contenedores independientes o cooperativos que se ejecutan en las instalaciones y/o en nubes públicas.
Garantizar que los clústeres tengan el mismo estado deseado (implementar un cambio y revertir un cambio en varias nubes) es un beneficio importante que GitOps proporciona a las empresas basadas en edge y IoT.
Edge de red
El paradigma GitOps es aplicable en el edge, ya que uno de los principales retos a los que se enfrentan los proveedores de servicios de comunicaciones (CSP) es la orquestación, automatización y gestión de sus redes. Si bien el 5G es una bendición para los consumidores, las redes definidas por software (SDN), la división de redes con diferentes anchos de banda y una implementación más rápida han creado desafíos para los proveedores de telecomunicaciones.
Un pipeline de implementación automatizada es una forma en que los CSP pueden llevar los servicios a los clientes más rápido. Tener un repositorio central y un enfoque declarativo para aprovisionar la infraestructura de contenedores significa un tiempo de comercialización más rápido para nuevas características y solicitudes de cambio. Este paradigma ayudará al aprovisionamiento de VNF (funciones de red virtual) y CNF (funciones de red nativas de la nube) en el Edge. La contenerización de los componentes de red permite gestionar dichas funciones. Por último, dado que toda la actividad de configuración se registra y se almacena en Git, la capacidad de realizar un seguimiento de los cambios es crítica para fines de cumplimiento y auditoría. Hay un par de blogs relacionados de WeaveWorks en las referencias:
Edge empresarial
GitOps permite a las organizaciones implementar en varios objetivos simultáneamente. Permite el despliegue de implementaciones detalladas. Esto sería extremadamente útil cuando se implementan aplicaciones en cientos y decenas de miles de nodos de edge, que vienen en diferentes formas y factores de forma y utilizan protocolos de comunicación variados, especialmente si los nodos de edge son pequeños clústeres edge que utilizan una Intel NUC o NVIDIA Jetson.
El marco GitOps puede ser beneficioso para implementar aplicaciones y utilizar el repositorio Git como única fuente fiable. Los equipos de ITOps buscan la implementación, la gestión y las operaciones autónomas de las aplicaciones de los nodos de edge, lo que se facilita con el uso de operadores Red Hat OpenShift.
Edge de dispositivo (o edge lejano)
El beneficio de GitOps es obvio en el edge de red y en el edge empresarial. Los dispositivos de edge lejano presentan un reto diferente porque la capacidad de almacenamiento y computación de algunos de estos dispositivos no es lo suficientemente grande como para alojar servicios GitOps y ejecutar aplicaciones.
El lanzamiento de distribuciones ligeras de Kubernetes, como K3 y K0, está destinado a casos de uso de IoT y edge. La capacidad de implementar una distribución ligera de Kubernetes en un dispositivo edge nos permite ejecutar una herramienta GitOps como Argo CD. A continuación, los dispositivos podrán adoptar el modelo de extracción de sondear un repositorio Git para obtener el estado deseado y sincronizarlo con el estado activo del clúster.
Al utilizar GitOps, resuelve los problemas de la expansión de la infraestructura y la configuración de las aplicaciones. El operador GitOps integrado en Red Hat OpenShift facilita la implementación de un pipeline basado en CD de Argo. Los clientes de IBM® Cloud Paks, incluido IBM® Cloud Pak for Network Automation, pueden utilizar los operadores de Red Hat para instalar recursos y emplear el marco GitOps para automatizar y controlar el proceso de implementación.
El IBM® Cloud Native Toolkit es un excelente punto de partida. Es una colección de activos de código abierto que permite el desarrollo de aplicaciones y la implementación de operaciones.
Un agradecimiento especial a Hollis Chui y Kavitha Bade por revisar el artículo.