CI/ CD as a Service : des pipelines en trois clics
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.
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
« 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 »
Moritz Plassnig VP Cloud – Cloudbees
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] » .
« Artifakt va définir automatiquement la plate- forme et la provisionner pour n’importe quel type de langage, de framework »
Aymeric Aitamer
CEO et cofondateur – Artifakt
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
« 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 »
Olivier Mikeladze Lead Architect – Red Hat
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.
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. ✖