Choisir entre Tekton et Jenkins pour les pipelines CI/CD sur Red Hat OpenShift

Né du projet Knative, Tekton a vite été considéré par Red Hat comme l'avenir des pipelines dans Red Hat OpenShift. En 2018, lorsque j'ai entendu parler de Tekton pour la première fois, je me suis demandé quel problème on essayait de résoudre. Après tout, je connais déjà Jenkins, qui me satisfait pleinement. Pourquoi apprendre à maîtriser une nouvelle technologie alors que celle que j'utilise fonctionne bien ?

Red Hat classé leader dans le rapport Magic Quadrant™ de Gartner® de 2023

Red Hat a obtenu la meilleure note pour sa capacité d'exécution et sa vision globale dans la catégorie Gestion des conteneurs du rapport Magic Quadrant de Gartner de 2023.

Lire le rapport

La plupart des personnes auxquelles j'ai demandé pourquoi Tekton était meilleur que Jenkins m'ont répondu qu'il était cloud-native, sans plus d'explications. Pour mieux comprendre, j'ai donc cherché une définition claire du terme « cloud-native ». 

En 2018, la CNCF (Cloud Native Computing Foundation) a publié cette définition : « Les technologies cloud-native permettent aux entreprises de construire et d'exploiter des applications évolutives dans des environnements modernes et dynamiques comme des clouds publics, privés ou hybrides. »

Je n'étais pas beaucoup plus avancé. En outre, j'ai tendance à beaucoup m'attacher aux outils que j'utilise depuis des années et qui fonctionnent bien. Pour me convaincre de me séparer de Jenkins, il me fallait des arguments en béton. Tekton devait m'offrir bien plus que ce que je connaissais déjà. 

J'en ai conclu que Tekton s'intégrait mieux avec OpenShift/K8s et offrait davantage d'opportunités que Jenkins.

La suite de cet article donne plus de détails. Si vous vous posez les mêmes questions que moi, j'espère vous aider à trouver des réponses.

Mon expérience avec Jenkins

Jenkins a beau être excellent, c'est un outil de la vieille école. Depuis sa création en 2005, il n'a pas vraiment changé. Son principal atout réside dans sa vaste sélection de plug-ins qui permettent d'interagir facilement avec à peu près tout. Mais c'est aussi une faiblesse, car ces plug-ins ont un cycle de vie logiciel indéterminé. Si un problème survient, vous devez généralement faire avec. 

Basé sur Java, Jenkins nécessite une grande quantité de mémoire et de ressources de calcul (il fonctionne en permanence), ce qui peut poser problème au vu des coûts cumulés des ressources de calcul.

Avant l'existence des conteneurs, l'ensemble du service de développement utilisait un seul serveur Jenkins, provoquant ainsi un goulet d'étranglement. Parce qu'il avait du mal à traiter la charge importante qui lui était imposée, il fallait souvent le « démêler » en le redémarrant. On reprenait tout depuis le début. 

Depuis l'arrivée des conteneurs, chaque équipe peut posséder un serveur Jenkins et le configurer à sa guise. Toutefois, un autre problème est survenu : la « prolifération » de Jenkins. Tous ces serveurs sont constamment actifs et très coûteux alors qu'ils sont rarement utilisés. De plus, chaque équipe propage de nombreux types de code de pipeline différents.

Il nous faudrait donc un outil décentralisé à très faible encombrement qui permette de créer des pipelines cohérents. Gardez cette idée en tête, nous y reviendrons plus tard.

Les modèles de séquençage de processus

Dans un système logiciel, il existe deux méthodes pour organiser la séquence d'appels de service ou d'étapes de processus afin de produire un résultat.

Le premier modèle, relatif à l'orchestration, est celui des gestionnaires de processus.

Source (Ce fichier est distribué sous la licence Creative Commons Attribution - Partage dans les mêmes conditions 4.0 International.)

En pratique, le gestionnaire de processus se comporte comme un chef d'orchestre. C'est de là que vient le nom orchestration.

Jenkins est un exemple de ce modèle. Il se comporte comme un gestionnaire de processus, ou un chef d'orchestre. En codant le processus avec JenkinsFile, vous définissez le processus. Les nombreuses interfaces de Jenkins basées sur des plug-ins renvoient les données au gestionnaire de processus pour marquer la fin d'une étape et en lancer une nouvelle. Dans la plupart des cas, il s'agit d'un comportement synchrone. 

L'ouvrage Refactoring to Patterns (Kerevsky 2004) décrit le modèle des gestionnaires de processus comme étant « intrinsèquement fragile ». En effet, si quelqu'un décide de redémarrer le gestionnaire de processus, tout élément en cours d'exécution est supprimé. Ainsi, on sait que ce modèle n'est pas conçu pour fonctionner avec des processus longs. 

Passons au deuxième modèle de séquençage. La photo ci-dessous représente une foule qui fait la ola lors d'un événement sportif aux États-Unis.

Source. (Ce fichier est distribué sous la licence Creative Commons Attribution - Partage dans les mêmes conditions 2.0 Générique.)

Chaque membre de la foule sait quand il doit se mettre debout et lever les mains, sans que personne ne donne d'indication. Dans un stade de cette taille, il s'avère impossible d'orchestrer tous les événements qui surviennent. Cet exemple illustre le deuxième modèle de séquençage, la chorégraphie.

La plupart des équipes de développement optent d'abord pour l'orchestration, mais la chorégraphie permet d'améliorer considérablement l'écriture ou la conception d'un système en l'adaptant aux événements.

Ce modèle se révèle très utile pour les microservices, car il peut être nécessaire de séquencer des centaines de services. La chorégraphie est également plus robuste et pratique pour mettre en place, tester et supprimer des pipelines sur une longue durée.

Les pipelines Tekton sont conçus à partir de conteneurs distincts qui sont séquencés via des événements Kubernetes internes sur le serveur de l'API K8. Ils illustrent le séquençage par chorégraphie orienté événements. Le verrouillage, le redémarrage, la monopolisation des ressources et l'échec ne dépendent pas d'un seul gestionnaire de processus. Tekton permet à chaque pod d'instancier lorsqu'il en a besoin pour effectuer l'étape du pipeline dont il est responsable. Une fois sa tâche terminée, il s'arrête, libérant ainsi les ressources qu'il utilisait.

L'idéal du couplage faible et de la cadence basée sur la réutilisation

Tekton présente également ce qu'on appelle un couplage faible dans l'architecture logicielle. Prenons l'exemple d'un petit train pour enfants :

« Toy train for wood tracks » par Ultra-lab, sous licence CC BY-SA 2.0 

Le train est relié aux wagons par des aimants, ce qui permet de l'utiliser seul ou avec tous les wagons, ou de toute autre manière imaginable. 

Il est également possible de modifier l'ordre des wagons, par exemple en inversant le vert clair et le jaune. Avec un deuxième petit train, on pourrait ajouter tous les wagons de l'un à l'autre afin de former un « super train ».

C'est pourquoi le « couplage faible » est l'architecture idéale pour la conception de logiciels. Cette pratique encourage la réutilisation, un concept essentiel dans la philosophie de Tekton. Une fois créés, les composants peuvent être facilement partagés entre les projets.

L'inverse du couplage faible est le couplage étroit. Observons un autre jouet :

« 09506_Pull-Along Caterpillar » par PINTOY^®, sous licence CC BY-SA 2.0. 

Cette chenille comprend également plusieurs sections, mais parce qu'elles sont fixes, l'ordre ne peut pas être modifié. Il est impossible de retirer des segments ou d'en ajouter pour créer une super chenille. Si un enfant ne voulait que trois segments sur sa chenille, il devrait convaincre ses parents d'en acheter une autre.

Cet exemple montre que le couplage étroit ne favorise pas la réutilisation, mais force la duplication.

Certes, les pipelines Jenkins peuvent être faiblement couplés et le code peut être partagé entre les projets. Mais ce résultat dépend en grande partie de la manière dont les pipelines ont été conçus. 

L'autre solution consiste à utiliser un pipeline Jenkins pour tous les projets. Il s'agit toutefois d'une pratique restrictive : vous vous retrouverez rapidement avec un projet dont les besoins ne seront pas satisfaits par l'approche générique. La conception de ce seul pipeline perdra ainsi son intégrité. 

Tekton est déclaratif par nature et ses pipelines ressemblent beaucoup à l'exemple du petit train. En surface, l'objet de haut niveau « Pipeline » s'apparente à la locomotive. Le pipeline contient un ensemble de tâches que vous pouvez considérer comme des wagons. Plusieurs pipelines peuvent contenir les mêmes tâches, avec différents paramètres et cas d'utilisation. Des tâches paramétrables et faiblement couplées sont donc reliées pour former des pipelines. Tekton encourage le couplage faible, permettant ainsi la réutilisation. Autrement dit, il est possible de récupérer le travail d'un projet pour l'intégrer et l'utiliser ailleurs.

De plus, Tekton se compose de définitions d'objets Kubernetes supplémentaires qui s'intègrent facilement à une approche « Everything-as-Code » et à GitOps. Le code de pipeline et les autres configurations de cluster/d'espace de noms peuvent facilement s'appliquer au cluster. 

L'intérêt de ce fonctionnement

Les environnements formels de développement, de test et de test d'acceptation par l'utilisateur font partie d'un système ancien. Avec ces environnements fixes, vous devez acheter des serveurs physiques et les réserver à un cas d'utilisation. 

Jusqu'ici, c'était la méthode standard. Avec OpenShift et l'approche Everything-as-Code, la mutualisation des entités isolées, etc., il est tout à fait possible d'instancier ces environnements de manière dynamique à l'aide de pipelines et de tests exécutés ensuite. Une fois terminés, ceux-ci peuvent être à nouveau supprimés pour en créer d'autres. 

La plupart des entreprises n'en sont pas encore là. Peut-être est-ce dû à l'incompatibilité des outils dont nous disposions jusqu'à présent.

Conclusion

Le monde cherche encore à rattraper son retard sur toutes les possibilités inédites que les technologies telles qu'OpenShift nous offrent. 

Avec toutes ces ressources de calcul inutilisées la nuit (et souvent à d'autres moments), il existe des possibilités infinies d'automatisation des tests pour fournir de meilleurs logiciels. J'y pense depuis longtemps, mais Jenkins ne m'a jamais permis de concrétiser mes idées. En revanche, en abordant Tekton avec un esprit ouvert, j'ai rapidement compris que c'était la solution idéale. 

Tekton s'intègre directement à l'API Kubernetes et au modèle de sécurité, et favorise le couplage faible et la réutilisation. Il est basé sur les événements et suit le modèle de la chorégraphie. Il s'agit donc d'un moyen efficace pour contrôler les processus de test de longue durée. Les artéfacts de pipeline sont essentiellement des ressources Kubernetes supplémentaires (définition de pods, comptes de service, secrets, etc.) compatibles avec l'approche « Everything-as-Code », en adéquation avec le reste de l'écosystème K8.

Les équipes en charge des applications peuvent avoir leur propre code de pipeline qui cesse de fonctionner lorsqu'il n'est pas exécuté, ce qui permet de profiter des avantages du « système Jenkins distribué » sans toutes les charges inactives. La plateforme Apache Maven a rencontré un succès rapide, car elle a changé la donne. En imposant une organisation précise pour les projets Java, elle aide les équipes de développement à déterminer la configuration de compilation entre les projets. Tekton procède de la même manière avec les pipelines et simplifie la réutilisation des tâches.

CruiseControl a été le premier outil d'intégration continue au début des années 2000, et je sais d'expérience qu'il était difficile à utiliser. À cette époque, Jenkins représentait une amélioration radicale. En ce qui concerne OpenShift/K8s, Tekton semble être la prochaine étape de la technologie des pipelines.

En savoir plus

• L'approche CI/CD cloud-native basée sur Red Hat OpenShift