Terraform et le multi-cloud

Dernière mise à jour : 26 août 2022

Terraform et le multi-cloud
Les missions confiées à Alien6 amènent nos collaborateurs à régulièrement mettre en place de nouvelles briques d'architecture cloud sous Azure, GCP, AWS ou Scaleway. Selon les besoins et les exigences de nos clients, la solution Hashicorp Terraform peut être proposée.

Quels en sont les bénéfices, limites et inconvénients ?

La proposition de valeur d’Hashicorp

Terraform est un outil de provisioning d’infrastructure dans lequel chacun doit pouvoir définir une architecture cloud sous forme de code (IaC). Il est utile à la définition et à l’initialisation d’une infrastructure immuable et réplicable. Il ne faut donc pas le confondre avec des produits de gestion de configuration comme Ansible dont il est complémentaire.

Dans son principe, Terraform est assez similaire à Cloud Formation que les ingénieurs AWS connaissent bien. Cependant, Terraform n’est pas restreint à un seul fournisseur cloud et offre un support à AWS, Azure, GCP, etc. Comment ? par emploi du HashiCorp Configuration Language (HCL), un langage déclaratif qui offre une syntaxe unifiée et une couche d’abstraction vis-à-vis des différentes APIs de fournisseurs cloud.

Au-delà, Terraform s’appuie sur un plan d’exécution en quatre phases (init, plan, apply et destroy). Ce cycle permet d’identifier les modifications telles que définies dans le plan et les écarts d’infrastructure qui peuvent apparaitre entre deux exécutions.

La problématique du multi-cloud

Le fait que le langage HCL offre une couche d’abstraction vis-à-vis des différentes APIs de fournisseurs cloud conduit souvent les ingénieurs à se méprendre sur les capacités de l’outil en environnement multi-cloud. Puisque chaque fournisseur propose ses propres interfaces, outils et workflows, il est naturel en tant qu’informaticien de souhaiter qu’un outil comme Terraform offre une forte généricité et un haut niveau d’abstraction vis-à-vis des fournisseurs. De fait, la complexité de l’apprentissage, de la veille et du maintien d’une infrastructure multi-cloud augmente proportionnellement au nombre de fournisseurs.

Or, par essence, Terraform n’essaie pas de faire abstraction de services similaires mais d’exposer l’ensemble des fonctionnalités proposées par chaque offre de fournisseur cloud. Par défaut, le langage HCL ne permet donc pas d’implémenter un éventuel objet terraform commun qui puisse abstraire deux ressources similaires comme chacun pourrait le supposer pour mettre en place une machine virtuelle par exemple. Aussi, parce que Terraform se limite à unifier le workflow et à gérer les dépendances entre fournisseurs cloud, il faudra que chacun puisse réfléchir à concevoir des plans d’exécution distincts et fonction du fournisseur. Les scripts développés pour un fournisseur ne pourront donc pas être réutilisés pour un second.

A noter que l’unification de plusieurs offres derrière une seule interface reste envisageable dans de très rares cas. A base de compromis forts, par la composition de modules Terraform, il est possible de créer des abstractions multi-cloud. Les nouvelles ressources ainsi créées pourront alors dépendre les unes des autres et utiliser des attributs communs ou hérités. Cependant et à maints égards, une approche de conception dite canonique (sur base du plus petit dénominateur commun) aura tendance à être restrictive et peu évolutive.

Notre retour d’expérience

Notre première expérience avec Terraform date de 2019. La mission qui nous avait été confiée avait pour objectif de définir une architecture reproductible et déployable à grande échelle. Nous avions convenu avec le client de réaliser une infrastructure de type Hub-Spoke. Ainsi, des équipes IT décentralisées pouvaient aisément mettre en place, sur l’infrastructure dont ils avaient la charge, des agents (spokes) connectés à la plate-forme centrale (hub). Pour ce faire, après avoir ajusté les scripts qui leur étaient transmis, il leur suffisait d’exécuter des plans Terraform. Vous pouvez retrouver les détails de cette mission sous ce lien.

Depuis lors, nous apprécions l’usage de Terraform en environnement multi-cloud en complément de Kubernetes et de produits de gestion de configuration. Cependant, nous en limitons l’usage pour assurer des structures de fichiers simples et nous assurons d’avoir des plans d’exécution différenciés. En cas de dépendances complexes avec des services tiers comme Mongo Atlas, nous nous assurons de créer des modules communs complémentaires que chaque plan pourra appeler. Chacun ayant son propre état.

Pour aller plus loin…