OpenTofu : le fork de Terraform est prêt pour la production
Quatre mois après sa présentation, OpenTofu, fork de Terraform, peut être utilisé en production, mais de nombreuses interrogations demeurent quant à son avenir au regard de la solution propriétaire de HashiCorp.
Le 20 septembre dernier, lors de l’Open Source Summit de Bilbao, La Linux Foundation annonçait accueillir le projet OpenTF, sous l’appellation OpenTofu. Ce fork de Terraform a été créé officiellement le 25 août en réaction de la décision de son contributeur principal, HashiCorp, consistant à passer d’une licence open source (Mozilla Public License ou MPL) à une autre permissive, mais propriétaire (Business Source License, BSL ou BUSL). Les éditeurs et startups, dont Gruntwork, Harness, Spacelift, Env0 et Scalr, qui dépendaient principalement des travaux de la R&D de HashiCorp, se sont rassemblés pour poursuivre le développement d’OpenTofu. Au 18 décembre, 60 contributeurs avaient participé plus ou moins activement à la poursuite du projet. OpenTofu a été téléchargé plus de 31 000 fois.
La page du manifeste d’OpenTofu a récolté plus de 36 000 étoiles, tandis que le dépôt du fork en accumule plus de 17 000.
Dans un rapport intitulé « Delayed Open Source Publication : a Survey of Historical and Current Practices » publié pour le compte de l’Open Source Initiative (OSI), les auteurs observent que peu d’autres projets ayant subi un changement de licence ont bénéficié du même niveau d’attention.
La rapidité d’exécution est un signe de cette popularité. Le 10 janvier, les contributeurs principaux d’OpenTofu ont annoncé le lancement de la première version stable de l’outil d’Infrastructure as code open source, OpenTofu 1.6.
OpenTofu 1.6, une version intentionnellement conservatrice
Le premier problème à résoudre pour les contributeurs n’était autre que le changement de registre, c’est-à-dire l’endroit où l’outil d’IaC stocke et gère ses modules et ses providers, des packages réutilisables de configurations. C’est une des contraintes du changement de licence opéré par HashiCorp.
Inspiré par l’architecture de Homebrew, un gestionnaire de paquets pour macOS et Linux, les contributeurs ont configuré un dépôt git spécifique, hébergé sur l’offre de stockage objet Cloudflare R2. Ici, il s’agissait d’obtenir un niveau de performance et de disponibilité similaires à celui de HashiCorp.
Outre la résolution d’un lot de bugs principalement liés aux changements effectués par les responsables du projet open source, les améliorations d’OpenTofu 1.6 se concentrent sur le système de backend des états sur Amazon S3. Les contributeurs ont ajouté des méthodes d’authentification, mais ont surtout fait en sorte que le projet demeure compatible avec les backends S3 déjà déployés. Pour le reste, des modifications incrémentales doivent optimiser les performances de l’outil et permettre de récolter davantage de données afin de tracer des erreurs ou des changements d’état non souhaités.
Une seule fonctionnalité inédite fait son apparition : la commande tofu test.
« Les tests OpenTofu sont écrits dans des fichiers .tftest.hcl, contrôlés par une série de blocs d’exécution. Chaque bloc exécute un plan OpenTofu ou applique une commande à la configuration OpenTofu testée et peut exécuter des conditions sur le plan et l’état obtenus », décrit la documentation.
La commande crée l’infrastructure cible et vérifie que les conditions d’exécution sont réunies. Une fois le test terminé, les ressources créées sont détruites.
Changement de licence oblige, la racine tofu remplace terraform dans toutes les commandes de l’alternative au produit de HashiCorp. Pour le reste, les responsables veulent éviter tout changement cassant pour simplifier l’adoption des équipes qui souhaiteraient abandonner Terraform.
« Nous allons faire en sorte que le chemin de migration soit aisé dans les deux sens dans un avenir prévisible ».
Kuba MartinResponsable ingénierie, Spacelift et lead technique par intérim, OpenTofu
« Nous n’allons pas pousser à de grands changements du DSL [langage de programmation spécifique au domaine N.D.L.R], nous n’allons pas pousser à des changements de protocole pour les providers, rien de tout cela. Nous ferons en sorte que le chemin de migration soit facile dans les deux sens dans un avenir prévisible », assure Kuba Martin, responsable ingénierie chez Spacelift et lead technique par intérim sur le projet OpenTofu, dans un billet de blog.
Il y aura tout de même des exceptions à ce principe au moment d’ajouter des fonctionnalités inédites.
Une feuille de route à étoffer
« Le plus grand changement à venir, prévu pour la version 1.7, est le chiffrement des états côté client. Demandé par beaucoup et depuis longtemps, il vous permettra de chiffrer à la fois vos fichiers d’état et vos fichiers de plan de bout en bout », promet Kuba Martin.
Cette fonctionnalité est la vitrine du projet. Évoquée dès son lancement, la proposition a été officiellement formulée au mois de novembre dernier. Il s’agit de protéger les clés d’accès utilisées pour activer les déploiements, mais également des fichiers pouvant représenter une cartographie entière d’une architecture, « dont chaque VM, cluster Kubernetes, base de données, etc. C’est un trésor pour un attaquant qui souhaite s’orienter dans votre réseau privé », mentionne l’auteur de la demande.
Pour l’heure, il est question de prendre en charge les clés de chiffrement fournies par les utilisateurs et les services KMS les plus populaires. Selon les contributeurs principaux, cette proposition était systématiquement refusée par HashiCorp, qui détient le coffre-fort Vault (qui a, lui aussi, été forké par les porteurs du projet OpenBao).
Pour le reste, les responsables entendent répondre en premier lieu aux requêtes les plus populaires.
La première d’entre elles est la prise en charge de backends, de fournisseurs et de modules paramétrables, afin de « simplifier la lecture du code ».
Par ailleurs, à l’instar du propriétaire de Terraform, les contributeurs principaux d’OpenTofu souhaitent favoriser la création de plugins compatibles avec l’outil IaC. Il s’agit en premier lieu de fournir un système pour prendre en charge d’autres backends d’état.
OpenTofu doit faire ses preuves
Jusqu’alors, la promesse de migration facilitée de Terraform vers OpenTofu est remplie, selon Ali Boudjaria, Senior Consultant Cloud & DevOps Transformation chez Wavestone. Sur X (ex-Twitter), plusieurs utilisateurs évoquent que la migration ne nécessite pas de modifier le code HCL déjà rédigé.
Pour autant, le consultant de Wavestone anticipe dans un billet de blog que « Terraform et OpenTofu vont suivre des cycles de développement totalement différents », et que « la migration d’un outil à un autre risque ainsi d’être de plus en plus complexe au fil des montées de version et des ajouts de fonctionnalités ».
Ce sont surtout les mainteneurs de providers et modules qui devront décider s’ils maintiennent ou non une compatibilité avec les Rémus et Romulus de l’Infrastructure as code.
« Les éditeurs de solutions devront donc possiblement adapter leurs providers aux deux registres, voire abandonner le support pour l’un des outils », envisage Ali Boudjaria.
« Les éditeurs de solutions devront donc possiblement adapter leurs providers aux deux registres, voire abandonner le support pour l’un des outils ».
Ali BoudjariaSenior Consultant Cloud & DevOps Transformation, Wavestone
L’alternative semble a priori intéressante, mais la situation crée une forme d’incertitude que les porteurs d’OpenTofu et de HashiCorp devront dissiper.
Il n’est pas impossible que des fonctionnalités futures dans OpenTofu soient portées dans Terraform et vice-versa, notent les auteurs du rapport de l’OSI. « L’accord de licence de contributeur de HashiCorp est “non exclusif” ; un contributeur externe pourrait éventuellement continuer à apporter les mêmes correctifs à un projet BUSL de HashiCorp et à une branche non HashiCorp du même projet, à condition que les bases de code n’aient pas divergé de manière trop importante au fil du temps », signalent-ils.
Dans un même temps, la Linux Foundation indique qu’OpenTofu profite du soutien de CloudFlare, mais aussi de BuildKite, GitLab et Oracle.
Il bénéficie également des apports de ses utilisateurs de la première heure, dont David Béjar, directeur de l’ingénierie logicielle de la branche indonésienne d’Allianz.
« La sortie d’une version “GA” est une réalisation importante pour OpenTofu, un événement à célébrer pour la communauté open source et un indicateur clair du rôle de pionnier d’Allianz en matière d’innovation technologique et de développement collaboratif », avance David Béjar, dans le communiqué de la Linux Foundation. Au vu de la taille et de la criticité de l’infrastructure de la branche indonésienne d’Allianz, la migration de Terraform vers OpenTofu risque d’être longue.
L’équipe Ops du projet open source OpenStreetMap, elle, a annoncé avoir déjà adopté l’alternative à Terraform pour gérer ces services cloud.
De son côté, Chris Aniszczyk, CTO de la Cloud Native Computing Foundation, filiale de la Linux Foundation amenée à accueillir le projet quand il sera plus mûr, a une nouvelle fois apporté son soutien à ce projet « naissant ».
Pour approfondir sur Administration et supervision du Cloud
