OpenTofu : gérer votre flotte de VPS en Infrastructure as Code

Rendez-vous sur opentofu.org/docs/intro/install pour les instructions selon votre OS. Sur macOS avec Homebrew : brew install opentofu. Sur Debian/Ubuntu : le dépôt officiel OpenTofu fournit le paquet opentofu. Vérifiez l'installation avec tofu version — la commande doit retourner la version installée.

Créez un répertoire dédié et quatre fichiers standards.

# main.tf — ressources principales
# variables.tf — déclarations de variables
# outputs.tf — valeurs exposées après apply
# terraform.tfvars — valeurs concrètes (gitignorer si secrets)

Cette structure n'est pas obligatoire pour OpenTofu, mais elle est la convention largement adoptée : main.tf porte les ressources, variables.tf déclare les types et valeurs par défaut, outputs.tf expose ce qu'Ansible ou un autre outil doit lire après le provisionnement (IP du serveur, nom d'hôte…), et terraform.tfvars contient les valeurs concrètes que vous ne souhaitez pas coder en dur dans main.tf.

OpenTofu installe les providers nécessaires au tofu init. Le provider hashicorp/tls génère une paire de clés SSH en local, ce qui évite de gérer des clés manuellement.

terraform {
  required_providers {
    tls = {
      source  = "hashicorp/tls"
      version = "~> 4.0"
    }
  }
}

resource "tls_private_key" "vps_key" {
  algorithm = "ED25519"
}

output "private_key_pem" {
  value     = tls_private_key.vps_key.private_key_pem
  sensitive = true
}

Lancez tofu init pour télécharger le provider, puis tofu apply pour générer la clé. Récupérez-la avec tofu output -raw private_key_pem > ~/.ssh/vps_key && chmod 600 ~/.ssh/vps_key.

Si votre fournisseur VPS n'a pas de provider OpenTofu officiel, le provider hashicorp/null avec un local-exec permet d'exécuter une commande locale (un appel API curl, un script shell) et de modéliser la ressource dans le state.

resource "null_resource" "vps_provision" {
  triggers = {
    server_name = var.server_name
  }

  provisioner "local-exec" {
    command = <<EOT
      curl -s -X POST https://api.votre-fournisseur.com/v1/servers \
        -H "Authorization: Bearer ${var.api_token}" \
        -d '{"name": "${var.server_name}", "image": "ubuntu-22.04"}'
    EOT
  }
}

Ce pattern est adapté à une phase transitoire. Si votre fournisseur expose une API REST, un script shell appelé en local-exec suffit pour créer le serveur et écrire son IP dans un fichier que outputs.tf exposera ensuite.

Une fois le VPS provisionné et Docker installé (par Ansible, typiquement), le provider kreuzwerker/docker vous permet de déclarer des conteneurs, des réseaux et des volumes dans OpenTofu.

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 3.0"
    }
  }
}

provider "docker" {
  host = "ssh://root@${var.server_ip}:22"
}

resource "docker_container" "app" {
  name  = "mon-app"
  image = docker_image.app.image_id
}

resource "docker_image" "app" {
  name = "nginx:alpine"
}

Le provider se connecte au daemon Docker du VPS via SSH — aucun port TCP supplémentaire à ouvrir. La version stable du provider est disponible sur le Terraform Registry.

En développement solo, le state local (terraform.tfstate) suffit. En équipe ou en CI/CD, deux développeurs qui lancent tofu apply simultanément corrompent le state. La solution est un backend distant avec verrouillage.

OpenTofu supporte nativement S3 (AWS, MinIO auto-hébergé) et le GitLab Managed Terraform State. Avec un bucket MinIO sur un VPS :

terraform {
  backend "s3" {
    bucket                      = "tofu-state"
    key                         = "production/terraform.tfstate"
    region                      = "eu-west-1"
    endpoint                    = "https://minio.votre-domaine.com"
    skip_credentials_validation = true
    skip_metadata_api_check     = true
    skip_region_validation      = true
    force_path_style            = true
  }
}

Le verrouillage est automatique : si un tofu apply est en cours, un second est refusé jusqu'à la fin du premier.

Un pipeline Woodpecker CI ou Forgejo Actions typique exécute tofu plan sur chaque pull request (pour revue humaine du diff d'infrastructure) et tofu apply sur merge dans la branche principale.

steps:
  - name: tofu-plan
    image: ghcr.io/opentofu/opentofu:latest
    commands:
      - tofu init
      - tofu plan -out=tfplan

  - name: tofu-apply
    image: ghcr.io/opentofu/opentofu:latest
    commands:
      - tofu apply tfplan
    when:
      branch: main
      event: push

Le state distant (étape précédente) est indispensable ici : le runner CI n'a pas accès au state local de votre poste.