Terraform Stacks : HashiCorp se met à « l’infrastructure-as-code… as code »
Avec les évolutions de HCP Terraform, HashiCorp entend faciliter la standardisation des déploiements de ses « piles » dans plusieurs régions et différents clouds.
Alors que Hashicorp évoquait ses produits de gestion d’infrastructure et de la sécurité de manière séparée, il affirme désormais que l’un ne va pas sans l’autre.
Armon Dadgar, cofondateur et CTO chez HashiCorp, distingue la gestion du cycle de vie des applications (ALM), de celle de l’infrastructure (ILM), de la sécurité (SLM) et du monitoring. « Nous nous concentrons sur les deux défis au centre : la gestion du cycle de vie de l’infrastructure et de la sécurité », déclare-t-il.
Pour autant, il continue de présenter séparément sa feuille de route consacrée à l’ILM et à la SLM. Il le fait principalement pour des raisons pratiques. Au vu du nombre de produits, la liste des annonces est fournie. Il a commencé par la gestion du cycle de vie de l’infrastructure.
L’année dernière, HashiCorp avait mis l’accent sur le maintien en condition opérationnelle des environnements de production. Lors d’HashiConf 2024 à Boston, l’éditeur a dévoilé une suite de fonctionnalités pour rendre Terraform, son outil d’infrastructure as code, sensible aux changements. Cette capacité se prête particulièrement aux environnements multicloud et hybrides.
L’annonce phare dans ce domaine est le lancement de la bêta publique de Terraform Stacks.
Du fait de l’isolation des états, il convient en temps normal de lier les dépendances entre elles.
Or, « il n’y a pas de moyens simples pour vérifier les changements à travers les dépendances », considère Sarah Hernandez, senior product manager Terraform chez HashiCorp.
Plus précisément, il n’y avait pas un moyen de « gérer la coordination, le déploiement, et le cycle de vie de configurations Terraform interdépendantes ».
D’où la naissance de Terraform Stacks. « L’avantage des Stacks se résume à l’utilisation des mêmes composants cohérents, de sorte que vous disposez d’une infrastructure identique dans l’ensemble de vos déploiements », note un porte-parole d’HashiCorp.
Techniquement, Stacks est une couche de configuration supplémentaire par-dessus les modules Terraform. De « l’infrastructure as code… as code », plaisante Sarah Hernandez.
Au lieu d’utiliser une seule configuration par déploiement, il s’agit de la subdiviser en composants et en étapes, afin de ne gérer qu’un seul bloc.
HashiCorp porte là une double promesse. La première est de déployer l’ensemble des composants nécessaire au déploiement d’une application (réseau, stockage, compute) tout en automatisant la gestion des dépendances. La seconde vise à faire en sorte que les déploiements dans plusieurs régions, zones de disponibilité, comptes cloud et charges de travail Kubernetes soient cohérents, sans tout refaire à chaque fois.
Comment fonctionne Terraform Stacks ?
Pour cela, Stacks dispose de plusieurs extensions de fichiers spécifiques :. tfstack.hcl, components.tfstack.hcl, en sus d’utiliser tfdeploy.hcl.
Tfstack est un manifeste qui liste les composants nécessaires à l’exécution d’une Stack.
Ces composants correspondent à des wrappers qui encapsulent des modules listés dans le fichier components.tfstack.hcl. Un module peut être un cluster EKS, un VPC, un bucket d’un stockage objet, un KMS, une base de données, etc., fourni par un « provider », généralement un fournisseur de cloud. Ces modules peuvent être spécifiques à une entreprise ou à une équipe Ops suivant le type de services qu’elle met à disposition des développeurs.
« Pour chaque instance de l’infrastructure, vous ajoutez un bloc de déploiement avec les valeurs d’entrée appropriées et Terraform se chargera de répéter cette infrastructure pour vous. »
Sarah HernandezSenior product manager Terraform chez HashiCorp
Il n’est pas nécessaire de réécrire les modules déjà existants. Une fois ces éléments en place, il convient de compléter le fichier tf.deploy.hcl. Celui-ci indique combien de fois il faut déployer l’infrastructure – ou la chaîne de modules interdépendante – dans la stack.
« Pour chaque instance de l’infrastructure, vous ajoutez un bloc de déploiement avec les valeurs d’entrée appropriées et Terraform se chargera de répéter cette infrastructure pour vous », précise Sarah Hernandez.
Par exemple, il est possible de déployer un environnement de développement, de test et de production ou bien une application et son backup (ainsi que son plan de reprise après sinistre) dans plusieurs régions cloud et chez plusieurs fournisseurs.
Les clients de Terraform faisaient déjà une grande partie de ce travail, mais l’éditeur ajoute une fonction afin d’appliquer les changements de configuration de la stack partout où elle est déployée. Chaque composant dispose de son « plan » de déploiement.
Normalement, il faut que les modules soient activés dans un certain ordre pour que l’infrastructure fonctionne.
Pour simplifier cette gestion, HashiCorp met en œuvre des « règles d’orchestration ».
« Cela va vous permettre de définir des blocs de contrôle granulaires qui se trouvent directement dans votre configuration pour faire des choses comme approuver automatiquement un plan de déploiement s’il remplit les critères de contrôle », explique Sarah Hernandez. « Cela nous permet en quelque sorte d’éliminer la nécessité d’une grande partie de ces opérations manuelles ».
« Je peux commencer par faire un changement de configuration et Terraform va se rendre compte qu’il n’a pas assez d’informations pour planifier et appliquer tout cela tout de suite. ».
Sarah HernandezSenior product manager Terraform chez HashiCorp
Mais si plusieurs plans ne remplissent pas les validations définies par les règles, alors il faut appliquer ces plans manuellement.
L’autre concept clé de Terraform Stacks n’est autre que les « changements différés ».
« En pratique, je peux commencer par faire un changement de configuration et Terraform va se rendre compte qu’il n’a pas assez d’informations pour planifier et appliquer tout cela tout de suite », explique Sarah Hernandez. « Ainsi, au lieu d’échouer comme il le fait aujourd’hui, l’outil va le diviser en deux parties ».
La première partie du plan est appliquée automatiquement à partir des informations accessibles par Terraform dans son graphe de dépendances.
« Ensuite, il va sauvegarder le reste des choses pour lesquelles il n’a pas assez d’informations pour plus tard », poursuit Sarah Hernandez.
« Ainsi, au lieu d’échouer comme il le fait aujourd’hui, l’outil va le diviser en deux parties ».
Sarah HernandezSenior product manager Terraform chez HashiCorp
Une fois que cette première partie du plan est déployée, l’outil IaC a suffisamment de contexte pour déployer la deuxième partie. « Une fois que nous aurons appliqué la deuxième partie du plan, nous aurons réussi à mettre en place notre configuration en utilisant les changements différés ».
Faciliter l’usage et la gestion des modules
Cette fonctionnalité serait particulièrement utile pour déployer des clusters Kubernetes identiques dans trois régions cloud.
De manière plus générale, Sarah Hernandez met en avant trois améliorations : une meilleure scalabilité et un accès plus standardisé aux stacks par les développeurs, une visibilité accrue grâce à une gestion simplifiée, et la consolidation de la configuration qui réduit le besoin de fragmentation et facilite la surveillance des déploiements.
L’arrivée de cette fonctionnalité a déjà convaincu Travis Rutledge, Senior Cloud engineer chez Duke Energy, un producteur, transporteur et distributeur d’électricité basé à Charlotte, en Caroline du Nord.
« Les stacks Terraform semblent essentiels pour simplifier et accélérer nos déploiements, notamment Kubernetes, en éliminant les complexités liées à nos automatisations actuelles, qui sont souvent instables », juge-t-il. « Un de nos plus grands défis est de rendre les choses plus accessibles pour les développeurs, qui n’ont pas le temps ni l’envie de s’attarder sur des détails techniques complexes ».
Ce serait d’ailleurs une motivation pour définir les infrastructures avec davantage de modules.
« Les améliorations dans la gestion du cycle de vie des modules, comme la dépréciation et les tests automatisés, vont vraiment nous permettre d’ouvrir de nouvelles portes et d’adopter les modules plus facilement, ce qui est crucial pour continuer à évoluer et grandir ».
Stacks pas encore adaptés aux déploiements à grande échelle
Pour l’heure, les stacks sont limités en taille. Chaque stack ne peut être déployé que 20 fois, « ce qui pourrait limiter sa mise à l’échelle pour les grands environnements ». Pendant la bêta publique, Stacks prend en charge jusqu’à 500 ressources managées par organisation HCP Terraform. Aussi, les clients disposant d’un forfait Team Edition (legacy) devront migrer vers la Standard Edition.
Comme le mentionne Travis Rutledge, l’éditeur a également annoncé la bêta publique de Terraform module lifecycle management. À partir de l’UI HCP Terraform Explorer, il est possible d’indiquer et d’expliquer quand un module privé est déprécié, quand il dérive, quand le provider a été mis à jour ou quand l’infrastructure a été actualisée. Les utilisateurs peuvent être informés par mail ou un autre canal de communication (Teams, Slack) ainsi que depuis leur CLI. L’action est réversible.
HashiCorp a également annoncé la bêta publique de Terraform Migrate. Ici, il s’agit d’encourager les clients à migrer de la version communautaire de TF vers HCP Terraform. L’éditeur n’a pas dit s’il entend faciliter les migrations depuis OpenToFu à l’avenir.
