Recherche

Que deviennent OpenTofu et OpenBao, ces forks de produits HashiCorp ?

Voilà un an qu'OpenTofu, fork de Terraform, a publié sa première version stable. OpenBao, fork de Vault, a franchi ce cap plus récemment. Point d'étape.

Publié par Clément Bohic le - mis à jour à
Lecture
6 min
  • Imprimer
Que deviennent OpenTofu et OpenBao, ces forks de produits HashiCorp ?
© Pavel Ignatov - Adobe Stock

Souvenez-vous, c'était en août 2023 : HashiCorp, qui n'appartenait pas encore à IBM, annonçait changer la licence de ses produits.

Exit la MPL (Mozilla Public License), place à la BSL (Business Source License). Celle-ci a eu pour principal effet d'interdire d'"embarquer" ou d'"héberger" les éditions communautaires des produits HashiCorp dans le cadre de toute offre commerciale destinée à un usage en production. Un choix tenant à une logique que bien des éditeurs, à l'image d'Elastic et de Grafana Labs, avaient déjà suivie. En l'occurrence, canaliser les fournisseurs - en premier lieu, les hyperscalers - qui se nourrissent desdits produits sans contribuer en retour.

En réaction, une initiative OpenTF avait émergé sous l'impulsion d'entreprises dont le modèle économique reposait au moins en partie sur Terraform. Leur message : si HashiCorp ne faisait pas marche arrière, ils développeraient un fork. C'est ce qui se passa après environ deux semaines de pression. L'initiative prit le nom d'OpenTofu. Elle partit de la dernière version de Terraform disponible sous licence open source, avec une centaine d'organisations s'engageant à apporter leur soutien. Quelques semaines plus tard, elle rejoignit la Fondation Linux.

OpenBao, soutenu par IBM... à l'origine

À l'automne, une autre initiative avait vu le jour : OpenBao, pensé comme un substitut à Vault. Sous licence MPL comme OpenTofu, et placé sous l'ombrelle LF edge, qui regroupe les initiatives de la Fondation Linux dans l'edge computing.

Dépendant de Vault à travers ses produits exploitant le middleware Open Horizon, IBM fut l'un des soutiens initiaux d'OpenBao. Avec l'acquisition de HashiCorp, il a pris du recul. Il a officiellement encore un siège au comité de pilotage, comme GitLab, IoTech Systems, Viaccess-Orca... et WALLIX.

Le point de départ fut la version 1.14.8 de Vault... plus quelques commits ultérieurs. La première version stable d'OpenBao (2.0.0) sortit en juillet 2024, apportant notamment la pagination des requêtes LIST pour les plug-in. La v 2.1.0 (publiée en novembre) a ajouté, entre autres, un back-end Postgres. Au dernier pointage, le projet compte environ 500 PR et 3000 étoiles sur GitHub. Sa roadmap comprend :

  • Intégration d'un registre similaire à celui d'OpenTofu
  • Jonctions avec des HSM
  • Élasticité horizontale pour le mode redondant
  • Prise en charge des namespaces (fonctionnalités de Vault Enterprise)

OpenTofu s'écarte de Terraform, mais reste largement compatible

La première version stable d'OpenTofu (1.6) est sortie il y a tout juste un an. Quelques semaines auparavant, le projet avait stabilité son registre public. Un impératif, HashiCorp ayant interdit d'utiliser le sien pour d'autres produits que Terraform.

Architecturé à la manière de Homebrew, ce registre utilise des fichiers statiques hébergés sur un bucket Cloudflare R2. Une action GitHub détecte les mises à jour des ressources. Un processus est en place pour le traitement et la validation automatiques des ajouts de providers.

La version 1.7, lancée en avril 2024, a ajouté, notamment :

  • Chiffrement de bout en bout des fichiers d'état (avec AES GCM ; fournisseurs pris en charge : AWS KMS, GCP KMS, OpenBao et les phrases de passe via pbkdf2)
  • Bloc removed permettant de supprimer des ressources ou des modules d'un fichier sans les détruire
  • Prise en charge des boucles for_each dans les blocs d'importation de ressources (idéal pour les déploiements multizones/multirégions)

La version 1.8 fit ses débuts en juillet 2024. Avec, entre autres :

  • Extension .tofu dédiée à OpenTofu (évite la duplication des fichiers .tf en cas d'exploitation de fonctionnalités non disponibles dans Terraform)
  • Possibilité d'utiliser des variables et des locales dans les back-end, les sources de modules et la configuration de chiffrement
  • Première bibliothèque logicielle (en Go) pour automatiser le déploiement d'OpenTofu
  • En parallèle, passage d'un processus RFC fondé sur les tickets à un processus basé sur les PR (format qui encourage davantage les commentaires)

La version 1.9, tout juste lancée, apporte entre autres un flag - exclude. Il permet, à l'exact inverse de -target, d'exclure certaines ressources d'un plan ou d'un apply.

Sopra Steria, dans la boucle d'OpenTofu

OpenTofu a greffé à son registre une UI - avec moteur de recherche -, pour le moment en bêta. La limite de 5000 requêtes/heure sur l'API GitHub ne suffisant pas pour mettre régulièrement à jour les quelque 30 000 providers et modules, il a été décidé d'utiliser les flux RSS (qui contiennent les 5 dernières releases). L'interface repose sur une application monopage plutôt que sur des fichiers HTML, afin d'éviter d'avoir éventuellement à regénérer ces derniers en cas de changement de canevas.

OpenTofu a aujourd'hui quelque 3400 followers sur GitHub (24 000 étoiles pour le repo principal), 19 000 sur LinkedIn et 4800 sur X. Sont représentés au comité de pilotage technique : env0, Gruntwork, Harness, Scalr et Spacelift. Sopra Steria est sur la liste des soutiens. Sur la feuille de route, les principales améliorations demandées concernent :

  • Prise en charge des registres OCI pour les providers et les modules
  • Support d'OpenTofu dans le serveur de langage VS Code
  • Option sans DynamoDB pour le verrouillage des fichiers d'état sur le back-end S3
  • Mécanisme pour marquer l'obsolescence de variables
  • Prise en charge des workspaces sur le back-end HTTP
  • Inspection des sous-modules (et non simplement de leurs outputs) sur la console

En avril 2024, HashiCorp avait mis en demeure les porteurs du projet OpenTofu pour réutilisation de code non conforme sous licence BSL, violation de sa propriété intellectuelle et réétiquetage de code de sorte qu'il paraissait avoir été à l'origine sous licence MPL-2.0.

Le code problématique, publié en février 2024, était composé de 5 fichiers. Il constituait le bloc "removed" d'OpenTofu. HashiCorp y voyait une grande ressemblance avec du code "inédit" qu'il avait publié en novembre 2023 sur le dépôt Terraform. Les accusés avaient nié toute inconformité. Si les deux implémentations se ressemblaient, c'était parce qu'elles avaient la même source. En l'occurrence, un bloc "moved" issu de la version open source de Terraform.

Le litige n'est pas allé plus loin, en tout cas en façade.

Illustration © Pavel Ignatov - Adobe Stock

Livres Blancs #cloud

Voir tous les livres blancs

Vos prochains événements

Voir tous les événements

Voir tous les événements

S'abonner
au magazine
Se connecter
Retour haut de page