Bien, finalmente una serie de 3 capítulos, siendo este el último, donde hemos ido tratando diferentes cositas de como poder gestionar tus apps en EKS usando Argo CD, desde el inicio, hasta el "final", nos gusta dejar siempre el "final" entre comillas, porque como es obvio, quedan muchísimas cosas pendientes.
En este post, nos vamos a centrar en algunos de los recursos y estrategias básicas pero no menos importantes que ofrece Argo CD: Applications, ApplicationSets, Generators, Argo CD Projects y Sync Policies. Hemos elegido estos porque permiten una configuración bastante buena y flexible, manteniendo la simplicidad y accesibilidad para todos los usuarios, sin entrar en detalles complejos/avanzados, ya que nuestra idea no es dar un master sobre Argo CD. Sin embargo, es importante mencionar que Argo CD incluye muchas otras funcionalidades que amplían aún más su potencial, RBAC, Notificaciones, Webhooks, ConfigMaps, Secrets...
Application: unidad básica de gestión en Argo CD, representa una aplicación que se sincroniza desde un repositorio GIT hacia un clúster de Kubernetes.
ApplicationSet: Recurso avanzado que permite definir múltiples Applications a partir de un template y una fuente dinámica de datos, como una lista, clústeres, o un generador de combinaciones. Ideal para gestionar configuraciones repetitivas o despliegues multi entorno.
Generators: Herramientas que crean Applications automáticamente según entradas dinámicas. Un Matrix generator combina varias listas de datos para generar configs un poco complejas. Otras usan listas simples, clústeres registrados o consultas a archivos JSON o YAML.
ArgoCD Projects: Son una forma de agrupación y limitación de Applications en Argo CD.
Sync Policies: Controlan cómo y cuándo ArgoCD sincroniza los recursos en Kubernetes.
Como siempre... para entenderlo mejor, vamos con un ejemplo.
Antes de empezar a desplegar aplicaciones con Argo CD, necesitamos definir un Project. Un Project en Argo CD actúa como un espacio lógico que nos permite organizar y gestionar nuestras aplicaciones de manera más eficiente. Es una forma de limitar qué repositorios, clústeres, namespaces y tipos de recursos pueden usar las aplicaciones asociadas a este proyecto.
En este ejemplo, vamos a crear un proyecto llamado default que permite el acceso a cualquier repositorio Git y cualquier clúster Kubernetes. Esto nos servirá como base para gestionar nuestras aplicaciones sin restricciones iniciales, pero si vas a usarlo en PROD, no lo hagas!
projects/project.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: default
namespace: argocd
spec:
description: Default project for managing applications
sourceRepos:
- '*'
destinations:
- namespace: '*'
server: '*'
clusterResourceWhitelist:
- group: '*'
kind: '*'
namespaceResourceWhitelist:
- group: '*'
kind: '*'
Para aplicarlo y no complicarnos ahora con temas de automatización (que ya tocaremos en futuros posts o proyectos), simplemente lo lanzaremos con un buen kubectl
kubectl apply -f projects/project.yaml
Bien, una vez tenemos el project necesitamos las apps, y como las configuramos? Pues definiendo un application, que no deja de ser otro yaml que define como se va a desplegar la aplicación desde un repo GIT en un cluster que tu indiques.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: test-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/tu-usuario/argocd-examples
targetRevision: main
path: apps/test
helm:
valueFiles:
- envs/staging/staging-values.yaml
destination:
server: https://kubernetes.default.svc
namespace: test-app
syncPolicy:
automated:
prune: true
selfHeal: true
Hasta ahora, hemos desplegado una aplicación utilizando un recurso de tipo Application, lo cual es bueno para proyectos pequeños o con pocas aplicaciones. Sin embargo, cuando necesitas gestionar muchas aplicaciones, o múltiples entornos para las mismas aplicaciones, este enfoque se vuelve poco práctico.
¿Te imaginas tener que crear y mantener 100 archivos YAML diferentes? Eso no solo genera complejidad, sino que aumenta el riesgo de errores y dificulta la escalabilidad del proyecto.
Aquí es donde el ApplicationSet gana puntos. Este recurso avanzado de Argo CD permite definir múltiples aplicaciones a partir de un único archivo YAML utilizando plantillas y fuentes de datos dinámicas. En lugar de definir manualmente cada aplicación, el ApplicationSet detecta cambios automáticamente en tu repositorio y genera las aplicaciones correspondientes, ahorrándote tiempo y esfuerzo.
¿Qué es un ApplicationSet y cómo funciona?
Un ApplicationSet es un recurso que combina:
- Template: Define cómo debería ser cada aplicación generada (por ejemplo, configuración común para todas las aplicaciones en un entorno).
- Generator: Proporciona los datos dinámicos para generar múltiples aplicaciones. Algunos generadores comunes son: Git: Detecta carpetas en un repositorio. List: Usa una lista fija de valores. Matrix: Combina múltiples listas para generar configuraciones más complejas.
El resultado es un conjunto de aplicaciones creadas automáticamente según las reglas definidas en el ApplicationSet.
Supongamos que queremos gestionar múltiples aplicaciones en un entorno production. Con un ApplicationSet, podemos definir un archivo que detecte todas las carpetas en apps/ y genere automáticamente aplicaciones para cada una de ellas.
Archivo YAML: prod-appset.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: prod-appset
namespace: argocd
spec:
generators:
- git:
repoURL: https://github.com/tu-usuario/argocd-examples
revision: main
directories:
- path: apps/*
template:
metadata:
name: '{{path.basename}}-prod'
spec:
project: default
source:
repoURL: https://github.com/tu-usuario/argocd-examples
targetRevision: main
path: '{{path}}/templates'
helm:
valueFiles:
- '{{path}}/envs/production/values.yaml'
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
Cómo desplegar el ApplicationSet
Para aplicar este archivo y permitir que Argo CD genere automáticamente las aplicaciones, simplemente ejecuta:
kubectl apply -f appsets/prod-appset.yaml
Ahora que hemos desplegado tanto una Application como un ApplicationSet, es buen momento para comparar ambas opciones y entender sus diferencias clave.
Aspecto | Application | ApplicationSet |
---|---|---|
Definición | Un archivo por aplicación y entorno. | Un archivo por entorno que gestiona múltiples aplicaciones. |
Automatización | No soporta detección dinámica. | Detecta automáticamente nuevas carpetas o entradas. |
Configuración común | Requiere duplicación en YAML. | Centralizada en un único template. |
Escenarios ideales | Proyectos pequeños con pocas apps. | Proyectos grandes o con entornos dinámicos. |
Conclusión
Con ApplicationSets, puedes simplificar drásticamente la gestión de aplicaciones en proyectos grandes o dinámicos. Al reducir el esfuerzo manual y garantizar la consistencia entre aplicaciones, este enfoque no solo te ahorra tiempo, sino que también mejora la escalabilidad de tu proyecto.
Como hemos comentado, las applications son perfectas para casos simples pero los ApplicationSets son la herramienta perfecta para quienes buscan automatizar y facilitar la gestión de múltiples entornos y servicios.
PD: Como siempre, dependerá de las necesidades de tu proyecto.
Con esto, vamos a dejar esta mini serie aquí, una vez desplegadas las aplicaciones con Applications y ApplicationSets, porque si seguimos, ¡no acabaríamos nunca! Además, ya sabéis que la gente PRO de verdad tiene sus cursos y certificaciones, y nosotros necesitamos dedicar más tiempo a los recursos nuevos de AWS y las automatizaciones. 😊
Nota: No hemos profundizado mucho ni siquiera entrado a hablar del patrón App of Apps en este post, porque no queríamos extender esta serie en mil capítulos. Sin embargo, si os interesa y queréis profundizar más en estos temas más avanzados, desde Codefresh podéis acceder a sus cursos oficiales con certificación, donde se incluyen laboratorios prácticos para aprender en un entorno controlado. ¡Totalmente recomendados! 🚀
Y ahora sí, ¡a seguir desplegando con estilo! 😉
Dejamos el link por aquí: https://learning.codefresh.io/
Top comments (0)