Diagrama del flujo de trabajo GitOps: entrega por pull con Argo CD o Flux

En un pipeline clásico, CI construye el código y después empuja el resultado al clúster con kubectl apply o helm upgrade. Funciona, pero el pipeline necesita credenciales de administrador para cada clúster, nadie puede decir con certeza qué está corriendo sin preguntarle al clúster, y un deployment editado a mano se desvía en silencio de lo que dice el repositorio.

GitOps invierte la dirección. Git guarda el estado deseado y un agente dentro del clúster lo obtiene continuamente y hace que el clúster coincida con él. Este artículo explica los principios, el flujo de dos repositorios que usa la mayoría de los equipos, cómo funcionan la promoción y el rollback, y dibuja el flujo completo.

Los cuatro principios

El proyecto OpenGitOps de la CNCF define GitOps con cuatro principios:

1. Declarativo: el estado deseado del sistema se expresa de forma declarativa.
2. Versionado e inmutable: ese estado se guarda de manera que conserve un historial de versiones completo e inmutable, lo que en la práctica significa Git.
3. Obtenido automáticamente: agentes de software obtienen el estado deseado desde la fuente.
4. Reconciliado continuamente: los agentes comparan sin parar el estado real con el deseado y corrigen la diferencia.

El tercer punto es lo que separa GitOps de «desplegar desde un pipeline que lee Git». El clúster tira; nada de fuera empuja hacia dentro.

Dos repositorios: código y configuración

La mayoría de los equipos separan dos tipos de cambio:

• El repositorio de la aplicación contiene el código fuente. CI lo construye, ejecuta las pruebas, lo analiza y publica una etiqueta de imagen inmutable en un registro.
• El repositorio de configuración contiene los manifiestos de Kubernetes, los values de Helm o los overlays de Kustomize de cada entorno. Describe qué debe correr dónde, incluidas las etiquetas de imagen.

El vínculo entre ambos es un cambio pequeño y explícito: CI, o una herramienta de automatización de imágenes, abre una pull request en el repositorio de configuración que sube la etiqueta de imagen de staging. Esa pull request es la solicitud de despliegue, con revisión y rastro de auditoría.

El controlador en el clúster

Argo CD y Flux son los dos controladores GitOps más usados. Ambos corren dentro del clúster, consultan el repositorio de configuración o reciben sus webhooks, renderizan los manifiestos, los comparan con los objetos en vivo y aplican la diferencia.

Sus ajustes de reconciliación deciden lo estricto que es el sistema:

• Sincronización automática: aplicar los commits nuevos sin que nadie pulse un botón.
• Pruning: borrar los objetos que se eliminaron de Git.
• Self-heal: revertir los cambios hechos directamente en el clúster. En las opciones de sincronización automática de Argo CD, self-heal es un interruptor independiente de la sincronización automática.

Self-heal es el ajuste que convierte a Git en la verdadera fuente de verdad. Sin él, un kubectl edit a las 3 de la madrugada se vuelve permanente e invisible.

Promoción y rollback

Los entornos son carpetas, overlays o archivos del repositorio de configuración. Promocionar significa copiar una versión de uno al siguiente:

1. La pull request sube la etiqueta de staging; staging se actualiza a los pocos minutos del merge.
2. Las pruebas y comprobaciones se ejecutan contra staging.
3. Una segunda pull request sube producción a la misma etiqueta. Hacer merge de ella es el despliegue en producción.

El rollback es un git revert de ese merge. El controlador ve la etiqueta antigua y la aplica. Como todo el historial está en Git, la pregunta «¿qué corría en producción el martes pasado a las 14:00?» tiene una respuesta exacta.

Quién abre la pull request

Hay dos formas habituales de conectar una imagen nueva con el repositorio de configuración:

• La abre CI. El último paso del pipeline clona el repositorio de configuración, cambia una línea, hace commit en una rama y abre una pull request. Es explícito y fácil de depurar, y el pipeline solo necesita un token para ese único repositorio.
• La confirma una herramienta de automatización de imágenes. Los controladores de automatización de imágenes de Flux y el proyecto Argo CD Image Updater pueden vigilar un registro, elegir las etiquetas nuevas que cumplan una política y escribirlas de vuelta en Git. Útil para entornos de staging que siempre deben ejecutar el último build.

Muchos equipos combinan ambas: la automatización mantiene staging al día, mientras que los cambios de producción siempre llegan como una pull request revisada de una persona o de un job de release. Elijas lo que elijas, escríbelo en el diagrama, porque «¿cómo llega aquí una versión nueva?» es lo primero que cualquiera pregunta sobre una instalación GitOps.

Una release de principio a fin

Sigue la versión 1.8.0 de un servicio shop desde el commit hasta producción:

1. Un desarrollador hace merge de un cambio en el repositorio de la aplicación. CI ejecuta las pruebas, construye la imagen, la analiza y publica shop:1.8.0 en el registro.
2. CI abre en el repositorio de configuración una pull request que cambia la etiqueta de staging de 1.7.3 a 1.8.0. Un revisor la aprueba y hace merge.
3. En uno o dos minutos, el controlador detecta el commit nuevo, renderiza los manifiestos de staging y actualiza el deployment. Kubernetes despliega pods nuevos, que obtienen la imagen del registro.
4. Las smoke tests pasan en staging. La responsable de la release abre una segunda pull request que pone producción en 1.8.0.
5. Tras ese merge, producción se despliega del mismo modo. Si suben las tasas de error, revertir el commit de merge devuelve la 1.7.3.

En ningún momento algo fuera del clúster necesitó credenciales del clúster, y cada paso dejó un commit detrás.

Secretos

Los secretos en texto plano no pueden ir a Git. Enfoques habituales:

• Cifrados en Git, con herramientas como Sealed Secrets o SOPS, que solo se descifran dentro del clúster.
• Referencias en Git, valores en otro sitio, con un operador como External Secrets que lee de un gestor de secretos.

En ambos casos, el repositorio de configuración sigue siendo revisable y los valores de los secretos nunca aparecen en un diff.

El diagrama de arquitectura

Cómo leerlo:

• Fila superior, el build: un desarrollador hace push al repositorio de la aplicación, CI construye y prueba la imagen 1.8.0 y la publica en el registro.
• Centro: CI abre una pull request que sube la etiqueta de staging en el repositorio de configuración. Es el único lugar donde CI toca el despliegue.
• Abajo, el clúster: el controlador GitOps hace pull del repositorio de configuración (discontinuo) y lo aplica al namespace de staging, que ahora ejecuta la 1.8.0, y a producción, que sigue con la 1.7.3 hasta que se haga merge de su propia pull request. Los nodos obtienen las imágenes del registro (punteado).
• El bloque Markdown enuncia las reglas del flujo: promoción por pull request, rollback por revert, desviaciones revertidas por self-heal.

Qué cambia para el equipo

• CI pierde las credenciales del clúster. Es el clúster el que sale a buscar; el pipeline solo necesita acceso de escritura a un repositorio.
• Las revisiones cubren los despliegues. Quién desplegó qué, cuándo y por qué queda en el historial de pull requests.
• Las desviaciones se hacen visibles. El controlador muestra los recursos desincronizados en lugar de ocultarlos.
• La depuración cambia de lugar. «¿Por qué no se desplegó esto?» se responde con el estado de sincronización y los eventos del controlador, así que hazlos visibles para quienes hacen merge.

Qué poner en un diagrama GitOps

• Los dos repositorios, y la pull request que los une.
• La dirección del pull, del controlador al repositorio de configuración, no del pipeline al clúster.
• Cada entorno con la versión que ejecuta, para que la promoción se vea.
• Los ajustes de sincronización: sincronización automática, prune, self-heal.

El diagrama de estrategias de despliegue muestra cómo el propio despliegue puede ser canary o blue-green, el diagrama de pipeline de CI/CD cubre en detalle las etapas del build, el diagrama de arquitectura de Kubernetes muestra el propio clúster y el artículo de YAML de Kubernetes a diagrama muestra cómo convertir los manifiestos del repositorio de configuración en una imagen.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade una Persona del pack Modelo C4, dos nodos Repositorio y una Canalización del pack DevOps, y un Registro del pack Docker.
3. Añade un Marco del pack Básico para el clúster, con un Contenedor para el controlador GitOps.
4. Añade dos nodos Namespace del pack Kubernetes con un Deployment en cada uno, etiquetado con la versión que ejecuta.
5. Dibuja el pull como una arista discontinua del controlador al repositorio de configuración y añade un bloque Markdown del pack Básico con las reglas del flujo.

El ejemplo usa 12 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué diferencia hay entre GitOps y CI/CD? CI/CD construye, prueba y entrega el software. GitOps es una forma de hacer la parte de entrega: el estado deseado vive en Git y un agente en el entorno de destino lo obtiene y lo reconcilia, en lugar de que un pipeline empuje los cambios hacia dentro.

¿Uso Argo CD o Flux? Ambos implementan el mismo modelo. Argo CD tiene una interfaz web completa y vistas centradas en aplicaciones; Flux es un conjunto de controladores componibles que muchos equipos manejan por completo a través de Git y la CLI.

¿Necesito repositorios separados para la aplicación y la configuración? Es una convención habitual, no una regla. Los repositorios separados mantienen limpio el historial de despliegues y permiten cambiar la configuración sin reconstruir el código.

¿Cómo hago rollback con GitOps? Revierte el commit que cambió la versión en el repositorio de configuración. El controlador aplica el estado anterior.

¿Cómo se gestionan los secretos en GitOps? Guárdalos cifrados en Git, o guarda referencias en Git y deja que un operador obtenga los valores de un gestor de secretos dentro del clúster.

Empieza gratis — un puesto, sin tarjeta de crédito.