Avec la fin de vie de Centos, j'ai du migrer mon installation gitlab sur un nouveau serveur. J'ai choisi pour cela la distribution Almalinux 9 (https://almalinux.org/), basée aussi sur RedHat, avec le même système de paquets, je ne serai pas perdu.
Cette procédure doit fonctionner avec toutes les distributions supportées par gitlab (https://docs.gitlab.com/install/package/#supported-platforms), modulo les adaptations dans certaines commandes (apt install au lieu de dnf install si vous êtes sur une base debian par exemple).
J'ai pris comme référence la documentation suivante : https://docs.gitlab.com/administration/backup_restore/restore_gitlab/
À noter, il faudra impérativement installer sur le nouveau serveur une version de gitlab identique à celle de l'ancien serveur, pour la trouver, rendez-vous sur le pannel d'administration et vous trouverez l'information en bas à droite :
Il vous faudra donc un accès ssh à votre ancien serveur (dans la suite l'ip sera substituée par ANCIEN), un accès ssh sur le nouveau serveur (dans la suite l'ip sera substituée par NOUVEAU), Le nouveau serveur est dans mon cas une instance où est fraîchement installé un AlmaLinux 9, et rien d'autre.
Installation de gitlab sur le nouveau serveur
Connectez-vous en ssh à votre nouveau serveur (ssh root@NOUVEAU)
# Mises à jour et installation de paquets nécessaires
dnf update
dnf install -y curl vim
# Installation des dépots Gitlab Community Edition
curl "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh" | sudo bash
# Trouver la version du paquet à installer correspondante à la version installée sur l'ancien serveur
dnf search --showduplicates gitlab-ce
# dans mon cas : gitlab-ce-17.7.7-ce.0.el9
# Installation de gitlab en spécifiant l'url de l'instance
sudo EXTERNAL_URL="https://gitlab.exemple.com" dnf install gitlab-ce-17.7.7-ce.0.el9Backup et transfert de l'instance existante
Connectez-vous en ssh à votre ancien serveur (ssh root@NOUVEAU)
# Si vous n'avez pas de paire de clé ssh sur votre ancien serveur, créez-en une :
ssh-keygen -t ed25519 -C "root@ancien"
# on ajoute la clée public de l'ancien serveur au nouveau afin de pouvoir s'y connecter sans mot de passe
ssh-copy-id root@NOUVEAU
# Avant de lancer le backup, on désactive l'accès à l'instance
sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma
# On lance un backup de son instance gitlab
gitlab-backup create BACKUP=dump_full GZIP_RSYNCABLE=yes
# Transferts des secrets (fichier non présent dans le backup)
rsync /etc/gitlab/gitlab-secrets.json -e ssh root@NOUVEAU:/etc/gitlab/
# Transferts de la configuration (fichier non présent dans le backup)
rsync /etc/gitlab/gitlab.rb -e ssh root@NOUVEAU:/etc/gitlab/
# Transfert des backups
rsync -avh --stats /var/opt/gitlab/backups/* -e ssh root@NOUVEAU:/var/opt/gitlab/backups/Restauration de la sauvegarde sur le nouveau serveur
De nouveau connecté ssh à votre nouveau serveur (ssh root@NOUVEAU)
# On arrête les services connectés à la base de données
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
# on regarde le nom du backup à restaurer :
ls -alh /var/opt/gitlab/backups/
# dans mon cas l'archive se nomme dump_full
# on ne prend pas en compte la partie du fichier « _gitlab_backup.tar »
# -rw-------. 1 git git 22G Oct 24 08:48 dump_full_gitlab_backup.tar
# on lance la restauration (processus long)
sudo gitlab-backup restore BACKUP=dump_full
# on lance une reconfiguration de gitlab à partir des données restaurées
sudo gitlab-ctl reconfigure
# on relance tous les services
sudo gitlab-ctl start
# On vérifie que tout va bien
sudo gitlab-rake gitlab:check SANITIZE=true
# On vérifie l'intégritées des données chiffrées à partir du fichier secrets que l'on a transféré
sudo gitlab-rake gitlab:doctor:secrets
# On vérifie l'intégritée globale de l'ensemble des données restaurées
sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check
sudo gitlab-rake gitlab:uploads:check
# On lance une analyse de la base de données via la console
sudo gitlab-rails dbconsole --database main
SET STATEMENT_TIMEOUT=0 ; ANALYZE VERBOSE;Fin de la migration
Si tout va bien, vous pouvez maintenant faire pointer soit changer la configuration dns pour pointer le nom de domaine de votre serveur gitlab vers le nouveau serveur ou alors affecter l'ip de l'ancien serveur au nouveau (ce que j'ai fait, étant sur des serveurs virtualisés).
Une fois que tout est ok, vous pourrez lancer les mises à jours de gitlab sur le nouveau serveur afin de profiter des dernières mise à jour :
sudo dnf updateDans mon cas, j'ai du faire des mises à jour intermédiaires, 17.8.x, 17.11.x puis 18.2.x avant de lancer la mise à jour finale:
Pour trouver la dernière version d'une version intermédiaire :
dnf search --showduplicates gitlab-ce | grep "17.8"
Last metadata expiration check: 0:03:51 ago on Fri 24 Oct 2025 01:06:17 PM UTC.
gitlab-ce-17.8.0-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.1-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.2-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.4-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.5-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.6-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.7-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)j'ai donc lancé successivement :
sudo dnf instal gitlab-ce-17.8.7-ce.0.el9.x86_64
sudo dnf install gitlab-ce-17.11.7-ce.0.el9.x86_64
sudo dnf install gitlab-ce-18.2.8-ce.0.el9.x86_64Pour terminer, pensez-bien à réinstaller gitlab runner si vous utilisiez la CI (https://docs.gitlab.com/runner/install/linux-repository/) et remettre en place la sauvegarde de votre instance. Voilà ce que j'ai dans mon crontab pour 2 sauvegarder par jour + une sauvegarde complète :
30 18 * * * gitlab-backup create BACKUP=dump_night GZIP_RSYNCABLE=yes SKIP=registry,artifacts
30 11 * * * gitlab-backup create BACKUP=dump_day GZIP_RSYNCABLE=yes SKIP=registry,artifacts
30 19 5 * * gitlab-backup create BACKUP=dump_full GZIP_RSYNCABLE=yes Contenus en rapport
Pré-requis : connexion root sur le serveur gitlab installé via omnibus
J'ai présenté lors du Drupalcamp de Rennes en mars 2024 mon nouveau sideproject : un ensemble de jobs factorisés pour gitlab ci.
La problématique était la suivante :
Ajouter un commentaire