Infrastructures Kubernetes : Pulumi veut simplifier les déploiements
Dans le domaine de l’IaC, le jeune éditeur américain veut contrer Terraform et Ansible avec une batterie de templates par infrastructure et des scripts qu’on peut écrire dans n’importe quel langage.
Faciliter la tâche des ingénieurs en charge des infrastructures applicatives au point de leur permettre de superviser dix fois plus de déploiements. Tel est l’argument commercial de Pulumi, l’éditeur d’une solution d’Infrastructure-as-Code (IaC) éponyme. Fondé en 2017 par des anciens de Microsoft, Pulumi propose une version Open source de son logiciel. Mais il a surtout vocation à vendre sa version complète à un public d’utilisateurs Kubernetes, généralement déjà conquis par les versions gratuites de Terraform et Ansible.
Pulumi a trois arguments. D’abord, une batterie de processus prédéfinis et de bonnes pratiques intégrables en une seule ligne de code ; ils font passer un script de déploiement en plus de 1 600 lignes à moins de 15 lignes. Ensuite, la possibilité d’écrire les scripts dans n’importe quel langage. Enfin, une console graphique qui sert aussi bien à superviser les ressources qu’à redéployer les codes mis à jour.
Joe DuffyFondateur de Pulumi
« Nous ciblons les entreprises qui déploient des applications publiques simultanément dans une multitude de régions autour du monde, chez une multitude d’hébergeurs. Dans ces conditions, votre application devrait prendre en compte des dizaines de variantes d’une architecture type, sinon vous multipliez les risques de cybersécurité et de surcoût. Les utilisateurs d’une autre plateforme d’IaC ne le font pas, car c’est excessivement compliqué. », argumente Joe Duffy, le fondateur de Pulumi.
LeMagtIT l’a rencontré à l’occasion d’un événement IT Press Tour consacré aux startups de la Silicon Valley qui innovent autour de Kubernetes.
Joe Duffy revendique 1 500 clients commerciaux dans le monde. Parmi eux, le constructeur automobile Mercedes-Benz aurait réussi grâce à Pulumi à simplifier drastiquement sa stratégie multicloud. Malgré les multitudes d’infrastructures différentes sur lesquelles s’exécutent ses centaines de clusters Kubernetes, ses déploiements seraient rapidement rentabilisés et garantis conformes aux exigences tant réglementaires que techniques.
La volonté de simplifier les déploiements via une plateforme IaC plus polyvalente n’est pas nouvelle. Le MagIT avait déjà évoqué la démarche de l’éditeur français Cycloid.
Des processus techniques et des bonnes pratiques prédéfinis
Dans le détail, la batterie de processus intégrables en une seule ligne comprend le support d’un très grand nombre de ressources (machines virtuelles ou physiques, OS, containers, réseau, stockage, mais aussi bases de données, modules d’authentification, modules de sécurité…) selon les spécifications techniques particulières de plusieurs infrastructures. Parmi ces dernières, citons les clouds publics d’AWS, Azure, GCP, mais aussi les clouds privés reposant sur VMware, OpenStack et d’autres. Bien entendu, ces ressources comprennent les différentes implémentations d’un cluster Kubernetes.
« Nous tâchons d’avoir l’offre la plus riche possible. Nous avons par exemple des templates pour configurer automatiquement la diffusion de données au travers des réseaux de proximité de Cloudflare, ou encore le relevé d’activité au travers de DataDog, etc. », illustre Joe Duffy.
Selon les informations que LeMagIt a pu obtenir, la quantité d’infrastructures automatiquement supportées serait supérieure à 80. Toutefois, ce comptage manque de précision : un extrait de la liste cite aussi bien l’hébergeur AWS, que la technologie Kubernetes et les logiciels d’analytique de New Relic.
Sont également fournis des tests de fonctionnalités, de sécurité, de conformité qui s’adaptent automatiquement au fonctionnement de l’infrastructure hôte. « Ce sont à la fois des templates de bonnes pratiques selon les cas d’usage, mais aussi des modules qui s’interfacent avec les services d’authentification des hébergeurs : Okta, pour s’interconnecter avec des services en ligne tiers, Azure Active Directory, G Suite et tout système d’authentification compatible SAML 2.0 », précise notre interlocuteur.
Selon la démonstration technique à laquelle LeMagIT a pu assister, Pulumi décide même tout seul de chiffrer certaines données selon la criticité des usages. Il le fait soit avec un système de clés KMS qu’il gère lui-même, soit via un système tiers.
Des scripts de déploiement dans n’importe quel langage
Les scripts exécutés par Pulumi peuvent s’écrire dans n’importe quel langage dans le but de satisfaire aussi bien les développeurs (C#, Java…), que les informaticiens (Python, TypeScript…) ou encore les responsables de la conformité et/ou de la sécurité (Go…). L’idée de Pulumi est de permettre la rédaction des scripts de déploiement depuis les environnements de développements (IDE) des utilisateurs.
Joe DuffyFondateur de Pulumi
Comparativement, Terraform dispose de son propre dialecte pour les fichiers de configurations et Ansible utilise YAML. L’éditeur Atlassian (Jira, Trello...), client de Pulumi, fait parvenir son témoignage : cette faculté de créer des scripts de déploiement dans le langage de son choix aurait permis à ses équipes de réduire de moitié le temps passé aux tâches de maintenance.
« Les entreprises que nous rencontrons finissent par avoir 5 000 lignes de YAML auxquelles elles ne comprennent plus rien. Nous pouvons convertir ces lignes dans n’importe quel langage pour satisfaire les connaissances de chaque intervenant. À la fin, vous obtenez des modules plus précisément définis par chaque équipe et qui s’interconnectent malgré la variété de leurs dialectes », dit Joe Duffy, en se vantant d’éditer plus une API qu’un langage de script.
Mieux s’interfacer avec les environnements tiers
Pulumi peut d’ailleurs s’interfacer avec plusieurs pipelines CI/CD (assemblage et mise à disposition en continu de containers applicatifs). L’éditeur cite Azure DevOps, Azure pipelines, Jenkins, Travis CI, CircleCI, CodeFresh, Octopus Deploy, Spinnaker… Par ailleurs, les éditeurs d’applications SaaS se servent de l’API pour programmer des déploiements selon les demandes de leurs clients ou les conditions tarifaires d’un hébergeur. Un système gère même les dates contractuelles pour déployer à un endroit ou l’autre selon la période d’activité.
Enfin, la console graphique permet de suivre l’utilisation des ressources, de visualiser un historique des déploiements et même de mettre à jour les applicatifs via un bouton. Celui-ci redéploie des applications directement depuis leurs codes hébergés dans un dépôt Git. Plus précisément, cela fonctionne pour l’instant depuis les dépôts Github. À terme, l’éditeur promet d’étendre ce système à GitLab, BitBucket et d’autres.
En version commerciale, la console graphique, le CLI et le moteur API peuvent s’exécuter en cloud public, privé ou sur site, y compris depuis une partie étanche du réseau. La version gratuite, qui décline un code disponible en Open source, ne s’utilise qu’en SaaS depuis le cloud d’AWS.