OpenTofu : provisionner son infrastructure open source de manière déclarative

OpenTofu : provisionner son infrastructure open source de manière déclarative

Ansible configure des machines. Docker empaquette des applications. Kubernetes les orchestre. Mais qui crée les machines, les réseaux et les espaces de stockage eux-mêmes ? C’est le rôle du provisionnement d’infrastructure — et c’est précisément ce que fait OpenTofu. Fork open source de Terraform né en 2023 sous l’égide de la Linux Foundation, OpenTofu permet de décrire l’intégralité de son infrastructure sous forme de code déclaratif, versionnable et reproductible. Cet article présente ses principes, son fonctionnement et sa place dans une stack auto-hébergée.

Pourquoi OpenTofu plutôt que Terraform ?

En août 2023, HashiCorp a changé la licence de Terraform de MPL 2.0 vers BSL (Business Source License), restreignant son usage en contexte concurrentiel. En réponse, la communauté open source a forké le projet sous le nom OpenTofu, placé sous la gouvernance de la Linux Foundation avec une licence Apache 2.0. Le code est compatible : les fichiers .tf existants fonctionnent sans modification. La différence est stratégique, pas technique — OpenTofu garantit que l’outil reste libre, sans restriction d’usage.

Le principe : déclarer l’état désiré

OpenTofu repose sur le paradigme déclaratif : on décrit l’infrastructure cible dans des fichiers HCL (HashiCorp Configuration Language), et l’outil calcule les actions nécessaires pour atteindre cet état. Le cycle de travail suit trois étapes fondamentales :

1. tofu init — Initialise le répertoire de travail, télécharge les providers (plugins qui interfacent avec les API des fournisseurs : Hetzner, OVH, Scaleway, Proxmox, AWS, etc.).

2. tofu plan — Compare l’état actuel (stocké dans un fichier terraform.tfstate) avec la configuration déclarée et affiche les changements prévus : créations, modifications, suppressions.

3. tofu apply — Exécute le plan après confirmation. Les ressources sont créées, modifiées ou détruites via les API des providers.

Ce cycle plan → apply est la clé de voûte du modèle : on ne touche jamais l’infrastructure manuellement, on modifie le code et on laisse l’outil converger vers l’état souhaité.

Exemple concret : provisionner un serveur et son réseau

Voici un exemple minimaliste pour créer un serveur chez Hetzner avec son réseau privé :

terraform {
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.45"
    }
  }
}

variable "hcloud_token" {
  sensitive = true
}

provider "hcloud" {
  token = var.hcloud_token
}

resource "hcloud_network" "internal" {
  name     = "stack-network"
  ip_range = "10.0.0.0/16"
}

resource "hcloud_network_subnet" "services" {
  network_id   = hcloud_network.internal.id
  type         = "cloud"
  network_zone = "eu-central"
  ip_range     = "10.0.1.0/24"
}

resource "hcloud_server" "node1" {
  name        = "node-prod-01"
  server_type = "cx31"
  image       = "ubuntu-22.04"
  location    = "fsn1"

  network {
    network_id = hcloud_network.internal.id
    ip         = "10.0.1.10"
  }
}

output "server_ip" {
  value = hcloud_server.node1.ipv4_address
}

En trois commandes (tofu init, tofu plan, tofu apply), le serveur et le réseau sont créés. L’état est enregistré localement dans terraform.tfstate. Toute modification ultérieure du fichier HCL sera détectée par tofu plan et appliquée de manière incrémentale.

Gérer le state : le nerf de la guerre

Le fichier d’état (.tfstate) est la mémoire d’OpenTofu : il contient la correspondance entre les ressources déclarées et les ressources réelles. En équipe ou en CI/CD, ce fichier doit être partagé et verrouillé. Plusieurs backends sont disponibles : stockage S3 (MinIO pour du auto-hébergé), PostgreSQL, Consul, ou un simple partage NFS sécurisé. OpenTofu ajoute une fonctionnalité absente de Terraform : le chiffrement natif du state, permettant de stocker l’état sur un backend non chiffré sans exposer les secrets qu’il contient.

Intégration dans une stack auto-hébergée

OpenTofu s’intègre naturellement dans une chaîne d’outils existante. Voici un workflow typique :

OpenTofu provisionne les machines, réseaux et volumes (couche infrastructure).

Ansible configure les machines provisionnées : paquets, utilisateurs, clés SSH, Docker (couche configuration).

Docker Compose ou Kubernetes déploie les services applicatifs : CKAN, Keycloak, Nextcloud, Gitea (couche applicative).

Les outputs d’OpenTofu (adresses IP, identifiants réseau) alimentent directement l’inventaire Ansible, créant une chaîne entièrement automatisée du bare metal à l’application.

Modules et réutilisation

Pour éviter la duplication, OpenTofu permet d’encapsuler des ensembles de ressources dans des modules réutilisables. Un module base-server peut créer un serveur, son réseau, son volume de données et ses règles de pare-feu. Il suffit ensuite de l’instancier avec des paramètres différents pour chaque environnement (staging, production). Les modules peuvent être versionnés dans un dépôt Git et référencés directement dans la configuration HCL.

Providers utiles pour l’auto-hébergement

L’écosystème de providers est vaste. Pour une infrastructure open source auto-hébergée, les plus pertinents sont :

• hcloud (Hetzner) — Serveurs, réseaux, load balancers, volumes

• scaleway — Instances, object storage, bases managées

• ovh — Cloud public OVHcloud

• proxmox — VMs et conteneurs sur Proxmox VE

• cloudflare — DNS, tunnels, règles de sécurité

• minio — Buckets et politiques sur MinIO

• postgresql — Bases, rôles et permissions

• keycloak — Realms, clients, mappers d’authentification

Bonnes pratiques

Versionner le code HCL dans Git — Chaque changement d’infrastructure passe par une merge request, avec review et plan automatique en CI.

Séparer les environnements — Utiliser des workspaces ou des répertoires distincts pour staging et production, avec des variables différentes.

Ne jamais modifier le state à la main — Utiliser tofu state mv, tofu import ou tofu state rm pour les opérations de maintenance.

Verrouiller les versions des providers — Le fichier .terraform.lock.hcl garantit la reproductibilité des déploiements.

Activer le chiffrement du state — Fonctionnalité native d’OpenTofu, absente chez Terraform, qui protège les données sensibles au repos.

Pour aller plus loin

La documentation officielle d’OpenTofu est disponible sur opentofu.org/docs. Le registre de providers, hérité de l’écosystème Terraform, reste accessible sur registry.terraform.io — les providers sont compatibles. Pour une migration depuis Terraform, la commande tofu init -migrate-state gère la transition.