Optimisation GoCD – crochets Web de type push pour la planification des pipelines
Notre dernier article de blog GoCD a examiné notre parcours avec GoCD depuis 2012. Aujourd’hui, nous partageons notre travail d’optimisation GoCD, expliquant comment nous avons amélioré les webhooks de style push pour la planification des pipelines.
L’équipe d’infrastructure cloud de Catalyst travaille avec GoCD jour après jour. À ce jour, nous avons créé 535 pipelines.
Explorez les services gérés par Catalyst
Comment fonctionnent les webhooks de type push pour la planification des pipelines
La plupart des pipelines créés par l’équipe Catalyst ont été créés avec deux référentiels Git qui leur sont associés : un pour le code principal et l’autre pour le projet en amont. Cela nous permet de fusionner automatiquement les correctifs de sécurité.
Par défaut, le serveur GoCD interroge les deux référentiels Git à la recherche de modifications, pour décider si une nouvelle construction de pipeline doit être démarrée. Cette approche par sondage conduit à :
• Utilisation continue élevée du processeur sur le serveur GoCD ;
• Trafic de paiement Git continu de Gitlab vers GoCD, et ;
• Temps d’attente potentiellement longs entre une poussée de code des développeurs et le démarrage du pipeline.
Crochets système
Gitlab a la possibilité de déclencher une requête HTTP pour chaque événement push Git. Ces requêtes contiennent une charge utile JSON, détaillant ce qui a changé. Vous pouvez trouver plus d’informations ici: https://docs.gitlab.com/ee/administration/system_hooks.html
L’objet JSON contient deux informations dont nous avons besoin :
• L’URL Git, et ;
• Détails de la branche vers laquelle le commit a été poussé.
API GoCD
Le serveur d’API GoCD dispose d’une API qui peut être utilisée pour déclencher un pipeline. Vous pouvez trouver les détails sur cette page: https://api.gocd.org/current/#scheduling-pipelines
Les hooks système générés par Gitlab ne sont pas compatibles avec l’API GoCD.
La solution d’optimisation – middleware
L’équipe Catalyst a écrit une application Python pour surmonter les défis du processus existant : La solution :
• Maintient un cache de tous les pipelines et de leurs matériaux et branches Git associés ;
• Reçoit les événements de hooks du système Gitlab ;
• Recherche les bons pipelines pour faire correspondre les matériaux et les pipelines ;
• Planifie l’exécution des pipelines selon les besoins. Effectuera plusieurs appels d’API à GoCD si un référentiel Git est utilisé sur plusieurs pipelines, et ;
• Actualise le cache de pipeline interne chaque fois que le référentiel qui définit les pipelines est modifié.
La différence que la solution a fait
Utilisation réduite du processeur sur le serveur GoCD
L’utilisation du processeur sur le serveur GoCD a chuté massivement dès que l’interrogation sur les pipelines internes a été désactivée. À l’avenir, il est probable que nous apporterons de nouvelles améliorations à mesure que nous passerons davantage de référentiels externes aux nouvelles notifications de type push.
Trafic réseau plus léger de GitLab
Le trafic réseau de GitLab a montré une forte baisse, la charge de base constamment élevée de 8 Go/heure qui était auparavant nécessaire, n’est plus nécessaire.
Temps de réponse GoCD améliorés
Par défaut, l’interrogation GoCD des matériaux se produit toutes les minutes, avec un maximum de dix matériaux à la fois. En pratique, cela signifie que les développeurs peuvent attendre jusqu’à cinq minutes pour qu’un pipeline démarre après une modification de Git. Avec le nouveau processus en place, cela ne prend plus que quelques secondes.
Économies de coûts
La nouvelle solution a permis de réaliser un certain nombre d’économies, telles que :
- Le serveur GoCD et les serveurs Gitlab s’exécutent désormais sur des instances AWS plus petites ;
- Le trafic du serveur Gitlab vers GoCD est considérablement en baisse, ce qui signifie qu’il y a une réduction significative du trafic inter-AZ ;
- Le serveur GocCD a besoin de moins d’espace disque interne pour mettre en cache les pipelines exécutés peu fréquemment, ce qui signifie des volumes EBS plus petits, et ;
- Les développeurs passent moins de temps à attendre les pipelines.
Innovation dans les services gérés
Cette initiative est un excellent exemple du travail fourni par l’équipe Catalyst pour garantir que notre infrastructure cloud est optimisée, leader du secteur et rentable. Fournir et maintenir des solutions de haute performance pour nos clients multirégionaux au niveau de l’entreprise est notre responsabilité et à l’avant-garde de tout ce que nous faisons.
Découvrez notre étude de cas client
Explore our client case study
En savoir plus sur les services gérés de Catalyst
Si vous souhaitez explorer nos options de services gérés et découvrir comment nous prenons en charge d’autres clients au niveau de l’entreprise, nous aimerions avoir de vos nouvelles.