Para empezar, vamos a repasar para qu\u00e9 sirve y hasta d\u00f3nde llegan las funcionalidades de ArgoCD. Seguidamente, veremos un caso de uso t\u00edpico de despliegue de aplicaciones usando ArgoCD y las ventajas que nos aporta su implementaci\u00f3n. Finalmente, comentaremos las conclusiones que hemos sacado en cuanto a pros y contras, y analizaremos que otras herramientas complementan ArgoCD para optimizar a\u00fan m\u00e1s el proceso de integraci\u00f3n y despliegue continuo de aplicaciones.<\/p>\n
\u00bfQue es ArgoCD?<\/h2>\n
ArgoCD es una herramienta que nos permite adoptar metodolog\u00edas GitOps<\/a> para el despliegue continuo de aplicaciones en cl\u00fasters de kubernetes.<\/p>\n La principal caracter\u00edstica es que ArgoCD sincroniza el estado de las aplicaciones desplegadas con sus respectivos manifiestos declarados en git. Permitiendo as\u00ed a los desarrolladores realizar cambios en la aplicaci\u00f3n con solo modificar el contenido de git, ya sea con commits a ramas de desarrollo o modificando main. Su refinada interfaz de usuario permite visualizar muy bien el contenido, estructura y estado de los cl\u00fasters ademas que deja manipular los recursos.<\/p>\n \u00bfPermite ArgoCD automatizar todo el proceso de CI\/CD de una aplicaci\u00f3n?<\/p>\n No, ArgoCD se encarga de desplegar la aplicaci\u00f3n una vez ya existe el artefacto en un registro de contenedores, como Dockerhub o ECR.\u00a0 Esto implica que previamente el c\u00f3digo de la aplicaci\u00f3n ya ha sido testado y \u00abcontainerizado\u00bb en una imagen. Al final de este art\u00edculo vamos a hablar sobre qu\u00e9 opciones existen actualmente para llevar a cabo esta tarea.<\/p>\n 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\u00f3digo de la aplicaci\u00f3n en s\u00ed, sino a otro repositorio separado, como indican las buenas pr\u00e1cticas, que contiene el c\u00f3digo de la infraestructura en kubernetes de la aplicaci\u00f3n, que puede ser en forma de helm charts, aplicaci\u00f3n kustomize, ksonnet…\u00a0<\/a><\/p>\n Para explicar mejor los principales beneficios que ofrece ArgoCD veamos un ejemplo de uso.<\/p>\n En este ejemplo vamos a ver c\u00f3mo ArgoCD puede desplegar ya sea aplicaciones desarrolladas por terceros, que tiene su propio helm chart mantenido por otra organizaci\u00f3n, o una propia donde hemos definido el chart nosotros mismos.<\/p>\n Para el ejemplo desplegaremos un stack de monitoring compuesto de Prometheus, Grafana y Thanos mediante sus helm charts.<\/p>\n ArgoCD despliega las aplicaciones mediante un objeto custom llamado Application<\/a>. Este objeto tiene como atributos un origen y una destinaci\u00f3n. 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\u00f3n es el cluster al cual ser\u00e1 desplegado el contenido del origen. En la configuraci\u00f3n del application podemos indicar que ArgoCD mantenga autom\u00e1ticamente sincronizado el estado de los objetos de kubernetes desplegados con la configuraci\u00f3n indicada en el origen (charts\/git). Esta opci\u00f3n 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 \u00fanicamente nos aseguramos la sincronizaci\u00f3n en el momento de un despliegue.<\/p>\n Ahora que ya hemos explicado que es el objeto Application, para nuestro monitoring-stack, vamos a crear cuatro. \u00bfPor qu\u00e9 cuatro Applications si solo habr\u00e1 3 servicios en el stack? (Prometheus, Grafana y Thanos)<\/p>\n ArgoCD tambi\u00e9n nos ofrece la posibilidad de generar grupos de aplicaciones que siguen el concepto de \u00abapp of apps pattern\u00bb<\/a> . Se trata de una ArgoCD application que despliega otras aplicaciones y as\u00ed recursivamente. En el caso de nuestro monitoring stack, vamos a crear una cuarta aplicaci\u00f3n que va a desplegar las otras 3 restantes, la aplicaci\u00f3n padre la vamos a llamar \u00abmonitoring-stack\u00bb.<\/p>\n Para crear una aplicaci\u00f3n podemos definir un manifiesto ArgoCD Application, como se indica en esta p\u00e1gina de la documentaci\u00f3n<\/a>. Tambi\u00e9n podemos mediante l\u00ednea de comandos.<\/a> Pero ArgoCD tiene una genial UI que permite crear aplicaciones manualmente tambi\u00e9n, puede ver c\u00f3mo aqu\u00ed.<\/a><\/p>\n La aplicaci\u00f3n \u00abmonitoring-stack\u00bb apuntar\u00e1 su origen a un repositorio git con un Helm chart. Este chart contendr\u00e1 los manifiestos de las otras tres aplicaciones en el directorio \u00abtemplates\u00bb en formato yaml. Estos archivos son definiciones de objetos Application<\/a> que apuntan al pertinente Helm chart oficial de cada servicio. Mediante los \u00abvalues files\u00bb, podremos desplegar diferentes versiones en entornos distintos.<\/p>\n <\/p>\n Una vez definidas las templates del chart \u00abmonitoring-stack\u00bb, 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 \u00abprod-values.yaml\u00bb.<\/p>\n Al finalizar la configuraci\u00f3n manual de la aplicaci\u00f3n, en la interfaz de usuario veremos como se representan todos los objetos generados, organizados de forma jer\u00e1rquica.<\/p>\n <\/p>\n Al estar las aplicaciones sincronizadas con nuestro repositorio, y los charts parametrizados con templates y values. Para desplegar una nueva versi\u00f3n de cualquiera de nuestras aplicaciones solo tendremos que modificar el archivo values mediante commits de git. <\/p>\n Como apunte, usando ArgoCD Image Updater<\/a> nos podemos ahorrar hacer este \u00faltimo paso manualmente, o incluso tener que desarrollar una pipeline compleja para actualizar el fichero values.yaml en git cuando queremos desplegar la nueva imagen. En este ejemplo hemos creado una aplicaci\u00f3n que apunta a un repositorio que crea aplicaciones las cuales apuntan a helm charts oficiales, sin embargo este bucle jer\u00e1rquico se puede extender mucho mas, siguiendo el \u00abapp of apps pattern\u00bb.<\/p>\n Otra caracter\u00edstica interesante de ArgoCD es que nos permite desplegar aplicaciones en distintos cl\u00fasters. Hay varias maneras de hacerlo, no obstante la m\u00e1s directa es mediante el recurso Application Set.<\/a> La relativa facilidad de instalaci\u00f3n que tiene ArgoCD supone otro punto positivo a tener en cuenta, aqu\u00ed puedes consultar los pasos<\/a>.<\/p>\n En el caso de querer ir un paso m\u00e1s all\u00e1 y automatizar todo el proceso de CICD en kubernetes, podemos complementar ArgoCD con el resto de herramientas que presenta el proyecto Argo.<\/a> Como soluci\u00f3n a la complejidad a\u00f1adida 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\u00f3n y despliegue des de una capa de mas alto nivel mas simplificada. A continuaci\u00f3n mencionamos un par de ellas, aun que en este post no vamos a analizar las funcionalidades particulares.<\/p>\n Devtron<\/a> 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\u00e1fica. Devtron simplifica bastante la configuraci\u00f3n, ya que interactuamos con las herramientas internas des de una capa de alto nivel. Aunque despu\u00e9s de probarlo, no creemos que la herramienta tenga la suficiente madurez como para ser implementada en un entorno productivo, de momento.<\/p>\n Similar al approach de Devtron, Codefresh<\/a> engloba todas las aplicaciones del stack de Argo para automatizar toda la integraci\u00f3n y despliegue. Pero aparte de que la herramienta a\u00fan se encuentra en early-access, una gran diferencia es que el acceso a la herramienta ser\u00e1 en formato SaaS. Como podemos ver en el apartado de pricing<\/a>, la opci\u00f3n de automatizaci\u00f3n completa ser\u00e1 de pago y el precio no se menciona en la web.<\/p>\n ArgoCD es una herramienta muy \u00fatil para automatizar el proceso de deploy mediante buenas pr\u00e1cticas GitOps. Gracias a su implementaci\u00f3n, los developers pueden probar las nuevas versiones de las aplicaciones m\u00e1s r\u00e1pidamente y desplegar en producci\u00f3n de forma segura una vez finalizados las pruebas. Adem\u00e1s, gracias a la funci\u00f3n 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\u00e1s herramientas del proyecto Argo podemos automatizar todo el proceso de CICD (y otras muchas utilidades fuera del scope de este post)\u00a0 siguiendo buenas pr\u00e1cticas para los est\u00e1ndares actuales.<\/p>\n Como punto negativo, usar ArgoCD introducir\u00e1 una capa extra de complejidad a nuestra configuraci\u00f3n, ya que dispone de muchas opciones distintas, introduce \u00abcustom objects\u00bb y conceptos a los cuales no estamos familiarizados a\u00fan. Puede ser \u00aboverkill\u00bb si tenemos un cl\u00faster muy peque\u00f1o con solo un pu\u00f1ado de aplicaciones.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Introducci\u00f3n En este art\u00edculo hablaremos de una de las herramientas del momento cuando se habla de procesos de integraci\u00f3n y despliegue continuo CICD en Kubernetes, ArgoCD. Y es que, en los \u00faltimos meses, son muchas las empresas punteras del sector de internet que han declarado p\u00fablicamente el uso de ArgoCD para desplegar aplicaciones en sus […]<\/p>\n","protected":false},"author":23,"featured_media":6552,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[114,18],"tags":[127],"yoast_head":"\n
\nUna vez modificado el c\u00f3digo en git, ArgoCD detecta, mediante webhook o comprobaci\u00f3n peri\u00f3dica 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\u00fasters y actualiza estos \u00faltimos hasta sincronizarlos.<\/p>\nUsando ArgoCD<\/h2>\n
![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2021\/10\/Screenshot-2021-10-29-at-13.39.28-300x248.png\")
![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2021\/10\/Screenshot-2021-10-29-at-12.35.05.png\")
![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2021\/10\/Screenshot-2021-10-29-at-14.40.16-1024x476.png\")
\nArgoCD se encargar\u00e1 de detectar los cambios en el repositorio y aplicarlos en el cl\u00faster de kubernetes mediante un despliegue rolling update.<\/p>\n![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2021\/10\/Screenshot-2021-10-29-at-14.54.37.png\")
\nEsta herramienta consulta peri\u00f3dicamente los \u00faltimos tags en nuestro repositorio de im\u00e1genes 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\u00f3n de git con el nombre del nuevo tag.
\nHace falta mencionar que a\u00fan no hay una versi\u00f3n estable de ArgoCD Image Updater,<\/a> pero se la espera pronto.<\/p>\n
\nEn su manifiesto podemos especificar una lista de clusters donde desplegar simult\u00e1neamente con distintos paths del repositorio. Ya que en nuestro repositorio podemos especificar diferentes versiones para cada cl\u00faster.<\/p>\nAutomatizaci\u00f3n de todo el proceso CICD con Argo<\/h2>\n
\nCombinando Argo Events, Argo Workflows, ArgoCD y Argo Rollouts es posible una mayor automatizaci\u00f3n siguiendo las mejores pr\u00e1cticas en los est\u00e1ndares actuales de integraci\u00f3n continua.
\nVictor Farcic lo explica de manera muy coherente en este video<\/a>.<\/p>\nConclusiones<\/h2>\n