zorandim75 - Fotolia

CloudBees veut renforcer les pipelines Jenkins

S’il lance sa plateforme SaaS, le spécialiste de la CI/CD ne compte pas laisser sur le carreau les clients de CloudBees CI. Il lance un mode haute disponibilité pour sécuriser les fonctionnements des pipelines Jenkins.

C’est parce que les pipelines Jenkins sont en croissance que l’éditeur a annoncé un mode haute disponibilité pour l’édition moderne de Cloudbees CI, accessible à partir du 20 septembre. « Nous avions des systèmes de reprise en cas d’échec, mais nous faisions face à deux problèmes », décrit Sacha Labourey, Chief Strategy Officer et cofondateur de CloudBees. La haute disponibilité était active/passive et il y avait la crainte de faire tomber les serveurs d’automatisation.

Load balancer, Kubernetes et déploiement actif-actif

Le nouveau mode HA repose sur une architecture distribuée, qui couple un répartiteur de charge et un système de déploiement actif-actif automatique.

Au lieu d’avoir un seul contrôleur, celui-ci est automatiquement répliqué en fonction de la charge réseau. Le load balancer répartit le trafic entre les contrôleurs. Si le trafic chute, les réplicas, qui ne sont que des pods Kubernetes, sont dépréciés par le système. Le contrôleur et les réplicas apparaissent aux yeux des développeurs comme une seule couche logique. Ces contrôleurs répliqués ont les mêmes données et elles ne sont pas divisées entre contrôleurs, selon CloudBees.

Chaque pod contient un nœud de la librairie open source Hazelcast, une base de données in-memory massivement parallèle. Celle-ci est utilisée pour synchroniser les réplicas. « Elle utilise un Bus pour publier et écouter les événements afin de synchroniser les structures de données entre les réplicas. Par exemple, si le réplica 1 exécute un job et qu’il est mis hors service, les agents seront automatiquement repris par le réplica 2 », explique CloudBees dans sa documentation.

« Non seulement il y a une meilleure tolérance aux pannes, mais cela apporte une montée à l’échelle horizontale. Si l’on avait 5 000 pipelines associés à un seul contrôleur, désormais ces mêmes pipelines peuvent être répartis sur dix contrôleurs », illustre Sacha Labourey.

« Au moment de pousser une nouvelle version en production sur un cluster, il est possible de déployer les nœuds progressivement. Si cela ne fonctionne pas, il convient de revenir à un état antérieur », avance-t-il.

Jusqu’à présent, l’éditeur conseillait aux entreprises de séparer leurs pipelines par groupe et par équipe afin de simplifier leur gestion. « Séparer la charge sur plusieurs contrôleurs demeure une bonne approche, surtout si vous utilisez beaucoup de plug-ins », insiste Sacha Labourey.

La difficulté ne réside pas forcément dans le fonctionnement du moteur, mais sur la pluralité des plug-ins pour compléter les pipelines associés à un cluster.

« C’est la richesse et en même temps la faiblesse de Jenkins. Ces plug-ins sont chargés au même titre que le cœur de Jenkins, mais s’il y a des instabilités, ils peuvent chuter [avec le cluster] », affirme le CSO.

Il faut dire que ces plug-ins, plus de 1 800 au total, sont à la fois développés par la communauté et les éditeurs des solutions qui interagissent avec Jenkins. « Nous maintenons une liste de 200 plug-ins certifiés, que nous testons régulièrement. »

Les plug-ins ont leur propre cycle de vie et ils ne sont pas testés ensemble.

Des fonctionnalités pour éviter la corruption des builds et des pipelines

CloudBees HA intègre trois fonctionnalités supplémentaires : Workspace Caching, Pipeline Explorer et Build Storm Prevention.

Workspace Caching doit régler un problème assez simple. « Une fois qu’un build de conteneur est exécuté, c’est terminé et on nettoie tout. C’est justement le problème. Il y a beaucoup de perte de contexte ».

Selon le CSO, beaucoup d’artefacts peuvent être réutilisés de manière sécurisée sans qu’il y ait le risque de corrompre les builds. « En gérant proprement ces aspects dans le cloud, l’on peut obtenir des gains de temps très importants ».

L’éditeur a donc décidé d’implémenter une couche qui met en cache des éléments persistants utiles pour plusieurs builds sur S3. Après avoir configuré la clé IAM AWS et le bucket S3, il est possible, à l’aide des étapes de pipelines writeCache et readCache, de conserver les éléments de paquets Maven, NPM, Gradle, etc. Ces éléments sont liés à un pipeline, des informations que l’on peut retrouver dans les métadonnées associées à un bucket S3. 

« [Workspace Caching] est utile pour les builds exécutées sur des agents cloud qui démarrent avec des caches d’outils vides, ou lorsque les builds impliquent des fichiers temporaires qui prennent beaucoup plus de temps à générer qu’ils n’en prennent à télécharger », selon la documentation de l’éditeur.

Pipeline Explorer permet d’analyser le résultat d’exécution d’un pipeline à l’aide d’une interface utilisateur. « Aujourd’hui, l’on se retrouve face à un gros fichier de logs, ce n’est pas structuré », affirme Sacha Labourey. « L’interface permet d’accéder aux étapes d’exécution parallèle, d’effectuer des recherches rapides, et de partager des portions de fichiers avec ses collègues ».

Enfin, Build Storm prevention doit empêcher le blocage des pipelines multibranche. « Quand vous avez des redémarrages de Jenkins, des dépôts Git, certaines activités réseau et autres, il va se produire une tempête de builds au moment du rattachement des clusters », relate Sacha Labourey. « Tout va être reconstruit parce que les états ont été perdus. Alors que vous cherchez à régler un problème en redémarrant, vous en créez un autre : cela peut créer une explosion de la charge ».

« Tout d’un coup, l’on se retrouve avec un backlog de 400 builds : il faut relier tous les dépôts et les pipelines. Ce n’est vraiment pas tenable ».

Pour éviter ce souci, Build Storm Prevention permet de conserver les états à l’aide d’un plugin dont le rôle est d’indexer les branches, les pulls requests, les tags associés à un pipeline et de le créer, sans l’exécuter.

« Ce pipeline reste inactif tant qu’un événement SCM n’a pas été réalisé sur la branche, la pull request ou le tag correspondant », indique la documentation de l’éditeur.

C’est un problème bien connu des moteurs CI, selon le responsable.

CloudBees espère convaincre les utilisateurs traditionnels de CloudBees CI de passer sur cette édition HA. Il s’agit également de persuader les équipes qui utiliseraient Jenkins OSS.

« Comme nous facturons au nombre de développeurs, il est peu probable que des clients déploient Jenkins OSS pour des environnements de développement et de test et CloudBees CI pour les environnements en production », explique Sacha Labourey. « En revanche, dans une même entreprise, certaines équipes peuvent déployer des systèmes de pipelines Jenkins spécifiques, tandis que d’autres exploitent CloudBees CI ».

Pour approfondir sur Outils de développement

Close