Por ocupado, caótico y distraído, ahora tengo un backlog gigante de artículos para escribir, ni hablemos por editar. La buena noticia es que si tengo los títulos para expresar mis ideas.
Hoy tengo otra historia, si bien mi rechazo, mi desapego a los conceptos de Ops, lo he expresado bastante en otras publicaciones, he de mencionar como espero haberlo hecho en otras ocasiones, mi problema no es con el fundamento, es con la mercadotecnia y las personas.
En tal caso, hoy voy a hablar de GitOps un grupo de practicas que permite mediante Git, llevar la operacion. Realizar todas las acciones de operaciones, mediante la gestion de ‘Pull Requests’ de Git, primariamente Github. Y esta tecnica es altamente compatible con Kubernetes, y Nubes publicas.
Y por otro lado tenemos Jenkins, que es un software, que facilita la automatizacion de procesos, mediante la orquestación de tareas, la ejecución remota, y la programacion.
En un mundo ideal, Jenkins existe como una pieza independiente que es capaz de recibir solicitudes humanas o de sistema, ejecutar acciones sobre nodos de computo, y generar salidas.
¿Pero como llegamos a la pesadilla? Hace casi ya una decada (2018 creo), durante una de mis consultorias al azar, en los dias iniciales de GitOps. Me llamaron por el siguiente problema “Nuestro pipeline de git, se queda en un loop, siempre tiene problemas de merge, y ‘El Jenkins’ deja de atender acciones”. Una muy extraña premisa.
Lo primero, y una de las cosas mas sorprendentes que vi en dicha empresa, aunque tiene su merito. Es que la empresa no usaba Github, Gitlab, Bitbucket etc. Su servidor centralizado de Git era un server SSH. Si bien tiene su merito, creo que puedo contar la cantidad de veces que he visto eso implementado con las manos. Esto era parte de sus problemas.
Lo segundo, su jenkins solo tenia un nodo de computo, el principal, y existia en una instancia del mismo equipo que hosteaba Git.
Lo tercero, en el mismo Git tenian varias extensiones y complementos, que fueron extremadamente dificiles de descifrar, y hacian sus ‘Pull requests’ estilo subversion. Al recibir un branch de nombre feature/, bug/, hotfix/ (Odio esta nomenclatura, todos fueron a la misma escuelita sin imaginacion). Lo mezclaba con develop/ y luego jenkins master.
Lo cuarto, su jenkins, recibia llamadas de los ‘merge triggers’ una vez integrado (Exitoso o no). Y lanzaba Builds y luego Merge con master. Siempre tomando la ultima version.
¿Cual era el problema?
El primer problema, es que si decides auto hospedar Git, no deberias tener tu Jenkins en el mismo servidor. Sobretodo si tienes una cantidad desmedida de extensiones que consumen una gran cantidad de memoria y recursos de disco.
El segundo problema, es que si decides tener tu propio jenkins. Deberia tener almenos un nodo de computo fuera del nodo maestro. Basicamente por la misma razon, capacidad de computo. En algunos experimentos, todo jenkins se inhibia.
Esos eran los problemas de sobrecarga, por ello aveces jenkins dejaba de funcionar.
Ahora vamos con los problemas logicos. Git no es un sistema transaccional, tener todas las acciones de operacion en Git es dudoso en el mejor de los casos. El mismo github funciona con bases de datos transacionales, para todo el tema alrededor de Pull Requests, Issues y comentarios.
¿Que sucedia? Pues era la combinacion de varias cosas.
Tener triggers de merge con autoresolucion de problemas es peligroso. Al menos es importante tener un set de pruebas para ejecutar. Lo que pasaba es que cada vez que un desarrollador hacia un push de sus ramas feature/ tomaba la ultima version del codigo. Si tenia conflictos automaticamente tomaba ‘theirs’ y reemplazaba todo. Y se iba a development. Esto pasaba para cada desarrollador. Si varios hacian push a la vez. Se causaba una destruccion sistematica del sistema.
Y no debo olvidar mencionar, que los parametros usados para los triggers de las extensiones los tomaban con un GREP del output.
Paralelo a lo anterior. Jenkins cada vez que development se mezclaba era disparado. Siempre tomando la ultima version (no necesariamente la que disparo la actividad). El mismo jenkins hacia su propia version en development haciendo algunos cambios fijos esta era la parte ‘gitops’ editaba algunos parametros del despliegue, colocaba la version, siempre antes de enviar a master.
Cierto, la misma persona que diseño extraer parametros con GREP del output en las extensiones de git, lo hizo aca tambien. Y habia momentos donde el hacer commit desde el job de jenkins. Disparaba los triggers /feature,/bug,/hotfix. Esto nunca sube porque, pero pasaba.
Este commit, se solapaba con los cambios de los developers. Y podia lanzar de forma infinita jobs que se gastaban la memoria en el mismo nodo, y en paralelo. Asi que era posible tener varios jobs, tratando de hacer el mismo merge a la vez.
¿Como se soluciono?
Esa tonteria de los GREP y Outputs, tuvo que desaparecer. Se empezo a usar los metodos de Git para extraer los ID, Tags, etc.
El job de jenkins se reparo. Ya no usaba la ultima version. Sino que el disparador enviaba el commit ID.
Esos complementos que usaban merge ‘theirs’ DESAPARECIERON. Tuve una pelea ridicula, de que si querian hacer eso, al menos necesitaban pruebas automaticas de toda la solucion. Que ese era el trabajo de su lider, hacer la integracion. Ni las IAs te permiten hacer esta tonteria.
Y ese fue el fin. Un horrible sistema, destruido por horribles practicas, por tratar de facilitar el trabajo del Lider. Que en el final no sabia ni que hizo.
Como reflexion, si las personas podian hacer esto antes de la IA, No me espero las consultorias del futuro.