GitOps: ArgoCD y Helm

Este es el primer post de una colección de artículos enfocados en herramientas para GitOps. En este post, analizaremos una herramienta para despliegue continuo en Kubernetes: ArgoCD. Si no has leído los artículos previos a cerca de Kubernetes deployments y Helm, échales un ojo antes de leer este post, ya que te ayudarán a entender la idea general mucho mejor.

GitOps

GitOps se define como una estrategia para gestionar la infraestructura de Kuberentes y sus aplicaciones en la que la definición declarativa de lo que debe estar corriendo en el clúster se almacena en un repositorio de git. El repositorio de git se considera como la la única fuente de verdad en el modelo de GitOps. Con esta estrategia, cualquier cambio en la definición de las aplicaciones (código), se refleja en la infraestructura desplegada y en las aplicaciones. Además, permite detectar diferencias y desviaciones entre el código de la aplicación y las versiones desplegadas.

GitOps incrementa la frecuencia de entregas de software, ya que en el momento en el que el código se encuentre en la rama productiva, también estará presente en el clúster en cuestión de segundos, incrementando también la productividad. Este modelo incrementa también la fiabilidad y robustez, ya que como todas las aplicaciones y los despliegues se encuentran bajo el control de versiones de git, los rollbacks y procedimientos de recuperación son más sencillos. Además, GitOps permite mejorar la estabilidad y la consistencia de las aplicaciones, al automatizar y unificar el método de despliegue.

ArgoCD

ArgoCD es una herramienta de despliegue continuo que funciona de forma declarativa. Se puede instalar en un clúster de Kubernetes y puede desplegar aplicaciones en el mismo clúster o en otros clústers, permitiendo así gestionar de forma centralizada y automática el despliegue de software. Además permite controlar qué versión de cada aplicación hay desplegada en cada entorno, detectar desviaciones y monitorizar el estado de los recursos de las aplicaciones. Gracias al control de las versiones que se despliegan, los rollbacks y upgrades de las aplicaciones se facilitan bastante.

Instalando ArgoCD

Para una instalación rápida, ArgoCD puede desplegarse utilizando sus manifiestos de Kubernetes. Ejecutando los comandos a continuación, ArgoCD se instala en un namespace dedicado, con todos los recursos que necesitará para operar en el clúster, incluyendo una interfaz web bastante útil. Esta instalación usa la configuración más sencilla posible, ya que se va a utilizar para una demostración sencilla. Para entornos productivos, el empleo de arquitecturas más complejas y resilientes es recomendables.



kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Al igual que Kubernetes, ArgoCD tiene su propio plano de control, incluyendo un API server, un controlador y un servidor de repositorios. Estos son los tres componentes que hacen la magia de ArgoCD posible:

El API server permite interaccionar con ArgoCD a través de la interfaz web y del CLI, y facilita su integración con plataformas de CI/CD y sus pipelines.
El controlador de aplicaciones se encarga de monitorizar las aplicaciones desplegadas en el clúster, subsanando cualquier posible desviación con respecto al estado deseado, sincronizando los objetos de Kubernetes presentes en el clúster con los definidos en el repositorio git.
El servidor de repositorios cachea el repositorio git asociado con cada aplicación presente en el clúster. Genera los manifiestos de Kubernetes que se despliegan en el clúster, aplicando herramientas de templatizado y gestión de configuración y plugins cuando sea necesario.

Para interaccionar con la API de ArgoCD de forma programática, es necesario instalar su CLI. Obtén la versión del CLI para tu SO esta página.



brew tap argoproj/tap
brew install argoproj/tap/argocd

El API server no se expone fuera del clúster con la configuración sencilla que estamos utilizando, por lo que hay que utilizar un ingress controller o un servicio de tipo LoadBalancer. Para mantener este ejemplo lo más sencillo posible, sencillamente parchearemos el servicio que utiliza el API server de ArgoCD para que se exponga usando un LoadBalancer.



kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Tras desplegar los recursos de ArgoCD y parchear el servicio, estos son los pods y servicios que deben estar corriendo en el clúster. Puedes observar que la IP externa que utiliza el LoadBalancer es localhost, esto se debe a que minikube fue el entorno empleado en este ejemplo.

Para la configuración inicial, ArgoCD utiliza el nombre del pod del API server como la clave del usuario admin, por lo que en este caso, la clave es argocd-server-7fbc7665b-plpj7. Loguéate en el servidor utilizando el CLI y cambia la contraseña.



argocd login [argocd-server-ip]
argocd account update-password

Utilizando el GUI

Ahora, podemos probar la nueva contraseña en la interfaz web. Estará accesible en la IP externa del servicio LoadBalancer en el puerto 80 y 443. Una vez que te hayas logueado correctamente, tendrás acceso al dashboard principal, desde el que se gestionan todas las aplicaciones y componentes desplegados en los clústers.

Para desplegar una nueva aplicación, primero es necesario añadir un repositorio, para que se pueda utilizar el código. En este caso, usaremos una sencilla aplicación con Helm que se ha utilizado en posts anteriores. Despliega un conjunto de pods utilizando imágenes de apache (httpd). A la hora de configurar el repositorio, es posible añadir credenciales, así como un certificado TLS para utilizar una conexión segura. Además, se puede utilizar SSH en las conexiones con el repositorio.

Una vez que el repositorio ha sido configurado, podemos empezar a crear la primera aplicación. Es recomendable comprobar antes que nada si ArgoCD puede conectarse al repositorio de ejemplo.

Para crear una nueva aplicación, hay que especificar una serie de parámetros, como el nombre, el repositorio de git y ruta a utilizar, así como el clúster de Kubernetes y el namespace en el que la aplicación se debe desplegar. En este paso, la política de sincronización puede definirse también. Para este primer ejemplo, la aplicación se desplegará de forma manual, dentro del mismo clúster en el que se encuentra ArgoCD, pero en un namespace diferente. En la imagen inferior puede verse que la revision HEAD está seleccionada, por lo que utilizará la rama máster del repositorio y . es la ruta dentro del repositorio en la que se buscarán los manifiestos de Kubernetes.

En este caso, se utilizará Helm como lenguaje de templatizado. No obstante, ArgoCD soporta Kustomize y Ksonnet también como herramientas para el templatizado y la gestión de la configuración en Kubernetes. De la misma forma, se pueden utilizar manifiestos de Kubernetes sin templatizado. Las funcionalidades de ArgoCD se pueden extender por medio de plugins, que permiten su integración con otras herramientas externas. Se puede observar cómo ArgoCD detecta el fichero values.yaml y permite modificar los valores directamente en la interfaz web, antes de desplegar el chart.

En el dashboard principal, clicando en la nueva aplicación, puede observarse como ArgoCD ha detectado todos los objetos de Kubernetes que conforman la aplicación. Esta visualización puede ser muy útil para despliegues complejos, ya que permite identificar las dependencias entre recursos de forma rápida y visual.

ArgoCD detecta la nueva aplicación en un estado de OutOfSync , ya que la aplicación se definió con un mecanismo de sincronización manual. Por ello, no existen aún componentes en el clúster asociados con la aplicación. A la hora de sincronizar, se pueden seleccionar diferentes opciones para los recursos, incluyendo el modo dry-run, ideal para validaciones.

Sincronicemos la aplicación manualmente! Para ello, es necesario clicar en el botón 'sync', y acto seguido la aplicación se empezará a sincronizar, mostrando el progreso en tiempo real. Una vez que acabe, los pods y el resto de recursos creados en el clúster aparecerán con un check en verde.

Aquí puede verse como los recursos que muestra ArgoCD coinciden con los que se encuentran desplegados en el clúster, pero el interfaz de ArgoCD proporciona un método más visual.

Utilizando el CLI

El API server de ArgoCD es lo que hace funcionar la interfaz web, por ello, interaccionando con el API server se pueden llevar a cabo las mismas acciones que utilizando el interfaz web. El CLI de ArgoCD es una herramienta que permite comunicarse con el API server de forma sencilla.

Puedes comprobar el estado de las aplicaciones del clúster y sincronizarlas con el CLI. Esto puede ser especialmente útil para la automatización. Los siguientes comandos muestran una lista de todas las aplicaciones que controla ArgoCD y describen los detalles de una aplicación específica.



argocd app list
argoc app get yourappname

Además, el CLI puede utilizarse para desplegar una aplicación utilizando su definición explícita, y soporta una gran variedad de opciones, por lo que si quieres conocerlo un poco mejor, la ayuda integrada del CLI será un poderoso aliado.



argocd app create helmcli --repo https://github.com/mifonpe/helmbasics --path . --dest-namespace test --dest-server https://kubernetes.default.svc

Como se puede ver en la siguiente imagen, la aplicación no se ha desplegado bien, ya que esta aplicación expone su servicio utilizando el mismo nodePort que emplea la aplicación que desplegamos anteriormente. Como los servicios NodePort en Kubernetes conectan los puertos de los contenedores con los puertos de los hosts físicos en los que corren, el mismo puerto del host no puede ser utilizado por dos servicios.

Solucionemos el problema rápidamente. Utilizando el interfaz web, si inspeccionas los detalles de la aplicación, podrás editar los values que toma el chart de Helm. Modifica el valor del puerto del NodePort para que cada despliegue utilice un número de puerto diferente. Una vez modificados los values de Helm, sincroniza la aplicación.

Con el nuevo número de puerto para el NodePort, esta nueva aplicación se despliega correctamente.

Por último, limpiemos el clúster utilizando el CLI. El comando que se muestra a continuación elimina la aplicación especificada y sus recursos.



argocd app delete yourappname

Definición declarativa

Las aplicaciones en ArgoCD pueden definirse como objetos en Kubernetes, haciendo posible la automatización de la creación de las mismas. Esto es lo que se conoce como la definición declarativa de las aplicaciones. Para crear una aplicación de forma declarativa, ésta debe ser creada en el namespace en el que ArgoCD se encuentra instalado. El siguiente código muestra el contenido de app.yaml, una definición de aplicación declarativa.



apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: declarative
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/mifonpe/helmbasics'
    path: .
    targetRevision: HEAD
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: default

Al crear este objeto en el clúster, la aplicación aparece en ArgoCD, pero como la sincronización automática no se activó, la aplicación se muestra de nuevo en estado OutOfSync.

Como comentamos anteriomente, el CLI puede utilizarse para sincronizar aplicaciones presentes en el clúster.

Por último, si se elmina el objeto creado en el clúster representando a la aplicación, desaparece en ArgoCD.

Sincronización automática

Para conseguir un despliegue continuo, es posible activar la sincronización automática de las aplicaciones. Cuando se activa, dos opciones adicionales pueden seleccionarse: prune y self-heal. La primera se asegura de que los recursos que se han borrado en el repositorio git se eliminen en el clúster, mientras que la segunda permite a ArgoCD recrear aquellos recursos que han sido modificados y no coinciden con el código original. Seleccionaremos los dos, y una rama diferente, la rama production . NOTA IMPORTANTE: No podrás reproducir este mismo ejemplo ya que el repositorio público empleado no puede ser editado por motivos de seguridad. Si quieres probarlo, puedes hacer un fork del repositorio helm basics y dar de alta una nueva aplicación que utilice la URL de tu repositorio. No olvides añadir claves SSH o autenticación por usuario y contraseña.

La mejor forma de probar el 'self-healing' de ArgoCD es jugar con nuestro despliegue. Escalemos el despliegue original a dos réplicas para que solo queden dos pods corriendo. Verás que es casi imposible, porque en el momento que ArgoCD detecta la diferencia entre el número de réplicas en el clúster y el código en git, restaura el número de réplicas originales.

Además, ArgoCD detecta nuevos commits en la rama del repositorio seleccionada en la configuración de la aplicación. Así, cualquier modificación en el código, se desplegará automáticamente en el clúster. Para este ejemplo, el número de réplicas se sube a 5 en el fichero values.yaml de la rama production.

Tras hacer el commit de los cambios en la rama production, y esperar a que ArgoCD detecte los cambios (20-30 segundos), dos nuevos pods se despliegan en nuestra aplicación.

El CLI de ArgoCD permite inspeccionar la historia de las aplicaciones, mostrando el checksum asociado con el commit de cada sincronización.

Si quieres limpiar el clúster al terminar este ejemplo, primero elimina la aplicación, y luego solo tendrás que eliminar los recursos de ArgoCD y su namespace.



argocd app delete yourappname
kubectl delete -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl delete namespace argocd

Conclusion

En este post se hizo una presentación de ArgoCD como herramienta de CD y habilitador para el modelo de GitOps. ArgoCD ayuda automatizando el despliegue de aplicaciones en Kubernetes, así como garantizando que lo que está corriendo en el clúster coincide con lo que se ha definido en el repositorio de git. Este comportamiento proporciona funcionalidades muy útiles: análisis del estado de salud de las aplicaciones, detección de modificaciones, control de versiones y rollback a versiones anteriores.

Además, ArgoCD ofrece su propio API server e interfaz web, que permiten consultar el estado de las aplicaciones en tiempo real, así como su propio CLI, ideal para integrarlo con pipelines de CI. Todas estas características son las que hacen de ArgoCD una buena elección para ser integrado en el de CI/CD en entornos cloud native.

Si quieres saber más acerca de ArgoCD, aquí tienes su documentación.