Planification des Capacités CI/CD GitLab avec Exemples Pratiques

Introduction

Les pipelines CI/CD de GitLab sont l'épine dorsale de la livraison logicielle moderne, mais ils peuvent devenir un goulot d'étranglement si leur capacité n'est pas planifiée avec soin. La planification des capacités n'est pas une tâche ponctuelle ; c'est un processus continu d'estimation des besoins en ressources, de surveillance de l'utilisation et d'ajustement des configurations à mesure que votre équipe et vos projets se développent. Sans une planification adéquate, les pipelines ralentissent, les tâches s'accumulent dans les files d'attente, les ressources des runners sont gaspillées et les développeurs perdent du temps à attendre des retours.

Ce guide fournit une approche pratique de la planification des capacités CI/CD de GitLab. Il couvre l'inventaire de votre environnement actuel, l'estimation des besoins en ressources, la configuration sécurisée des runners, la vérification de votre configuration, l'anticipation des modes de défaillance et l'établissement d'une liste de contrôle opérationnelle. Tout au long, nous incluons des commandes concrètes, des extraits de configuration et des exemples avec les sorties attendues. À la fin, vous disposerez d'un cadre reproductible pour maintenir votre infrastructure CI/CD fluide à mesure que la demande évolue.

Inventaire de la version et de l'environnement

Avant d'apporter des modifications, vous devez comprendre votre configuration GitLab actuelle et l'infrastructure des runners. Cela inclut la version de GitLab, les types et configurations des runners, la répartition des projets et l'utilisation actuelle des ressources. Un inventaire clair vous aide à identifier les goulots d'étranglement et à planifier la croissance.

Version et topologie du serveur GitLab

Tout d'abord, enregistrez la version de GitLab et le rôle du serveur. Les instances GitLab peuvent être autogérées ou hébergées sur GitLab.com. Pour les instances autogérées, connectez-vous en SSH au serveur et exécutez :

gitlab-rake gitlab:env:info

Extrait de sortie attendu :

System information
System:         Ubuntu 20.04
Current User:   git
Using RVM:      no
Ruby Version:   2.7.6p219
Gem Version:    3.1.6
Bundler Version:2.3.5
Rake Version:   13.0.6
Redis Version:  6.2.7
Git Version:    2.33.1
Go Version:     unknown

GitLab information
Version:        15.11.2
Revision:       abc123
Directory:      /opt/gitlab
DB Adapter:     PostgreSQL
DB Version:     13.8
URL:            https://gitlab.example.com
HTTP Clone URL: https://gitlab.example.com/some-group/some-project.git
SSH Clone URL:  [email protected]:some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers: google_oauth2

Prenez note de la version de GitLab, de la base de données et des intégrations externes. Les utilisateurs de GitLab.com peuvent ignorer cette étape, mais doivent noter que GitLab.com propose des runners partagés avec des quotas définis (par exemple, le niveau gratuit offre 400 minutes CI par mois pour les projets privés, tandis que les niveaux payants en offrent davantage). Les instances autogérées nécessitent de gérer vos propres runners et leur infrastructure sous-jacente.

Inventaire des runners

Les runners exécutent les tâches CI/CD réelles. Listez les runners enregistrés et leur configuration :

gitlab-runner list

Exemple de sortie :

Listing configured runners    ConfigFile=/etc/gitlab-runner/config.toml
my-runner-1                   Executor=docker Token=abc123 URL=https://gitlab.example.com
my-runner-2                   Executor=shell  Token=def456 URL=https://gitlab.example.com

Pour chaque runner, vérifiez son fichier /etc/gitlab-runner/config.toml pour comprendre son type d'exécuteur, sa concurrence et d'autres paramètres. Une configuration typique d'un runner avec exécuteur Docker pourrait ressembler à ceci :

concurrent = 4
check_interval = 0

[[runners]]
  name = "my-runner-1"
  url = "https://gitlab.example.com"
  token = "abc123"
  executor = "docker"
  [runners.docker]
    image = "alpine:latest"
    privileged = false
    volumes = ["/cache"]
    shm_size = 0

Le paramètre concurrent limite le nombre de tâches que ce runner peut exécuter simultanément. Connaître vos types d'exécuteurs actuels est crucial car différents exécuteurs ont des caractéristiques de performance et des limites de capacité différentes. Par exemple, les exécuteurs Docker peuvent être gourmands en ressources en raison de la surcharge des conteneurs, tandis que les exécuteurs shell exécutent les tâches directement sur l'hôte.

Utilisation des projets et des pipelines

Identifiez combien de projets utilisent la CI/CD et leur fréquence de pipeline. Dans GitLab, vous pouvez analyser l'activité des pipelines via l'interface utilisateur (par exemple, la page d'analyse CI/CD du projet) ou via l'API. Pour une instance autogérée, utilisez la console Rails :

gitlab-rails console

Puis interrogez :

Project.where('ci_pipelines_count > 0').count

Cela donne le nombre de projets avec au moins un pipeline. Pour obtenir le nombre total de pipelines par jour (approximativement) :

Ci::Pipeline.where('created_at > ?', 1.week.ago).group("DATE(created_at)").count

La sortie attendue peut ressembler à :

{"2023-05-01"=>45, "2023-05-02"=>52, "2023-05-03"=>61}

Vérifiez également les temps d'attente des tâches. Dans l'interface GitLab, accédez à l'analyse CI/CD d'un projet ou utilisez l'API pour lister les tâches et leur champ queued_duration. Des temps d'attente élevés indiquent un manque de capacité des runners.

Fondamentaux de la planification des capacités

La planification des capacités consiste à faire correspondre l'offre (ressources des runners) à la demande (tâches de pipeline) tout en maintenant des performances acceptables. Cette section explique comment estimer les besoins en ressources en fonction de votre charge de travail.

Comprendre les modèles de charge de travail

Votre charge de travail CI/CD est déterminée par le nombre de tâches et leur consommation de ressources. Commencez par catégoriser les tâches :

Tâches de build : Compilation de code, exécution de tests, construction de conteneurs. Elles peuvent être gourmandes en CPU et en mémoire.
Tâches de test : Exécution de tests automatisés, souvent parallélisables. Elles peuvent nécessiter des services spécifiques (bases de données, caches).
Tâches de déploiement : Publication d'artefacts ou déploiement vers des environnements. Généralement courtes mais peuvent nécessiter un accès réseau.
Tâches utilitaires : Lint, analyse ou nettoyage. Typiquement légères.

Analysez vos pipelines existants pour comprendre la répartition des types de tâches et leur durée moyenne. Par exemple, vous pourriez constater que 70 % des tâches sont des tests, 20 % des builds et 10 % des déploiements. Cette répartition vous aide à décider d'utiliser des runners spécialisés ou d'ajuster la concurrence.

Estimation des besoins en ressources

Pour estimer les besoins en CPU et en mémoire, vous pouvez mesurer l'utilisation réelle des tâches. Si vous utilisez des exécuteurs Docker, utilisez docker stats pendant l'exécution d'une tâche. Par exemple, une tâche de build Node.js typique pourrait utiliser :

CPU : 1,5 cœur en moyenne
Mémoire : 2 Go en pic

Si vous disposez d'un hôte runner avec 4 cœurs CPU et 8 Go de RAM, vous pouvez exécuter en toute sécurité 2 tâches de ce type simultanément (4 cœurs / 1,5 cœur par tâche ≈ 2,6, mais laissez une marge). Ajustez le paramètre concurrent en conséquence.

Pour les runners partagés de GitLab.com, la disponibilité des ressources est gérée par GitLab, mais vous pouvez contrôler l'utilisation via les minutes CI/CD et les délais d'expiration des tâches.

Calcul de la capacité des runners

Une formule simple pour la capacité des runners :

Tâches simultanées max = floor(ceurs CPU disponibles / CPU moyen par tâche)

et assurez-vous également que la mémoire n'est pas surchargée :

Tâches simultanées max = floor(mémoire disponible / mémoire moyenne par tâche)

Prenez le minimum des deux. Par exemple, un hôte avec 8 cœurs et 16 Go de RAM, et des tâches moyennes de 2 cœurs et 3 Go de RAM, peut exécuter au maximum 4 tâches simultanément (8/2=4, 16/3=5,3, min=4).

Réservez toujours des ressources pour le système d'exploitation et la surcharge du runner. Une pratique courante est de laisser au moins 1 cœur et 1 à 2 Go de RAM libres.

Chemin de configuration sécurisé

La planification des capacités implique d'apporter des modifications de configuration qui peuvent affecter tous les utilisateurs des pipelines. Pour ce faire en toute sécurité, adoptez une approche ciblée et incrémentale. Commencez par un petit groupe pilote, mesurez l'impact, puis déployez progressivement.

Comprendre les options de mise à l'échelle des runners

Il existe deux principales façons de faire évoluer la capacité CI/CD de GitLab :

Mise à l'échelle horizontale : Ajoutez plus de runners ou augmentez la concurrence sur les runners existants. C'est l'approche la plus courante.
Mise à l'échelle verticale : Augmentez les ressources (CPU, mémoire) de la machine hébergeant le runner. Cela aide lorsque les tâches individuelles sont gourmandes en ressources.

Pour les runners autogérés, vous pouvez les déployer sur des machines dédiées ou utiliser l'autoscaling (par exemple, avec Docker Machine ou GitLab Runner Autoscaler sur les plateformes cloud). Pour GitLab.com, vous pouvez acheter des minutes CI supplémentaires ou utiliser vos propres runners.

Exemple : ajustement de la concurrence dans config.toml

Supposons que vous ayez un runner avec exécuteur Docker sur un hôte avec 4 CPU et 8 Go de RAM. La valeur actuelle de concurrent est 1, mais vous observez des files d'attente de tâches. Vous pouvez augmenter la concurrence à 2 ou 3, mais vous devez vous assurer que l'hôte dispose de suffisamment de ressources pour éviter la surcharge.

Modifiez /etc/gitlab-runner/config.toml et définissez :

concurrent = 3

Puis redémarrez le runner :

sudo gitlab-runner restart

Vérifiez l'état du runner :

sudo gitlab-runner status

Sortie attendue :

gitlab-runner: Service is running

Surveillez le CPU et la mémoire de l'hôte pendant un pipeline typique pour vous assurer que les tâches n'échouent pas en raison de limites de ressources. Pour les exécuteurs Docker, envisagez de définir des limites de ressources par tâche via les options [runners.docker] telles que cpu_limit et memory_limit pour empêcher une seule tâche de consommer toutes les ressources.

Exemple d'extrait :

[runners.docker]
  cpu_limit = "1"
  memory_limit = "2g"

Cela limite chaque conteneur de tâche à 1 CPU et 2 Go de mémoire, empêchant une tâche d'affamer les autres.

Ajout d'un nouveau runner

Si un seul hôte ne peut pas gérer la charge, ajoutez un autre runner. Il peut s'agir d'une autre machine ou d'un runner conteneurisé sur le même hôte. Pour enregistrer un nouveau runner :

Dans GitLab, accédez aux paramètres de votre projet ou groupe Paramètres > CI/CD > Runners et obtenez le jeton d'enregistrement.
Sur la machine cible, exécutez :

sudo gitlab-runner register \
  --url https://gitlab.example.com \
  --registration-token PROJECT_REGISTRATION_TOKEN \
  --executor docker \
  --description "additional-runner" \
  --docker-image alpine:latest

Suivez les invites pour définir les balises et autres options. Après l'enregistrement, le runner apparaît dans la liste :

gitlab-runner list

La sortie attendue inclut le nouveau runner.

Utilisation des balises pour contrôler la répartition des tâches

Les balises vous permettent d'acheminer les tâches vers des runners spécifiques. Par exemple, vous pouvez avoir un runner dédié aux builds lourds avec plus de ressources. Dans votre .gitlab-ci.yml, vous pouvez spécifier :

job:
  tags:
    - heavy-build

Assurez-vous que le runner est configuré avec la même balise :

[[runners]]
  name = "heavy-build-runner"
  tags = ["heavy-build"]

Cela empêche les tâches légères d'occuper le runner lourd et garantit que les tâches lourdes obtiennent les ressources dont elles ont besoin.

Vérification et diagnostics

Après avoir apporté des modifications de configuration, vous devez vérifier que le système se comporte comme prévu et que la capacité répond à la demande. Cette section fournit des commandes et des vérifications concrètes.

Surveiller la file d'attente des tâches et l'exécution

Utilisez l'API GitLab pour vérifier le nombre de tâches en attente pour un runner spécifique. Tout d'abord, obtenez l'ID du runner depuis l'interface ou listez les runners :

curl --header "PRIVATE-TOKEN: <votre_jeton_d'accès>" "https://gitlab.example.com/api/v4/runners"

Trouvez l'ID de votre runner, puis interrogez ses tâches :

curl --header "PRIVATE-TOKEN: <votre_jeton_d'accès>" "https://gitlab.example.com/api/v4/runners/<runner_id>/jobs?status=running"

Cela montre les tâches en cours d'exécution. Pour voir les tâches en attente pour tous les runners, utilisez :

curl --header "PRIVATE-TOKEN: <votre_jeton_d'accès>" "https://gitlab.example.com/api/v4/jobs?scope=pending"

Si des tâches en attente existent, cela signifie que les runners ne les récupèrent pas assez rapidement. Vérifiez la disponibilité et la concurrence des runners.

Inspecter les journaux du runner

Les journaux du runner sont essentiels pour diagnostiquer les problèmes. Utilisez :

sudo journalctl -u gitlab-runner -f

Cela affiche les journaux du service runner en continu. Recherchez des erreurs telles que des délais d'expiration de tâches, des échecs de récupération d'images ou des problèmes d'espace disque. Pour l'exécuteur Docker, vérifiez également les journaux des conteneurs :

docker logs <container-id>

Mesurer l'utilisation des ressources

Sur l'hôte du runner, utilisez des outils Linux standard :

top

vmstat 1

Observez la charge CPU, l'utilisation de la mémoire et les E/S. Pour les exécuteurs Docker, docker stats donne des métriques par conteneur :

docker stats

Sortie attendue :

CONTAINER ID   NAME              CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O   PIDS
abc123         runner-abc-job1   95.00%    1.2GiB / 3.8GiB       31.58%    1.2MB / 2.3MB     0B / 0B     25
def456         runner-def-job2   12.00%    800MiB / 3.8GiB       20.53%    500kB / 1.1MB     0B / 0B     18

Une utilisation élevée du CPU ou de la mémoire peut indiquer que vous devez réduire la concurrence ou augmenter les ressources.

Vérifier les performances des pipelines

Utilisez les analyses CI/CD intégrées de GitLab pour visualiser la durée des pipelines, les taux de réussite et les temps d'attente des tâches. Pour un projet, accédez à Analyses > Analyses CI/CD. Vous pouvez également utiliser l'API pour obtenir des données sur les pipelines :

curl --header "PRIVATE-TOKEN: <votre_jeton_d'accès>" "https://gitlab.example.com/api/v4/projects/:id/pipelines?per_page=20"

Recherchez des pipelines avec de longues durées ou des temps d'attente élevés. Un temps d'attente supérieur à quelques minutes suggère une capacité insuffisante des runners.

Pièges courants et comment les éviter

Même avec une planification minutieuse, les équipes tombent souvent dans des pièges qui dégradent les performances de la CI/CD. Voici les pièges les plus courants, pourquoi ils surviennent et comment les éviter ou s'en remettre.

Piège 1 : surcharger les ressources du runner

Pourquoi cela arrive : Les équipes augmentent concurrent au-delà de ce que l'hôte peut supporter, en supposant que plus de parallélisme est toujours meilleur. Cela conduit à une contention des ressources, des délais d'expiration des tâches et des défaillances en cascade.

Comment l'éviter : Calculez toujours la capacité en fonction de l'utilisation réelle des ressources des tâches (comme indiqué précédemment). Testez avec une augmentation progressive, en surveillant le CPU et la mémoire. Définissez des limites de ressources par conteneur de tâche pour empêcher une tâche d'accaparer les ressources.

Récupération : Si vous avez surchargé, réduisez concurrent et redémarrez le runner. Nettoyez tout processus ou conteneur zombie. Surveillez l'amélioration.

Piège 2 : ignorer les métriques de file d'attente des tâches

Pourquoi cela arrive : Les équipes se concentrent sur le succès des pipelines mais négligent les temps d'attente des tâches. Au fil du temps, la profondeur de la file d'attente augmente silencieusement, provoquant de la frustration.

Comment l'éviter : Configurez des alertes pour le nombre de tâches en attente. Vous pouvez utiliser la surveillance intégrée de GitLab ou des outils externes comme Prometheus. Examinez les métriques de file d'attente chaque semaine. Attribuez un responsable, par exemple l'ingénieur DevOps, pour examiner les métriques de file d'attente chaque lundi matin.

Récupération : Si vous remarquez une profondeur de file d'attente élevée, vérifiez immédiatement la disponibilité et la capacité des runners. Ajoutez des runners ou augmentez la concurrence selon les besoins.

Piège 3 : utiliser le mauvais type d'exécuteur

Pourquoi cela arrive : Certaines équipes utilisent par défaut les exécuteurs Docker sans considérer si les exécuteurs shell ou Kubernetes seraient plus efficaces pour leur charge de travail.

Comment l'éviter : Évaluez vos types de tâches. Pour des scripts simples, l'exécuteur shell peut être plus rapide en raison de l'absence de surcharge de conteneur. Pour des environnements complexes, Docker offre l'isolation. L'exécuteur Kubernetes offre une mise à l'échelle dynamique mais ajoute de la complexité.

Récupération : Si les tâches sont lentes en raison de la surcharge de l'exécuteur, envisagez de changer le type d'exécuteur pour un sous-ensemble de runners et de baliser les tâches en conséquence.

Piège 4 : négliger l'espace disque

Pourquoi cela arrive : Les builds Docker et les caches s'accumulent au fil du temps, remplissant les disques des runners. Cela entraîne l'échec des tâches avec « no space left on device ».

Comment l'éviter : Planifiez un nettoyage régulier via cron ou utilisez les politiques de nettoyage de GitLab pour le registre de conteneurs. Configurez des alertes d'utilisation du disque.

Récupération : Élaguez manuellement les ressources Docker :

docker system prune -a --volumes

Piège 5 : coder en dur les balises des runners sans stratégie

Pourquoi cela arrive : Les équipes ajoutent des balises ad hoc, ce qui entraîne une confusion dans l'acheminement des tâches et des runners sous-utilisés.

Comment l'éviter : Définissez une stratégie de balisage dès le départ. Par exemple, utilisez des balises comme small, medium, heavy en fonction des besoins en ressources. Documentez le mappage.

Récupération : Auditez les balises existantes et consolidez. Mettez à jour les fichiers .gitlab-ci.yml pour les aligner sur la nouvelle stratégie.

Modes de défaillance et récupération

Même avec une planification minutieuse, des problèmes peuvent survenir. Cette section décrit les modes de défaillance courants dans la capacité CI/CD de GitLab et comment s'en remettre.

Surcharge du runner et échecs de tâches

Symptôme : Les tâches échouent avec des erreurs telles que « no space left on device » ou « connection refused » lors du démarrage des conteneurs. L'hôte du runner peut être à court d'espace disque ou de mémoire.

Diagnostic : Vérifiez l'espace disque avec df -h et la mémoire avec free -h. Si le disque est plein, nettoyez les images et volumes Docker :

docker system prune -a --volumes

Récupération : Réduisez temporairement concurrent, ajoutez de l'espace disque ou déplacez le cache du runner vers un volume plus grand. Assurez-vous de surveiller par la suite.

Service runner non réactif

Symptôme : Les tâches restent en attente et le runner ne les récupère pas. gitlab-runner status indique que le service n'est pas en cours d'exécution.

Diagnostic : Vérifiez les journaux du runner pour les raisons du plantage. Redémarrez le service :

sudo gitlab-runner restart

Récupération : Si le runner ne démarre pas, vérifiez la syntaxe du fichier de configuration avec gitlab-runner verify. Recherchez des mauvaises configurations comme un TOML invalide ou des paramètres d'exécuteur incorrects. Revenez à une configuration connue et fonctionnelle si nécessaire.

Échecs d'autoscaling (runners cloud)

Si vous utilisez l'autoscaling (par exemple, avec des instances AWS Spot), les instances peuvent être terminées de manière inattendue, provoquant des échecs de tâches.

Symptôme : Les tâches échouent avec « runner system failure » ou « job aborted ».

Diagnostic : Vérifiez la configuration d'autoscaling du runner et les journaux du fournisseur cloud. Assurez-vous d'avoir une capacité de secours avec des instances à la demande.

Récupération : Ajustez les paramètres de l'autoscaler pour maintenir un nombre minimum d'instances. Testez avec une tâche simple pour confirmer la stabilité.

Problèmes réseau entre GitLab et les runners

Symptôme : Les runners perdent la connexion à GitLab, entraînant des tâches bloquées.

Diagnostic : Depuis l'hôte du runner, testez la connectivité :

curl -I https://gitlab.example.com

Si cela échoue, vérifiez les règles de pare-feu et le routage réseau.

Récupération : Assurez-vous que le HTTPS sortant est autorisé. Si vous êtes derrière un proxy, configurez le runner en conséquence.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle comme guide reproductible pour la gestion continue de la capacité. Attribuez un responsable unique pour chaque élément et définissez une fréquence d'examen.

Élément de la liste	Description	Responsable	Fréquence
Inventaire	Mettez régulièrement à jour l'inventaire des runners et des projets. Enregistrez les spécifications des runners, les types d'exécuteurs et la concurrence actuelle.	Ingénieur DevOps	Mensuelle
Surveiller la profondeur de la file d'attente	Configurez des alertes pour un nombre élevé de tâches en attente. Utilisez l'API GitLab ou les métriques Prometheus.	Ingénieur fiabilité du site	Examen hebdomadaire
Examiner l'utilisation des ressources	Vérifiez le CPU, la mémoire et le disque sur les hôtes des runners. Utilisez `docker stats` ou des moniteurs système.	Ingénieur DevOps	Hebdomadaire
Analyser les tendances des pipelines	Examinez la durée des pipelines et les temps d'attente. Identifiez les projets avec une utilisation CI de pointe.	Responsable ingénierie	Mensuelle
Planifier la croissance	Estimez la demande à venir en fonction de la croissance de l'équipe ou des nouveaux projets. Testez la capacité avec une charge simulée si possible.	Responsable plateforme	Trimestrielle
Tester les procédures de récupération	Pratiquez périodiquement le retour en arrière des modifications de configuration du runner ou la récupération après une défaillance du runner.	Ingénieur DevOps	Semestrielle
Maintenir les logiciels à jour	Mettez à jour GitLab Runner et GitLab lui-même régulièrement pour bénéficier des améliorations de performances et des corrections de bugs.	Administrateur système	Mensuelle
Documenter les modifications	Tenez un journal des modifications de configuration des runners, y compris les ajustements de concurrence et les ajouts de nouveaux runners.	Ingénieur DevOps	Continue

Chaque responsable doit documenter ses conclusions d'examen et suivre les éléments d'action. Par exemple, l'ingénieur DevOps pourrait noter que l'utilisation du disque du runner a atteint 80 % le 15/06/2023 et planifier un nettoyage pour la semaine suivante.

Conclusion

La planification des capacités pour la CI/CD de GitLab est une pratique essentielle pour maintenir une livraison logicielle rapide et fiable. En adoptant une approche systématique, vous pouvez éviter les pièges courants tels que la surcharge des runners, le gaspillage de ressources et le retard des retours aux développeurs.

Dans ce guide, vous avez appris à inventorier votre environnement actuel, à configurer les runners en toute sécurité, à vérifier la capacité avec des diagnostics concrets, à récupérer après des défaillances et à maintenir une liste de contrôle opérationnelle. Le point clé à retenir est de commencer petit : choisissez un pilote étroit, mesurez l'impact et étendez progressivement. Surveillez en permanence vos pipelines et ajustez à mesure que votre équipe se développe.

Pour les prochaines étapes, envisagez de mettre en place une surveillance automatisée de la santé des runners et des files d'attente de tâches, d'explorer les options d'autoscaling si vous êtes sur une plateforme cloud, et d'examiner régulièrement vos analyses CI/CD. Avec ces pratiques, vous pouvez maintenir votre infrastructure CI/CD GitLab fluide et vous concentrer sur la fourniture de valeur à vos utilisateurs.