Introduction
Exploiter GitLab CI/CD en production ne se limite pas à installer le logiciel. Cela exige une approche disciplinée de la configuration, de la surveillance, de la maintenance, des sauvegardes et des mises à niveau. Cette liste de contrôle fournit des étapes pratiques et concrètes pour maintenir un environnement GitLab CI/CD fiable, sécurisé et performant. Nous nous concentrons sur les instances GitLab auto-hébergées, qu'elles soient déployées sur du matériel nu, des machines virtuelles ou des instances cloud, et évitons les conseils spécifiques aux conteneurs sauf mention explicite. En suivant ce guide, vous établirez une base pour l'inventaire des versions, mettrez en œuvre des changements de configuration sûrs, vérifierez la santé du système, planifierez la reprise après défaillance et maintiendrez une routine opérationnelle reproductible.
Inventaire des versions et de l'environnement
Avant d'effectuer tout changement, documentez votre configuration actuelle. Cet inventaire est la base pour le dépannage et la planification.
Déterminer les versions des composants
Exécutez les commandes suivantes sur votre serveur GitLab (en supposant une installation Omnibus) :
sudo gitlab-rake gitlab:env:infoLa sortie attendue inclut des lignes de version comme :
GitLab version: 16.7.0
GitLab Shell version: 14.33.0
PostgreSQL version: 14.8Vérifiez également la version de GitLab Runner sur chaque exécuteur :
gitlab-runner --versionSortie attendue :
Version: 16.7.0
Git revision: 1234abcd
Git branch: 16-7-stable
GO version: go1.21.4
Built: 2023-12-18T14:00:00Z
OS/Arch: linux/amd64Cartographier votre topologie
Enregistrez comment les composants GitLab sont répartis. Pour une installation Omnibus typique sur un seul serveur, tous les services s'exécutent sur un même hôte. Pour des configurations plus importantes, vous pouvez avoir des hôtes séparés pour PostgreSQL, Redis, Gitaly et plusieurs exécuteurs. Notez les noms d'hôtes, les adresses IP, l'allocation des ressources et la connectivité réseau.
Vérifier les prérequis
Assurez-vous que le système d'exploitation répond aux exigences de GitLab et que les paquets et ports requis sont accessibles. Ports courants : 80/443 pour HTTP/HTTPS, 22 pour SSH et 5050 pour le registre de conteneurs (si activé). Vérifiez avec :
sudo ss -tulpn | grep -E ':(80|443|22|5050)'La sortie attendue montre des sockets en écoute pour ces ports.
Documenter vos procédures de sauvegarde et de restauration
Sachez où les sauvegardes sont stockées, leur fréquence et comment les restaurer. Une vérification simple :
sudo ls -lh /var/opt/gitlab/backups/La sortie attendue montre des fichiers de sauvegarde horodatés, par exemple 1699999999_2023_11_15_16.7.0_gitlab_backup.tar.
Conservez cet inventaire dans un document sous contrôle de version et mettez-le à jour à chaque changement. Attribuez un responsable unique, tel que le responsable DevOps, pour le maintenir et le réviser trimestriellement.
Chemin de configuration sûr
Évitez d'effectuer des changements larges et non testés directement en production. Adoptez plutôt une approche limitée et incrémentale.
Utiliser la gestion de configuration et le contrôle de version
Stockez /etc/gitlab/gitlab.rb dans un dépôt Git. Avant chaque changement, créez une branche et validez la syntaxe de la configuration :
sudo gitlab-ctl reconfigure --dry-runLa sortie attendue inclut Would reconfigure GitLab... sans appliquer réellement les changements.
Tester sur un environnement de préproduction
Maintenez une instance de préproduction qui reflète la production le plus fidèlement possible. Appliquez d'abord les changements là-bas, exécutez votre suite de tests et observez tout problème éventuel.
Mettre en œuvre des indicateurs de fonctionnalité et un déploiement progressif
Pour les nouvelles fonctionnalités CI/CD, utilisez les indicateurs de fonctionnalité de GitLab ou des variables d'environnement pour les activer sur un sous-ensemble de projets. Par exemple, pour activer une nouvelle fonctionnalité d'exécuteur pour un seul projet, vous pouvez définir une variable CI uniquement pour ce projet.
Exemple : Modifier les paramètres CI/CD
Supposons que vous souhaitiez augmenter le délai d'expiration des artefacts. Au lieu de le changer globalement, définissez-le par projet dans .gitlab-ci.yml :
default:
artifacts:
expire_in: 1 weekValidez la syntaxe YAML :
python3 -c "import yaml, sys; yaml.safe_load(open('.gitlab-ci.yml'))"Aucune sortie signifie que la syntaxe est valide.
Documenter la procédure de retour en arrière
Pour chaque changement, notez la configuration précédente et comment revenir en arrière. Utilisez git revert ou restaurez le fichier gitlab.rb précédent et reconfigurez.
En suivant un chemin de configuration sûr, vous réduisez le risque de perturbation du service et facilitez le dépannage. Le propriétaire de la configuration doit approuver tous les changements et les réviser mensuellement.
Vérification et diagnostic
Après avoir appliqué les changements, vérifiez que le système fonctionne correctement. Utilisez les commandes intégrées et les outils de surveillance.
Vérifier la santé des services
Exécutez :
sudo gitlab-ctl statusLa sortie attendue montre chaque service sous la forme run: service_name: (pid) 123s; run: log: (pid) 456s.
Exécuter des auto-vérifications
GitLab fournit plusieurs vérifications :
sudo gitlab-rake gitlab:checkCela exécute diverses vérifications de cohérence, telles que la connectivité à la base de données et l'intégrité des dépôts. Recherchez des lignes comme Checking GitLab ... Finished with no errors.
Surveiller les indicateurs clés
Utilisez les métriques Prometheus exposées par GitLab (si activées) ou une surveillance externe. Par exemple, pour vérifier la file d'attente des tâches en arrière-plan :
sudo gitlab-rails runner 'puts Sidekiq::Queue.new.size'Sortie attendue : 0 (ou un petit nombre). Des nombres élevés indiquent des problèmes.
Vérifier l'exécution des pipelines CI/CD
Créez un projet de test avec un .gitlab-ci.yml simple et exécutez un pipeline. Vérifiez que le travail se termine et que les artefacts attendus sont produits.
Vérifier l'intégrité des sauvegardes
Testez périodiquement la restauration dans un environnement bac à sable. Une sauvegarde qui ne peut pas être restaurée est inutile. Confiez à l'ingénieur d'exploitation la réalisation mensuelle d'un test de restauration et la documentation des résultats.
Gardez les journaux accessibles et examinez-les régulièrement :
sudo gitlab-ctl tailUtilisez cette section de vérification à chaque changement ou selon un calendrier pour détecter les problèmes tôt.
Modes de défaillance et reprise
Les systèmes de production tomberont en panne. Planifiez les modes de défaillance courants et sachez comment récupérer.
Épuisement de l'espace disque
Symptôme : GitLab devient non réactif, les journaux affichent No space left on device.
Reprise : Identifiez les gros fichiers :
sudo du -sh /var/opt/gitlab/* | sort -hNettoyez les anciens artefacts, journaux ou images de conteneurs. Si nécessaire, étendez le disque. Configurez des alertes de surveillance pour une utilisation du disque supérieure à 80 % afin d'éviter un épuisement complet.
Corruption de la base de données
Symptôme : erreurs GitLab, les journaux PostgreSQL montrent une corruption.
Reprise : Restaurez à partir de la sauvegarde valide la plus récente. Avant de restaurer, arrêtez les services :
sudo gitlab-ctl stop
sudo gitlab-backup restore BACKUP=1699999999
sudo gitlab-ctl startVérifiez ensuite avec sudo gitlab-rake gitlab:check.
Erreur de configuration
Symptôme : les services échouent après la reconfiguration.
Reprise : Revenez à la version précédente connue comme bonne de gitlab.rb et exécutez sudo gitlab-ctl reconfigure. Si cela échoue, restaurez à partir de la sauvegarde.
Défaillances des exécuteurs
Symptôme : les travaux restent en attente, l'exécuteur est hors ligne.
Reprise : Vérifiez l'état de l'exécuteur :
sudo gitlab-runner statusRedémarrez si nécessaire :
sudo gitlab-runner restartExaminez les journaux de l'exécuteur pour les erreurs.
Problèmes de réseau ou de certificat
Symptôme : interface web inaccessible ou erreurs SSL.
Reprise : Vérifiez les règles de pare-feu, le DNS et la validité du certificat. Renouvelez ou corrigez les certificats et reconfigurez.
Utilisation élevée des ressources
Symptôme : réponse lente, CPU/mémoire élevés.
Reprise : Identifiez les processus :
topAjustez les paramètres GitLab (par exemple, réduisez les processus de travail) ou augmentez les ressources.
Ayez toujours une procédure de sauvegarde et de restauration testée. Documentez chaque défaillance et reprise dans un journal d'incidents pour améliorer les réponses futures. Le commandant d'incident (rôle tournant) doit examiner le journal chaque semaine.
Pièges courants et comment les éviter
Exploiter GitLab CI/CD comporte des pièges récurrents. Voici les plus courants, pourquoi ils surviennent et comment les prévenir ou s'en remettre.
Piège 1 : Ne pas tester les sauvegardes
Pourquoi cela arrive : Les équipes supposent que les sauvegardes sont bonnes parce qu'elles sont créées avec succès, mais la restauration peut échouer en raison d'une configuration manquante, de permissions ou de versions incompatibles.
Comment l'éviter : Planifiez des tests de restauration mensuels dans un environnement isolé. Utilisez le fichier de sauvegarde exact et suivez la procédure documentée. Consignez le résultat du test et le temps pris.
Reprise : Si une restauration échoue, dépannez immédiatement. Vérifiez les journaux de sauvegarde, l'intégrité du stockage et la compatibilité. N'attendez pas un véritable désastre.
Piège 2 : Effectuer des changements de configuration sans essai à blanc
Pourquoi cela arrive : Dans la précipitation pour résoudre un problème, les ingénieurs modifient directement gitlab.rb et exécutent reconfigure, provoquant des redémarrages de service inattendus ou des erreurs de configuration.
Comment l'éviter : Utilisez toujours --dry-run d'abord et testez en préproduction. Gardez gitlab.rb sous contrôle de version et examinez les diffs.
Reprise : Si un changement casse la production, revenez à la version précédente depuis Git et reconfigurez. Si cela échoue, restaurez à partir de la sauvegarde.
Piège 3 : Ignorer la maintenance des exécuteurs
Pourquoi cela arrive : Les exécuteurs sont souvent configurés une fois puis oubliés jusqu'à ce que des échecs de pipeline surviennent.
Comment l'éviter : Mettez régulièrement à jour les versions des exécuteurs, surveillez leur état et supprimez les exécuteurs inutilisés. Utilisez un outil de gestion de configuration pour imposer la cohérence.
Reprise : Lorsque les exécuteurs échouent, vérifiez les journaux, redémarrez et, si nécessaire, réenregistrez l'exécuteur avec un nouveau jeton.
Piège 4 : Manquer d'espace disque
Pourquoi cela arrive : Les artefacts, journaux et images de conteneurs s'accumulent sans politiques de nettoyage.
Comment l'éviter : Définissez l'expiration des artefacts dans .gitlab-ci.yml, configurez la rotation des journaux et planifiez des tâches de nettoyage régulières. Surveillez les tendances d'utilisation du disque.
Reprise : Supprimez immédiatement les anciens artefacts et journaux, étendez le disque si possible et mettez en œuvre des politiques de rétention.
Piège 5 : Sauter la préparation aux mises à niveau
Pourquoi cela arrive : Les équipes mettent à niveau sans lire les notes de version ni sauvegarder, entraînant des changements cassants inattendus ou des pertes de données.
Comment l'éviter : Lisez les notes de mise à niveau pour chaque version mineure, sauvegardez avant de mettre à niveau et utilisez un environnement de préproduction pour tester.
Reprise : Si la mise à niveau échoue, restaurez à partir de la sauvegarde et analysez la cause avant de réessayer.
Liste de contrôle des opérations
Utilisez cette liste de contrôle pour les opérations courantes et les revues périodiques. Attribuez chaque élément à un responsable (par exemple, ingénieur DevOps) et définissez une fréquence de revue.
Contrôles quotidiens (Responsable : ingénieur DevOps de garde)
- Examinez
sudo gitlab-ctl statuspour vérifier que tous les services fonctionnent. - Vérifiez l'utilisation des ressources système (CPU, mémoire, disque).
- Surveillez la taille de la file Sidekiq :
sudo gitlab-rails runner 'puts Sidekiq::Queue.new.size'doit être faible. - Vérifiez les travaux de pipeline échoués dans les projets critiques.
Contrôles hebdomadaires (Responsable : responsable DevOps)
- Examinez les journaux pour les erreurs (
sudo gitlab-ctl tailou recherche centralisée dans les journaux). - Vérifiez l'achèvement des sauvegardes et l'espace de stockage.
- Vérifiez les mises à jour GitLab disponibles et les correctifs de sécurité.
Contrôles mensuels (Responsable : ingénieur d'exploitation)
- Testez la procédure de restauration dans un environnement bac à sable.
- Examinez les comptes utilisateurs et les permissions ; supprimez les comptes obsolètes.
- Vérifiez le parc d'exécuteurs pour les exécuteurs hors ligne et mettez à jour leurs versions.
- Examinez les changements de configuration dans le contrôle de version et documentez toute dérive.
Contrôles trimestriels (Responsable : responsable DevOps)
- Effectuez un audit de sécurité complet (certificats TLS, règles de pare-feu).
- Examinez l'efficacité des pipelines CI/CD : tailles des artefacts, durées des travaux et utilisation des exécuteurs.
- Évaluez la planification de capacité : croissance du disque, tendances CPU/mémoire.
- Mettez à jour le document d'inventaire de l'environnement.
Avant et après les mises à niveau (Responsable : gestionnaire de version)
- Lisez les notes de mise à niveau et planifiez les temps d'arrêt si nécessaire.
- Sauvegardez avant la mise à niveau.
- Mettez à niveau une version mineure à la fois (pour Omnibus :
sudo apt-get update && sudo apt-get install gitlab-ce=<version>). - Après la mise à niveau, exécutez
sudo gitlab-ctl reconfigureetsudo gitlab-rake db:migratesi nécessaire. - Vérifiez le système avec
sudo gitlab-rake gitlab:check.
Conservez cette liste de contrôle dans un emplacement partagé et passez-la en revue avec votre équipe pour vous assurer qu'aucune étape n'est manquée.
Conclusion
Exploiter GitLab CI/CD en production nécessite une approche structurée. Cette liste de contrôle a couvert l'inventaire des versions, les pratiques de configuration sûres, la vérification et le diagnostic, les modes de défaillance et la reprise, les pièges courants et une routine opérationnelle. En mettant en œuvre ces étapes, vous pouvez réduire les temps d'arrêt, améliorer la fiabilité et répondre efficacement aux incidents. Commencez par un projet pilote restreint pour tester vos procédures, puis étendez. N'oubliez pas de maintenir votre documentation à jour et de revoir et améliorer continuellement vos processus d'exploitation.