Un peu plus de quatre mois après l’annonce du changement de licence de Terraform par HashiCorp vers la licence Business Source License (BUSL), le nouveau concurrent open source de l’outil, appelé OpenTofu, est enfin disponible en GA depuis le 10/01/2024 !
Qu’est-ce qu’OpenTofu ?
OpenTofu est issu du mécontentement d’une partie de la communauté open source derrière Terraform, qui reproche à Hashicorp de menacer l’ensemble de la communauté et de l’écosystème construit autour de Terraform depuis quelques années avec le changement de licence. En effet, l’utilisation de la licence BUSL donne théoriquement à Hashicorp la possibilité de limiter voir d’interdire l’utilisation de Terraform à une organisation ou une entreprise considérée comme “concurrente” d’Hashicorp (voir https://www.digitalcorner-wavestone.com/2023/09/how-hashicorps-license-change-impacts-organizations/ pour plus de détails).
En réponse à ce changement de licence, et face à la volonté d’Hashicorp d’assumer ce choix, la communauté s’est rassemblée autour d’un projet commun, sous la tutelle de la Fondation Linux (https://www.linuxfoundation.org/projects). Le projet est notamment soutenu par des entreprises qui se sont engagées à proposer au total 18 ETP sur 5 ans pour soutenir l’effort de développement (Harness, Spacelift, env0, Scalr…).
OpenTofu est ainsi né d’un fork d’une des dernières versions de Terraform soumise à la licence MPL 2.0, c’est à dire la version 1.5.6. Les différentes manières d’installer OpenTofu sont présentées sur la page suivante : https://opentofu.org/docs/intro/install/.
J’utilise Terraform : qu’est-ce que ça change pour moi aujourd’hui ?
Pour l’instant… Rien !
En effet, l’utilisation d’OpenTofu 1.6 est quasi identique à celle de Terraform 1.6 : les concepts clés sont tous conservés (state, backend, plan, apply…), le langage utilisé est identique à terraform, les commandes à executer sont aussi identiques… à la différence près que l’on va utiliser la commande tofu au lieu de terraform. C’était d’ailleurs l’objectif principal d’OpenTofu pour publier la première version stable : pouvoir remplacer Terraform sans effort de migration particulier (on parle de “drop-in replacement”), et donc un outil déjà prêt pour gérer de la production.
Testons la migration en pratique. Initialisons un projet terraform sur AWS avec la commande terraform init et un backend s3.
La commande terraform plan donne le résultat suivant :
Déployons l’infrastructure avec Terraform sur AWS avec la commande terraform apply:
Essayons maintenant de refaire un plan avec OpenTofu et la commande tofu plan :
L’erreur permet de mettre en évidence une différence majeure avec Terraform : OpenTofu utilise son propre registry de providers et de modules. En effet, les conditions d’utilisation du registry ont évolué le 20 août 2023 … pour restreindre l’utilisation du registry aux utilisateurs de Terraform. Le registry OpenTofu a ainsi été créé pour proposer sa liste de providers et modules (disponible ici https://github.com/opentofu/registry/).
Utilisons la commande tofu init -upgrade pour récupérer le provider aws du coté d’OpenTofu :
Réessayons maintenant la commande tofu plan :
OpenTofu s’est bien synchronisé avec le state créé par Terraform. Si on modifie le code et qu’on fait un plan via OpenTofu :
Suivi d’un tofu apply :
La promesse est pour l’instant respectée : aucune modification de code n’a été nécessaire pour migrer de Terraform à OpenTofu !
Mais alors, quels enjeux à migrer de Terraform à OpenTofu ?
- Terraform et OpenTofu vont suivre des cycles de développement totalement différents, et 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. OpenTofu présente déjà dans sa documentation des “protected workflow commands”, c’est à dire des commandes qui ne seront pas sujettes à breaking change sur la version majeure 1.X d’OpenTofu (ex :
tofu plan), et des commandes qui seront potentiellement amenées à évoluer (ex :tofu import). - L’utilisation de deux registry différents risque à terme de créer des disparités entre les providers / modules disponibles sur les deux registry, que ce soit en qualité ou en quantité d’accélérateurs disponible. Les éditeurs de solutions devront donc possiblement adapter leurs providers aux deux registry, voire même abandonner le support pour l’un des outils.
- Pour le moment, difficile de prévoir le comportement de la communauté des développeurs face à ces deux produits concurrents : y aura-t-il une cohabitation saine, avec une répartition équitable du marché entre les deux solutions et donc du soutien de la communauté pour faire progresser les deux produits, ou au contraire assistera-t-on à la chute d’un des deux produits par manque de support ? Chaque équipe, organisation ou entreprise doit donc décider de miser et de parier sur la pérennité d’un des deux outils.
- Une des promesses des développeurs derrière OpenTofu est de proposer de nouvelles fonctionnalités basées sur les demandes les plus populaires de la communauté (comme par exemple l’utilisation de variables pour les backends, providers et versions de module https://github.com/opentofu/opentofu/issues/1042). Les développeurs de IaC vont donc devoir suivre attentivement les roadmaps des deux outils afin de décider quel outil sera le plus adapté à leur besoin.
OpenTofu est peut-être le premier d’une longue série de produits dérivés des solutions Hashicorp. Ainsi, le projet OpenBao a vu le jour dans la foulée afin de développer un fork d’une autre solution très populaire d’Hashicorp, Vault, qui est un gestionnaire de données sensibles (secrets, certifications, clés…) et un des leaders sur ce marché.
Sources :
