[04/08/2020] La última década de programación ha visto una serie de transformaciones revolucionarias. Una de ellas ha surgido de un grupo de prácticas en torno a devops que alinean a los equipos de desarrollo y operaciones en un proceso de trabajo compartido y, la integración y distribución continuas (CI/CD), en la que los equipos de devops entregan actualizaciones incrementales constantes a una codebase. Otra transformación se ha producido a partir del movimiento relacionado con la transición de bases de código monolíticas a microservicios basados en la nube que se ejecutan en contenedores gestionados por plataformas de orquestación como Kubernetes.
Las aplicaciones basadas en contenedores, que se ejecutan en sistemas agrupados o en la nube pueden, ser complejas y difíciles de aprovisionar y gestionar, incluso con una plataforma como Kubernetes orquestando las cosas. GitOps es un conjunto emergente de prácticas que pretende simplificar esta tarea de gestión mediante la aplicación de técnicas del mundo de devops y de CI/CD.
La clave de GitOps es la idea de la infraestructura como código, que adopta el mismo enfoque de aprovisionamiento de la infraestructura que utiliza devops para aprovisionar las aplicaciones. Así, no solo la aplicación, sino también las máquinas y redes anfitrionas subyacentes, son descritas en archivos que pueden ser tratados como cualquier otro código dentro de un sistema de control de versiones, con procesos automatizados que trabajan para hacer converger la aplicación del mundo real con la descrita en esos archivos.
En el lenguaje de GitOps, el código en el sistema de control de versiones es la única fuente de verdad sobre cómo debe ser la aplicación en producción.
Definición de GitOps
Weaveworks es la empresa que más ha hecho para popularizar el concepto de GitOps. Entraremos en los detalles del papel de Weaveworks en un momento, pero primero, echemos un vistazo a la definición de GitOps, que tiene dos partes:
- Un modelo operativo para Kubernetes y otras tecnologías nativas de la nube, que proporciona un conjunto de mejores prácticas que unifican el despliegue, la gestión y la supervisión de clústeres y aplicaciones en contenedores.
- Un camino hacia una experiencia de desarrollador para la gestión de aplicaciones, donde los canales de CI/CD end-to-end y los flujos de trabajo Git son aplicados tanto a las operaciones como al desarrollo.
En otras palabras, GitOps es un conjunto específico de prácticas diseñadas para gestionar Kubernetes y plataformas similares, que también se presta a una aplicación más amplia a medida que más y más tiendas de desarrollo adoptan prácticas de devops y migran el código a la nube. Sin embargo, para entender la salsa secreta de GitOps y los problemas que resuelve, tenemos que hablar de sus componentes.
Definición de Git
El Git en GitOps se refiere al popular sistema de control de versiones distribuidas desarrollado por Linus Torvalds en el 2005. Git es una herramienta que permite a los equipos de desarrolladores trabajar juntos en una codebase de una aplicación, almacenando varias ramas de código que modifican antes de fusionarlas en el código de producción. Un concepto clave dentro de Git es la solicitud de extracción, en la que un desarrollador pide formalmente que algún código en el que ha estado trabajando sea integrado en otra rama dentro de la base de la codebase.
Una solicitud de extracción de Git proporciona una oportunidad para que los miembros del equipo colaboren y discutan antes de llegar a un consenso sobre si el nuevo código debe ser añadido a la aplicación. Git también almacena versiones antiguas del código, lo que facilita volver a la última versión buena si es que algo va mal, y le permite ver rápidamente lo que ha cambiado entre revisiones. Puede que Git sea más conocido como el fundamento de GitHub, un sistema de control de versiones alojado en la nube, pero Git en sí mismo es un software de código abierto que puede ser desplegado en cualquier lugar, desde los servidores corporativos internos hasta su PC.
Tenga en cuenta que, aunque normalmente pensamos en Git como una herramienta de programación de computadoras, en realidad es agnóstica en cuanto al contenido para el que lo usa. Git tratará gustosamente cualquier conjunto de archivos de texto como su "codebase" y puede, por ejemplo, ser usado por escritores que buscan llevar un registro de las ediciones de un trabajo colaborativo. Esto es importante porque gran parte de la base de la codebase en el núcleo de GitOps consiste en archivos de configuración declarativos más que en código ejecutable.
Una última cosa que decir antes de seguir adelante: a pesar de que "Git" está en el nombre, GitOps en realidad no requiere el uso de Git. Las tiendas que ya han invertido en otro software de control de versiones, como Subversion, también pueden implementar GitOps. Sin embargo, Git es ampliamente utilizado en el mundo de los desarrolladores para implementar CI/CD, por lo que la mayoría de los proyectos de GitOps terminarán usando Git.
¿Qué es el proceso de CI/CD?
Una mirada completa a CI/CD va más allá del alcance de este artículo, pero necesitamos decir unas cuantas palabras sobre ésta porque es relevante para entender la manera en la que funciona GitOps. La integración continua de CI/CD es habilitada por los repositorios de control de versiones como Git: los desarrolladores pueden hacer pequeñas mejoras constantes en su codebase, en lugar de desplegar nuevas versiones enormes y monolíticas cada pocos meses o años. La pieza de despliegue continuo es posible gracias a los sistemas automatizados llamados "pipelines" que construyen, prueban y despliegan el nuevo código en/a producción.
De nuevo, seguimos hablando de código y eso normalmente reúne visiones de código ejecutable escrito en un lenguaje de programación como C, Java o JavaScript. Pero en GitOps, el "código" que manejamos está compuesto en gran parte por archivos de configuración. Esto no es solo un detalle menor -es el corazón de lo que hace GitOps. Estos archivos de configuración son, como hemos dicho, la "única fuente de verdad" que describe cómo debería ser nuestro sistema. Son declarativos más que instructivos. Eso significa que en lugar de decir "iniciar diez servidores", el archivo de configuración dirá simplemente, "este sistema incluye diez servidores".
La mitad CI de la ecuación de GitOps permite a los desarrolladores desplegar rápidamente ajustes y mejoras en estos archivos de configuración; y la mitad CD ocurre cuando los agentes de software automatizado hacen todo lo posible para asegurar que la versión en vivo de la aplicación refleje las descripciones en los archivos de configuración -que converja con el modelo declarativo, en el lenguaje de GitOps.
GitOps y Kubernetes
Como mencionamos, los conceptos de GitOps se desarrollaron originalmente en torno a la gestión de las aplicaciones de Kubernetes. Con lo que sabemos ahora, volvamos a la discusión sobre GitOps de Weaveworks aquí, y veamos cómo describen la manera en la que se harían las actualizaciones de un Kubernetes gestionado de acuerdo con los principios de GitOps. Aquí hay un resumen:
- Un desarrollador hace una solicitud de extracción de Git para una nueva característica.
- El código es revisado y aprobado, y luego fusionado en la codebase principal.
- La fusión activa los canales de CI/CD, que automáticamente prueban y reconstruyen el nuevo código y lo despliega en un registro.
- Un agente de software se da cuenta de la actualización, extrae el nuevo código del registro y actualiza el archivo de configuración (escrito en YAML) en el repositorio de configuración.
- Un agente software en el clúster de Kubernetes detecta que está desactualizado, con base en el archivo de configuración, saca los cambios e implementa la nueva característica.
Weaveworks y GitOps
Claramente los pasos 4 y 5 están haciendo gran parte del trabajo pesado. Los agentes de software que sincronizan mágicamente la "fuente de la verdad" en el repositorio de Git con la aplicación real de Kubernetes son la magia que hace posible GitOps. Como mencionamos, en términos de GitOps, el proceso de hacer que los sistemas en vivo se parezcan más a los sistemas ideales descritos en los archivos de configuración se llama convergencia. (Cuando el sistema en vivo y el sistema ideal no están sincronizados, se llama divergencia). Idealmente, la convergencia se lograría mediante procesos automatizados, pero hay límites a lo que la automatización puede hacer y a veces la intervención humana es necesaria.
Hemos descrito el proceso en términos genéricos, pero si realmente va a ver la página de Weaveworks, los "agentes de software" que mencionamos son parte de la plataforma Weave Cloud de la compañía. El término "GitOps" fue acuñado por el CEO de Weaveworks, Alexis Richardson, y sirve en parte para hacer de la plataforma de Weaveworks una atractiva para los desarrolladores ya empapados en los mundos de devops y CI/CD.
Pero Weaveworks nunca ha reclamado el monopolio de GitOps, que es más una filosofía y un conjunto de mejores prácticas, que un producto específico. Como señala el blog de CloudBees, una empresa que proporciona soluciones de CI/CD, GitOps representa un modelo abierto y neutral de proveedor que fue desarrollado como una reacción a las soluciones gestionadas patentadas de Kubernetes que están siendo desplegadas por grandes proveedores de nubes como Amazon, Google y Microsoft. CloudBees ofrece sus propias soluciones GitOps, al igual que un gran número de jugadores en este espacio.
GitOps y devops
Atlassian, una empresa que fabrica varias herramientas para desarrolladores agile, hizo una publicación de blog, que vale la pena leer, en la que habla sobre la historia y el propósito de GitOps En su opinión, GitOps representa una extensión lógica de las ideas que se unieron como devops. Específicamente, GitOps es una elaboración del concepto de infraestructura como código, una idea que surgió del entorno de devops. GitOps, tal como lo ve Atlassian, tendió un puente entre las técnicas de devops existentes, que habían evolucionado para resolver problemas de administración de sistemas, y las necesidades específicas de las aplicaciones distribuidas de alojamiento en la nube. La convergencia automatizada que ofrecen varios proveedores de nube es lo que hace especial a GitOps.
Y aunque GitOps sigue centrándose en Kubernetes, esperamos haber dejado claro cómo se aplica al mundo mucho más amplio de las aplicaciones distribuidas y basadas en la nube. Una publicación en el blog del proveedor de seguridad de código abierto WhiteSource resumen las ventajas de GitOps:
- Observabilidad: Los sistemas GitOps ofrecen monitoreo, registro, seguimiento y visualización en aplicaciones complejas para que los desarrolladores puedan ver qué se está quebrando y dónde.
- Control de versiones y gestión de cambios: Obviamente este es un beneficio clave de usar un sistema de control de versiones como Git. Las actualizaciones defectuosas pueden ser fácilmente eliminadas/deshechas.
- Fácil adopción: GitOps se basa en las habilidades devops que muchos desarrolladores ya tienen.
- Productividad: GitOps proporciona los incrementos de productividad que devops y CI/CD han llevado a otras dimensiones.
- Auditoría: Gracias a Git, cada acción puede ser rastreada hasta un compromiso específico, facilitando el seguimiento de la causa de los errores.
Incluso si no usa Kubernetes, es muy probable que GitOps forme parte de su flujo de trabajo tarde o temprano.
Josh Fruhlinger, InfoWorld (EE.UU.)
Puede ver también