GitOps para Empresas con ArgoCD

Por qué GitOps cambia la operación empresarial

El modelo push-based tradicional (el pipeline de CI aplica cambios directamente al cluster con kubectl) tiene problemas fundamentales de auditoría y consistencia. ¿Qué versión está exactamente en producción ahora? ¿Quién aplicó el último cambio y cuándo? ¿Puedo reproducir el estado exacto del cluster? Con GitOps, todas estas preguntas tienen respuesta en el historial de Git.

El beneficio menos mencionado: GitOps convierte los cambios manuales en producción en no persistentes por diseño. ArgoCD detecta cualquier desviación del estado declarado en Git y la revierte automáticamente. Esto elimina la práctica de aplicar hotfixes directamente al cluster sin documentar — una de las fuentes más frecuentes de incidentes difíciles de diagnosticar.

ArgoCD: configuración base para producción

ArgoCD introduce el concepto de Application como recurso de Kubernetes. Cada Application define qué repositorio Git observar, en qué path encontrar los manifiestos, y en qué cluster/namespace aplicarlos.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-production
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/empresa/infra-gitops.git
    targetRevision: main
    path: apps/api/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true       # elimina recursos no definidos en Git
      selfHeal: true    # revierte cambios manuales al cluster
    syncOptions:
    - CreateNamespace=true

selfHeal: true activa la reconciliación automática contra drift. prune: true elimina recursos del cluster que ya no están definidos en Git. Para cambios de alta criticidad, es recomendable deshabilitar automated y requerir sync manual con aprobación — el balance entre automatización y control depende del SLA del servicio.

App of Apps: arquitectura para múltiples equipos

El patrón App of Apps permite que una Application raíz gestione las demás aplicaciones como código. En lugar de crear cada Application manualmente por interfaz o kubectl, defines una root app que observa un directorio con los manifiestos de todas las demás applications.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-apps
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/empresa/infra-gitops.git
    path: apps/
    directory:
      recurse: true
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Con esta arquitectura, cada equipo gestiona sus propias applications mediante PRs al repositorio central de infraestructura. Ningún desarrollador necesita acceso directo al cluster de producción — ArgoCD es el único actor que aplica cambios.

Gestión de Secretos con GitOps: el problema real

La gestión de secretos es el obstáculo principal para adoptar GitOps en empresas. No puedes commitear credenciales en Git, ni siquiera en repositorios privados. Las dos soluciones production-grade que usamos en proyectos empresariales:

Sealed Secrets (Bitnami): Cifra los secretos con la clave pública del cluster. El SealedSecret cifrado puede vivir en Git de forma segura — solo el cluster puede descifrarlo con su clave privada. Es la solución más simple cuando todos los secretos son específicos del cluster.

# Crear Secret y sellarlo en un solo comando
kubectl create secret generic db-credentials \
  --from-literal=password=mysecretpassword \
  --dry-run=client -o yaml | \
  kubeseal --format yaml > sealed-db-credentials.yaml

# El archivo sealed puede commitearse de forma segura en Git

External Secrets Operator: Sincroniza secretos desde AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager o Azure Key Vault directamente a Kubernetes Secrets. La mejor opción para empresas que ya tienen una solución centralizada de secrets management o necesitan rotar secretos sin re-deployar.

RBAC Empresarial con ArgoCD Projects

En una organización con múltiples equipos usando el mismo cluster, el control de acceso en ArgoCD es crítico. Los AppProjects permiten restringir qué repositorios puede usar cada equipo, en qué clusters puede desplegar y qué namespaces puede gestionar.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-payments
  namespace: argocd
spec:
  description: Proyecto del equipo de pagos
  sourceRepos:
  - 'https://github.com/empresa/payments-service.git'
  destinations:
  - namespace: payments-*
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace

El equipo de pagos puede desplegar únicamente desde su repositorio, solo a namespaces con prefijo payments-. Cualquier intento de acceder a otros namespaces o clusters falla en la validación de ArgoCD, sin requerir intervención manual.

Integración CI: la diferencia entre push y pull

Con GitOps, el pipeline de CI solo actualiza el repositorio de infraestructura (nueva versión de imagen, nueva configuración). ArgoCD detecta el cambio y aplica el nuevo estado al cluster. El CI nunca habla directamente con el cluster.

# GitLab CI — stage que actualiza el tag de imagen en el repo de infra
update-image-tag:
  stage: deploy
  script:
    - git clone https://oauth2:${GITOPS_TOKEN}@github.com/empresa/infra-gitops.git
    - cd infra-gitops
    - |
      sed -i "s|image: empresa/api:.*|image: empresa/api:${CI_COMMIT_SHORT_SHA}|g" \
        apps/api/production/deployment.yaml
    - git config user.email "ci@empresa.com"
    - git config user.name "GitLab CI"
    - git commit -am "ci: update api to ${CI_COMMIT_SHORT_SHA}"
    - git push origin main
  only:
    - main

Esta separación es fundamental para auditoría y compliance. Cada cambio a producción tiene un commit en Git con autor identificado. El rollback es un git revert. La reconciliación de ArgoCD garantiza que el estado del cluster siempre converge al estado declarado en Git.

Rollback en 30 Segundos

Una de las ventajas más concretas de GitOps es el rollback instantáneo. El estado deseado es el commit de Git — hacer rollback es literalmente seleccionar una revision anterior en ArgoCD o hacer git revert en el repositorio. No hay reconstrucción de configuración, no hay comandos de kubectl complejos.

En producción, el rollback via ArgoCD tarda el tiempo que tome reconciliar (típicamente 30-90 segundos). Comparado con el proceso manual de identificar la imagen anterior, editar el deployment, aplicar y verificar, la diferencia en MTTR puede ser de minutos u horas.