GitOps perimetral
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 el despliegue y la gestión coherentes de los entornos de tiempo de ejecución de contenedores.
¿Cuál es el problema que GitOps intenta resolver? 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 eficaz.
Este blog explorará si GitOps se puede aplicar a topologías perimetrales, especialmente en la creación de pipelines de CI/CD que pueden desplegar aplicaciones en dispositivos perimetrales lejanos. Para reiterar, el perímetro abarca dispositivos perimetrales lejanos hasta la nube, con la periferia empresarial y de red a lo largo del camino.
GitOps es una práctica de DevOps que utiliza Git como única fuente de información 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 usar. Son las interfaces proporcionadas por Git las que automatizan las operaciones. GitOps termina usando 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 favorecido 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 estaríamos de acuerdo con Argo CD, una herramienta de GitOps que ayuda con los flujos de trabajo de GitOps. Argo CD es una herramienta declarativa de código abierto para la integración continua y el despliegue continuo (CI/CD) de aplicaciones. Implementado como un controlador de Kubernetes, Argo CD monitorea 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 solo 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. Para tomar prestado de 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 de información para las definiciones de infraestructura. Git realiza un seguimiento de todos los cambios en la gestión de 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 de configuración, como cambios manuales o errores, se sobrescribe con la automatización de GitOps para que el entorno converja en el estado deseado definido en Git, proporcionando así 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 de 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 desean utilizar GitOps al proporcionar los operadores necesarios. Una vez desplegados, se pueden ver en la sección Installed Operators en OpenShift Console. El operador Red Hat OpenShift GitOps es el operador ascendente de ArgoCD, y el operador Red Hat OpenShift Pipelines, que también se despliega, es el operador ascendente de Tekton. Ver la figura 3:
Los operadores y las API relacionadas se pueden utilizar para iniciar uno o más pipelines de GitOps que pueden desplegarse 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 computación perimetral.
Los recursos de despliegue se clasifican en tres áreas: infraestructura, servicios y aplicaciones. Estas áreas facilitan la separación y gestión del despliegue de recursos relacionados:
- Infraestructura es donde se definen los espacios de nombres y las unidades de almacenamiento necesarios.
- Servicios es donde se describen los diversos operadores necesarios para configurar las instancias.
- Aplicaciones es donde se enumeran las aplicaciones que se desplegarán.
En un blog anterior, hablamos de DevOps en el dominio de la computación perimetral; aquí, echamos un vistazo a cómo se puede aplicar GitOps en la computación perimetral. Aludimos a las tres aristas en la computación perimetral:
- Perímetro empresarial
- Perímetro de red
- Perímetro del dispositivo (o perímetro lejano)
También está la nube o el centro de datos empresarial. Echemos un vistazo en profundidad a estas áreas. Junto con los entornos perimetrales, la Figura 4 también representa las tres áreas de GitOps: infraestructura, servicios y aplicaciones.
Centro de datos empresarial/en la nube
La computación perimetral 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 despliegues 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 on-prem y/o en nubes públicas.
Garantizar que los clústeres tengan el mismo estado deseado (implementar un cambio y revertir un cambio en múltiples nubes) es un beneficio importante que GitOps brinda a las empresas basadas en el perímetro e IoT.
Perímetro de red
El paradigma de GitOps es aplicable en el perímetro de la red, ya que uno de los principales desafíos que enfrentan los proveedores de servicios de comunicación (CSP) es buscar la orquestación, automatización y gestión de sus redes. Si bien 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 un despliegue más rápido han creado desafíos para los proveedores de telecomunicaciones.
Un pipeline de despliegue automatizado es una forma en que los CSP pueden llevar 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 perímetro de la red. La contenerización de los componentes de red permite gestionar dichas funciones. Por último, debido a que toda la actividad de configuración se registra y almacena en Git, la capacidad de rastrear los cambios es crítica para fines de cumplimiento y auditoría. Hay un par de blogs relacionados de WeaveWorks en las referencias:
Perímetro empresarial
GitOps permite a las organizaciones desplegar en múltiples objetivos simultáneamente. Permite la puesta en marcha de despliegues detallados. Esto sería extremadamente útil al desplegar aplicaciones en cientos y decenas de miles de nodos perimetrales, que vienen en diferentes formas y factores de forma y utilizan protocolos de comunicación variados, especialmente si los nodos perimetrales son pequeños clústeres Eedge que utilizan Intel NUC o NVIDIA Jetson.
El marco de GitOps puede ser beneficioso para desplegar aplicaciones y utilizar el repositorio de Git como única fuente de información. Los equipos de ITOps buscan el despliegue autónomo de aplicaciones, gestión y operaciones de nodos perimetrales, lo que se facilita con el uso de operadores de Red Hat OpenShift.
Perímetro del dispositivo (o perímetro lejano)
El beneficio de GitOps es obvio en el perímetro de la red y en el perímetro empresarial. Los dispositivos perimetrales auditivos presentan un desafío 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á previsto para casos de uso de IoT y en el perímetro. La capacidad de desplegar una distribución ligera de Kubernetes en un dispositivo perimetral nos permite ejecutar una herramienta GitOps como Argo CD. Luego, 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 en vivo del clúster.
Al utilizar GitOps, usted resuelve los problemas de la expansión de la infraestructura y la configuración de aplicaciones. El operador de GitOps integrado en Red Hat OpenShift facilita la implementación de un pipeline basado en CD de Argo. Los clientes de IBM® Cloud Paks, incluyendo IBM® Cloud Pak for Network Automation, pueden utilizar los operadores de Red Hat para instalar recursos y emplear la infraestructura de GitOps para automatizar y controlar el proceso de despliegue.
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 el despliegue de operaciones.
Un agradecimiento especial a Hollis Chui y Kavitha Bade por revisar el artículo.