Le provisioning d'infrastructure a fait beaucoup de chemin. Tout a commencé par l'installation physique du matériel. Puis, grâce à la virtualisation, il a suffi de quelques clics dans une interface. Ensuite, les fournisseurs cloud ont commencé à proposer des API REST pour provisionner leurs services. Il est désormais possible de définir de façon déclarative l'état final d'un environnement à l'aide de code. L'infrastructure as code était née. Parmi les exemples : Terraform, Cloudformation, les templates ARM, etc.
Ce qu'il faut savoir sur l'infrastructure as code
L'infrastructure as code excelle en matière de reproductibilité. Elle minimise les erreurs humaines et renforce l'immuabilité. Cerise sur le gâteau, elle fait également office de documentation. Terraform permet de provisionner et de modifier l'infrastructure de manière incrémentale, et conserve l'état d'exécution après chaque run. Mais dès qu'on le pousse dans ses retranchements en entreprise, ses limites apparaissent.
D'abord, intégrer la moindre logique sous forme d'instructions if reste compliqué. Le langage HCL de Terraform a fini par prendre en charge les instructions if et les boucles for, mais celles-ci font davantage figure d'ajout tardif que de citoyens de premier rang dans HCL. Les frameworks d'infrastructure as code n'embarquent aucune capacité de test native. HCL, Cloudformation et les templates Azure Resource Manager ont chacun leur propre courbe d'apprentissage. Ils vous enferment également dans leurs écosystèmes respectifs.
Pulumi, un compromis bienvenu
À l'autre bout du spectre, on trouve des SDK cloud pour de nombreux langages de programmation populaires. Tous les principaux fournisseurs cloud proposent ce type de SDK, appelés CDK pour cloud development kit. Les CDK sont remarquables car ils offrent tous les avantages d'un langage de programmation ; en revanche, ils n'intègrent pas de gestion d'état comme le fait Terraform. Or c'est précisément la gestion d'état qui rend les modifications incrémentales d'infrastructure prévisibles et maîtrisables.
C'est là qu'intervient Pulumi, en réunissant ces deux atouts. Il offre à la fois un langage de programmation complet et la gestion d'état.
Par exemple, voici à quoi ressemble du JavaScript classique pour plusieurs conditions if :
switch (ostype){
case 'linux':
Userdata = userdata
break;
case 'windows':
Userdata = windowsuserdata
break;
}
La même logique exprimée dans le HCL de Terraform donne :
Linux = var.ostype == "linux" ? true : false
Windows = var.ostype == "windows" ? true : false
Comme on peut le constater, la lisibilité est nettement meilleure avec la notation JavaScript bien connue qu'avec le HCL de Hashicorp. HCL est un langage spécifique à un domaine, qui n'a pas la souplesse d'un langage généraliste. On peut donc enrichir l'infrastructure as code d'une logique plus poussée à l'aide d'un langage généraliste.
Pulumi apporte également d'autres avantages issus du cycle de développement logiciel : développement piloté par les tests, intégration continue, releases versionnées, gestion de paquets, etc.
Désormais, code applicatif et code d'infrastructure peuvent cohabiter. Un même dépôt git peut héberger les deux, écrits dans le même langage de programmation.
Les concepts de Pulumi
Terraform repose sur des concepts comme provider, module, state, etc. De son côté, Pulumi a repensé et simplifié ces concepts comme suit :
Stacks
Les Stacks sont des regroupements de ressources d'infrastructure liées partageant les mêmes variables d'environnement. Ils s'apparentent à des environnements (dev, stage, prod), chacun disposant d'un jeu distinct de variables. Ces variables sont définies exclusivement dans Pulumi.dev.yaml, Pulumi.stage.yaml, etc.
Projects
Un Project est un regroupement logiquement isolé de ressources d'infrastructure englobant des stacks. Les Projects peuvent être associés à des équipes, des initiatives ou des types d'infrastructure (containers, serverless, réseau, etc.). Chaque organisation reste libre de définir le type de regroupement qui lui convient.
Backends
Les Backends stockent l'état d'exécution de Pulumi dans un système de stockage persistant. Ils peuvent être de plusieurs types :
1. Service backends : Pulumi cloud (SaaS) ou Pulumi auto-hébergé. Les service backends offrent l'avantage de prendre des snapshots de l'infrastructure à intervalles réguliers. Cela facilite les rollbacks et la récupération en cas d'erreurs fatales lors du provisioning.
2. Stockage objet auto-géré (AWS S3, GCP GCS, Azure blobs, etc.).
Providers
Pulumi permet de provisionner des infrastructures et des services sur plusieurs plateformes. À ce jour, il dispose de providers pour AWS, GCP, Azure, Kubernetes, Cloudflare et bien d'autres encore.
Annexe
Tableau comparatif
À venir
La 2ᵉ partie de cet article explorera les fonctionnalités avancées de Pulumi qui permettent à des équipes autonomes de provisionner et de maintenir leur propre infrastructure aux côtés de leur application. Nous nous pencherons également sur une codebase capable de provisionner des clusters EKS sur AWS — des clusters EKS qui vont au-delà du simple hello world, avec un certain niveau de durcissement et de production readiness. Restez à l'écoute !
Pour rester connecté, suivez-nous sur le DoiT Engineering Blog , DoiT Linkedin Channel et DoiT Twitter Channel . Pour découvrir les opportunités de carrière, rendez-vous sur https://careers.doit-intl.com .
Sur le plan strictement technique de la sémantique, l'écart n'est peut-être pas si marqué entre HCL et un langage généraliste. Mais lorsqu'il faut choisir entre un langage de programmation généraliste mature et largement adopté et un langage déclaratif propriétaire spécifique à un domaine pour parvenir au même résultat — pourquoi opter pour le moins connu ? HCL et un langage généraliste font tous deux le travail de manière satisfaisante. Cela dit, compte tenu des écosystèmes bien établis autour des langages généralistes et des talents disponibles sur le marché, il est judicieux de privilégier un framework comme Pulumi plutôt que Terraform.