GitOps con Argo CD: mi homelab como código

Durante meses gestioné mi clúster a base de kubectl apply y manifiestos sueltos. Funcionaba… hasta que dejaba de funcionar y no recordaba qué había cambiado. GitOps resolvió ese caos: el estado deseado vive en Git, y un agente lo reconcilia en el clúster.

El repo como única fuente de verdad

La idea central es simple: nadie toca el clúster directamente. Cualquier cambio es un commit. Argo CD vigila el repositorio (alojado en mi propio GitLab) y, si detecta deriva entre lo que hay en Git y lo que corre en producción, la corrige automáticamente con selfHeal.

El patrón app-of-apps

No declaro las aplicaciones una a una. Aplico una sola vez una Application raíz que vigila la carpeta apps/ del repo; a partir de ahí descubre y sincroniza una Application por cada componente (cada una apuntando a un chart Helm o a manifiestos del propio repo). Añadir un servicio es soltar un YAML en apps/ y hacer push.

# bootstrap/root-app.yaml — se aplica UNA vez; luego se gestiona solo
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: root, namespace: argocd }
spec:
  source:
    repoURL: https://gitlab.lan/ismael/homelab.git
    path: apps                 # una Application por componente
    targetRevision: HEAD
  destination: { server: https://kubernetes.default.svc }
  syncPolicy:
    automated: { prune: true, selfHeal: true }

A partir de ahí, un git revert es literalmente un rollback de infraestructura. La única regla es no pelearse con Argo: nada de kubectl rollout restart en apps gestionadas, porque selfHeal lo revierte. Para reiniciar algo, cambias Git o borras el pod.

Si no está en Git, no existe. Y si está en Git, el clúster acabará pareciéndose a él.