5 publicaciones etiquetados con "Migración"

Nuestro GitLab self-hosted (gitlab.sils.tech) está en 15.11.5, una versión de mayo de 2023, corriendo sobre Ubuntu 18.04. Para esa versión de Ubuntu no hay paquetes de GitLab posteriores a la 16.11, así que no alcanza con actualizar el paquete: hay que mover GitLab a una VM nueva.

La estrategia es dejar el GitLab actual fuera de servicio y congelado durante la migración. Así nadie puede escribir mientras copiamos los datos y no se pierde nada. La VM vieja queda apagada e intacta como plan de vuelta atrás.

Este post es el plan de trabajo. Los checkboxes se van tildando a medida que avanzamos.

Actualizado 2026-10-10: la migración quedó terminada en SilsX. Se cerraron la Fase 3 y la Fase 4 (Bootstrap y bootstrap-vue desinstalados, sin prefijo tw: y sin important), y se sumaron aprendizajes nuevos.

El frontend de SilsX (dashboard-k2) nació sobre Bootstrap 4 + bootstrap-vue 2. Desde hace un tiempo convive con un kit de componentes propio en src/components/ui/ (Tailwind 4, puerto Vue 2.7 del design system de SilsX, galería en /#/ui). En septiembre/octubre de 2026 armamos un plan por fases para sacar Bootstrap del todo, y hoy está ejecutado completo: no quedan componentes de bootstrap-vue, ni el paquete bootstrap, ni el prefijo de Tailwind.

Este post cuenta la estrategia, qué se hizo en cada fase, cómo verificamos que nada cambiara visualmente, y los problemas que aparecieron en el camino para que nadie se los vuelva a comer.

Hasta octubre de 2026, todos los pipelines de Jenkins de plataforma y colectores se autenticaban contra GCP con claves JSON de las service accounts por defecto de App Engine (sils-producto-stage@appspot y sils-producto@appspot). Esas claves tenían años, daban Editor en stage y Owner en prod, y terminaban copiadas en workspaces, imágenes Docker y máquinas locales.

Las reemplazamos por impersonación de dos service accounts de deploy con permisos mínimos, sin ninguna clave. Este post cuenta qué cambió, cómo se deploya ahora y los problemas que aparecieron en el camino.

Al consultar ciertas tablas de MySql notamos que tienen una cantidad excesiva de filas. Acá veremos una forma de hacer una copia de los datos en un dataset de BigQuery por un lado, y por el otro la posibilidad de borrar los datos de MySql.

La intención es plasmar los impedimentos con sus soluciones que encontré al actualizar la versión de MySQL de 5.7 a 8.0.

El problema no está en hacer el upgrade desde GCP, sino algunas queries que no son exactamente iguales en la versión 8.x, sobre todo las relacionadas a consultas sobre columnas Geometry. Para solucionar estos problemas ver la sección sobre columnas geometry.

Otro error detectado en los logs se produce en la función cron-jobs-executer que al intentar correr uno de los jobs, la consulta falla por problemas de compatibilidad. Ver en la sección.