El termino GITOPS comienza a darse a conocer en el año 2017, como complemento a la creciente demanda de nuevas tecnologías como Docker, Kubernetes, Cloud, etc.
Este nuevo concepto derivado de la palabra GIT (sistema de control de versiones) y OPS (operaciones) es un conjunto de buenas practicas y el concepto de que todo gira en torno de GIT.
GITOPS se considera una evolución de infraestructura como código, incorporando las buenas practicas de DevOps, chocando así con el modelo tradicional establecido de CI/CD.
Este proceso lineal que se usa en CI/CD se divide en 2 cuando aplicamos las practicas GITOPS:
-Por un lado, se compilara la imagen y por otro se actualizara un repositorio de git, donde se indicara que se ha subido de versión la imagen para un despliegue.
-La herramienta usada en GITOPS se encargara de que el despliegue en el clúster coincida con este nuevo estado deseado registrado en GIT.
GITOPS Pipeline
Como se puede ver en el diagrama, el verdadero cambio se centra en el despliegue. Aparecen dos nuevos elementos: el repositorio de configuración, donde se almacena todos los ficheros de despliegue de nuestra aplicación y un operador desplegado en el clúster de kubernetes que se encarga de monitorear el repositorio de configuración y cuando exista un cambio, desplegarlo en el clúster. Por tanto, cuando se quiera subir una nueva versión de la aplicación, se deberá realizar un Pull Request en el repositorio de configuración, y cuando éste se haya aprobado por las personas encargadas para este propósito se despliega automáticamente en el entorno correspondiente en el que se haya solicitado el despliegue.
Seguridad.
GitOps añade un beneficio considerable desde el punto de vista de seguridad. El propio clúster es el que se encarga de desplegar las aplicaciones. Además, con GitOps, cualquier cambio de estado del clúster esta registrado: se sabe quién realizo el cambio, quién lo aprobó y cuando se desplegó. Otro aspecto importante es cuando se necesita restaurar el clúster por algún desastre solo se debe sincronizar los repositorios de configuración
Beneficios de GitOps
-Mejor experiencia de desarrollador: Ayuda a los desarrolladores a utilizar una herramienta muy familiar como Git para gestionar Kubernetes con facilidad sin necesidad de conocer sus detalles internos. También aumenta la productividad de los desarrolladores recién incorporados.
-Seguro: Con la ayuda de funcionalidades en Git, como la reversión, es fácil volver a una versión estable en caso de cualquier colapso, lo que reduce drásticamente el tiempo de recuperación.
-Consistente: El flujo de trabajo de un extremo a otro de GitOps es muy consistente como infraestructura; un modelo proporciona aplicación, administración de Kubernetes, todo.
-Implementación más rápida: Le ayuda a implementar aplicaciones más rápido que antes al integrar la automatización de implementación continua con un circuito de control de retroalimentación.
-Entornos autodocumentados: Puede obtener un historial completo de cada cambio en el sistema y todos los detalles de lo que se implementó consultando la rama maestra. Ayuda a facilitar la colaboración con otros equipos o comparte suficiente conocimiento con un nuevo miembro.
-Seguridad y cumplimiento: GitOps ayuda a las grandes organizaciones a mantenerse seguras y en cumplimiento. Puede bloquear los permisos de las personas que realmente tienen permiso para fusionarse en una rama.
¿GitOps es un reemplazo de DevOps?
DevOps es una practica que tiene en cuenta factores culturales, de procesos y de tecnología. En DevOps, la cultura es parte fundamental para asegurarse de que las personas se alineen y trabajen de forma fluida.
Pero GitOps incluye aquellas mejores prácticas que unifican la implementación, la gestión y la supervisión de aplicaciones, y la administración de clústeres de containers.
GitOps por tanto, es un complemento de DevOps, con mayor orientación al desarrollo Cloud Native, Container First, o Serverless.
Flujo de trabajo de ejemplo:
1-Se escribe el código en el local.
2-Se envía al repositorio de la aplicación y al mismo tiempo se ejecuta una pull request para revisar y aprobar el código.
3-El responsable revisa y aprueba el código, el PR ejecuta la validación.
4-Se dispara CI, valida el cambio del equipo y se completa correctamente.
5-Se dispara CD, el pipeline de CD crea una PR al repositorio de GitOps con los cambios deseados en el estado del clúster.
6-En cuestión de minutos, la aplicacion (operador) observa un cambio en el repositorio de GitOps e incorpora el cambio.
7-Debido al cambio de imagen de Docker, el pod de aplicación requiere una actualización. Flux aplica el cambio al clúster.
8-Se comprueba que la implementación se completó correctamente.
Muchas gracias.
Top comments (0)