DevOps desde Cero: GitOps con ArgoCD

Introduccion

Bienvenido al articulo catorce de la serie DevOps desde Cero. En el articulo anterior aprendimos como deployear nuestra API TypeScript a un cluster EKS. Corrimos comandos kubectl apply y helm install para poner las cosas a funcionar, y eso esta bien cuando vos sos la unica persona deployeando a un solo cluster. Pero que pasa cuando tu equipo crece, cuando tenes multiples entornos, o cuando alguien aplica un fix rapido directamente en el cluster y se olvida de actualizar los archivos YAML en Git?

Ahi es donde entra GitOps. GitOps es una forma de gestionar tus deployments de Kubernetes donde Git es la unica fuente de verdad. En vez de correr comandos contra el cluster, pusheas cambios a un repositorio Git y un controlador dentro del cluster los toma y los aplica automaticamente. Se acabo el preguntarse que esta corriendo donde. Se acabo el drift manual. Todo esta trackeado, revisado y es reproducible.

ArgoCD es la herramienta GitOps mas popular para Kubernetes. Es un proyecto graduado de la CNCF con una excelente interfaz web, un CLI poderoso, y soporte nativo para Helm, Kustomize y YAML plano. En este articulo vamos a instalar ArgoCD en nuestro cluster EKS, deployear nuestra API TypeScript a traves de el, y aprender como funciona todo el loop de sincronizacion y reconciliacion.

Si ya estas comodo con GitOps y queres aprender sobre patrones avanzados como ApplicationSets, App of Apps, sync waves, gestion multi-cluster, RBAC y notificaciones, mira GitOps con ArgoCD de la serie SRE. Este articulo se mantiene amigable para principiantes y se enfoca en llevarte de cero a un setup GitOps funcionando.

Vamos a ello.

Que es GitOps?

GitOps es un modelo operativo para Kubernetes donde declaras lo que queres corriendo en tu cluster en un repositorio Git, y un controlador corriendo dentro del cluster se asegura continuamente de que el estado real coincida con el estado declarado. Si alguien cambia algo manualmente o si un pod crashea y se recrea con diferentes configuraciones, el controlador detecta el desfase y lo corrige.

Esto es diferente del enfoque tradicional de CI/CD donde un pipeline ejecuta kubectl apply o helm upgrade al final de un build. Con ese modelo basado en push, el sistema de CI necesita credenciales de tu cluster, el drift pasa desapercibido, y no hay una forma facil de saber exactamente que esta corriendo en este momento. Con GitOps, el flujo se invierte: el controlador vive dentro del cluster, pullea el estado deseado desde Git, y se encarga del paso de aplicacion el mismo.

# CI/CD tradicional basado en push:
# Desarrollador -> Git push -> CI construye -> CI ejecuta kubectl apply -> Cluster
#                                              (CI necesita credenciales del cluster)
#                                              (los cambios manuales pasan desapercibidos)

# GitOps basado en pull:
# Desarrollador -> Git push -> Controlador detecta cambio -> Controlador aplica -> Cluster
#                              (el controlador vive en el cluster)
#                              (el drift se detecta y corrige automaticamente)

Principios de GitOps

Hay cuatro principios fundamentales que definen un workflow GitOps:

• Declarativo: Todo tu sistema se describe como archivos YAML o JSON en Git. Sin scripts imperativos, sin pasos manuales, sin comandos one-off. Declaras lo que queres, no como llegar ahi.
• Versionado e inmutable: Cada cambio pasa por Git, lo que significa que cada cambio esta versionado, tiene un autor, tiene un timestamp, y puede ser revisado en un pull request. Obtenes un audit trail completo gratis.
• Pulleado automaticamente: Un controlador corriendo en tu cluster observa el repositorio Git y pullea cambios a medida que aparecen. No pusheas al cluster. Esto es mas seguro porque las credenciales del cluster nunca salen del cluster.
• Reconciliado continuamente: El controlador no aplica cambios una vez y se olvida. Corre un loop que constantemente compara el estado vivo con el estado deseado. Si difieren por cualquier razon, corrige el drift.

La gran ventaja aca es que Git se convierte en la unica fuente de verdad. Si queres saber que esta corriendo en tu cluster, mira Git. Si queres hacer rollback, revertir un commit. Si queres auditar quien cambio que y cuando, revisa el historial de Git. Todo fluye por el mismo proceso: commit, push, review, merge, y el controlador se encarga del resto.

Por que ArgoCD

Hay varias herramientas GitOps disponibles (Flux es otra opcion popular), pero ArgoCD se convirtio en la opcion preferida para la mayoria de los equipos. Aca esta el por que:

• Graduado de la CNCF: ArgoCD es un proyecto graduado en la Cloud Native Computing Foundation, lo que significa que paso auditorias de seguridad rigurosas y tiene una comunidad grande y activa.
• Excelente interfaz web: ArgoCD viene con un dashboard donde podes ver cada aplicacion, su estado de sincronizacion, estado de salud, y el arbol de recursos. Esto es increiblemente util para debuggear y para dar visibilidad a todo el equipo.
• Nativo de Kubernetes: ArgoCD usa Custom Resource Definitions (CRDs) para definir aplicaciones. Gestionas ArgoCD con las mismas herramientas que usas para todo lo demas en Kubernetes.
• Soporte multi-formato: ArgoCD funciona con manifiestos YAML planos, charts de Helm, overlays de Kustomize, Jsonnet y plugins personalizados. No tenes que cambiar como escribis tus manifiestos.
• CLI y API: Mas alla de la interfaz, ArgoCD tiene un CLI completo y una API gRPC/REST para automatizacion y scripting.

Instalando ArgoCD en EKS

Vamos a instalar ArgoCD en el cluster EKS que configuramos en el articulo anterior. La forma recomendada es usando Helm. Primero, agrega el repositorio Helm de Argo y crea el namespace:

# Agregar el repositorio Helm de ArgoCD
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

# Crear el namespace de argocd
kubectl create namespace argocd

Ahora crea un archivo de values para configurar la instalacion. Lo vamos a mantener simple por ahora:

# argocd-values.yaml
configs:
  params:
    # Si estas terminando TLS en el load balancer o ingress,
    # configura esto para que ArgoCD no intente manejar TLS el mismo
    server.insecure: true

server:
  service:
    type: LoadBalancer

Esta es una configuracion minima. Seteamos server.insecure: true porque en un setup tipico de EKS terminas TLS en el load balancer o ingress controller. Tambien seteamos el tipo de servicio a LoadBalancer para que puedas acceder a la interfaz desde tu navegador.

Instala ArgoCD con Helm:

helm install argocd argo/argo-cd \
  --namespace argocd \
  --values argocd-values.yaml \
  --wait

# Verificar que todos los pods estan corriendo
kubectl get pods -n argocd

Deberias ver algo como esto:

NAME                                                READY   STATUS    RESTARTS   AGE
argocd-application-controller-0                     1/1     Running   0          2m
argocd-repo-server-6b7f8d7b4-x9k2l                 1/1     Running   0          2m
argocd-server-7c4f8b6d9-m3n8p                       1/1     Running   0          2m
argocd-redis-5b6c7d8e9-q4r7s                        1/1     Running   0          2m
argocd-applicationset-controller-8f9a1b2c3-t5u6v    1/1     Running   0          2m
argocd-notifications-controller-4d5e6f7a8-w9x0y     1/1     Running   0          2m

Ahora obtene la password de admin inicial y la URL del load balancer:

# Obtener la password de admin inicial
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d
# Guarda esta password, la vas a necesitar para iniciar sesion

# Obtener la URL del load balancer
kubectl -n argocd get svc argocd-server \
  -o jsonpath="{.status.loadBalancer.ingress[0].hostname}"

Abri esa URL en tu navegador e inicia sesion con usuario admin y la password que acabas de obtener. Deberias ver el dashboard de ArgoCD sin aplicaciones todavia. Vamos a crear una en un momento.

Tambien podes instalar el CLI de ArgoCD para gestionar cosas desde la terminal:

# macOS
brew install argocd

# Linux
curl -sSL -o argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x argocd
sudo mv argocd /usr/local/bin/

# Iniciar sesion en tu instancia de ArgoCD
argocd login <load-balancer-url> --username admin --password <tu-password> --insecure

Una vez logueado, cambia la password por defecto:

argocd account update-password

Conceptos de ArgoCD

Antes de crear nuestra primera aplicacion, entendamos los conceptos clave. ArgoCD tiene un punado de bloques de construccion que vas a usar todo el tiempo:

• Application: La unidad fundamental en ArgoCD. Una Application define un source (un repositorio Git con manifiestos o un chart de Helm), un destination (un cluster de Kubernetes y namespace), y una sync policy. Cada Application representa una unidad deployeable.
• Project: Un agrupamiento logico de Applications con controles de acceso. Los Projects definen que repositorios y clusters puede usar una Application. El proyecto default permite todo, lo cual esta bien para empezar.
• Repository: Un repositorio Git que ArgoCD observa. Registras repositorios con ArgoCD para que sepa de donde pullear manifiestos. Los repositorios publicos funcionan de una. Los privados necesitan credenciales.
• Sync: El proceso de aplicar el estado deseado desde Git al cluster. Cuando ArgoCD detecta una diferencia entre lo que esta en Git y lo que esta corriendo en el cluster, puede sincronizar (aplicar los cambios) automaticamente o cuando vos haces click en un boton.
• Health: ArgoCD entiende la salud de los recursos de Kubernetes. Un Deployment esta sano cuando todas las replicas estan disponibles. Un Pod esta sano cuando esta corriendo y listo. Un Service siempre esta sano. ArgoCD te muestra la salud de cada recurso en tu aplicacion.

Estos cinco conceptos cubren el 90% de lo que necesitas para trabajar con ArgoCD dia a dia. Vamos a ponerlos juntos creando nuestra primera Application.

Configurando un repositorio GitOps

Lo primero que necesitas es un repositorio Git que contenga tus manifiestos de Kubernetes. Este es el repositorio que ArgoCD va a observar. Podes usar el mismo repositorio que tu codigo de aplicacion, pero la practica comun es tener un repositorio separado para los manifiestos de deployment. Esta separacion hace el workflow mas limpio: los cambios de codigo de aplicacion disparan builds de CI que producen nuevas imagenes, y los cambios de manifiestos de deployment disparan syncs de ArgoCD.

Vamos a crear una estructura simple de repositorio GitOps:

# Crear e inicializar el repositorio
mkdir gitops-repo && cd gitops-repo
git init
mkdir -p apps/task-api

Ahora crea los manifiestos de Kubernetes para nuestra API TypeScript. Vamos a usar YAML plano para mantener las cosas simples, pero recorda que ArgoCD tambien soporta charts de Helm (que creamos en el articulo doce).

# apps/task-api/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: task-api

# apps/task-api/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: task-api
  namespace: task-api
  labels:
    app: task-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: task-api
  template:
    metadata:
      labels:
        app: task-api
    spec:
      containers:
        - name: task-api
          image: ghcr.io/your-org/task-api:v1.0.0
          ports:
            - containerPort: 3000
          env:
            - name: NODE_ENV
              value: production
            - name: PORT
              value: "3000"
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 20

# apps/task-api/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: task-api
  namespace: task-api
spec:
  selector:
    app: task-api
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

Commitea y pushea estos archivos a tu repositorio Git:

git add .
git commit -m "Add task-api manifests"
git remote add origin https://github.com/your-org/gitops-repo.git
git push -u origin main

Creando tu primera Application en ArgoCD

Ahora vamos a decirle a ArgoCD sobre nuestra aplicacion. Podes hacer esto a traves de la interfaz web, el CLI, o aplicando un manifiesto YAML. Vamos a usar el enfoque de manifiesto YAML porque es declarativo, versionable y sigue la filosofia GitOps.

# application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: task-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/gitops-repo
    targetRevision: main
    path: apps/task-api
  destination:
    server: https://kubernetes.default.svc
    namespace: task-api
  syncPolicy:
    syncOptions:
      - CreateNamespace=true

Veamos que significa cada campo:

• metadata.namespace: Las Applications siempre viven en el namespace argocd, sin importar donde deployen recursos.
• spec.project: Usamos default, que no tiene restricciones. En un setup real de equipo crearias proyectos dedicados con acceso limitado.
• spec.source.repoURL: El repositorio Git que ArgoCD observa.
• spec.source.targetRevision: La branch, tag o commit a seguir. Usar main significa que ArgoCD sigue la punta de la branch main.
• spec.source.path: El directorio dentro del repositorio que contiene los manifiestos.
• spec.destination.server: El servidor API de Kubernetes donde deployear. https://kubernetes.default.svc significa el mismo cluster donde esta corriendo ArgoCD.
• spec.destination.namespace: El namespace destino para los recursos deployeados.
• syncPolicy.syncOptions: CreateNamespace=true le dice a ArgoCD que cree el namespace si no existe.

Aplicalo:

kubectl apply -f application.yaml

Si abris la interfaz de ArgoCD ahora, vas a ver la aplicacion task-api. Su estado va a ser OutOfSync porque todavia no la sincronizamos. Vamos a hacerlo.

El loop de sincronizacion: como ArgoCD detecta drift y reconcilia

ArgoCD corre un loop de reconciliacion cada tres minutos por defecto. Esto es lo que pasa durante cada ciclo:

• Paso 1: El Application Controller lee el CRD Application y le pide al Repository Server que clone el repositorio Git y renderice los manifiestos del path especificado.
• Paso 2: El Repository Server obtiene el ultimo commit de la branch (o tag), lee los archivos YAML, y devuelve los manifiestos renderizados. Si estas usando Helm, ejecuta helm template. Si estas usando Kustomize, ejecuta kustomize build.
• Paso 3: El Application Controller compara los manifiestos renderizados con el estado vivo de los recursos en el cluster. Hace una comparacion campo por campo para detectar cualquier diferencia.
• Paso 4: Si hay diferencias, ArgoCD marca la aplicacion como OutOfSync y te muestra exactamente que cambio. Dependiendo de tu sync policy, o espera a que vos dispares un sync manualmente o aplica los cambios automaticamente.

Loop de reconciliacion (cada 3 minutos):

  Repositorio Git       ArgoCD                  Cluster Kubernetes
  ┌──────────────┐    ┌───────────────┐        ┌──────────────────┐
  │ Archivos     │───>│ Repo Server   │        │ Recursos vivos   │
  │ YAML (estado │    │ (renderiza    │        │ (estado actual)  │
  │ deseado)     │    │  manifiestos) │        │                  │
  └──────────────┘    └───────┬───────┘        └────────┬─────────┘
                              │                         │
                              v                         │
                      ┌───────────────┐                 │
                      │ App Controller │<────────────────┘
                      │ (compara      │
                      │  deseado vs   │
                      │  actual)      │
                      └───────┬───────┘
                              │
                      OutOfSync? ──> Sync (aplicar cambios)
                      Synced?   ──> No hacer nada

Este loop continuo es lo que hace a GitOps poderoso. Si alguien ejecuta kubectl edit y cambia la cantidad de replicas directamente en el cluster, ArgoCD va a detectar el drift y o te alerta o lo corrige automaticamente (dependiendo de tu configuracion).

Sync manual vs auto-sync

Cuando creamos nuestra Application antes, no habilitamos auto-sync. Esto significa que ArgoCD va a detectar cambios pero esperar a que vos dispares el sync manualmente. Hagamos nuestro primer sync manual:

# Sincronizar usando el CLI
argocd app sync task-api

# O podes hacer click en el boton "Sync" en la interfaz de ArgoCD

ArgoCD va a aplicar todos los manifiestos del repositorio Git al cluster. Podes ver el progreso en la interfaz o con el CLI:

# Ver el progreso del sync
argocd app get task-api

# Verificar que los pods estan corriendo
kubectl get pods -n task-api

Despues de que se complete el sync, el estado de la aplicacion deberia mostrar Synced y Healthy. Ahora hablemos de cuando usar sync manual versus auto-sync.

Sync manual es bueno para:

• Entornos de produccion donde queres que un humano revise y apruebe cada deployment.
• Setup inicial cuando te estas familiarizando con ArgoCD y queres ver que va a hacer antes de que lo haga.
• Aplicaciones sensibles donde necesitas una capa extra de control.

Auto-sync es bueno para:

• Entornos de desarrollo y staging donde queres que los cambios se apliquen apenas se mergean a la branch main.
• Componentes de infraestructura que siempre deberian coincidir con lo que esta en Git (monitoreo, logging, ingress controllers).
• Equipos que tienen un proceso de review solido y confian en que todo lo mergeado a main esta listo para deployear.

Para habilitar auto-sync, actualiza el manifiesto de la Application:

# application.yaml (con auto-sync habilitado)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: task-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/gitops-repo
    targetRevision: main
    path: apps/task-api
  destination:
    server: https://kubernetes.default.svc
    namespace: task-api
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Los dos campos nuevos bajo automated son importantes:

• prune: Cuando esta en true, ArgoCD va a eliminar recursos del cluster que ya no existen en Git. Si eliminas un ConfigMap de tu repositorio Git, ArgoCD lo elimina del cluster tambien. Sin esto, los recursos eliminados quedarian para siempre.
• selfHeal: Cuando esta en true, ArgoCD va a revertir cualquier cambio manual hecho en el cluster. Si alguien ejecuta kubectl scale deployment task-api --replicas=5 directamente, ArgoCD va a detectar el drift y lo va a volver a lo que esta declarado en Git.

Aplica el manifiesto actualizado:

kubectl apply -f application.yaml

De ahora en mas, cada vez que pushees un cambio al directorio apps/task-api en la branch main, ArgoCD lo va a aplicar automaticamente al cluster en menos de tres minutos (o antes si configuras un webhook).

Deployeando la API TypeScript con un chart de Helm

En el articulo doce creamos un chart de Helm para nuestra API TypeScript. ArgoCD tiene soporte nativo de Helm, asi que podes apuntar una Application directamente a un chart de Helm en un repositorio Git. Vamos a configurarlo.

Asumiendo que tu repositorio GitOps tiene el chart de Helm en charts/task-api/, crea una Application que lo use:

# application-helm.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: task-api-helm
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/gitops-repo
    targetRevision: main
    path: charts/task-api
    helm:
      releaseName: task-api
      valueFiles:
        - values-production.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: task-api
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

La seccion spec.source.helm es donde va la configuracion especifica de Helm. releaseName es el nombre que Helm usa para el release, y valueFiles apunta a un archivo de values relativo al directorio del chart. Tambien podes poner valores inline directamente:

    helm:
      releaseName: task-api
      values: |
        replicaCount: 3
        image:
          repository: ghcr.io/your-org/task-api
          tag: v1.2.0
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            memory: 256Mi

Asi es como la mayoria de los equipos manejan deployments en la practica: el chart de Helm vive en el repositorio GitOps (o en un registry OCI), y ArgoCD lo renderiza y aplica. Para deployear una nueva version, actualizas el tag de la imagen en el archivo de values, commiteas, pusheas, y ArgoCD se encarga del resto.

Navegando la interfaz de ArgoCD

La interfaz web de ArgoCD es uno de sus mayores puntos de venta. Veamos que vas a encontrar.

Vista de lista de aplicaciones: Esta es la pagina principal. Ves todas tus aplicaciones como tarjetas, cada una mostrando el nombre de la aplicacion, estado de sync (Synced, OutOfSync, Unknown), estado de salud (Healthy, Degraded, Progressing, Missing), la revision target, y la hora del ultimo sync. Verde significa que todo esta bien. Amarillo significa que algo esta progresando. Rojo significa que algo anda mal.

Vista de detalle de aplicacion: Hace click en una aplicacion para ver su arbol de recursos. Es una representacion visual de cada recurso de Kubernetes gestionado por la aplicacion. Para nuestra task-api, verias el Deployment, que es dueno de un ReplicaSet, que es dueno de los Pods individuales. El Service se muestra como un nodo separado. Cada recurso muestra su estado de salud con un icono de color.

Vista de diff de recursos: Hace click en cualquier recurso para ver sus detalles. La pestana “Diff” te muestra exactamente que es diferente entre el estado deseado (de Git) y el estado vivo (en el cluster). Esto es extremadamente util para debuggear problemas de sync.

Barra de estado de sync: En la parte superior de la vista de detalle, ves el estado actual de sync y un boton “Sync”. Si la aplicacion esta OutOfSync, podes hacer click en Sync para disparar un sync manual. Tambien podes elegir sincronizar recursos especificos en vez de la aplicacion entera.

Historial y rollback: La pestana “History” muestra cada operacion de sync con el commit de Git que la disparo, la hora en que ocurrio, y si fue exitosa o fallo. Podes hacer rollback a cualquier sync anterior desde aca.

Rollback: volviendo a un estado anterior

Las cosas salen mal. Una imagen mala se deployea, un cambio de configuracion rompe algo, o una nueva version tiene un bug. Con GitOps, tenes dos formas de hacer rollback.

La forma GitOps (recomendada): Revertir el commit en Git. Este es el enfoque mas limpio porque mantiene a Git como la fuente de verdad y crea un audit trail del rollback:

# Revertir el ultimo commit
git revert HEAD --no-edit
git push

# ArgoCD detecta el cambio y sincroniza automaticamente (si auto-sync esta habilitado)
# O dispara un sync manual:
argocd app sync task-api

La forma ArgoCD (para emergencias): Usa el CLI o la interfaz de ArgoCD para hacer rollback a un sync anterior. Esto es mas rapido pero tiene una salvedad: no cambia Git, asi que si auto-sync esta habilitado, ArgoCD eventualmente va a re-sincronizar al ultimo estado de Git y deshacer tu rollback:

# Ver historial de syncs
argocd app history task-api

# Ejemplo de salida:
# ID  DATE                 REVISION
# 3   2026-05-30 10:15:00  abc1234 (main)
# 2   2026-05-29 14:30:00  def5678 (main)
# 1   2026-05-28 09:00:00  ghi9012 (main)

# Rollback al sync ID 2
argocd app rollback task-api 2

Si usas el rollback de ArgoCD, asegurate de deshabilitar auto-sync primero, o el controlador va a re-aplicar el ultimo estado de Git y deshacer tu rollback:

# Deshabilitar auto-sync antes de hacer rollback
argocd app set task-api --sync-policy none

# Rollback
argocd app rollback task-api 2

# Arreglar el problema en Git, luego re-habilitar auto-sync
argocd app set task-api --sync-policy automated --self-heal --auto-prune

La conclusion clave es que git revert es la forma preferida de hacer rollback en un workflow GitOps. Mantiene todo consistente y deja un registro claro de que paso y por que.

Un workflow GitOps tipico

Juntemos todo y recorramos como se ve un deployment tipico de punta a punta:

• Paso 1: Un desarrollador abre un pull request que cambia el tag de la imagen en el manifiesto de deployment (o el archivo de values de Helm) de v1.0.0 a v1.1.0.
• Paso 2: El equipo revisa el cambio. Como es solo un diff YAML en un pull request, es facil ver exactamente que va a cambiar en el cluster.
• Paso 3: El pull request se mergea a main.
• Paso 4: ArgoCD detecta el nuevo commit en menos de tres minutos (o inmediatamente si tenes un webhook configurado). Compara el nuevo estado deseado con el estado vivo y encuentra que el tag de la imagen difiere.
• Paso 5: Si auto-sync esta habilitado, ArgoCD aplica el cambio. El Deployment se actualiza, Kubernetes hace un rolling update, y los nuevos pods levantan con la imagen v1.1.0.
• Paso 6: ArgoCD marca la aplicacion como Synced y Healthy una vez que todos los pods estan corriendo y pasando los readiness checks.
• Paso 7: Si algo sale mal, el equipo revierte el commit en Git y ArgoCD hace rollback automaticamente.

Este workflow te da code review para cambios de infraestructura, un audit trail completo en Git, deployment automatico, deteccion automatica de drift, y rollback facil. Eso es mucho valor para un setup relativamente simple.

Temas avanzados: hacia donde ir despues

Una vez que estes comodo con lo basico cubierto aca, hay mucho mas que ArgoCD puede hacer. Aca va un panorama rapido de temas avanzados:

• Patron App of Apps: En vez de crear manifiestos de Application uno por uno, creas una Application padre que gestiona Applications hijos. Esto te permite bootstrapear un cluster entero con una sola Application.
• ApplicationSets: Una forma de generar multiples Applications desde un solo template. Util para deployear la misma aplicacion en multiples clusters o entornos automaticamente.
• Sync waves y hooks: Controlar el orden en que los recursos se aplican. Por ejemplo, podes asegurar que un Job de migracion de base de datos corra antes de que arranque el Deployment.
• RBAC y SSO: Restringir quien puede ver y sincronizar que aplicaciones. Integrar con tu proveedor de identidad para single sign-on.
• Notificaciones: Enviar alertas a Slack, email u otros canales cuando los syncs tienen exito o fallan.

Todos estos temas estan cubiertos en profundidad en GitOps con ArgoCD de la serie SRE. Ese articulo entra en detalle sobre generadores de ApplicationSet, anotaciones de sync wave, politicas RBAC con AppProjects, templates de notificaciones, monitoreo de ArgoCD con Prometheus, y mas. Una vez que tengas lo basico de este articulo, ese es un gran siguiente paso.

Notas finales

GitOps con ArgoCD te da un workflow de deployment que es declarativo, versionado, automatizado y auditable. En vez de correr comandos contra tu cluster y esperar que todos sigan el mismo proceso, pusheas cambios a Git y dejas que ArgoCD se encargue del resto. Cada cambio se revisa en un pull request, se trackea en el historial de Git, y se aplica automaticamente al cluster.

En este articulo cubrimos que es GitOps y por que importa, instalamos ArgoCD en un cluster EKS con Helm, aprendimos los conceptos clave (Application, Project, Sync, Health), creamos nuestra primera Application apuntando a un repositorio Git, entendimos el loop de reconciliacion y como ArgoCD detecta drift, comparamos sync manual y auto-sync y cuando usar cada uno, deployeamos nuestra API TypeScript usando manifiestos planos y un chart de Helm, exploramos la interfaz de ArgoCD, y aprendimos como hacer rollback de forma segura.

El proximo articulo va a cubrir monitoreo y observabilidad, porque deployear aplicaciones es solo la mitad de la batalla. Tambien necesitas saber si estan sanas y rindiendo bien.

Espero que te haya resultado util y lo hayas disfrutado, hasta la proxima!

Errata

Si encontras algun error o tenes alguna sugerencia, mandame un mensaje para que se corrija.

Tambien, podes revisar el codigo fuente y los cambios en los fuentes aca