Sauvegarde et restauration GitLab CI/CD : guide pratique avec commandes et vérification

Introduction

La sauvegarde et la restauration GitLab CI/CD avec des exemples pratiques doivent aider les opérateurs à passer d'un problème observé à un résultat vérifié. Commencez par identifier la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté.

Cet article se concentre sur la sauvegarde GitLab CI/CD pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie la restauration GitLab CI/CD, la reprise après sinistre GitLab CI/CD, le retour en arrière GitLab CI/CD et la validation GitLab CI/CD aux commandes, aux sorties attendues, aux signaux d'échec et aux décisions de récupération qui correspondent à la technologie choisie.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire de la version et de l'environnement

Pour la sauvegarde GitLab CI/CD, l'inventaire de la version et de l'environnement doit nommer le composant concerné, la plage de versions prises en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans l'inventaire de la version et de l'environnement, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour l'inventaire de la version et de l'environnement sont la sauvegarde GitLab CI/CD, la restauration GitLab CI/CD, la reprise après sinistre GitLab CI/CD, le retour en arrière GitLab CI/CD et la validation GitLab CI/CD. Les domaines connexes tels que GitLab Runner, Docker et Kubernetes ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour l'inventaire de la version et de l'environnement, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule provenant de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'effectuer une modification.

Dans l'inventaire de la version et de l'environnement, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Exemple : Vérifier la version et la topologie de GitLab

Avant toute sauvegarde ou restauration, confirmez l'édition et la version de GitLab. Sur une installation par paquet Linux, exécutez :

sudo gitlab-rake gitlab:env:info

La sortie attendue comprend des lignes telles que :

GitLab information
Version:        16.9.1
Revision:       abc1234
Directory:      /opt/gitlab
DB Adapter:     PostgreSQL

Si la commande échoue avec une erreur de permission, assurez-vous de disposer des droits sudo sur le serveur GitLab. Pour un déploiement Docker, utilisez :

docker exec -t <nom_du_conteneur> gitlab-rake gitlab:env:info

Remplacez <nom_du_conteneur> par le nom réel de votre conteneur, trouvé via docker ps.

Cette vérification en lecture seule vous indique la version, ce qui détermine les bons indicateurs de sauvegarde et les exigences de restauration.

Chemin de configuration sûr

Pour la sauvegarde GitLab CI/CD, le chemin de configuration sûr doit nommer le composant concerné, la plage de versions prises en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans le chemin de configuration sûr, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour le chemin de configuration sûr sont la sauvegarde GitLab CI/CD, la restauration GitLab CI/CD, la reprise après sinistre GitLab CI/CD, le retour en arrière GitLab CI/CD et la validation GitLab CI/CD. Les domaines connexes tels que GitLab Runner, Docker et Kubernetes ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour le chemin de configuration sûr, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule provenant de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'effectuer une modification.

Dans le chemin de configuration sûr, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Exemple : Configuration de MinIO pour le stockage d'objets externe

Les sauvegardes GitLab incluent souvent les données de stockage d'objets (par exemple, les artefacts CI, les téléversements). Si vous utilisez un service compatible S3 comme MinIO, vérifiez la connexion avant de sauvegarder.

Vérifiez les paramètres actuels du stockage d'objets (lecture seule) :

sudo gitlab-rails runner "puts Gitlab::CurrentSettings.current_application_settings.object_store_connection.inspect"

La sortie attendue montre le point de terminaison, le compartiment et le fournisseur sans secrets. Pour définir une nouvelle valeur, modifiez /etc/gitlab/gitlab.rb et changez un seul paramètre à la fois :

gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'us-east-1',
  'aws_access_key_id' => 'VOTRE_CLE_ACCES',
  'aws_secret_access_key' => 'VOTRE_CLE_SECRETE',
  'endpoint' => 'https://minio.example.com',
  'path_style' => true
}

Après modification, appliquez le changement :

sudo gitlab-ctl reconfigure

Puis vérifiez avec une tâche rake :

sudo gitlab-rake gitlab:check

Recherchez Checking Object storage ... OK dans la sortie. En cas d'échec, restaurez le fichier de configuration à partir de votre copie de sauvegarde et reconfigurez à nouveau.

Cette section est volontairement minimale : évitez de modifier plusieurs paramètres simultanément et ayez toujours un plan de retour en arrière.

Vérification et diagnostics

Pour la sauvegarde GitLab CI/CD, la vérification et les diagnostics doivent nommer le composant concerné, la plage de versions prises en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans la vérification et les diagnostics, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour la vérification et les diagnostics sont la sauvegarde GitLab CI/CD, la restauration GitLab CI/CD, la reprise après sinistre GitLab CI/CD, le retour en arrière GitLab CI/CD et la validation GitLab CI/CD. Les domaines connexes tels que GitLab Runner, Docker et Kubernetes ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour la vérification et les diagnostics, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule provenant de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'effectuer une modification.

Dans la vérification et les diagnostics, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Exemple : Vérifier l'intégrité de l'archive de sauvegarde

Après avoir créé une sauvegarde, confirmez qu'elle est valide et contient les fichiers attendus. Listez le répertoire de sauvegarde (par défaut /var/opt/gitlab/backups) :

sudo ls -lh /var/opt/gitlab/backups

Sortie typique :

-rw------- 1 git git 2.1G Mar 20 10:00 1710914400_2024_03_20_16.9.1_gitlab_backup.tar

L'horodatage 1710914400 est l'ID de sauvegarde ; la version 16.9.1 doit correspondre à la version cible de GitLab pour la restauration.

Pour tester l'intégrité de l'archive sans restaurer, utilisez tar :

sudo tar -tf /var/opt/gitlab/backups/1710914400_2024_03_20_16.9.1_gitlab_backup.tar > /dev/null && echo "Archive OK"

Si la commande affiche Archive OK, le fichier tar est lisible. Pour une vérification plus approfondie, extrayez un fichier spécifique (par exemple, backup_information.yml) dans un répertoire temporaire :

sudo tar -xf /var/opt/gitlab/backups/1710914400_2024_03_20_16.9.1_gitlab_backup.tar -C /tmp backup_information.yml

Puis inspectez-le :

sudo cat /tmp/backup_information.yml

Le contenu attendu inclut :db_version: 14.9 ou similaire. Si l'extraction échoue, la sauvegarde peut être corrompue ; ne comptez pas sur elle pour la récupération.

Modes de défaillance et récupération

Pour la sauvegarde GitLab CI/CD, les modes de défaillance et la récupération doivent nommer le composant concerné, la plage de versions prises en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans les modes de défaillance et la récupération, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour les modes de défaillance et la récupération sont la sauvegarde GitLab CI/CD, la restauration GitLab CI/CD, la reprise après sinistre GitLab CI/CD, le retour en arrière GitLab CI/CD et la validation GitLab CI/CD. Les domaines connexes tels que GitLab Runner, Docker et Kubernetes ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour les modes de défaillance et la récupération, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule provenant de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'effectuer une modification.

Dans les modes de défaillance et la récupération, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Exemple : Restaurer à partir d'une sauvegarde après une suppression accidentelle

Scénario : Les paramètres CI/CD d'un projet ont été modifiés accidentellement et vous devez revenir à un état antérieur à l'aide d'une sauvegarde GitLab.

Prérequis :

Le fichier de sauvegarde existe dans /var/opt/gitlab/backups
La version de la sauvegarde correspond à la version de l'installation GitLab (vérifiez avec gitlab-rake gitlab:env:info)
Les services GitLab sont arrêtés (pour la cohérence de la base de données)

Étape 1 : Arrêtez les services GitLab (rayon d'impact : toute l'instance GitLab est indisponible pendant la restauration) :

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq

Étape 2 : Effectuez la restauration. Remplacez 1710914400_2024_03_20_16.9.1 par votre ID de sauvegarde :

sudo gitlab-backup restore BACKUP=1710914400_2024_03_20_16.9.1

Étape 3 : Redémarrez GitLab :

sudo gitlab-ctl restart

Étape 4 : Vérifiez la restauration. Vérifiez que les paramètres CI/CD du projet sont conformes aux attentes via l'interface utilisateur GitLab (pas de commande, mais vous pouvez utiliser l'API si vous préférez). Exécutez également :

sudo gitlab-rake gitlab:check

La sortie attendue inclut Checking GitLab ... OK. Si la restauration échoue avec une erreur d'incompatibilité de version, vous devez utiliser une sauvegarde créée à partir de la même version de GitLab, ou mettre à niveau/rétrograder GitLab pour correspondre avant de restaurer.

Chemin de récupération : Si la restauration a aggravé la situation, vous pouvez restaurer à nouveau en utilisant une sauvegarde antérieure, ou restaurer les fichiers de configuration depuis /etc/gitlab si vous les aviez sauvegardés séparément.

Liste de contrôle des opérations

Pour la sauvegarde GitLab CI/CD, la liste de contrôle des opérations doit nommer le composant concerné, la plage de versions prises en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans la liste de contrôle des opérations, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour la liste de contrôle des opérations sont la sauvegarde GitLab CI/CD, la restauration GitLab CI/CD, la reprise après sinistre GitLab CI/CD, le retour en arrière GitLab CI/CD et la validation GitLab CI/CD. Les domaines connexes tels que GitLab Runner, Docker et Kubernetes ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour la liste de contrôle des opérations, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule provenant de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'effectuer une modification.

Dans la liste de contrôle des opérations, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Liste de contrôle avant sauvegarde

[ ] Confirmez la version de GitLab et le type de déploiement : exécutez sudo gitlab-rake gitlab:env:info ou équivalent.
[ ] Assurez-vous que le répertoire de sauvegarde dispose d'un espace libre suffisant : df -h /var/opt/gitlab/backups (prévoyez au moins 2 fois la taille estimée de la sauvegarde).
[ ] Vérifiez que les services externes (PostgreSQL, Redis, stockage d'objets) sont accessibles : utilisez sudo gitlab-rake gitlab:check et recherchez les statuts OK.
[ ] Planifiez une période de calme ou informez les utilisateurs.
[ ] Créez une sauvegarde des fichiers de configuration : sudo tar -czf /var/opt/gitlab/backups/gitlab_config_$(date +%s).tar.gz /etc/gitlab.

Commande de sauvegarde

sudo gitlab-backup create

La sortie attendue se termine par :

Backup complete! Backup information:
Backup timestamp: 1710914400
Backup path: /var/opt/gitlab/backups/1710914400_2024_03_20_16.9.1_gitlab_backup.tar

Vérification après sauvegarde

[ ] Vérifiez l'intégrité de l'archive : sudo tar -tf <fichier_de_sauvegarde> > /dev/null && echo "Archive OK"
[ ] Stockez une copie hors site ou dans un stockage d'objets séparé.
[ ] Enregistrez l'ID de sauvegarde et la version dans votre runbook.

Cette liste de contrôle minimise le risque d'échec de restauration dû à des prérequis manquants ou à des sauvegardes non testées.

Conclusion

La sauvegarde et la restauration GitLab CI/CD avec des exemples pratiques ne sont utiles que si chaque recommandation est limitée à la version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure opérationnelle.

Comme prochaine étape, choisissez une vérification à faible risque pour la sauvegarde GitLab CI/CD, enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et passez en revue les dépendances telles que GitLab Runner, Docker et Kubernetes.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision.