Recientemente, se ha detectado una vulnerabilidad en Gitlab que afecta a las siguientes versiones:
- 13.10.3
- 13.9.6
- 13.8.8
Nos puede suceder que tengamos algún Gitlab aún mas viejo a estas versiones, entonces tendremos que actualizarlo a la versión más reciente pasando por varias versiones intermedias.
A continuación, mostraremos los pasos para actualizar Gitlab en Ubuntu 18. Partiremos en el ejemplo de gitlab-ee 12.7.5-ee y lo llevaremos hasta la versión 14.4.2-ee.
Consideramos que Gitlab está instalado previamente desde el repositorio oficial con sus servicios postgresql y redis embebidos.
Pasos previos
Si estamos trabajando en el Cloud y tenemos nuestro Gitlab instalado en una instancia EC2<, se recomienda crear una imagen de la instancia y clonarla en una nueva para realizar los pasos de migración.
También necesitaremos acceso a la consola de Linux de dicha instancia y tener permisos de root.
Updates + snapshots
Ejecutamos en secuencia los siguientes comandos <apt install> esperando en cada caso que no nos dan ningún error y finalizan correctamente.
sudo apt install gitlab-ee=12.10.14-ee.0 sudo apt install gitlab-ee=13.0.14-ee.0 sudo apt install gitlab-ee=13.1.11-ee.0 sudo apt install gitlab-ee=13.8.8-ee.0 sudo apt install gitlab-ee=13.12.10-ee.0 sudo apt install gitlab-ee=13.12.12-ee.0
Una vez finalizados estos pasos, tendremos que ejecutar en consola el siguiente comando, ya que gitlab necesita migrar sus proyectos existentes al nuevo sistema de hashed_storage que utilizan las versiones siguientes.
sudo gitlab-rake gitlab:storage:migrate_to_hashed
Al finalizar el comando anterior, debemos reiniciar la instancia y volver a conectarnos a ella.
En este punto contamos con Gitlab 13.12.12
Continuemos con las actualizaciones
sudo apt install gitlab-ee=14.0.11-ee.0
Al terminar este paso, deberemos comprobar que todas las migraciones han finalizado correctamente.
A partir de esta versión Gitlab nos proporciona una nueva herramienta que nos permite ver si se están ejecutando migraciones. Debemos comprobar que no haya ninguna en cola y que todas hayan finalizado sin errores.
Encontramos esta herramienta en: administration>monitoring>Background Migrations.
Además, también comprobaremos en administration>monitoring>healthCheck que Gitlab se encuentra en estado “Healthy”.
Al finalizar este paso, se recomienda hacer un snapshot
Seguiremos con la siguiente secuencia de updates
Al final de cada una, repetiremos el ejercicio de comprobar por cada finalización, Background Migrations
sudo apt install gitlab-ee=14.1.6-ee.0 sudo apt install gitlab-ee=14.2.0-ee.0 sudo apt install gitlab-ee=14.2.6-ee.0 sudo apt install gitlab-ee=14.3.0-ee.0 sudo apt install gitlab-ee=14.3.4-ee.0 sudo apt install gitlab-ee=14.4.0-ee.0 sudo apt install gitlab-ee=14.4.2-ee.0
Otro tip importante a saber es que en algunas versiones, previas a la 14, veremos que el comando apt ha terminado, pero al intentar acceder a Gitlab obtenemos un error 502. Esto sucede porque existen los ya mencionados Background Migrations, pero para estas versiones no existía la herramienta que nos permitía observar su estado. Pero no desesperemos porque podemos ver el log! y observar cuando hayan acabado.
Podemos ver las últimas entradas del log así y comprobar que no se encuentren transacciones en ejecución:
sudo tail -f /varlog/gitlab/gitlab-rails/production.log
Y ya está, lo hemos logrado! Enhorabuena
Espero que este artículo te haya servido de ayuda para aprender algo nuevo y seguir ampliando tus conocimientos.
Te invito a que si necesitas información sobre el mundo DevOps , nos contactes y sigas revisando nuestro blog para encontrar otras publicaciones útiles.
¡Hasta la próxima!👋
→ Post escrito por Christian Tagliapietra y Álvaro Abad.