OpenTofu, le successeur de Terraform ?

Paul Boisson 11 déc. 2023

OpenTofu, on en entend parler partout mais on ne sait pas trop quoi en penser pour le moment. Tapez OpenTofu sur Youtube et vous aurez plus de chances de tomber sur des recettes de tofu que sur de véritables présentations du soi-disant remplaçant de Terraform. Dans cet article, écrit en Novembre 2023 (détail à prendre en compte étant donné que le projet évolue rapidement), je vous propose de revenir sur la genèse d’OpenTofu et de voir différentes possibilités concernant son avenir dans la communauté DevOps.

L'avènement de Terraform

Le principe d’Infrastructure As Code (IAC) a été conceptualisé par Amazon en 2006 comme étant une façon de provisionner des instances dans le cloud tout en écrivant du code. Progressivement, différents outils d’IAC sont apparus comme AWS CloudFormation ou Ansible (plutôt pour de la configuration) chacun de ces outils ayant leurs avantages et leurs inconvénients. C’est en 2014 que la société HashiCorp, d’abord connue pour des outils comme Vagrant et Packer, dévoile son propre logiciel d’IAC : Terraform. Ce dernier, développé en Go, est rapidement devenu une référence dans le milieu, car il a notamment pour avantage de pouvoir déployer des infrastructures chez de nombreux cloud providers (même sur des solutions dites On Premise), mais également parce qu’il est rendu disponible sous la licence MPL v2 (Mozilla Public Licence), ce qui en fait un outil Open Source. Cette licence permet notamment l’utilisation de l’outil et le développement d'offres autour de Terraform et a permis à d’autres outils comme Terragrunt ou Spacelift de voir le jour et d’ajouter des fonctionnalités supplémentaires (avec des fonctionnalités payantes en générales).

Il existe différents éléments liés à l’utilisation de Terraform

Les states : sont les informations liées à l’état d’une infrastructure après un déploiement de Terraform.
Les providers : Ce sont les plugins utilisés par Terraform pour communiquer avec les APIs des différents providers.
Les modules : Ce sont des templates d’infrastructure qui permettent de mutualiser le code

Schématisation de l'utilisation de Terraform

Le Changement de licence qui fait mal

Le 10 Août 2023, HashiCorp annonce un changement de licence pour un grand nombre de ses produits (Terraform, Vault, Packer, Consul etc). Après avoir été open source depuis 9 ans, Terraform passe donc sous licence BSL v1 (Business Source Licence) et de fait n’est plus open source.

Cette licence spécifie notamment (dans ses termes exacts) :

“The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work.”

Si on ne se fie qu’à cette partie de la licence BSL, nous pouvons comprendre qu’utiliser et modifier les outils sous cette licence sont autorisés mais que toute utilisation de Terraform pour créer des infrastructures de production est interdite.

Mais heureusement, la licence laisse à HashiCorp la possibilité de donner des droits supplémentaires aux utilisateurs et notamment en précisant :

“You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with HashiCorp’s paid version(s) of the Licensed Work.”

Donc pas de panique, en tant qu’utilisateur lambda, aucun changement n’est perceptible. Cependant, toutes les solutions construites autour de l’utilisation de Terraform (Terragrunt, Spacelift, Atlantis) ne peuvent plus utiliser le code développé par HashiCorp.

Ce qui fait mal, c'est que c'est à l'opposé de la promesse de HashiCorp qui appelait les développeurs à se baser sur Terraform pour développer de nouveaux outils d'IaC. Et que dire des providers Terraform ? Ils sont développés par la communauté mais sont-ils soumis à ces restrictions ou pas ? Pour l’instant, ce n’est pas le cas mais les termes de la licence semblent être volontairement flous pour pouvoir faire évoluer les règles en fonction de la volonté de HashiCorp.

Du point de vue de HashiCorp, comment justifier une telle décision ? Dans un article de blog, publié en août 2023, Armon Dadgar, CTO et cofondateur de HashiCorp explique le pourquoi de cette décision. Il écrit notamment :

“However, there are other vendors who take advantage of pure OSS models, and the community work on OSS projects, for their own commercial goals, without providing material contributions back. We don’t believe this is in the spirit of open source.”

En effet, les GAFAM, toujours à la recherche de nouveaux outils à vendre sur leurs plateformes ont généralement tendance à s’approprier des outils open source afin d’en vendre les services. C’est le cas de Kubernetes par exemple, d’abord développé comme un outil open source (par Google), qui sert de base à AWS pour vendre le service EKS ou Azure avec le service AKS. On pourrait citer aussi Hadoop, un framework open source pour le stockage et le traitement distribué de gros volumes de données, qui a été utilisé par AWS pour développer son service Amazon EMR (Elastic MapReduce) et le facturer à ses clients.

Un autre exemple, qui ressemble fortement à la situation que HashiCorp tente d’éviter, est celui de l’entreprise Elastic. Elasticsearch est un moteur de recherche et d’analyse de données open source distribué qui a changé de licence après avoir constaté qu’AWS fournissait un service autour d’Elasticsearch (Amazon Elasticsearch service) en se basant sur son code open source mais sans l’accord de l’entreprise et sans contribuer suffisamment au projet selon Elastic. AWS avait alors été forcé de forker le projet avant son changement de licence et de changer le nom de son service par OpenSearch.

On peut donc imaginer que HashiCorp, qui essaye de fournir des services managés de ses outils, n’a pas envie que d’autres entreprises ne génèrent des bénéfices à partir de produits que l’entreprise maintient et fait évoluer.

La réaction de la communauté Open Source

Très rapidement après le changement de licence de Terraform, la communauté Open Source s’est soudée et un groupe d’abord nommé OpenTF (pour Open Terraform) puis renommé OpenTofu (TF étant souvent utilisé comme abréviation de Terraform, OpenTF était un nom trop proche et pouvait donc leur attirer les foudres de HashiCorp) a fortement milité pour un retour de Terraform sous licence open source, notamment via un manifeste publié sur le site opentofu.org.

“Our aim with this manifesto is to return Terraform to a fully open-source license. BUSL is not open source, so this would mean moving Terraform back to the MPL license, or some other well-known, widely accepted open-source license (e.g., Apache License 2.0). Moreover, we want to be confident that Terraform will always remain open source, so you don't have to worry about another sudden license change putting everything at risk.”

Faute de réaction de la part du créateur de Terraform, l’équipe derrière OpenTofu (des développeurs de Gruntwork, Spacelift, Harness, Env0, Scalr et d'autres encore) a décidé de forker la dernière release de Terraform encore open source, à savoir sa version 1.5. Le projet a ensuite rejoint la Linux Foundation, assurant de fait son autonomie et son statut d’outil communautaire.

Et donc, ça marche bien tofu ?

A l'heure où ces lignes sont écrites (24 Novembre 2023), OpenTofu est en version v1.6.0-alpha5, c’est la 4e release depuis le fork de Terraform v1.5.X. OpenTofu est donc pour l’instant encore extrêmement proche de Terraform et fonctionne aussi bien que la version 1.5.0.

Schématisation de l'utilisation de OpenTofu

La question qui se pose ensuite, c’est de savoir si OpenTofu va pouvoir continuer à utiliser la registry de Terraform pour récupérer les providers et les différents modules (souvent développés par la communauté). Et bien la réponse n’a pas tardée à venir après la création d’OpenTofu, au vue des changements effectués par HashiCorp au niveau des termes d’utilisation de la Registry de Terraform :

“You may download providers, modules, policy libraries and/or other Services or Content from this website solely for use with, or in support of, HashiCorp Terraform”

OpenTofu a donc dû créer sa propre registry pour mettre à disposition des modules et des providers, d’abord un miroir de celle de Terraform, elle sera développée indépendamment au fur et à mesure.

Installation et démonstration

Pour les utilisateurs de Windows, je vous conseille d’aller jeter un coup d'œil aux différentes releases disponibles sur https://github.com/opentofu/opentofu/releases et de télécharger directement l’exécutable.

En ce qui nous concerne, je vais utiliser un environnement Cloud9 sous Ubuntu pour faire mes essais (directement accessible depuis la console AWS), et d’exécuter le script d’installation fourni sur le site officiel:

$ curl -s https://packagecloud.io/install/repositories/opentofu/tofu/script.deb.sh?any=true -o /tmp/tofu-repository-setup.sh

$ sudo bash /tmp/tofu-repository-setup.sh
$ rm /tmp/tofu-repository-setup.sh

$ sudo apt-get install tofu

Une fois installée, essayons la commande tofu :

$ tofu
Usage: tofu [global options] <subcommand> [args]

The available commands for execution are listed below.
The primary workflow commands are given first, followed by
less common or more advanced commands.

Main commands:
  init          Prepare your working directory for other commands
  validate      Check whether the configuration is valid
  plan          Show changes required by the current configuration
  apply         Create or update infrastructure
  destroy       Destroy previously-created infrastructure

Maintenant que la commande est installée, créons un petit projet en HCL (HashiCorp Configuration Language) permettant de déployer un VPC, un subnet et une instance EC2 sur AWS.

D’abord déclarons le provider à utiliser, ici AWS dans la région eu-west-1 et à une version supérieure à 4.16.

provider.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "eu-west-1"
}

Déclarons ensuite la petite infrastructure que nous souhaitons créer :

main.tf

resource "aws_vpc" "tofu" {
  cidr_block = "10.1.0.0/16"
}

resource "aws_subnet" "tofu" {
  vpc_id            = aws_vpc.tofu.id
  cidr_block        = "10.1.10.0/24"
  availability_zone = "eu-west-1a"

  tags = {
    Name = "tf-example"
  }
}

resource "aws_instance" "app_tofu" {
  ami           = "ami-07355fe79b493752d"
  instance_type = "t2.micro"
  subnet_id = aws_subnet.tofu.id

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

Lançons ensuite la commande d’initialisation du provider AWS.

$ tofu init

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 4.16"...
- Installing hashicorp/aws v4.67.0...
- Installed hashicorp/aws v4.67.0 (signed, key ID 0C0AF313E5FD9F80)

…

Créons ensuite notre infrastructure :

$ tofu apply

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # aws_instance.app_tofu will be created
  + resource "aws_instance" "app_tofu" {
      + ami                                  = "ami-07355fe79b493752d"
      + arn                                  = (known after apply)


      (.
      .
      .
      .
      .
      .)

Plan: 3 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  OpenTofu will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_vpc.tofu: Creating...
aws_vpc.tofu: Creation complete after 1s [id=vpc-0b43c3c7d8a804f5f]
aws_subnet.tofu: Creating...
aws_subnet.tofu: Creation complete after 2s [id=subnet-08e12842e9e334018]
aws_instance.app_tofu: Creating...
aws_instance.app_tofu: Still creating... [10s elapsed]
aws_instance.app_tofu: Still creating... [20s elapsed]
aws_instance.app_tofu: Creation complete after 24s [id=i-01ec105e844a7f869]

Sans surprise, côté AWS, notre infrastructure est bien créée. Impressionnés ? Bon oui … c’est Terraform. Nous pourrions même utiliser la commande de Terraform pour construire et la détruire avec Tofu. Tant de bruit pour ça ? Il suffirait de garder Terraform 1.5 et le problème est réglé ?

Il ne faut pas oublier que le Cloud évolue rapidement, de nouvelles plateformes apparaissent régulièrement , les providers de Terraform doivent se mettre à jour régulièrement. La version 1.5 de Terraform ne pourra pas être éternellement utilisée pour répondre à des besoins nouveaux.

Faut-il migrer nos projets Terraform vers OpenTofu ?

En quelques années, Terraform a été une des solutions privilégiées pour la construction d’infrastructures. Cela a permis à différents contributeurs de s’investir dans le projet et notamment à fournir et mettre à jour de nouveaux providers. Mais la communauté va-t-elle autant s’investir après ce changement de licence et la fermeture de la registry Terraform à d’autres outils ?

Nous avons aujourd’hui 2 registries différentes, une pour Terraform et une (qui est un miroir pour l’instant) pour OpenTofu. Va-t-il y avoir des développements exclusivement pour l’un ou pour l’autre ? Il est encore trop tôt pour le dire.

Certains outils ont été développés pour répondre à des besoins des ops auxquels Terraform ne répondait pas (Terragrunt pour faire du multi environnement par exemple). Si HashiCorp arrive à rester innovant sur Terraform et à développer constamment de nouvelles fonctionnalités, je pense que le changement de licence aura été une bonne chose (pour eux). Mais c’est, pour moi, sous estimer l’envie et le dynamisme de la communauté Open Source (peut être aussi la compétitivité ?). Aujourd’hui, de grands acteurs ont rejoint le projet OpenTofu (Gitlab, CloudFlare, la CNCF) et vont sûrement se faire un malin plaisir à rendre Terraform obsolète et développer de nouvelles fonctionnalités que Terraform n’aura probablement pas.

Il est encore trop tôt pour se prononcer sur la nécessité de migrer sur OpenTofu mais les termes de la licence restent flous sur certains points, ce qui pourrait rendre certaines entreprises réticentes à l’idée d’utiliser Terraform. De plus, l’équipe derrière OpenTofu ambitionne d’intégrer les fonctionnalités de Terraform enterprise dans leur solution open source, ce qui pourrait rendre l’offre payante de HashiCorp totalement obsolète.

Par exemple, pour nous, chez Ippon Technologies, est-ce que le fait de produire une pipeline CI/CD permettant de déployer une infrastructure via Terraform sur un environnement de production entre en concurrence avec l’offre Cloud de Terraform ? Et si c’est le cas, sommes-nous en concurrence avec HashiCorp ?

Conclusion

Alors ? Ce changement de licence, bonne ou mauvaise idée de HashiCorp ? Je ne saurais le dire. D’un côté, je comprends les motivations de HashiCorp, c’est normal de refuser que d’autres génèrent de l’argent à partir des outils que l’on développe et je trouve que ce fork est plus un combat de principe qu’une réelle recherche d’un meilleur outil. Mais je pense que les logiciels de HashiCorp n’auraient pas eu autant de succès et d’évolution s’ils n’avaient pas été Open Source, notamment car la communauté a permis à Hashicorp de corriger de nombreux bugs et de développer de nouvelles fonctionnalités qui n’avaient pas été prévues à l’origine du projet. De plus, ce changement de licence coïncide avec l’arrivée d’une nouvelle politique tarifaire qui va fortement augmenter la facture d'utilisation de Terraform Cloud. Cela va très certainement motiver un changement d’outil d’Infrastructure as Code chez de nombreuses entreprises. Ce changement de licence est-il un moyen pour HashiCorp de se défendre ou simplement une façon de forcer l’adoption de son offre Terraform Cloud (qui peine à faire sa place) chez les utilisateurs tout en éliminant la concurrence ?
Quoi qu’il en soit, le projet OpenTofu évolue rapidement et nous fait réfléchir sur l’importance des projets Open Source. Nous les utilisons au quotidien mais peut être qu’en tant qu’entreprises, nous n’y contribuons pas assez. La communauté derrière le projet communique beaucoup via le site officiel ou via un canal Slack, OpenTofu Community, je vous encourage à suivre le sujet et pourquoi pas à y contribuer.

Update du 23 Décembre 2023 :

Après 5 mois de travail acharné, la communauté autour du projet OpenTofu a annoncé, dans un article publié sur le site officiel du projet, OpenTofu v1.6.0-rc1 pour le 20 Décembre 2023, une dernière pré-release avant la release officielle pour le 10 Janvier 2024.