Introducción
En este artículo hablaremos de una de las herramientas del momento cuando se habla de procesos de integración y despliegue continuo CICD en Kubernetes, ArgoCD. Y es que, en los últimos meses, son muchas las empresas punteras del sector de internet que han declarado públicamente el uso de ArgoCD para desplegar aplicaciones en sus clústers. Puedes ver una lista aquí.
Para empezar, vamos a repasar para qué sirve y hasta dónde llegan las funcionalidades de ArgoCD. Seguidamente, veremos un caso de uso típico de despliegue de aplicaciones usando ArgoCD y las ventajas que nos aporta su implementación. Finalmente, comentaremos las conclusiones que hemos sacado en cuanto a pros y contras, y analizaremos que otras herramientas complementan ArgoCD para optimizar aún más el proceso de integración y despliegue continuo de aplicaciones.
¿Que es ArgoCD?
ArgoCD es una herramienta que nos permite adoptar metodologías GitOps para el despliegue continuo de aplicaciones en clústers de kubernetes.
La principal característica es que ArgoCD sincroniza el estado de las aplicaciones desplegadas con sus respectivos manifiestos declarados en git. Permitiendo así a los desarrolladores realizar cambios en la aplicación con solo modificar el contenido de git, ya sea con commits a ramas de desarrollo o modificando main.
Una vez modificado el código en git, ArgoCD detecta, mediante webhook o comprobación periódica cada 3 minutos, que ha habido cambios en los manifiestos de las aplicaciones. Seguidamente, compara los manifiestos declarados en git con los que hay aplicados en los clústers y actualiza estos últimos hasta sincronizarlos.
Su refinada interfaz de usuario permite visualizar muy bien el contenido, estructura y estado de los clústers ademas que deja manipular los recursos.
¿Permite ArgoCD automatizar todo el proceso de CI/CD de una aplicación?
No, ArgoCD se encarga de desplegar la aplicación una vez ya existe el artefacto en un registro de contenedores, como Dockerhub o ECR. Esto implica que previamente el código de la aplicación ya ha sido testado y «containerizado» en una imagen. Al final de este artículo vamos a hablar sobre qué opciones existen actualmente para llevar a cabo esta tarea.
Como ya hemos explicado, ArgoCD sincroniza el estado de las aplicaciones desplegadas con sus respectivos manifiestos declarados en git. Pero no se refiere al repositorio git del código de la aplicación en sí, sino a otro repositorio separado, como indican las buenas prácticas, que contiene el código de la infraestructura en kubernetes de la aplicación, que puede ser en forma de helm charts, aplicación kustomize, ksonnet…
Para explicar mejor los principales beneficios que ofrece ArgoCD veamos un ejemplo de uso.
Usando ArgoCD
En este ejemplo vamos a ver cómo ArgoCD puede desplegar ya sea aplicaciones desarrolladas por terceros, que tiene su propio helm chart mantenido por otra organización, o una propia donde hemos definido el chart nosotros mismos.
Para el ejemplo desplegaremos un stack de monitoring compuesto de Prometheus, Grafana y Thanos mediante sus helm charts.
ArgoCD despliega las aplicaciones mediante un objeto custom llamado Application. Este objeto tiene como atributos un origen y una destinación. El origen puede tener varios formatos, como por ejemplo un helm chart de un repositorio de charts, o un repositorio git que contiene helm charts. La destinación es el cluster al cual será desplegado el contenido del origen. En la configuración del application podemos indicar que ArgoCD mantenga automáticamente sincronizado el estado de los objetos de kubernetes desplegados con la configuración indicada en el origen (charts/git). Esta opción es muy interesante, ya que nos asegura que ArgoCD va a estar pendiente cada pocos minutos de que todo siga en su sitio, por contra, desplegando las aplicaciones directamente con comandos de helm únicamente nos aseguramos la sincronización en el momento de un despliegue.
Ahora que ya hemos explicado que es el objeto Application, para nuestro monitoring-stack, vamos a crear cuatro. ¿Por qué cuatro Applications si solo habrá 3 servicios en el stack? (Prometheus, Grafana y Thanos)
ArgoCD también nos ofrece la posibilidad de generar grupos de aplicaciones que siguen el concepto de «app of apps pattern» . Se trata de una ArgoCD application que despliega otras aplicaciones y así recursivamente. En el caso de nuestro monitoring stack, vamos a crear una cuarta aplicación que va a desplegar las otras 3 restantes, la aplicación padre la vamos a llamar «monitoring-stack».
Para crear una aplicación podemos definir un manifiesto ArgoCD Application, como se indica en esta página de la documentación. También podemos mediante línea de comandos. Pero ArgoCD tiene una genial UI que permite crear aplicaciones manualmente también, puede ver cómo aquí.
La aplicación «monitoring-stack» apuntará su origen a un repositorio git con un Helm chart. Este chart contendrá los manifiestos de las otras tres aplicaciones en el directorio «templates» en formato yaml. Estos archivos son definiciones de objetos Application que apuntan al pertinente Helm chart oficial de cada servicio. Mediante los «values files», podremos desplegar diferentes versiones en entornos distintos.
Una vez definidas las templates del chart «monitoring-stack», vamos a crear la ArgoCD Application, y en source vamos a apuntar hacia el repositorio que lo contiene. ArgoCD va a detectar que se trata de un helm chart y podremos indicar el path del values file concreto, por ejemplo «prod-values.yaml».
Al finalizar la configuración manual de la aplicación, en la interfaz de usuario veremos como se representan todos los objetos generados, organizados de forma jerárquica.
Al estar las aplicaciones sincronizadas con nuestro repositorio, y los charts parametrizados con templates y values. Para desplegar una nueva versión de cualquiera de nuestras aplicaciones solo tendremos que modificar el archivo values mediante commits de git.
ArgoCD se encargará de detectar los cambios en el repositorio y aplicarlos en el clúster de kubernetes mediante un despliegue rolling update.
Como apunte, usando ArgoCD Image Updater nos podemos ahorrar hacer este último paso manualmente, o incluso tener que desarrollar una pipeline compleja para actualizar el fichero values.yaml en git cuando queremos desplegar la nueva imagen.
Esta herramienta consulta periódicamente los últimos tags en nuestro repositorio de imágenes buscando nuevos artefactos para desplegar. De esta forma, una vez ha encontrado uno nuevo, se encarga de automatizar el proceso de despliegue editando la configuración de git con el nombre del nuevo tag.
Hace falta mencionar que aún no hay una versión estable de ArgoCD Image Updater, pero se la espera pronto.
En este ejemplo hemos creado una aplicación que apunta a un repositorio que crea aplicaciones las cuales apuntan a helm charts oficiales, sin embargo este bucle jerárquico se puede extender mucho mas, siguiendo el «app of apps pattern».
Otra característica interesante de ArgoCD es que nos permite desplegar aplicaciones en distintos clústers. Hay varias maneras de hacerlo, no obstante la más directa es mediante el recurso Application Set.
En su manifiesto podemos especificar una lista de clusters donde desplegar simultáneamente con distintos paths del repositorio. Ya que en nuestro repositorio podemos especificar diferentes versiones para cada clúster.
La relativa facilidad de instalación que tiene ArgoCD supone otro punto positivo a tener en cuenta, aquí puedes consultar los pasos.
Automatización de todo el proceso CICD con Argo
En el caso de querer ir un paso más allá y automatizar todo el proceso de CICD en kubernetes, podemos complementar ArgoCD con el resto de herramientas que presenta el proyecto Argo.
Combinando Argo Events, Argo Workflows, ArgoCD y Argo Rollouts es posible una mayor automatización siguiendo las mejores prácticas en los estándares actuales de integración continua.
Victor Farcic lo explica de manera muy coherente en este video.
Como solución a la complejidad añadida que supone instalar y manejar todas estas herramientas de Argo project, ya han salido al mercado algunas aplicaciones que engloban todo este stack y nos permiten configurar los pipelines para la integración y despliegue des de una capa de mas alto nivel mas simplificada. A continuación mencionamos un par de ellas, aun que en este post no vamos a analizar las funcionalidades particulares.
Devtron es una herramienta open source que instala por debajo todo este paquete de Argo y otras herramientas y promete permitirnos automatizar todo el proceso CICD por completo des de la interfaz gráfica. Devtron simplifica bastante la configuración, ya que interactuamos con las herramientas internas des de una capa de alto nivel. Aunque después de probarlo, no creemos que la herramienta tenga la suficiente madurez como para ser implementada en un entorno productivo, de momento.
Similar al approach de Devtron, Codefresh engloba todas las aplicaciones del stack de Argo para automatizar toda la integración y despliegue. Pero aparte de que la herramienta aún se encuentra en early-access, una gran diferencia es que el acceso a la herramienta será en formato SaaS. Como podemos ver en el apartado de pricing, la opción de automatización completa será de pago y el precio no se menciona en la web.
Conclusiones
ArgoCD es una herramienta muy útil para automatizar el proceso de deploy mediante buenas prácticas GitOps. Gracias a su implementación, los developers pueden probar las nuevas versiones de las aplicaciones más rápidamente y desplegar en producción de forma segura una vez finalizados las pruebas. Además, gracias a la función de auto-sync y su bonita interfaz, ArgoCD nos permite tener controlado en todo momento el estado de las aplicaciones y sus recursos desplegados en Kubernetes. Combinado con las demás herramientas del proyecto Argo podemos automatizar todo el proceso de CICD (y otras muchas utilidades fuera del scope de este post) siguiendo buenas prácticas para los estándares actuales.
Como punto negativo, usar ArgoCD introducirá una capa extra de complejidad a nuestra configuración, ya que dispone de muchas opciones distintas, introduce «custom objects» y conceptos a los cuales no estamos familiarizados aún. Puede ser «overkill» si tenemos un clúster muy pequeño con solo un puñado de aplicaciones.
