El término DevOps hace referencia a la cultura y conjunto de prácticas que pretenden acortar el ciclo de vida de desarrollo del software mediante el acercamiento de los equipos de desarrollo y de operaciones, quienes tradicionalmente trabajaban aisladamente. DevOps tiene su origen en las metodologías ágiles y se basa principalmente en la automatización de las tareas y el monitoreo constante de estas. A raíz de su aplicación en distintos ámbitos, han ido surgiendo otros conceptos parecidos como MLOps, DevSecOps, DataOps, etc. Así, es razonable plantearse: ¿Es posible aplicar estos principios a la gestión de la infraestructura?
La respuesta es Sí. GitOps es una evolución de DevOps que consiste en el uso de repositorios de Git como única fuente de verdad del estado de la infraestructura. Mediante el uso de prácticas y herramientas como infraestructura como código (IaC) o pipelines de CI/CD, el objetivo consiste en conseguir que el estado del sistema descrito por el contenido de los ficheros del repositorio coincida exactamente con su estado real. Algunas de las ventajas más destacadas son:
- Automatización: El código y configuraciones que conducen al estado actual se encuentran en un repositorio accesible por el equipo de trabajo. En caso de fallo, es posible reproducir automáticamente el estado de la infraestructura.
- Transparencia y visibilidad: El propio repositorio de Git sirve como documentación del estado del sistema. Cualquiera con acceso a este puede conocer con exactitud qué configuraciones se están aplicando, ya que Git actúa como fuente única de verdad.
- Control de versiones: Git, al ser un sistema de control de versiones, permite registrar cada uno de los cambios realizados en la infraestructura, permitiendo realizar rollbacks fácilmente en caso de errores o conocer su historial.
GitOps y Kubernetes
Uno de los puntos clave de Kubernetes es su carácter declarativo, es decir, los recursos del clúster como pueden ser los Pods, Deployments, Ingress, Service, etc. pueden ser creados de manera declarativa mediante archivos yaml, llamados manifests. ¿Qué pasaría si se elimina un Ingress? Si conservamos su definición, basta con volverlo a aplicar y Kubernetes se encargará de realizar los cambios correspondientes. Pero, ¿y si incluso este proceso se pudiera llegar a automatizar, de manera que el propio sistema fuera capaz de detectar qué recursos faltan y recrearlos?
El término GitOps se originó en este contexto, pero aún falta por introducir un componente, “el controlador”. El controlador es el software responsable de reconciliar el estado del repositorio con el estado del clúster. Para ello, el controlador debe poder conectarse al clúster, monitorizar las definiciones de los recursos existentes y compararlos con aquellos del repositorio. Si el controlador detecta alguna diferencia, este se encargará de sincronizarlos y aplicar las medidas necesarias para solucionarlo, incluyendo tareas como la creación, eliminación y actualización de recursos.
¿Qué es ArgoCD?
ArgoCD es una herramienta declarativa de despliegue continuo (CD) que permite implementar GitOps en Kubernetes. ArgoCD consiste en un controlador de Kubernetes que monitoriza continuamente las aplicaciones que se están ejecutando (estado actual) y las compara con el estado deseado. Si estos dos estados difieren, ArgoCD marcará la aplicación como OutOfSync y ofrecerá la posibilidad de sincronizarla automáticamente o manualmente a través de una interfaz web o CLI.
Ejemplo práctico: Modificando un Deployment
Supongamos que queremos gestionar un conjunto de recursos de Kubernetes con GitOps, y para ello queremos usar ArgoCD. Inicialmente, se debe disponer de un repositorio de Git y un clúster de Kubernetes con ArgoCD instalado. Existen varias formas de instalarlo (por ejemplo Helm). En este caso, se asume que ArgoCD se ha instalado en el mismo clúster de Kubernetes, aunque esto no tiene por qué siempre ser así.
Para este ejemplo, se desplegará el siguiente Deployment:
ArgoCD distingue qué recursos debe gestionar mediante Applications. Una Application es un Custom Resource (CR) propio de ArgoCD que contiene información acerca de dónde encontrar los manifests y dónde aplicarlos.
Con esta aplicación, ArgoCD se configurará de la siguiente manera:
- Estado deseado: El directorio manifests de la rama main del repositorio de Git gitops-workshop.
- Estado actual: El contenido del namespace nginx del clúster de Kubernetes dónde se encuentra ArgoCD.
Nota: Las aplicaciones también se pueden crear desde la Web UI o la CLI. Ambos métodos acaban generando el mismo recurso.
Accediendo a la interfaz web de ArgoCD se podrá observar que se ha creado la aplicación nginx. Aparecerá como OutOfSync, ya que el deployment que hay en el repositorio aún no existe en el clúster. Para solucionarlo, hay que clicar en el botón de Sync.
Si todo ha ido bien, unos instantes después la aplicación pasará a Synced, pudiéndose verificar cómo ArgoCD ha creado el recurso.
Para ilustrar el funcionamiento de ArgoCD, se puede modificar algún parámetro del recurso. El siguiente comando reduce el número de réplicas del deployment a 1:
$ kubectl scale deploy nginx-deployment –replicas=1 -n nginx
Al ejecutarlo, veremos como la aplicación vuelve de nuevo a estar OutOfSync. Al clicar en la sección diff, podremos comprobar las diferencias entre el estado actual (izquierda) y el estado deseado (derecha).
Después de volver a sincronizar, ArgoCD restaurará el número original de réplicas, reconciliando así el clúster con la información del repositorio de Git. En consecuencia, cualquier cambio que se desee llevar a cabo debe estar registrado en el repositorio de Git.
ArgoCD ofrece un amplio número de posibles configuraciones, como por ejemplo la posibilidad de ignorar cambios en campos específicos de algunos recursos, la selección de distintas maneras de crearlos, la posibilidad de sincronizar automáticamente las aplicaciones, etc. Su documentación es detallada y contiene información acerca de todas sus funcionalidades.
Conclusión
Hemos visto en qué consiste el paradigma GitOps y cómo se puede llevar a cabo para gestionar clústers de Kubernetes mediante ArgoCD. Sin embargo, su aplicación no está limitada únicamente a este sector: Debido a las ventajas que ofrece GitOps, en los últimos años han surgido otras soluciones destinadas a aplicar estas prácticas en otros contextos, como es el despliegue de infraestructura cloud con Terraform. Actualmente, GitOps es una realidad consolidada en muchos sistemas IT y es un paradigma recomendado a la hora de iniciar un proyecto de estas características.