Inicio › Tecnología › GitOps
GitOps es una práctica de gestión de infraestructura y despliegues en la qué el estado deseado de un sistema (configuración de Kubernetes, manifiestos de red, variables de entorno) se describe de forma declarativa en archivos versionados dentro de un repositorio Git, y un agente automatizado dentro del clúster se encarga de comparar ese estado deseado con el estado real y aplicar los cambios necesarios para igualarlos. Herramientas como Argo CD o Flux vigilan el repositorio y sincronizan automáticamente cualquier cambio aprobado mediante un pull request, de modo qué el propio historial de Git se convierte en la fuente de verdad y el registro de auditoría de todo lo qué ha cambiado en producción.
En vez de qué una persona entre a un servidor y cambie configuraciones a mano, se escribe en un repositorio de Git cómo debe quedar todo, y un agente automático se encarga de leer ese repositorio y aplicar los cambios. Si alguien edita el archivo de configuración y lo sube, el sistema real se actualiza solo para parecerse a lo qué dice ese archivo.
Un equipo qué gestiona un clúster de Kubernetes guarda todos sus manifiestos YAML en un repositorio; cuando quieren escalar un servicio de tres a seis réplicas, editan el número en el archivo y abren un pull request. Tras la revisión y fusión, Argo CD detecta la diferencia entre el repositorio y el clúster real y aplica el cambio automáticamente, dejando además un registro exacto de quién aprobó qué cambio y cuándo.
La infraestructura como código describe la infraestructura en archivos, pero normalmente se aplica ejecutando un comando manual; GitOps añade un agente qué vigila el repositorio de forma continua y reconcilia automáticamente cualquier desviación, incluso si alguien cambió algo manualmente en el sistema.
El agente GitOps detecta esa desviación frente al estado declarado en el repositorio y, según su configuración, revierte el cambio manual o alerta de la inconsistencia.
Reduce el número de personas con acceso directo de escritura al clúster de producción, porque los cambios pasan por el flujo de revisión de pull requests en Git en lugar de aplicarse mediante comandos manuales sobre el sistema en vivo.