Jakub Jirsk - Fotolia
Terraform 1.0 : Hashicorp à la recherche de la stabilité
Grâce au déploiement d’une version stable, les utilisateurs de Terraform n’auront plus à faire face à des changements cassants dans les prochaines itérations de l’outil d’infrastructure as code, promet Hashicorp.
Croix de bois, croix de fer. La version 1.0 de HashiCorp Terraform, publiée cette semaine, ne contient que peu de nouvelles fonctionnalités techniques. Mais c’est justement le but recherché.
La société est connue pour sa philosophie non conventionnelle sur ce qui constitue un produit « version 1.0 » et a passé sept ans à mettre à jour, supporter et commercialiser l’outil d’Infrastructure as Code (IaC) sans afficher cette désignation. D’autres produits d’HashiCorp, tels que l’orchestrateur de conteneurs Nomad et le gestionnaire de secrets Vault, ont longtemps été utilisés en production avant d’atteindre la version 1.0.
Terraform est employé pour définir des ressources d’infrastructure à l’aide de lignes de code, que les équipes DevOps peuvent ensuite tester et déployer automatiquement en même temps que les applications, afin de reproduire les processus. Terraform est l’un des outils IaC les plus populaires. L’éditeur revendique plus de 100 millions de téléchargements de la version libre à ce jour. Terraform Cloud hébergé par HashiCorp compte 120 000 clients.
En dépit de sa large utilisation en production, chaque nouvelle version de Terraform disponible au cours des trois dernières années a été accompagnée de mises à jour importantes, provoquant parfois des changements déstabilisants. Lancée au début de l’année 2019, la version 0.12 comportait une refonte de HCL, la syntaxe de programmation spécifique à l’outil. Elle a obligé les utilisateurs à remanier leur code d’infrastructure.
Mitchell HashimotoCofondateur et directeur technique, Hashicorp
Trois autres versions publiées en 2020 ont ajouté de nouvelles capacités techniques importantes, telles qu’une gestion efficace des dépendances et une meilleure intégration avec d’autres outils d’HashiCorp, mais elles ont également nécessité des modifications conséquentes des workflows de Terraform.
Désormais, les usagers de Terraform de HashiCorp qui passent de la version 0.14 et plus à la version 1.0 peuvent s’attendre à une expérience différente, selon le discours du cofondateur et directeur technique Mitchell Hashimoto lors de l’événement virtuel HashiConf.
« Nous nous concentrons sur l’interopérabilité, les mises à niveau et la maintenance pour la version 1.0 et au-delà », affirme Mitchell Hashimoto. « Toute mise à jour de la [release] Terraform 1.x à partir de la [version] 1.0 ne nécessitera plus la réécriture du code existant, et toutes les [configurations] 1.x seront rétrocompatibles. »
Terraform 1.0 : fini les mises à jour douloureuses, promet Hashicorp
À partir de la version 1.0, les mises à jour de Terraform ne doivent plus perturber les workflows en production, ce qui contraste nettement avec les expériences antérieures des utilisateurs.
« Par le passé, nous faisions de gros efforts pour mettre à jour tous nos modules et dépôts internes après chaque nouvelle version de Terraform », témoigne Björn Jessen-Noak, consultant principal en ingénierie du cloud chez MediaMarktSaturn, une enseigne de la grande distribution high tech en Allemagne. Les ingénieurs maintiennent plus de 30 modules Terraform pour provisionner les ressources Google Cloud pour des centaines de projets.
« Maintenant, nous pouvons nous occuper [des] nouvelles modifications par version, et chaque module devrait également fonctionner avec la version 1.x précédente », anticipe Björn Jessen-Noak. « C’est particulièrement utile lorsque nous considérons cela à l’échelle – cela dépend du module et de la version de Terraform, mais cela [prenait] auparavant entre 40 et 100 heures [par mise à jour]. »
La version 1.0 laisse entrevoir une stabilité accrue pour certains utilisateurs de Terraform, qui ont dû faire face à des problèmes lors des mises à niveau précédentes. Certains se souviennent du passage à la version 0.14.0 de Terraform en décembre qui ne prenait pas en compte une commande ignore_changes dans certains fichiers de configuration de modules. Ce défaut a été corrigé avec la version 0.14.1 en une semaine, mais il aurait pu faire des ravages dans des environnements non supervisés par des Ops expérimentés.
« Nous avions détecté ce bug, mais si cela n’avait pas été le cas, tous les serveurs de tous les environnements auraient été reconstruits, ce qui aurait pu être catastrophique », explique Kyler Middleton, architecte réseau DevOps principal chez Veradigm, une société de services de données médicales basée à Chicago. Pour Kyler Middleton, la version 1.0 est « une promesse d’HashiCorp » que ces types de bugs effrayants seront moins nombreux et que la stabilité sera traitée en priorité par rapport aux nouvelles fonctionnalités.
Terraform 1.0 sera pris en charge pendant 18 mois. Dans la version open source, cela signifie qu’HashiCorp continuera d’étudier et de corriger les défauts et les failles tout au long de cette période, même si des correctifs peuvent être publiés dans des versions ultérieures. Toutefois, la version 1.0 sera compatible avec les états Terraform des versions 0.14 et 0.15, et prendra en charge les sources de données d’état distantes à partir de la version 0.12. Les utilisateurs pourront exécuter plusieurs versions de ressources Terraform en même temps dans les versions 1.x.
Une nouvelle interface utilisateur et des intégrations pour Terraform Cloud
Hashicorp en profite pour annoncer deux nouvelles fonctionnalités dédiées à Terraform Cloud. La première n’est autre que l’interface utilisateur « Workspace Overview ». L’IU doit afficher des informations plus détaillées que les versions précédentes de Terraform Cloud sur ce qui se passe en temps réel pendant les exécutions du moteur IaC et sur les ressources affectées.
Avec la seconde, les administrateurs de Terraform Cloud pourront proposer leurs propres versions des modules publics partagés de Terraform Registry au sein de registres privés afin de garantir leur conformité aux politiques de sécurité.
Les utilisateurs de Terraform Enterprise espèrent que ces ajouts seront également disponibles dans la déclinaison de l’outil IaC sur site.
« L’interface utilisateur actuelle n’est pas vraiment informative et facile à utiliser [avec] plus de deux ou trois espaces de travail [et], la nouvelle interface utilisateur ajoutera également la visibilité des changements », espère Björn Jessen-Noak. « Le registre pourrait nous aider à aller plus loin sur la voie de la conformité ».
HashiCorp a également présenté en avant-première une nouvelle fonctionnalité à venir en version bêta le trimestre prochain pour Terraform Cloud, appelée Run Checks, qui intègre des outils tiers tels que les actions GitHub et les analyses de conformité Bridgecrew directement dans les flux de travail Terraform. Grâce à ces intégrations, Terraform fera appel à un système externe tel qu’un outil de gestion des coûts ou d’analyse de la sécurité, ce qui empêchera Terraform d’appliquer des changements qui ne sont pas conformes aux politiques de ces outils.
Run Checks finalisera la transition de Terraform d’un langage spécifique à un domaine, pour le provisionnement de ressources d’infrastructure vers une plateforme et un écosystème d’automatisation IT élargis, estime Gregg Siegfried, analyste chez Gartner.
« La concurrence commence à se faire sentir dans différents domaines, mais à mesure que vous intégrez ce workflow [élargi] dans la manière dont vous gérez les ressources du cloud, cela va bien au-delà du provisionnement », déclare l’analyste. « Comparer cet outil à CloudFormation (AWS) ou à Resource Manager (Azure) ne lui rend plus justice. »
Enfin, HashiCorp garde un œil sur ce que font les concurrents comme Pulumi en proposant le Cloud Development Kit, dont la version 0.4 est arrivée à la fin du mois dernier. Il prend en charge les principaux langages de programmation tels que Python, TypeScript et Java.
Les équipes d’ingénieurs déjà familiarisées avec Terraform HCL ne se jetteront pas nécessairement sur les autres interfaces de langage, mais elles pourraient élargir l’attrait de Terraform au-delà de sa clientèle actuelle, remarque Phil Fenstermacher, ingénieur système à William & Mary, une université de Williamsburg, en Virginie.
« Du point de vue de notre équipe DevOps, il n’y a pas de vide énorme à combler ici », considère-t-il. « Mais c’est une option intéressante qui pourrait aider [l’adoption de l’IaC] dans d’autres départements ».