|
|
# Plan y procedimiento de actualización y migración de GitLab CE desde una instalación `from source` a una `Omnibus`
|
|
|
|
|
|
Contexto: [Métodos de instalación de GitLab](https://docs.gitlab.com/ce/install/README.html)
|
|
|
|
|
|
## Breve introducción
|
|
|
|
|
|
Este plan/procedimiento fue desarrollado (ensayo-error mediante) con motivo de actualizar la instancia de GitLab CE utiliza por la *Red de Unidades Informáticas de la UdelaR en el Interior*, aprovechando la oportunidad de su migración a un nuevo servidor.
|
|
|
|
|
|
La antigua instancia se encontraba montada a partir de una template Proxmox desarrollado por [Turnkey Linux](https://www.turnkeylinux.org/gitlab). El template utilizado parte de un container LXC con Debian Jessie sobre el cual se realiza la instalación `from source` de GitLab CE en su versión `8.8.0-rc1`, empleando `MySQL 5.5.60` como servidor de base de datos.
|
|
|
|
|
|
Debido al bajo porcentaje de éxito al realizar upgrades de GitLab cuando la instalación se realizó `from source` (sobre todo con versiones tan antiguas), el plan de migración para nuestro caso consistió en saltar a una instalación de `Omnibus` tan pronto fue posible, y una vez en `Omnibus` realizar los upgrades sucesivos hasta alcanzar la actual versión: `12.2.3`.
|
|
|
|
|
|
El plan de migración incluyó los siguientes pasos:
|
|
|
- Clonar el servidor en producción para trabajar sin alterar/dañar la instalación original.
|
|
|
- Migrar el servidor de base de datos de MySQL a PostgreSQL (RDBMS recomendado por GitLab e incluido en instalaciones `Omnibus`).
|
|
|
- Realizar un upgrade manual (`from source`) hasta la versión `8.9.11` de GitLab, ya que el template de Turnkey no se basó en una versión estable.
|
|
|
- Realizar un dump o backup completo de la instancia mediante los utilitarios provistos por GitLab
|
|
|
- Instalar mediante `Omnibus` una instancia de GitLab sobre una máquina virtual auxiliar con Debian Jessie, empleando exáctamente la misma versión `8.9.11` sobre la que se realizó el backup en el paso anterior.
|
|
|
- Recupear el backup en realizado sobre la instalación `from source` en la nueva instalación `Omnibus`.
|
|
|
- Sobre la instalación `Omnibus`, realizar los upgrades sucesivos hasta alcanzar la última versión: `12.2.3`.
|
|
|
- Alcanzada la versión `12.2.3`, realizar un nuevo backup con los utilitarios GitLab.
|
|
|
- Realizar una instalación "limpia" de GitLab CE actualizado (`12.2.3`) a partir de nuestros playbooks Ansible sobre `Matera`, el nuevo servidor de producción (VM corriendo Debian Buster).
|
|
|
- Recuperar el backup realizado en la VM auxiliar en el nuevo servidor en producción.
|
|
|
- Disfrutar el resultado.
|
|
|
|
|
|
|
|
|
## Migrar el servidor de base de datos de MySQL a PostgreSQL
|
|
|
|
|
|
Referencias: [Migrating from MySQL to PostgreSQL](https://docs.gitlab.com/ce/update/mysql_to_postgresql.html) / [How To Migrate a MySQL Database to PostgreSQL Using pgLoader](https://www.digitalocean.com/community/tutorials/how-to-migrate-mysql-database-to-postgres-using-pgloader)
|
|
|
|
|
|
Para realiar la readaptación de la estructura de la base de datos, recurrimos al utilitario [pgLoader](https://pgloader.io/). Debido a que sobre Debian Jessie y Stretch, su ejecución se interrumpía por memoria insuficiente, fue necesario optar por realizar la instalación sobre Ubuntu 18.04 en una VM auxiliar.
|
|
|
|
|
|
> A modo de comentario/recomendación, para simplificar el trabajo con las máquina virtuales auxiliares utilizadas en este procedimiento, se empleó la herramienta [Vagrant](https://www.vagrantup.com/).
|
|
|
|
|
|
Al requerir una VM auxiliar para pgLoader, necesitaremos también permitir el acceso remoto a los servidores MySQL y PostgreSQL instalados en el clon del servidor en producción. Comenzamos realizando dichas configuraciones.
|
|
|
|
|
|
### Configuración de MySQL
|
|
|
|
|
|
**En clon de servidor en producción**
|
|
|
|
|
|
Detener servicio de GitLab
|
|
|
|
|
|
```
|
|
|
service gitlab stop
|
|
|
```
|
|
|
|
|
|
Resetear contraseña del usuario `root` MySQL (no se cuenta con ella por tratarse de una instalación TurnKey).
|
|
|
|
|
|
```bash
|
|
|
service mysql stop
|
|
|
mysqld_safe --skip-grant-tables --skip-networking&
|
|
|
mysql -u root
|
|
|
use mysql;
|
|
|
UPDATE user SET password=PASSWORD('secret-password') WHERE user='root';
|
|
|
exit
|
|
|
service mysql restart
|
|
|
```
|
|
|
|
|
|
Habilitar login remoto:
|
|
|
|
|
|
Editar `/etc/mysql/my.cnf`
|
|
|
|
|
|
Descomentar la entrada `skip-external-locking` y cambiar la entrada `bind-address = 127.0.0.1` por `bind-address = 0.0.0.0`
|
|
|
|
|
|
Reiniciar el servcicio de MySQL:
|
|
|
|
|
|
```
|
|
|
service mysql restart
|
|
|
```
|
|
|
|
|
|
Crear usuario con contraseña `secret` y privilegios de acceso a la BD remotamente:
|
|
|
```
|
|
|
mysql -u root -p
|
|
|
CREATE USER 'pgloader_my'@'%' IDENTIFIED BY 'secret';
|
|
|
GRANT ALL ON gitlab_production.* TO 'pgloader_my'@'%';
|
|
|
FLUSH PRIVILEGES;
|
|
|
exit
|
|
|
```
|
|
|
|
|
|
### Instalación y configuración de PostgreSQL
|
|
|
|
|
|
Referencias: [Installation from source: Database](https://docs.gitlab.com/ce/install/installation.html#6-database)
|
|
|
|
|
|
**En clon de servidor en producción**
|
|
|
|
|
|
```bash
|
|
|
|
|
|
# Instalar PostgreSQL
|
|
|
sudo apt update
|
|
|
sudo apt install postgresql postgresql-client libpq-dev postgresql-contrib
|
|
|
|
|
|
# Crear base de datos y usuario
|
|
|
sudo -u postgres psql -d template1 -c "CREATE USER git CREATEDB;"
|
|
|
sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"
|
|
|
sudo -u postgres psql -d template1 -c "CREATE DATABASE gitlabhq_production OWNER git;"
|
|
|
|
|
|
# Probar conexión al servidor
|
|
|
sudo -u git -H psql -d gitlabhq_production
|
|
|
|
|
|
# Chequear si la extensión pg_trgm está habilitada
|
|
|
SELECT true AS enabled FROM pg_available_extensions
|
|
|
WHERE name = 'pg_trgm' AND installed_version IS NOT NULL;
|
|
|
|
|
|
### Correcto si retorna lo siguiente:
|
|
|
# enabled
|
|
|
# ---------
|
|
|
# t
|
|
|
# (1 row)
|
|
|
|
|
|
# Cerrar sesión en Postgre:
|
|
|
\q
|
|
|
|
|
|
# Establecer contraseña al role 'git' en Postgres
|
|
|
sudo -u postgres psql
|
|
|
|
|
|
ALTER ROLE git PASSWORD 'secret';
|
|
|
\q
|
|
|
```
|
|
|
|
|
|
#### Configurar login remoto para Postgre:
|
|
|
|
|
|
Editar `/etc/postgresql/9.4/main/postgresql.conf`
|
|
|
|
|
|
Descomentar y cambiar la entrada `listen_addresses = 'localhost'` por `listen_addresses = '*'`
|
|
|
|
|
|
Editar `/etc/postgresql/9.4/main/pg_hba.conf`
|
|
|
|
|
|
Bajo `IPv4 local connections`, reemplazar `127.0.0.1/32` por `all`
|
|
|
|
|
|
Reiniciar el servcicio de Postgre:
|
|
|
|
|
|
```
|
|
|
service postgresql restart
|
|
|
```
|
|
|
|
|
|
#### Configurar GitLab para usar la nueva base de datos Postgres:
|
|
|
|
|
|
```bash
|
|
|
# Asegurarse que el servicio 'gitlab' está detenido
|
|
|
service gitlab stop
|
|
|
|
|
|
# Modificar el archivo de configuración de GitLab
|
|
|
cd /home/git/gitlab
|
|
|
sudo -u git mv config/database.yml config/database.yml.bak
|
|
|
sudo -u git cp config/database.yml.postgresql config/database.yml
|
|
|
```
|
|
|
|
|
|
Reflejar nuestra configuración en el archivo `config/database.yml`, quedando así:
|
|
|
```yml
|
|
|
#
|
|
|
# PRODUCTION
|
|
|
#
|
|
|
production:
|
|
|
adapter: postgresql
|
|
|
encoding: unicode
|
|
|
database: gitlabhq_production
|
|
|
pool: 10
|
|
|
username: git
|
|
|
password: secret
|
|
|
host: localhost
|
|
|
port: 5432
|
|
|
```
|
|
|
|
|
|
```bash
|
|
|
# Asegurarse que el archivo cuenta con los permisos correctos
|
|
|
sudo -u git -H chmod o-rwx config/database.yml
|
|
|
|
|
|
# Instalar las gemas relacionadas a Postgres
|
|
|
sudo -u git -H rm .bundle/config
|
|
|
sudo -u git -H bundle install --deployment --without development test mysql aws kerberos
|
|
|
|
|
|
# Preparar la estructura de la base de datos ejecutando las db:migrations
|
|
|
sudo -u git -H bundle exec rake db:create db:migrate RAILS_ENV=production
|
|
|
```
|
|
|
|
|
|
|
|
|
### Instalar pgLoader
|
|
|
|
|
|
**En Ubuntu 18.04 sobre VM auxiliar**
|
|
|
|
|
|
Se utiliza específicamente la versión `3.6.1` compilada desde la fuente, cuyo correcto funcionamiento fue comprobado.
|
|
|
|
|
|
```bash
|
|
|
# Instalar dependencias
|
|
|
sudo apt update
|
|
|
sudo apt install sbcl unzip libsqlite3-dev gawk curl make freetds-dev libzip-dev
|
|
|
|
|
|
# Descargar la release 3.6.1
|
|
|
wget https://github.com/dimitri/pgloader/archive/v3.6.1.tar.gz
|
|
|
|
|
|
# Desempaquetar, compilar e instalar
|
|
|
tar xvf v3.6.1.tar.gz
|
|
|
cd pgloader-3.6.1/
|
|
|
make pgloader
|
|
|
sudo mv ./build/bin/pgloader /usr/local/bin/
|
|
|
|
|
|
# Comprobar resultado de la instalación
|
|
|
pgloader --version
|
|
|
```
|
|
|
|
|
|
### Migrar la base de datos
|
|
|
|
|
|
**En Ubuntu 18.04 sobre VM auxiliar**
|
|
|
|
|
|
Crear un archivo de texto en el que indicaremos los parámetros de la migración, llamado por ejemplo `migrarDB.load`.
|
|
|
|
|
|
La estructura del archivo será la siguiente:
|
|
|
```sql
|
|
|
LOAD DATABASE
|
|
|
FROM mysql://<nombre-de-usuario-mysql>:<password-mysql>@<dominio-o-ip-del-servidor>/<nombre-de-la-bd-mysql>
|
|
|
INTO postgresql://<nombre-de-usuario-psql>:<password-psql>@<dominio-o-ip-del-servidor>/<nombre-de-la-bd-psql>
|
|
|
|
|
|
WITH include no drop, truncate, disable triggers, create no tables,
|
|
|
create no indexes, preserve index names, no foreign keys,
|
|
|
data only
|
|
|
|
|
|
ALTER SCHEMA '<nombre-de-la-bd-mysql>' RENAME TO 'public';
|
|
|
```
|
|
|
|
|
|
Para nuestro caso, el archivo queda definido así:
|
|
|
```sql
|
|
|
LOAD DATABASE
|
|
|
FROM mysql://pgloader_my:secret@164.73.232.13/gitlab_production
|
|
|
INTO postgresql://git:secret@164.73.232.13/gitlabhq_production
|
|
|
|
|
|
WITH include no drop, truncate, disable triggers, create no tables,
|
|
|
create no indexes, preserve index names, no foreign keys,
|
|
|
data only
|
|
|
|
|
|
ALTER SCHEMA 'gitlab_production' RENAME TO 'public';
|
|
|
```
|
|
|
|
|
|
Por último ejecutamos la migración:
|
|
|
```bash
|
|
|
pgloader migrarDB.load
|
|
|
```
|
|
|
|
|
|
El proceso tarda solo algunos segundos. Si todo fue bien, podremos observar en la terminal algo similar a lo siguiente:
|
|
|
```
|
|
|
table name errors rows bytes total time
|
|
|
------------------------------ --------- --------- --------- --------------
|
|
|
fetch meta data 0 59 0.086s
|
|
|
Truncate 0 59 0.169s
|
|
|
------------------------------ --------- --------- --------- --------------
|
|
|
public.abuse_reports 0 0 0.048s
|
|
|
public.appearances 0 1 0.2 kB 0.022s
|
|
|
public.audit_events 0 527 82.7 kB 0.037s
|
|
|
public.ci_application_settings 0 0 0.037s
|
|
|
public.ci_commits 0 889 151.7 kB 0.077s
|
|
|
public.application_settings 0 1 0.3 kB 0.027s
|
|
|
public.broadcast_messages 0 0 0.027s
|
|
|
public.ci_jobs 0 0 0.150s
|
|
|
public.ci_builds 0 2 0.7 kB 0.056s
|
|
|
public.ci_runners 0 0 0.345s
|
|
|
public.ci_events 0 0 0.153s
|
|
|
|
|
|
............................................
|
|
|
............................................
|
|
|
............................................
|
|
|
|
|
|
|
|
|
public.ci_triggers 0 0 0.419s
|
|
|
public.ci_sessions 0 0 0.362s
|
|
|
public.ci_variables 0 0 0.428s
|
|
|
public.ci_tags 0 0 0.414s
|
|
|
public.deploy_keys_projects 0 7 0.3 kB 0.437s
|
|
|
public.ci_trigger_requests 0 0 0.425s
|
|
|
public.ci_web_hooks 0 0 0.437s
|
|
|
public.events 0 1535 3.0 MB 0.769s
|
|
|
public.emails 0 0 0.465s
|
|
|
public.forked_project_links 0 1 0.0 kB 0.482s
|
|
|
public.issues 0 113 84.8 kB 0.520s
|
|
|
public.labels 0 16 1.9 kB 0.482s
|
|
|
public.taggings 0 0 0.429s
|
|
|
public.todos 0 80 6.1 kB 0.431s
|
|
|
public.users_star_projects 0 1 0.0 kB 0.422s
|
|
|
------------------------------ --------- --------- --------- --------------
|
|
|
COPY Threads Completion 0 4 0.924s
|
|
|
Reset Sequences 0 58 0.041s
|
|
|
Install Comments 0 0 0.000s
|
|
|
------------------------------ --------- --------- --------- --------------
|
|
|
Total import time ✓ 6970 4.3 MB 0.965s
|
|
|
```
|
|
|
|
|
|
|
|
|
**En clon de servidor en producción**
|
|
|
|
|
|
Para comprobarlo, iniciamos el servicio de GitLab:
|
|
|
|
|
|
```
|
|
|
service gitlab start
|
|
|
```
|
|
|
|
|
|
y accedemos a través de la web como de costumbre. Ahora nos encontramos sobre una base de datos PostgreSQL, lo que podremos comprobar en el panel de información de los usuarios administradores.
|
|
|
|
|
|
|
|
|
## Upgrade manual de GitLab desde la versión inestable `8.8.0-rc1` a la estable `8.9.11`
|
|
|
|
|
|
Referencias: [From 8.8 to 8.9](https://gitlab.com/gitlab-org/gitlab-ce/blob/11-8-stable/doc/update/8.8-to-8.9.md)
|
|
|
|
|
|
**En clon de servidor en producción**
|
|
|
|
|
|
Actualizaremos a la versión estable más próxima, para tener la misma versión de `Omnibus` como candidato de instalación. **Necesitamos que sean versiones idénticas para luego poder recuperar el backup completo.**
|
|
|
|
|
|
```bash
|
|
|
# Detener el servicio de GitLab
|
|
|
sudo service gitlab stop
|
|
|
|
|
|
# Actualizar el repositorio y "pararse" en la versión 8.9.x estable
|
|
|
cd /home/git/gitlab
|
|
|
sudo -u git -H git fetch --all
|
|
|
sudo -u git -H git checkout -- db/schema.rb # Los cambios locales se recuperarán automáticamente
|
|
|
sudo -u git -H git checkout 8-9-stable
|
|
|
|
|
|
# Actualizar gitlab-shell
|
|
|
cd /home/git/gitlab-shell
|
|
|
sudo -u git -H git fetch --all --tags
|
|
|
sudo -u git -H git checkout v3.0.0
|
|
|
|
|
|
# Actualizar gitlab-workhorse
|
|
|
## NO NECESARIO EN LA VERSION DE TURNKEY
|
|
|
## YA QUE EL COMPONENTE NO ESTÁ INSTALADO
|
|
|
cd /home/git/gitlab-workhorse
|
|
|
sudo -u git -H git fetch --all
|
|
|
sudo -u git -H git checkout v0.7.5
|
|
|
sudo -u git -H make
|
|
|
|
|
|
# Instalar librerías y actualizar base de datos:
|
|
|
cd /home/git/gitlab
|
|
|
sudo -u git -H bundle install --without mysql development test --deployment
|
|
|
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
|
|
|
sudo -u git -H bundle exec rake assets:clean assets:precompile cache:clear RAILS_ENV=production
|
|
|
|
|
|
# Deshabilitar 'git gc --auto'
|
|
|
sudo -u git -H git config --global gc.auto 0
|
|
|
|
|
|
# Asegurar que el script de inicio está actualizado
|
|
|
sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab
|
|
|
|
|
|
# Iniciar servicio de GitLab y reiniciar el servicio Nginx
|
|
|
sudo service gitlab start
|
|
|
sudo service nginx restart
|
|
|
|
|
|
```
|
|
|
|
|
|
### Comprobar el resultado de la actualización
|
|
|
|
|
|
Para chequear si el entorno de GitLab está configurado correctamente:
|
|
|
|
|
|
```
|
|
|
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
|
|
|
```
|
|
|
|
|
|
Deberá retornar algo similar a lo siguiente:
|
|
|
|
|
|
```
|
|
|
System information
|
|
|
System: Debian 8.10
|
|
|
Current User: git
|
|
|
Using RVM: no
|
|
|
Ruby Version: 2.1.5p273
|
|
|
Gem Version: 2.2.2
|
|
|
Bundler Version:1.12.4
|
|
|
Rake Version: 10.5.0
|
|
|
Sidekiq Version:4.1.2
|
|
|
|
|
|
GitLab information
|
|
|
Version: 8.9.11
|
|
|
Revision: 9a05855
|
|
|
Directory: /home/git/gitlab
|
|
|
DB Adapter: postgresql
|
|
|
URL: http://git.interior.edu.uy
|
|
|
HTTP Clone URL: http://git.interior.edu.uy/some-group/some-project.git
|
|
|
SSH Clone URL: git@git.interior.edu.uy:some-group/some-project.git
|
|
|
Using LDAP: no
|
|
|
Using Omniauth: no
|
|
|
|
|
|
GitLab Shell
|
|
|
Version: 3.0.0
|
|
|
Repositories: /home/git/repositories/
|
|
|
Hooks: /home/git/gitlab-shell/hooks/
|
|
|
Git: /usr/bin/git
|
|
|
```
|
|
|
|
|
|
Para comprobar la integridad de la instalación:
|
|
|
|
|
|
```
|
|
|
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
|
|
|
```
|
|
|
|
|
|
Observando el resultado podremos detectar si algo va mal. El utilitario nos indicará como arreglar los eventuales problemas que se presenten (resaltados en rojo).
|
|
|
|
|
|
```
|
|
|
( ... )
|
|
|
Redis version >= 2.8.0? ... yes
|
|
|
Ruby version >= 2.1.0 ? ... yes (2.1.5)
|
|
|
Your git bin path is "/usr/bin/git"
|
|
|
Git version >= 2.7.3 ? ... no
|
|
|
Try fixing it:
|
|
|
Update your git to a version >= 2.7.3 from 2.1.4
|
|
|
Please fix the error above and rerun the checks.
|
|
|
Active users: 25
|
|
|
|
|
|
Checking GitLab ... Finished
|
|
|
( ... )
|
|
|
```
|
|
|
|
|
|
En nuestro caso se solicita actualizar `git` al menos a la versión `2.7.3`. Dado que esta versión no se encuentra disponible en las fuentes oficiales de Debian Jessie, toca agregar al `sources.list` los de Debian Stretch:
|
|
|
|
|
|
Agregando la línea: `deb http://http.debian.net/debian stretch main` en el archivo `/etc/apt/sources.list`.
|
|
|
|
|
|
```bash
|
|
|
echo 'deb http://http.debian.net/debian stretch main' >> /etc/apt/sources.list
|
|
|
```
|
|
|
|
|
|
Ahora podemos actualizar `git`:
|
|
|
|
|
|
```bash
|
|
|
apt update
|
|
|
apt install git
|
|
|
```
|
|
|
|
|
|
Una vez corregidos los problemas, ejecutamos nuevamente el utilitario. Repetimos el proceso hasta que no se presenten errores.
|
|
|
|
|
|
|
|
|
## Obtener un backup completo de la instancia GitLab para recuperar en la instalación `Omnibus`
|
|
|
|
|
|
**En clon de servidor en producción**
|
|
|
|
|
|
Mediante los utilitarios provistos por GitLab, generamos un archivo `.tar` que empaqueta base de datos, repositorios y configuraciones.
|
|
|
|
|
|
Para generar el backup hacemos lo siguiente:
|
|
|
```bash
|
|
|
cd /home/git/gitlab
|
|
|
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
|
|
|
```
|
|
|
Una vez finalizado el proceso, el archivo resultante se ubicará en la ruta `/home/git/gitlab/tmp/backups/<timestamp>_gitlab_backup.tar`.
|
|
|
|
|
|
Posteriormente debemos copiar este archivo, por ejemplo mediate `scp`, a la VM auxiliar en la que realizaremos la instalación `Omnibus`.
|
|
|
|
|
|
## Instalar GitLab `8.9.11` mediante `Omnibus` en una VM auxiliar con Debian Jessie
|
|
|
|
|
|
Una vez que contamos con una instalación de Debian Jessie x64 en una VM auxiliar (Recomentable utilizar [Vagrant](https://www.vagrantup.com/)), instalamos GitLab CE `8.9.11` mediante `Omnibus`. El procedimiento es sencillo, basta con agregar los repositorios de GitLab:
|
|
|
|
|
|
```
|
|
|
apt-get update
|
|
|
apt-get install curl
|
|
|
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
|
|
|
```
|
|
|
|
|
|
Y realizar la instalación indicando la versión específica:
|
|
|
|
|
|
```
|
|
|
sudo apt-get install gitlab-ce=8.9.11-ce.0
|
|
|
```
|
|
|
|
|
|
Finalizado el proceso de descarga e instalación, debemos editar el archivo de configuración `/etc/gitlab/gitlab.rb`. En él actualizamos el campo `external_url` para que corresponda a la IP de nuestra VM (o nombre de dominio si lo tiene).
|
|
|
|
|
|
```
|
|
|
( ... )
|
|
|
external_url 'http://164.73.233.165'
|
|
|
( ... )
|
|
|
```
|
|
|
|
|
|
Concluimos la instalación de la instancia ejecutando:
|
|
|
|
|
|
```
|
|
|
gitlab-ctl reconfigure
|
|
|
```
|
|
|
|
|
|
Finalizado el proceso, accedemos desde un navegador a la IP indicada en el campo `external_url`. Deberemos ver la página de inicio de GitLab solicitando establecer una password para el usuario `root`. Una vez configurada la cuenta `root` podremos iniciar sesión para comprobar que todo marcha bien.
|
|
|
|
|
|
## Recupear el backup realizado sobre la instalación `from source` en la nueva instalación `Omnibus`
|
|
|
|
|
|
Referencias: [Restore for Omnibus GitLab installations](https://docs.gitlab.com/ce/raketasks/backup_restore.html#restore-for-omnibus-gitlab-installations)
|
|
|
|
|
|
**En VM auxiliar con Debian Jessie**
|
|
|
|
|
|
Con GitLab `8.9.11` ya instalado, transferimos el archivo de backup generado en la instalación `from source` (clon de servidor en producción) a la VM con Debian Jessie.
|
|
|
|
|
|
Ya transferido, lo ubicamos en la ruta `/var/opt/gitlab/backups/` y asignamos al usuario y grupo `git` como propietario del archivo:
|
|
|
|
|
|
```
|
|
|
chown git:git /var/opt/gitlab/backups/<timestamp>_gitlab_backup.tar
|
|
|
```
|
|
|
|
|
|
Antes de recuperar el backup, debemos detener los servicios de GitLab que se conectan a la base de datos:
|
|
|
|
|
|
```
|
|
|
gitlab-ctl stop unicorn
|
|
|
gitlab-ctl stop sidekiq
|
|
|
```
|
|
|
|
|
|
Con los servicios detenidos (podemos comprobarlo con `gitlab-ctl status`), restauramos desde el backup:
|
|
|
|
|
|
```
|
|
|
gitlab-rake gitlab:backup:restore BACKUP=<timestamp>
|
|
|
```
|
|
|
|
|
|
Si todo va bien, se nos consultará si deseamos limpiar la base de datos antes de continuar. Ya que no contamos tablas adicionales a las de la instalación, respondemos que si:
|
|
|
|
|
|
```
|
|
|
root@jessie:~# gitlab-rake gitlab:backup:restore BACKUP=1567120222
|
|
|
Unpacking backup ... done
|
|
|
Before restoring the database we recommend removing all existing
|
|
|
tables to avoid future upgrade problems. Be aware that if you have
|
|
|
custom tables in the GitLab database these tables and all data will be
|
|
|
removed.
|
|
|
|
|
|
Do you want to continue (yes/no)? yes
|
|
|
```
|
|
|
|
|
|
Luego nos consulta si deseamos reconstruir las `authorized_keys`, a lo que también responderemos afirmativamente:
|
|
|
|
|
|
```
|
|
|
( ... )
|
|
|
Put GitLab hooks in repositories dirs [DONE]
|
|
|
done
|
|
|
Restoring uploads ...
|
|
|
done
|
|
|
Restoring builds ...
|
|
|
done
|
|
|
Restoring artifacts ...
|
|
|
done
|
|
|
Restoring lfs objects ...
|
|
|
done
|
|
|
This will rebuild an authorized_keys file.
|
|
|
You will lose any data stored in authorized_keys file.
|
|
|
Do you want to continue (yes/no)? yes
|
|
|
|
|
|
........................................
|
|
|
Deleting tmp directories ... done
|
|
|
done
|
|
|
( ... )
|
|
|
```
|
|
|
|
|
|
Finalizada la restauración, reconfiguramos GitLab y reiniciamos todos sus servicios:
|
|
|
|
|
|
```
|
|
|
gitlab-ctl reconfigure
|
|
|
```
|
|
|
|
|
|
```
|
|
|
gitlab-ctl restart
|
|
|
```
|
|
|
|
|
|
|
|
|
### Comprobar el resultado de la restauración
|
|
|
|
|
|
Para comprobar la integridad de la instancia:
|
|
|
|
|
|
```
|
|
|
gitlab-rake gitlab:check SANITIZE=true
|
|
|
```
|
|
|
|
|
|
Al igual que en pasos anteriores, el utilitario nos indicará como arreglar los eventuales problemas que se presenten.
|
|
|
|
|
|
En nuestro escenario, no se presenta ningún error, así que continuamos.
|
|
|
|
|
|
Al acceder a la web para comprobar que todos los datos se hayan recuperado, constatamos que **se obtiene un "misterioso" error `500`** al consultar la página de inicio de los respositorios. Todo los demás funciona correctamente. Continuamos de todas formas, ya que el error es solucionado por el paso siguiente (Al llegar a la versión `8.15.0` de GitLab).
|
|
|
|
|
|
|
|
|
## Actualizar GitLab desde la version `8.9.11` a la más reciente
|
|
|
|
|
|
Referencias: [Updating methods](https://docs.gitlab.com/omnibus/update/README.html#updating-methods)
|
|
|
|
|
|
**En VM auxiliar con Debian Jessie**
|
|
|
|
|
|
Llegados aquí, ya tenemos nuestro GitLab migrado a una instalación `Omnibus`, sobre PostgreSQL y con todos nuestros datos recuperados.
|
|
|
|
|
|
Tratándose de una instalación `Omnibus`, realizar upgrades entre versiones mayores es simple. Solo hay que tener en cuenta realizar los "saltos" intermedios correctos entre las versiones que introdujeron cambios importantes.
|
|
|
|
|
|
Consultando [aquí](https://docs.gitlab.com/omnibus/update/README.html) y [aquí](https://about.gitlab.com/releases/), identificamos que las versiones intermedias por las que es recomendable pasar son:
|
|
|
- `8.11.0`
|
|
|
- `8.15.0`
|
|
|
- `9.0.0`
|
|
|
- `9.5.10`
|
|
|
- `10.0.0`
|
|
|
- `10.8.7`
|
|
|
- `11.0.0`
|
|
|
- `11.2.0`
|
|
|
- `11.4.0`
|
|
|
- `11.6.0`
|
|
|
- `11.8.3`
|
|
|
- `12.0.0`
|
|
|
- `12.1.0`
|
|
|
- `12.2.3` (Más reciente al documentar este procedimiento)
|
|
|
|
|
|
Ya que GitLab fue instalado desde repositorios, realizar los upgrades es tan simple como indicar la version correspondiente a `apt-get`:
|
|
|
|
|
|
```bash
|
|
|
sudo apt-get install gitlab-ce=<VERSION>-ce.0
|
|
|
```
|
|
|
|
|
|
Debemos iterar el proceso para cada versión listada arriba. El mismo instalador se encarga de migrar todos los datos y configuraciones.
|
|
|
|
|
|
En caso de requerirse acciones manuales adicionales, el instalador nos lo indicará, por lo que es necesario estar atentos a la salida. **Notar que al saltar entre las versiones indicadas, no se solicitarán acciones manuales.**
|
|
|
|
|
|
Finalizada cada instalación, y habiendo realizado lo que eventualmente se nos indique, podremos chequear que todo va bien accediendo a GitLab y observando en el panel de administrador la versión de cada uno de los componentes de GitLab.
|
|
|
|
|
|
|
|
|
## Obtener un backup completo de la instancia GitLab actualizada a versión más reciente
|
|
|
|
|
|
Referencias:
|
|
|
[Backup options](https://docs.gitlab.com/ce/raketasks/backup_restore.html#backup-options)
|
|
|
[Restore for Omnibus GitLab installations](https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-omnibus-gitlab-installations)
|
|
|
|
|
|
**En VM auxiliar con Debian Jessie**
|
|
|
|
|
|
Al igual que varios pasos atrás, generamos un archivo `.tar` que empaqueta base de datos, repositorios y configuraciones.
|
|
|
|
|
|
Esta vez el proceso de backup es ligeramente diferente. Basta con ejecutar:
|
|
|
|
|
|
```
|
|
|
gitlab-backup create
|
|
|
```
|
|
|
|
|
|
Finalizado el proceso, el archivo resultante se encontrará en:
|
|
|
|
|
|
`/var/opt/gitlab/backups/<timestamp>_<fecha>_<version>_gitlab_backup.tar`
|
|
|
|
|
|
**Adicionalmente a este archivo `.tar`, debemos recuperar el archivo `/etc/gitlab/gitlab-secrets.json`, ya que contiene tokens necesarios para la correcta ejecución de GitLab cuando recuperemos el backup.**
|
|
|
|
|
|
Ambos archivos se destinarán a recuperar los datos de la instancia en una instalación "limpia" de GitLab CE sobre Debian Buster, el que consideraremos nuestro nuevos servidor en producción.
|
|
|
|
|
|
|
|
|
## Realizar una instalación limpia de GitLab CE en su versión más reciente
|
|
|
|
|
|
**En nuevo servidor de producción con Debian Buster**
|
|
|
|
|
|
Finalizando el largo camino de la migración, necesitamos un nuevo servidor a destinar a producción, con una instalación estándar y actualizada de Debian Buster.
|
|
|
|
|
|
Sobre este servidor instalaremos la versión más reciente de GitLab CE utilizando nuevamente `Omnibus`.
|
|
|
|
|
|
Este procedimiento se encuentra automatizado en nuestros playbooks Ansible, empleando el role de la galaxia `geerlingguy.gitlab`, por lo que no es necesario hacer nada más en este paso.
|
|
|
|
|
|
Si por curiosidad o necesidad, la instalación se realiza manualmente, en esencia el role implementa el procedimiento utilizado en pasos anteriores:
|
|
|
|
|
|
Agrega los repositorios correpsondientes:
|
|
|
|
|
|
`curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash`
|
|
|
|
|
|
Y realiza la instalación indicando la versión idéntica a la que se utilizó para generar el backup del paso previo:
|
|
|
|
|
|
`sudo apt-get install gitlab-ce=12.2.3-ce.0`
|
|
|
|
|
|
Finalizado el proceso de descarga e instalación, (si no utilizamos el role Ansible) debemos editar el archivo de configuración `/etc/gitlab/gitlab.rb`. En él actualizaremos el campo `external_url` para que corresponda al nombre de dominio de nuestro flamante servidor. Este archivo concentra todas las configuraciones de GitLab, por lo que podremos modificar otros parámetros en caso de necesitarlo.
|
|
|
|
|
|
Se concluye la instalación y configuración de la instancia ejecutando:
|
|
|
|
|
|
`gitlab-ctl reconfigure`
|
|
|
|
|
|
|
|
|
## Restaurar el backup final en el servidor de producción
|
|
|
|
|
|
**En nuevo servidor de producción con Debian Buster**
|
|
|
|
|
|
**¡Último paso!** Deberemos transferir al servidor en producción el archivo de backup `.tar` y el de configuración `gitlab-secrets.json`. Deben ubicarse en la ruta `/var/opt/gitlab/backups/` y `/etc/gitlab/gitlab-secrets.json` respectivamente (sobreescribiendo el existente).
|
|
|
|
|
|
Asignar al usuario y grupo `git` como propietario del archivo `.tar`:
|
|
|
```
|
|
|
chown git:git /var/opt/gitlab/backups/<timestamp>_<fecha>_<version>_gitlab_backup.tar
|
|
|
```
|
|
|
|
|
|
Antes de recuperar el backup, detener los servicios de GitLab que se conectan a la base de datos:
|
|
|
```
|
|
|
gitlab-ctl stop unicorn
|
|
|
gitlab-ctl stop sidekiq
|
|
|
```
|
|
|
|
|
|
Con los servicios ya detenidos (podemos comprobarlo con `gitlab-ctl status`) restauramos desde el backup:
|
|
|
```
|
|
|
gitlab-backup restore BACKUP=<timestamp>_<fecha>_<version>
|
|
|
```
|
|
|
|
|
|
Finalizado la restauración, reconfiguramos GitLab y reiniciamos todos sus servicios:
|
|
|
```
|
|
|
gitlab-ctl reconfigure
|
|
|
gitlab-ctl restart
|
|
|
```
|
|
|
|
|
|
|
|
|
### Comprobar el resultado de la restauración
|
|
|
|
|
|
Para comprobar la integridad de la instancia:
|
|
|
```
|
|
|
gitlab-rake gitlab:check SANITIZE=true
|
|
|
```
|
|
|
|
|
|
Al igual que en pasos anteriores, el utilitario nos indicará como arreglar los eventuales problemas que se presenten.
|
|
|
|
|
|
Por último accedemos a la web para comprobar que todos los datos se hayan recuperado y todo funciona correctamente.
|
|
|
|
|
|
|
|
|
# ¡Disfrutar! |
|
|
\ No newline at end of file |