L’intégration et la livraison continues sont des composantes fondamentales de la démarche DevOps. Toutefois, alors que les pipelines doivent prendre en compte les nouvelles architectures – conteneurs notamment –, il devient nécessaire d’abstraire un peu plus ces étapes du cycle de vie d’une application : c’est le sens d’une approche as a Service du CI/CD.
Optant dès sa Version 3 pour une approche Container as a Service, OpenShift cherche à rendre les conteneurs plus accessibles aux développeurs, quand bien même ils n’auraient pas une connaissance approfondie de Kubernetes.
CI, CD : de quoi parle-t-on ?
Par intégration continue, on entend l’intégration de changements apportés au code par les différents membres d’une équipe de manière continuelle. Ces intégrations, qui fusionnent dans un répertoire commun les copies de chaque développeur, vont être automatiquement testées (tests unitaires et d’intégration) par un build de sorte à vérifier que des erreurs ne se soient pas glissées dans les modifications.
La livraison continue, ou Continuous Delivery, reprend cette brique en l’élargissant au dépôt du code vérifié dans un référentiel (GitHub, GitBucket, GitLab) afin qu’il puisse être déployé par l’équipe d’exploitation. Enfin, le déploiement continu (Continuous Deployment), là encore CD désigne le transfert automatique des modifications effectuées par le développeur du référentiel vers l’environnement de production. Il se différencie donc de la livraison continue en ce que celle-ci simplifie le passage en production, réalisé par l’équipe d’exploitation, quand le déploiement continu automatise ce même processus.
Mais attention, d’un éditeur à l’autre, les définitions varient, les deux CD étant bien souvent interchangeables et confondues. Ainsi, déploiement et livraison sont parfois opposés comme deux méthodes distinctes, quand d’autres en font deux étapes consécutives d’un même processus. Toujours est-il que tout le monde s’entend sur le fait le CI/CD repose sur l’automatisation de différentes phases du cycle de vie d’une application. Pour l’ensemble de la chaîne, on parle de “ pipeline CI/CD ”.
Début décembre, CloudBees annonçait “ CloudBees CI/CD powered by Jenkins X ”, décrite comme une solution de CI/CD (Continuous Integration / Continuous Delivery ou Deployment) as a Service. Petit retour en arrière : Jenkins a été, au début de la décennie 2010, une des premières briques du DevOps. Cet outil open source d’intégration continue, développé en Java, vient automatiser les étapes de build et de tests. Surtout, par le biais de ses 1 500 plugins, Jenkins étend ses fonctionnalités en s’intégrant à moult autres outils de tests et de déploiement. Bref, Jenkins fait tout sauf le café. Mais voilà qu’arrivent les conteneurs et Kubernetes. C’est à partir de ce moment-là que Jenkins commence à caler.
Pour livrer une application sous forme de conteneurs en passant par Jenkins, il est nécessaire de configurer les pipelines, d’ajouter les bons plugins… Bilan, les développeurs se voient contraints d’étudier comment empaqueter des logiciels sous forme d’images Docker, de créer des fichiers YAML adaptés pour exécuter leur application dans Kubernetes, de créer des environnements de prévisualisation, d’apprendre à écrire leurs propres pipelines Jenkinsfile… Ce qui s’avère chronophage et, pendant ce temps, les développeurs ne développent pas.
En 2018 a donc été conçu Jenkins X, qui vient supprimer certains des problèmes causés par la complexité globale de Kubernetes et son écosystème, en évitant de devoir passer des mois à essayer de trouver la bonne façon de faire les choses.
S’adapter aux conteneurs et à Kubernetes
Jenkins X est un outil de CI/CD qui, une fois installé, configure automatiquement tous les différents outils (Helm, Docker, Nexus, Skaffold, etc.) et crée, à partir d’un nouveau projet ou d’un projet existant et importé, un pipeline CI/CD et des aperçus entièrement automatisés. « Cela permet à vos développeurs de se concentrer sur la création d’applications pendant que vous déléguez à Jenkins X pour gérer votre CD CI », explique l’équipe derrière le projet. Par défaut, un pack contient le nécessaire pour transformer le code en une image de Docker (DockerFile), pour composer le pipeline (Jenkinsfile), pour générer les ressources Kubernetes permettant l’exécution dans Kubernetes (helm chart) et pour définir les dépendances (preview chart). L’outil est donc taillé pour les applications cloud-native et automatise leur intégration et leur déploiement. La distribution stable de Jenkins X est fournie par l’un des principaux contributeurs au projet, CloudBees. Qui a donc, en décembre dernier, annoncé une préversion de sa propre itération de Jenkins X en mode as a Service.
As a Service désigne des services fournis par le biais du Cloud, qu’il s’agisse de SaaS, de IaaS ou de PaaS. Facile d’en conclure que CI/CD as a Service signifie alors que le pipeline, managé ou non, s’appuie sur une infrastructure cloud. Dans le cas de CloudBees CI/CD powered by Jenkins X, c’est sur Google Cloud Platform que la solution fonctionne. Et, selon CloudBees, ce modèle permet aux équipes de s’affranchir des problèmes habituels et des frais liés à la gestion et au maintien d’une infrastructure CI/CD. « Puisqu’il s’agit d’un SaaS entièrement géré, votre équipe de développement ou d’opérations n’a plus besoin de maintenir une infrastructure CI/CD interne. Jenkins X automatise l’ensemble du pipeline CI/ CD », nous explique Moritz Plassnig, VP Cloud chez CloudBees. « Plus besoin d’assembler un CI et une solution CD. Et grâce à toute cette automatisation, chaque changement qui entre en production est minutieusement testé et vérifié. Cela réduit considérablement le risque de livraison continue et les problèmes de production. » D’autant que, si jamais un bug devait passer entre les mailles du filet, une fonction de roll back est disponible. Côté fonctionnement, CloudBees CI/ CD powered by Jenkins s’intègre au service de référentiel de votre choix (GitHub, Bitbucket, GitLab, etc.). À chaque fois que les développeurs poussent du code sur ce référentiel, la solution prend le relais, exécute le pipeline CI/CD et exécute les outils de build et de test choisis avant de déployer les modifications de code en production. Moritz Plassnig reconnaît que le SaaS est « profondément intégré à Google Cloud et GKE », mais insiste sur le fait qu’il sera également possible de « déployer sur le fournisseur d’infrastructure ou l’hébergeur de votre choix. CloudBees CI/ CD powered by Jenkins X sera disponible on-premise via Google Anthos à l’avenir. Cette possibilité a été l’une des principales raisons pour lesquelles nous avons décidé de collaborer avec Google sur le SaaS », ajoute-il. « Nous allons également étendre le SaaS pour permettre à nos clients d’apporter leur propre cluster auprès du fournisseur d’infrastructure de leur choix. Cela permettra au client d’exécuter le pipeline CI/CD sur, par exemple, EKS [Amazon Elastic Kubernetes Service] ».
En mode PaaS
Plus près de nous, Artifakt, une jeune pousse parisienne, ne va pas jusqu’à parler de CI/CD as a Service, mais de PaaS. Sa plate-forme DevOps s’articule surtout autour du déploiement d’applications web et va gérer la configuration, les tests, la livraison et le provisionnement d’infrastructures, en s’appuyant sur des solutions open source, de Terraform pour l’infrastructure-as-code à Kubernetes. Au départ, la start-up ne proposait de déployer que sur l’infrastructure d’AWS avec une sélection limitée d’applications et de frameworks (WordPress, Akeneo, Magento, Symfony…) pour lesquelles le service propose des configurations prédéfinies, mais elle s’est depuis ouverte à d’autres cloud providers, Google Cloud, Azure et Alibaba Cloud, tandis que son dépôt GitHub recèle de démo de déploiements sur Scaleway, Digital Ocean ou encore OVH. « La CI/CD est une feature de la plate-forme », souligne Aymeric Aitamer, CEO et cofondateur d’Artifakt. « On va amener le code jusqu’au déploiement, tests et builds compris. » Il suffit que le développeur choisisse le fournisseur de Cloud et la région, ainsi que le type d’environnement et de stack sur lequel il souhaite déployer son code, et Artifakt s’occupe du reste. « Artifakt va définir automatiquement la plate-forme et la provisionner pour n’importe quel type de langage, de framework », ajoute son cofondateur. L’idée générale, à l’instar de la définition du DevOps, est de faire gagner du temps au développeur afin que celui-ci puisse se concentrer sur le code.
Industrialiser la CI
Impossible en outre de parler de CI/CD en mode PaaS sans évoquer OpenShift. La plate-forme de Red Hat permettant de tester, déployer et exécuter des applications a opéré à partir de sa version 3 un virage à 90° afin d’intégrer Docker et Kubernetes, passant du PaaS au CaaS (Container as a Service). Pour Olivier Mikeladze, Lead Architect chez Red Hat, le CI/CD as a Service est la capacité à « industrialiser et instancier en deux ou trois clics l’ensemble de la chaîne ». Il précise qu’il y a deux approches : « Soit une seule CI pour toute l’entreprise, mais cela pose un problème de scalabilité, soit une CI par équipe, et là c’est l’enfer pour les équipes opérationnelles pour la maintenance. Fournir la CI as a Service, c’est la garantie que le service est managé par le fournisseur de la solution. »
Dans un post de blog, Cisco revient sur la situation à l’heure actuelle et part du constat suivant : les différentes équipes métier et développement ont très probablement des ensembles d’outils préférés. Ici, une équipe a recours à GitLab pour la partie Source Control Management, Jenkins pour le buîld et la CI, Nexus pour le repo, le tout dans un environnement GCP. Là, une autre équipe utilisera un combo Bitbucket, Travis CI, Nexus pour un environnement hybride AWS et on-premise. En résumé, les outils du marché sont nombreux et, Shadow IT aidant, une entreprise peut se retrouver avec des dizaines de configurations différentes. La solution : créer de multiples pipelines CI/CD, chacun supporté par des VM ou des containers. Ce qui implique un coût, plus le temps passé à maintenir les différentes infrastructures tout en s’assurant que la chaîne d’outils est bien conforme aux prérequis de sécurité. Le PaaS permet de créer un socle standardisé de sorte que le modèle de déploiement soit le même pour un projet A que pour un projet B. Et éviter ainsi que les équipes d’exploitation ne s’arrachent les cheveux, tout en permettant aux développeurs de « s’abstraire de la complexité inhérente de leur système d’information », selon Olivier Mikeladze.
La plate-forme d’Artifakt provisionne les ressources nécessaires pour le déploiement d’une application sur un Cloud public, sans que le développeur ait à mettre les mains dans le cambouis.
L’enfer d’intégration
Une analyse partagée par Jordi Mon, Senior Product Marketing Manager pour GitLab, pour qui le principal intérêt du as a Service est de « ne pas avoir à maintenir de pipeline ». Hors de toute considération sur le Cloud, il voit le CI/ CDaaS comme des services managés, alors que « les pipelines deviennent de plus en plus complexes à maintenir ». D’où l’automatisation, qui passe pour une bonne partie par des packs prédéfinis, des templates. Chez Sopra Steria a été mis en place en mars 2017 une plate-forme, Innersource, basée sur Gitlab CI et sur des modèles couvrant la quinzaine d’architectures utilisées dans l’entreprise. Yves Nicolas, Group CTO Office de l’ESN, nous explique que par le biais d’Innersource, les responsables techniques vont commencer un nouveau projet sur la base d’un template prédéfini. Ils vont y récupérer toute la chaîne d’intégration et de déploiement continus, des tests jusqu’au déploiements de clusters de containers Kubernetes ou OpenShift. « Le simple fait de partir des templates fait gagner beaucoup de temps : les responsables de projet n’ont pas besoin d’installer d’outils d’intégrations, tout cela est directement disponible dans le template », indique Yves Nicolas. « La mise en place est dans une logique de rapidité sur le plan du déploiement et de meilleure qualité de déploiement industriel. »
Et l’automatisation ne concerne pas que le Cloud native : même sur des applications anciennes, sans en modifier le code, Sopra Steria a développé des templates pour les tester sur des conteneurs.
Continuous Delivery Foundation, nouveau foyer du CI/CD open source
En mars 2019, la fondation Linux annonçait la création d’une nouvelle structure, baptisée Continuous Delivery Foundation (CDF). Cette initiative, à laquelle participent Google, Alibaba, Atos, Netflix, GitLab, SAP, Red Hat, Huawei ou encore IBM, entend fournir un nouveau foyer vendor-neutral à des projets open source majeurs dans le secteur de l’intégration et de la livraison continue. Jenkins, Jenkins X, Tekton ainsi que Spinnaker, une solution de CD multicloud développée par Netflix, ont été les premiers projets à être transférés et désormais gérés sous l’égide de la CDF. «
La CDF facilitera la collaboration entre développeurs, utilisateurs finaux et fournisseurs pour évangéliser les méthodologies CI/CD et DevOps, définir et documenter les meilleures pratiques, fournir des directives et créer du matériel de formation pour permettre à toute équipe de développement de logiciels du monde entier de mettre en œuvre les meilleurs pratiques de CI/CD », écrit la fondation dans son premier communiqué.
Tekton, future base du CI/CD ?
Né chez Google, d’abord dans le cadre de Knative, Tekton est un projet ambitieux : il s’agit de fournir un framework natif de Kubernetes afin de pouvoir développer des pipelines CI/CD capables de s’exécuter n’importe où, là où Kubernetes s’exécute.
Dans le détail, Tekton est un ensemble de spécifications et de composants open source qui comprend à l’heure actuelle des primitives pour la définition de pipeline, l’accès au code source, la gestion des artefacts et l’exécution des tests. « L’objectif du projet est de fournir des spécifications industrielles pour les pipelines, les workflows, l’accès au code source et d’autres primitives. Il modernise le plan de contrôle de livraison en continu en tirant parti de tous les avantages intégrés de mise à l’échelle, de fiabilité et d’extensibilité de Kubernetes, et y déplace la logique de déploiement des logiciels », indique sa fiche. Tektone est dans la roadmap d’OpenShift, nous confirme Olivier Mikeladze, chez Red Hat, l’éditeur étant contributeur du projet au sein de la CDF. Jenkins X utilise Tekton comme moteur d’exécution du pipeline. L’utilisateur écrit un fichier jenkins-x.yml, qui décrit le pipeline CI/ CD, que Jenkins X traduit en instructions pour Tekton. Tekton exécute ensuite le pipeline sur le cluster Kubernetes. « Tekton est une composante utile de l’écosystème Kubernetes, qui effectue une grande partie du travail indifférencié au niveau de l’infrastructure », indique Moritz Plassnig, chez CloudBees. « Cela permet à Jenkins X de se concentrer sur la fourniture d’une excellente expérience de développeur et la simplification de CI/CD pour Kubernetes. »