Planification de la capacité des runners GitLab avec des exemples pratiques

Introduction

GitLab Runner est le moteur de GitLab CI/CD, exécutant les tâches définies dans vos pipelines. À mesure que votre équipe et le nombre de projets augmentent, un seul runner devient rapidement un goulot d'étranglement : les files d'attente s'allongent, les pipelines expirent et les développeurs attendent. La planification de la capacité consiste à déterminer combien de runners, de quelle taille et dans quelle configuration vous avez besoin pour atteindre vos objectifs de débit et de latence sans gaspiller de ressources.

Cet article fournit un guide pratique de planification de la capacité des runners GitLab avec des exemples concrets. Vous apprendrez à inventorier votre environnement actuel, estimer les besoins en ressources, choisir des options de configuration sécuritaires, vérifier les performances, gérer les pannes et maintenir une liste de contrôle opérationnelle. À la fin, vous disposerez d'une méthode reproductible pour dimensionner votre parc de runners et éviter les pièges courants de mise à l'échelle.

Inventaire des versions et de l'environnement

Avant de planifier la capacité, vous devez savoir ce que vous avez. Cette section explique comment inventorier la version de votre GitLab Runner, la topologie et les prérequis.

Version de GitLab Runner

Commencez par vérifier la version du runner sur chaque hôte. Utilisez la commande suivante sur la machine du runner :

gitlab-runner --version

Sortie attendue :

Version : 15.9.0

Notez la version ; des fonctionnalités comme ff_use_direct_download ou la mise à l'échelle automatique docker+machine peuvent varier. Les différentes versions ont des capacités différentes, il est donc important de connaître la version exacte pour planifier les mises à niveau ou le dépannage.

Aperçu de la topologie

Documentez minutieusement la topologie de vos runners. Cela comprend :

• Types de runners : runners partagés, de groupe ou spécifiques à un projet.
• Exécuteurs : Shell, Docker, Kubernetes, etc.
• Types d'hôtes : machines physiques, virtuelles ou instances cloud.
• Emplacement réseau : sur site ou dans le cloud.

Un tableau d'inventaire vous aide à comprendre votre capacité actuelle. Voici un exemple pour une organisation de taille moyenne typique :

Dans cet exemple, les runners Docker partagés gèrent les charges de travail générales, tandis que le runner Kubernetes est dédié à un projet spécifique avec des besoins de débit plus élevés.

Prérequis pour la planification de la capacité

Vous aurez besoin des éléments suivants avant de pouvoir planifier efficacement la capacité :

• Accès aux fichiers de configuration des runners (config.toml) et à la zone d'administration GitLab.
• Surveillance des hôtes des runners : métriques CPU, mémoire, E/S disque.
• Données historiques des tâches de GitLab : durée des pipelines, temps d'attente des tâches.
• Compréhension des caractéristiques des ressources de vos tâches CI : sont-elles intensives en CPU, en E/S ou gourmandes en mémoire ?

Sans ces données, toute planification de capacité n'est que conjecture. Par exemple, si vous ne savez pas que votre suite de tests est intensive en E/S, vous risquez de surprovisionner le CPU et d'avoir quand même des tâches lentes.

Identification des goulots d'étranglement

Utilisez l'interface utilisateur ou l'API de GitLab pour vérifier l'utilisation actuelle des runners. Par exemple, listez tous les runners et leur statut :

curl --header "PRIVATE-TOKEN: <votre_token>" "https://gitlab.example.com/api/v4/runners/all"

La réponse JSON inclut des champs comme online, status et maximum_timeout. Recherchez les runners qui sont toujours occupés ou les tâches qui attendent longtemps en état « en attente ». Un runner constamment à sa limite de concurrence avec un arriéré de tâches en attente est un goulot d'étranglement évident.

Estimation des besoins en ressources

Une fois l'inventaire établi, vous pouvez estimer la capacité nécessaire. Cela implique de comprendre votre charge de travail et de la traduire en spécifications de runner.

Caractérisation de vos types de tâches

Différentes tâches ont des profils de ressources différents. Commencez par catégoriser vos tâches de pipeline typiques :

• Tâches de compilation : souvent intensives en CPU, comme la compilation de code ou la construction d'images Docker.
• Tâches de test : peuvent être intensives en CPU ou en mémoire selon le cadre de test et l'environnement.
• Tâches de déploiement : généralement légères en ressources mais peuvent nécessiter des outils spécifiques ou un accès réseau.

Pour chaque catégorie, mesurez la durée moyenne et la consommation de ressources. Vous pouvez le faire en exécutant une tâche représentative et en la surveillant avec des outils comme htop ou Prometheus. Par exemple, une tâche de compilation typique peut prendre 5 minutes et utiliser 2 cœurs CPU et 4 Go de mémoire au pic.

Calcul des besoins en débit

Déterminez le nombre de tâches que vous devez exécuter par minute pendant les périodes de pointe. C'est votre débit cible. Par exemple, si votre équipe exécute 200 pipelines par jour, avec une moyenne de 3 tâches par pipeline, cela fait 600 tâches par jour. En supposant une journée de travail de 8 heures avec un pic à 2 fois la moyenne, le débit de pointe est d'environ 3,75 tâches par minute. Pour gérer les pics, prévoyez au moins 5 tâches par minute.

Ensuite, calculez le nombre de tâches simultanées nécessaires. Si une tâche prend en moyenne 5 minutes, pour soutenir 5 tâches par minute, vous devez exécuter 25 tâches simultanément (5 tâches/min x 5 min = 25 tâches simultanées). Ce calcul est simplifié ; en réalité, les durées des tâches varient, donc ajoutez une marge.

Dimensionnement des runners

Avec le nombre de tâches simultanées, vous pouvez dimensionner votre parc de runners. Un runner unique a une limite concurrent, qui est le nombre de tâches qu'il peut exécuter simultanément. Pour l'exécuteur Docker, cette limite est contrainte par les ressources de l'hôte : cœurs CPU, mémoire et E/S disque.

Une règle empirique courante : concurrent = nombre de cœurs CPU - 1 (laissez un cœur pour le système d'exploitation hôte et le démon Docker). Pour la mémoire, allouez au moins 512 Mo par tâche plus une marge, donc un hôte avec 16 Go de RAM pourrait exécuter environ 12 tâches (16 Go / 1,5 Go par tâche ≈ 10, laissez de la place pour l'hôte).

Par exemple, si vous avez besoin de 25 tâches simultanées, vous pourriez avoir trois machines virtuelles à 8 cœurs, chacune avec concurrent = 7, ce qui donne 21 tâches simultanées, plus un runner Kubernetes pour le surplus. Ou vous pourriez utiliser des machines plus grandes avec plus de cœurs.

Considérer les pics par rapport à la moyenne

La planification de la capacité doit se concentrer sur l'utilisation de pointe, pas sur la moyenne. Si votre équipe a un jour de déploiement ou une version mensuelle, vous verrez des pics. Planifiez pour le 95e centile de la charge, pas la moyenne. Surveillez votre instance GitLab pendant quelques semaines pour identifier les modèles. Par exemple, si la charge double chaque lundi matin en raison des commits du week-end, dimensionnez pour ce pic.

Chemin de configuration sécuritaire

La planification de la capacité implique d'apporter des modifications de configuration qui peuvent avoir un impact sur l'ensemble de votre système CI. Suivez une approche sécuritaire et incrémentale.

Commencer par une base de référence

Avant de passer à l'échelle, établissez une base de référence des performances. Exécutez une tâche représentative plusieurs fois et enregistrez les durées. Par exemple, une tâche de compilation typique peut prendre 5 minutes. Mesurez le temps d'attente : si les tâches attendent 10 minutes, votre temps total de pipeline est de 15 minutes, ce qui indique un problème de capacité. Cette base de référence vous aide à évaluer l'impact des changements.

Utiliser le bon exécuteur

Choisissez un exécuteur adapté à votre charge de travail et à votre infrastructure :

• Exécuteur Shell : simple, mais les tâches s'exécutent sur l'hôte, ce qui risque de créer des conflits de ressources et des problèmes de sécurité. Idéal pour les tâches légères ou lorsque vous avez besoin d'un accès direct à l'hôte.
• Exécuteur Docker : isole les tâches dans des conteneurs, offrant des environnements cohérents. Ajoute une certaine surcharge mais est le choix le plus courant pour le CI général.
• Exécuteur Kubernetes : mise à l'échelle dynamique, idéal pour les configurations cloud natives, mais complexe à régler. Idéal pour les charges de travail importantes et fluctuantes.

Pour la plupart des équipes, l'exécuteur Docker sur des machines virtuelles dédiées est un choix sûr par défaut. Il équilibre l'isolation, les performances et la facilité de gestion.

Paramètres de concurrence

Le paramètre concurrent dans config.toml contrôle le nombre de tâches qu'un runner peut exécuter simultanément. Réglez-le en fonction du CPU et de la mémoire disponibles. Une règle empirique : concurrent = nombre de cœurs CPU - 1 pour les tâches liées au CPU, mais ajustez en fonction de la mémoire. Par exemple, sur une machine virtuelle à 4 cœurs avec 8 Go de RAM, vous pouvez définir concurrent = 3 pour laisser une marge.

Exemple d'extrait de config.toml :

concurrent = 3
check_interval = 0

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

Ajustez concurrent progressivement. Surveillez l'utilisation des ressources après chaque changement. Par exemple, passez de 3 à 4, attendez un jour et vérifiez la saturation du CPU et de la mémoire.

Limites de ressources

Définissez des limites de ressources par tâche pour empêcher une seule tâche de consommer toutes les ressources de l'hôte. Pour l'exécuteur Docker, vous pouvez définir memory et cpus dans la configuration du runner ou dans les définitions de tâches. Pour l'exécuteur Kubernetes, utilisez des demandes et des limites de ressources. Exemple de limites au niveau de la tâche pour Kubernetes :

job:
  variables:
    KUBERNETES_CPU_REQUEST: "500m"
    KUBERNETES_MEMORY_REQUEST: "512Mi"
    KUBERNETES_CPU_LIMIT: "1"
    KUBERNETES_MEMORY_LIMIT: "1Gi"

Cela empêche la famine des ressources et améliore la stabilité. Définissez les limites en fonction de vos besoins mesurés en ressources, avec une certaine marge.

Mise à l'échelle automatique

Pour les charges de travail variables, envisagez la mise à l'échelle automatique. GitLab Runner offre plusieurs options :

• docker+machine (obsolète) : utilise Docker Machine pour créer et détruire des machines virtuelles à la demande.
• Exécuteur docker-autoscaler : l'approche plus récente et recommandée pour les fournisseurs cloud.
• Exécuteur Kubernetes avec autoscaler de cluster : met à l'échelle les pods et les nœuds automatiquement.

La mise à l'échelle automatique aide à gérer les coûts mais nécessite un réglage minutieux pour éviter le sous-provisionnement pendant les pics. Par exemple, définissez un nombre minimum de runners inactifs pour gérer les rafales soudaines et configurez des délais de réduction d'échelle pour éviter les oscillations.

Projet pilote limité

Avant de déployer des changements à l'échelle mondiale, testez sur un seul runner ou projet. Utilisez un runner séparé enregistré avec un nouveau jeton et limitez-le à un projet de test. Surveillez le projet pilote pendant au moins une semaine avant de l'étendre. Par exemple, créez un nouveau runner avec concurrent = 2 et affectez-le uniquement à un projet à faible trafic. Observez ses performances par rapport à votre base de référence.

Vérification et diagnostics

Après avoir mis en œuvre les changements de capacité, vérifiez qu'ils fonctionnent et diagnostiquez tout problème.

Vérifier l'état du runner

Utilisez l'interface utilisateur ou l'API de GitLab pour confirmer que les runners sont en ligne et acceptent des tâches. Exemple de commande :

curl --header "PRIVATE-TOKEN: <votre_token>" "https://gitlab.example.com/api/v4/runners/all?scope=active"

Attendu : une liste de runners avec online: true et status: "online". Si un runner est hors ligne, vérifiez ses journaux et l'état de l'hôte.

Surveiller les temps d'attente

Suivez le temps que les tâches attendent en état « en attente ». Vous pouvez interroger l'API GitLab pour les durées de pipeline, ou utiliser les métriques Prometheus si elles sont activées. Un système sain devrait avoir un temps d'attente moyen inférieur à 1 minute. Par exemple, si vous voyez des temps d'attente moyens de 5 minutes, vous avez besoin de plus de capacité.

Utilisation des ressources

Sur les hôtes des runners, surveillez le CPU et la mémoire. Utilisez des outils comme htop, vmstat ou l'exportateur de nœuds Prometheus. Exemple de sortie de vmstat :

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 2048576 123456 345678    0    0    10    20  100  200 20  5 70  5  0

Si us (CPU utilisateur) est constamment supérieur à 80 %, vous avez besoin de plus de runners ou d'une concurrence plus élevée.

Tester l'exécution des tâches

Créez une tâche de test simple qui affiche l'utilisation des ressources dans le conteneur. Pour l'exécuteur Docker, vous pouvez exécuter :

test:
  script:
    - nproc
    - free -h
    - cat /proc/cpuinfo | grep "cpu cores"

La sortie attendue montre les ressources allouées, par exemple, nproc renvoie 1 si vous avez défini cpus=1. Cela vérifie que les limites de ressources sont correctement appliquées.

Journaux et événements

Vérifiez les journaux du runner pour les erreurs. Sur les systèmes avec systemd :

sudo journalctl -u gitlab-runner -f

Recherchez les avertissements concernant les délais d'expiration des tâches, l'espace disque ou les problèmes réseau. Par exemple, des messages comme ERROR: Job failed (system failure): preparing environment: context canceled peuvent indiquer un épuisement des ressources.

Modes de défaillance et récupération

Malgré la planification, des problèmes de capacité peuvent survenir. Soyez prêt à les gérer.

Modes de défaillance courants

• Épuisement des ressources : l'hôte manque de CPU ou de mémoire, ce qui fait échouer ou ralentir les tâches. Cela se produit souvent lorsque la concurrence est réglée trop haut pour les ressources de l'hôte.
• Disque plein : le disque de l'hôte du runner se remplit d'artefacts de tâches ou d'images Docker, empêchant de nouvelles tâches. Les images Docker peuvent s'accumuler rapidement si elles ne sont pas nettoyées régulièrement.
• Saturation du réseau : trop de tâches simultanées submergent la bande passante réseau, provoquant des échecs de pipeline, en particulier pour les tâches qui téléchargent de grosses dépendances.
• Accumulation de files d'attente : un pic soudain de tâches entraîne de longs temps d'attente et des délais d'expiration. Cela peut se répercuter si les tâches ont des délais stricts.
• Retard de mise à l'échelle automatique : l'autoscaler ne peut pas provisionner les ressources assez rapidement, entraînant des échecs de tâches, en particulier dans les environnements cloud avec des temps de démarrage d'instance lents.

Procédures de retour en arrière

Si un changement de configuration provoque une instabilité, revenez à la configuration précédente connue comme bonne. Conservez des sauvegardes de config.toml avant les changements. Exemple :

cp /etc/gitlab-runner/config.toml /etc/gitlab-runner/config.toml.bak

Après le retour en arrière, redémarrez le runner :

sudo gitlab-runner restart

Par exemple, si vous avez augmenté concurrent de 4 à 8 et commencé à voir des problèmes de mémoire, revenez à 4 et redémarrez.

Vérifications de récupération

Après avoir récupéré d'une défaillance, vérifiez :

• Les runners sont en ligne et les tâches s'exécutent.
• Les temps d'attente sont revenus à des niveaux acceptables.
• L'utilisation des ressources est dans des marges sûres.
• Aucune perte de données ou artefact corrompu.

Marge de capacité

Maintenez toujours une marge de capacité (par exemple, 20 % de capacité disponible) pour absorber les charges soudaines. Cela évite les défaillances en cascade pendant les pics de trafic. Par exemple, si votre demande de pointe est de 25 tâches simultanées, provisionnez pour 30 afin de gérer les rafales inattendues.

Pièges courants et comment les éviter

La planification de la capacité est pleine de pièges subtils. Voici les erreurs les plus courantes et comment les éviter.

Surestimer ou sous-estimer la concurrence

Piège : Régler concurrent trop haut entraîne des conflits de ressources et des échecs de tâches ; le régler trop bas gaspille des ressources et provoque de longues files d'attente.

Pourquoi cela arrive : Les planificateurs utilisent souvent une règle empirique simple sans tenir compte de l'utilisation réelle des ressources par type de tâche ou de la capacité de l'hôte.

Comment éviter : Mesurez la consommation réelle de ressources par type de tâche. Utilisez la surveillance pour déterminer la concurrence maximale durable sur un hôte donné. Commencez prudemment et augmentez progressivement.

Récupération : Si vous avez surprovisionné, réduisez concurrent et redémarrez. Si vous avez sous-provisionné, ajoutez des runners ou augmentez la concurrence avec des ressources hôtes adéquates.

Ignorer la variabilité de la charge de pointe

Piège : Dimensionner pour la charge moyenne entraîne de mauvaises performances pendant les pics.

Pourquoi cela arrive : Les équipes regardent les moyennes quotidiennes ou hebdomadaires et manquent les pics périodiques.

Comment éviter : Analysez les données historiques des tâches pour identifier les périodes de pointe (jours de déploiement, fin de sprint, etc.). Planifiez pour le 95e centile de la charge.

Récupération : Mettez en œuvre la mise à l'échelle automatique pour gérer les pics, ou ajoutez manuellement des runners temporaires avant les événements à forte charge connus.

Ne pas définir de limites de ressources

Piège : Une seule tâche consomme des ressources excessives, affamant les autres tâches sur le même runner.

Pourquoi cela arrive : Les configurations par défaut n'ont souvent aucune limite, et les développeurs peuvent ne pas être conscients des besoins en ressources de leur tâche.

Comment éviter : Définissez des limites de ressources dans la configuration du runner ou les définitions de tâches. Formez les équipes à l'estimation des besoins en ressources.

Récupération : Ajoutez des limites aux nouvelles tâches immédiatement. Pour les tâches existantes, appliquez progressivement des limites basées sur l'utilisation mesurée pour éviter de les casser.

Négliger le nettoyage du disque

Piège : Les disques des runners se remplissent de vieilles images Docker et d'artefacts de tâches, provoquant des échecs.

Pourquoi cela arrive : Les images Docker s'accumulent à chaque pipeline, et les scripts de nettoyage sont souvent absents.

Comment éviter : Planifiez un nettoyage régulier des images Docker inutilisées et des anciens artefacts. Pour l'exécuteur Docker, utilisez docker system prune -f chaque semaine ou configurez une tâche cron.

Récupération : Si le disque est plein, supprimez manuellement les images et les artefacts, puis mettez en œuvre une politique de nettoyage.

Ne pas surveiller de manière proactive

Piège : Les problèmes ne sont détectés qu'après les plaintes des utilisateurs ou les échecs de pipeline.

Pourquoi cela arrive : Les équipes manquent de surveillance ou d'alertes appropriées, ou elles ignorent les signes avant-coureurs.

Comment éviter : Configurez des tableaux de bord de surveillance pour les hôtes des runners et les métriques GitLab. Configurez des alertes pour les temps d'attente élevés, l'utilisation du CPU et l'espace disque.

Récupération : Mettez en œuvre la surveillance rétroactivement. Commencez par des vérifications de base comme le temps d'attente et l'état du runner, puis élargissez.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour la gestion continue de la capacité. Chaque élément doit avoir un propriétaire désigné et une fréquence de révision pour garantir la responsabilité.

Vérifications quotidiennes

• Surveiller l'état des runners et la longueur des files d'attente : Vérifiez l'interface utilisateur de GitLab pour tout runner hors ligne ou tâche bloquée en attente. Propriétaire : Ingénieur CI/CD. Fréquence : Quotidienne.
• Vérifier l'espace disque sur les hôtes des runners : Assurez-vous que l'utilisation est sous le seuil. Propriétaire : Administrateur système. Fréquence : Quotidienne.
• Examiner les taux d'échec des tâches CI : Recherchez des pics d'échecs. Propriétaire : Responsable DevOps. Fréquence : Quotidienne.

Vérifications hebdomadaires

• Examiner la durée moyenne des tâches et les tendances des temps d'attente : Identifiez toute tendance à la hausse. Propriétaire : Ingénieur CI/CD. Fréquence : Hebdomadaire.
• Vérifier l'utilisation des ressources (CPU, mémoire) au cours de la semaine : Comparez avec les bases de référence. Propriétaire : Administrateur système. Fréquence : Hebdomadaire.
• Identifier les tâches consommant des ressources excessives : Signalez-les pour optimisation. Propriétaire : Responsable DevOps. Fréquence : Hebdomadaire.

Vérifications mensuelles

• Réévaluer les besoins en capacité en fonction de la croissance des projets : Examinez les tendances du nombre de pipelines. Propriétaire : Directeur d'ingénierie. Fréquence : Mensuelle.
• Tester la configuration de mise à l'échelle automatique le cas échéant : Assurez-vous que la montée et la descente en charge fonctionnent correctement. Propriétaire : Ingénieur CI/CD. Fréquence : Mensuelle.
• Mettre à jour la version du runner si nécessaire : Vérifiez les correctifs de sécurité et les améliorations de fonctionnalités. Propriétaire : Responsable DevOps. Fréquence : Mensuelle.

Ajustements proactifs

• Ajoutez des runners lorsque le temps d'attente moyen dépasse 2 minutes.
• Augmentez la concurrence lorsque l'utilisation du CPU dépasse constamment 70 %.
• Ajoutez de l'espace disque lorsque l'utilisation dépasse 80 %.
• Examinez les marges de sécurité pendant les périodes de pointe, surtout avant les événements à forte charge connus comme les versions.

Conclusion

La planification de la capacité des runners GitLab est essentielle pour maintenir des pipelines CI/CD rapides et fiables. En inventoriant votre environnement, en configurant les runners de manière sécuritaire, en surveillant les performances et en vous préparant aux pannes, vous pouvez vous assurer que la productivité de votre équipe reste élevée. Commencez par une base de référence, apportez des modifications progressives et gardez toujours une marge de capacité. Mettez en œuvre la liste de contrôle opérationnelle avec des propriétaires clairs et des fréquences de révision pour rester en avance sur la croissance. Avec ces pratiques, vous pouvez faire évoluer efficacement votre parc de GitLab Runner et éviter des temps d'arrêt coûteux.

Révisez régulièrement votre plan de capacité, au moins mensuellement, pour tenir compte de la croissance de l'équipe, des nouveaux projets et des charges de travail changeantes. N'oubliez pas que la planification de la capacité n'est pas une tâche ponctuelle mais un processus continu de mesure et d'ajustement.