Índice de contenidos
1. Entorno
Este tutorial está escrito usando el siguiente entorno:
- Hardware: Slimbook Pro 2 13.3″ (Intel Core i7, 32GB RAM)
- Sistema Operativo: LUbuntu 18.04
- GitLab 11.1.4
2. Introducción
No hay cosa más importante en una empresa que desarrolla software que mantener a salvo el código fuente que genera. Otros elementos de la integración continua como los pipelines, el resultado de Jenkins, las métricas de software se pueden recrear a través del código fuente pero si perdemos el código fuente perdemos un tiempo y dinero incalculable.
En este tutorial vamos a ver cómo tenemos que configurar GitLab para poder hacer un backup periódico de nuestro código fuente, salvarlo en un lugar seguro y qué tenemos que hacer para restaurarlo.
Toda la información oficial detallada la tenéis en la siguiente URL
3. Vamos al lío
Partimos de que ya tenemos una instancia en producción de GitLab.
Primero vamos a hacer los cambios de configuración necesarios para hacer backup.
Para ello editamos el fichero /etc/gitlab/gitlab.rb
$> sudo nano /etc/gitlab/gitlab.rb
Dentro de este fichero con CTRL + W buscamos la palabra Backup Settings que nos llevará directamente a la sección.
En esta sección podemos ver dónde se almacenarán localmente los backups generados en la propiedad «backup_path». Por defecto, en «/var/opt/gitlab/backups»
En la propiedad «backup_keep_time» podemos definir en segundos el tiempo de vida de los ficheros de backup a fin de no llenar el disco de la máquina. Por defecto este valor se establece a 604800 segundos que son 7 días.
Si queremos que el fichero de backup se almacene automáticamente en un bucket S3 de AWS solo tenemos que descomentar las líneas que se refieren a la propiedad «backup_upload_connection» y establecer el nombre del bucket en la propiedad «backup_upload_remote_directory».
Para que los cambios de configuración tengan efecto, tenemos que ejecutar:
$> sudo gitlab-ctl reconfigure
Hecho esto en cualquier momento que queramos generar un fichero de backup solo tendremos que ejecutar el siguiente comando:
$> sudo gitlab-rake gitlab:backup:create
Al ejecutar este comando se generará el archivo y tendremos que ver que también se almacena en el bucket de AWS previamente configurado. En el enlace a la documentación oficial tenéis otras estrategias de salvado.
Nota: Por razones de seguridad los ficheros: /etc/gitlab/gitlab.rb y /etc/gitlab/gitlab-secrets.json no se incluyen dentro del fichero generado y tienen que ser salvados de forma independiente.
Ahora si lo que queremos es que el backup se realice de forma automática todos los días a las 2 AM tenemos que crear un cron siguiendo estos pasos:
$> sudo su - $> crontab -e
Y añadimos la siguiente línea:
0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1
Una vez tenemos salvado el fichero con el backup, vamos a ver cómo podemos utilizarlo para restaurar nuestra instancia en caso de que sea necesario.
Lo primero que necesitamos es que GitLab esté corriendo y al menos hayamos ejecutado una vez un reconfigure.
$> sudo gitlab-ctl reconfigure
Nota: En caso de no estar corriendo no se puede restaurar el backup, así que al menos necesitamos una instancia limpia con la misma versión de GitLab corriendo.
El siguiente paso sería copiar el fichero de backup deseado en la ruta de la propiedad backup_path que por defecto es /var/opt/gitlab/backups/
Ahora vamos a parar los servicios «unicorn» y «sidekiq» únicamente, el resto de servicios tienen que estar corriendo.
$> sudo gitlab-ctl stop unicorn $> sudo gitlab-ctl stop sidekiq
Podemos comprobar que solo estos servicios están parados ejecutando:
$> sudo gitlab-ctl status
Ahora ejecutamos el comando de resturación indicando el timestamp del fichero de backup.
$> sudo gitlab-rake gitlab:backup:restore BACKUP=1534804928_2018_08_21_11.1.4_gitlab
Hecho esto de forma satisfactoria es el momento de restaurar los ficheros /etc/gitlab/gitlab.rb y /etc/gitlab/gitlab-secrets.json y reiniciar.
$> sudo gitlab-ctl restart
Podemos comprobar que todos los procesos están correctamente con el comando:
$> sudo gitlab-rake gitlab:check SANITIZE=true
4. Conclusiones
A nadie se le escapa la importancia de preservar el fruto de nuestro esfuerzo y GitLab nos lo pone realmente fácil para hacer y restaurar los backups.
Cualquier duda o sugerencia en la zona de comentarios.
Saludos.
Hola, realizé un respaldo de un servidor Gitlab que tengo en la nube y lo restauré en un servidor que tengo local, el punto es que al querer realizar commits al nuevo servidor me da error 401 Unauthorized , ¿alguna sugerencia?