GitOps con ArgoCD: del hype a la produccion estable

javi
Pantalla con ramas y commits de Git en un grafo visual

ArgoCD ha pasado en pocos años de ser un proyecto interesante a la práctica deploy estándar para Kubernetes. GitOps — el modelo donde el repositorio Git es la única fuente de verdad del estado deseado del cluster — ha demostrado funcionar mejor que las pipelines push tradicionales para muchos equipos. Cubrimos los principios, lo que ArgoCD hace bien, los errores que se ven en producción, y la comparativa con Flux.

Los principios reales de GitOps

GitOps no es solo “deployar desde Git”. Tiene cuatro principios formales:

  1. Declarativo: el sistema entero se describe declarativamente (YAML de Kubernetes, manifiestos Helm/Kustomize), no como secuencia de comandos.
  2. Versionado y inmutable: el estado deseado vive en Git. Cada cambio es un commit auditable.
  3. Pulled automáticamente: agentes en el cluster (ArgoCD/Flux) tiran del repositorio y aplican cambios. No hay push externo desde CI.
  4. Reconciliación continua: el agente compara estado real vs deseado constantemente y corrige drift.

La implicación más importante es la cuarta: drift se corrige automáticamente. Si alguien edita un recurso a mano (kubectl edit), ArgoCD lo revierte al estado del Git. Es la diferencia clave con pipelines tradicionales.

Por qué ArgoCD ha ganado adopción

Algunas razones por las que es la opción más popular en 2023:

  • UI excelente. Vista visual de aplicaciones, sus recursos, estado de health, diff entre Git y cluster.
  • Multi-tenancy serio. Soporta múltiples equipos con permisos granulares vía RBAC + projects.
  • Sync policies flexibles: manual, auto, con prune, con self-heal — cada combinación útil para escenarios distintos.
  • Soporte amplio de herramientas: Helm, Kustomize, plain YAML, Jsonnet — coexisten en el mismo cluster.
  • App-of-apps pattern. Una app de ArgoCD que despliega otras apps de ArgoCD — útil para gestionar el cluster entero declarativamente.
  • Sync waves y hooks. Control sobre orden de despliegue cuando importa (ej: CRDs antes que recursos que los usan).

Estructura típica del repositorio

Una organización razonable que veo en proyectos:

config-repo/
├── applications/
│   ├── prod/
│   │   ├── app-a.yaml      # ArgoCD Application apuntando a manifests
│   │   └── app-b.yaml
│   └── staging/
│       └── ...
├── manifests/
│   ├── app-a/
│   │   ├── base/           # Kustomize base
│   │   └── overlays/
│   │       ├── prod/
│   │       └── staging/
│   └── app-b/
│       └── helm/           # Helm chart o values
└── argocd-bootstrap/       # Configuración del propio ArgoCD

Patrones que funcionan:

  • Separar app code de configuración. El repo del código de la app no es el config repo. Cambios de configuración no requieren rebuild de imagen.
  • Branch o directory por entorno. Yo prefiero directorios (overlays Kustomize) sobre branches — más fácil ver diferencias entre entornos.
  • Image automation con commits automatizados. Tools como ArgoCD Image Updater detectan nuevas imágenes y commitean al config repo.

Sync policies: cuándo cada una

ArgoCD ofrece varias opciones para auto-sync:

  • Manual sync: alguien debe pulsar “Sync” tras cambios en Git. Bueno para entornos productivos críticos donde quieres revisión humana.
  • Auto-sync sin prune: aplica cambios pero no borra recursos que desaparecen del Git. Más conservador.
  • Auto-sync con prune: aplica todos los cambios y borra lo que ya no está en Git. Más estricto pero peligroso si alguien borra algo accidentalmente.
  • Self-heal: además de aplicar Git, revierte cualquier cambio manual. Strict GitOps real.

Una recomendación: manual sync en producción inicialmente, auto-sync sin prune en staging, self-heal en dev. A medida que confianza crece, mover producción a auto-sync controlado.

Errores comunes en producción

Después de varios proyectos, los errores que más veo:

  • Self-heal sin disciplina de equipo. Si un dev cambia algo a mano para debug y ArgoCD lo revierte al minuto, frustración. Política clara: cambios manuales → entender que se revierten, hacerlos solo en emergencias documentadas.
  • Secrets en Git. Anti-patrón evidente pero ocurre. Usa Sealed Secrets, External Secrets Operator (ESO), o algo similar — nunca commits con secretos en claro.
  • Repositorios de configuración monstruosos. Un único repo con 200 apps termina lento de sincronizar y difícil de revisar. Considera split por dominio o equipo.
  • Sync waves mal usadas. Demasiadas dependencias entre waves complica deploys. Mantén el grafo simple.
  • CRDs como app normal. Las CRDs deben estar antes que los recursos que las usan. Sync waves o app separada de bootstrap.
  • No backups de la configuración de ArgoCD. ArgoCD mismo debe estar en Git (app-of-apps). Si tu cluster muere, lo recuperas haciendo argocd app create apuntando al config repo.
  • Cluster admin para todos. Configura proyectos ArgoCD con permisos limitados. Equipo X solo puede deployar en namespaces Y.

Comparativa con Flux

Flux es la otra herramienta GitOps madura. Diferencias prácticas:

  • UI: ArgoCD tiene UI rica nativa; Flux la tiene más limitada (mejorando con Weave GitOps).
  • Multi-tenancy: ArgoCD lo cubre con projects; Flux con namespaces y multi-source.
  • Filosofía: ArgoCD se siente más “aplicación”, Flux más “controllers en el cluster”.
  • Helm: ambos lo soportan; integraciones ligeramente distintas.
  • Image automation: Flux la tiene nativa; ArgoCD requiere componente extra (Image Updater).
  • Adopción: ArgoCD parece más popular en proyectos que vi recientemente.

Cualquiera de los dos es elección razonable. ArgoCD es más amigable para equipos que valoran UI; Flux es más alineado con “todo es controller en el cluster”.

Conclusión

ArgoCD ha consolidado GitOps como práctica deploy madura para Kubernetes. Bien implementado — con disciplina de equipo, secretos gestionados aparte, y sync policies adecuadas al entorno — mejora confiabilidad de deploys, audit trail, y velocidad de recovery. Mal implementado — con secretos en Git, configuración monstruosa, sin backups — solo añade una capa más que mantener. La diferencia está en los detalles operativos.

Síguenos en jacar.es para más sobre Kubernetes, deployment automation y prácticas modernas de operación.

Entradas relacionadas