# Terraform contre Ansible pour provisionner l’infrastructure d’un parc WordPress

> Avant même d'installer WordPress, comparer l'approche déclarative de Terraform et l'approche impérative d'Ansible pour créer les serveurs d'un parc.

- Auteur : Clément Hadrot
- Publié le : 2024-02-03
- Mis à jour le : 2024-02-03
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/terraform-ansible-provisionner-infrastructure/

## L’essentiel

- Terraform décrit un état final, Ansible décrit une suite d'actions
- Terraform excelle à créer et détruire des serveurs
- Ansible reste imbattable pour configurer ce qui tourne dessus

Une agence qui gère une quinzaine de VPS chez différents hébergeurs, pour des clients aux besoins hétérogènes, finit toujours par se poser la même question : comment créer et faire évoluer ces serveurs sans repasser par l'interface web de chaque fournisseur ? La réponse ne se limite pas à choisir un outil, elle demande de comprendre à quel étage du problème chaque outil intervient.

Terraform et Ansible sont souvent présentés comme concurrents, alors qu'ils répondent à deux questions différentes. Terraform répond à « quels serveurs doivent exister, avec quelles ressources ? ». Ansible répond à « une fois que ce serveur existe, comment doit-il être configuré ? ». Comprendre cette frontière évite bien des débats stériles en réunion technique.

## Déclaratif contre impératif, ce que ça change concrètement

Terraform fonctionne en mode déclaratif : un fichier décrit l'état souhaité de l'infrastructure, et l'outil calcule lui-même la différence entre cet état et la réalité actuelle, puis applique les changements nécessaires. Demander trois serveurs et en obtenir cinq à cause d'une exécution précédente mal terminée n'arrive pas : Terraform détruira les deux serveurs en trop pour revenir à l'état décrit.

Ansible fonctionne en mode principalement impératif : un playbook décrit une suite d'étapes à exécuter, dans l'ordre. Certains modules Ansible sont idempotents, ce qui limite les effets de bord d'une réexécution, mais l'outil ne raisonne pas nativement en termes d'état cible global comme le fait Terraform.

## Créer les serveurs avec Terraform

Pour la seule création d'infrastructure, avant toute installation de WordPress, un fichier Terraform typique chez un hébergeur comme Hetzner Cloud ressemble à ceci :

> L'essentiel à retenir : Terraform décrit un état final, Ansible décrit une suite d'actions ; Terraform excelle à créer et détruire des serveurs ; Ansible reste imbattable pour configurer ce qui tourne dessus

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

variable "hcloud_token" {
  sensitive = true
}

provider "hcloud" {
  token = var.hcloud_token
}

resource "hcloud_server" "site" {
  for_each    = toset(["boutique-nord", "boutique-sud", "boutique-est"])
  name        = each.key
  server_type = "cx22"
  image       = "debian-12"
  location    = "nbg1"

  ssh_keys = [hcloud_ssh_key.deploiement.id]
}

resource "hcloud_ssh_key" "deploiement" {
  name       = "cle-deploiement-agence"
  public_key = file("~/.ssh/deploiement_agence.pub")
}

output "adresses_ip" {
  value = { for k, s in hcloud_server.site : k => s.ipv4_address }
}
```

La boucle `for_each` permet de créer trois serveurs identiques à partir d'une seule déclaration de ressource. Ajouter un quatrième site revient à ajouter une chaîne à l'ensemble, sans dupliquer de bloc. C'est là que Terraform gagne en confort dès qu'un parc dépasse deux ou trois serveurs.

## Configurer le serveur avec Ansible

Une fois le serveur créé et son adresse IP connue, la suite du travail, installation de Nginx, PHP-FPM, MariaDB, configuration des utilisateurs système, relève d'Ansible :

```
- hosts: nouveaux_serveurs
  become: true
  tasks:
    - name: Installer les paquets de base
      apt:
        name:
          - nginx
          - php8.2-fpm
          - php8.2-mysql
          - mariadb-server
        state: present
        update_cache: true

    - name: Créer l'utilisateur de déploiement
      user:
        name: deploiement
        groups: www-data
        shell: /bin/bash

    - name: Déposer la configuration Nginx du site
      template:
        src: templates/site.conf.j2
        dest: /etc/nginx/sites-available/{{ inventory_hostname }}.conf
      notify: recharger nginx

  handlers:
    - name: recharger nginx
      service:
        name: nginx
        state: reloaded
```

Ce découpage se justifie par la nature même des deux tâches : créer un serveur est une opération rare, généralement suivie d'une destruction propre en fin de vie. Configurer ce qui tourne dessus est une opération répétée, ajustée au fil du temps, avec des variations fines selon le client. Le langage impératif d'Ansible, avec ses modules riches pour la gestion de paquets, de fichiers de configuration et de services, colle mieux à ce second besoin.

## Tableau comparatif

| Critère | Terraform | Ansible |
| --- | --- | --- |
| Paradigme | Déclaratif, état cible | Impératif, suite d'étapes |
| Détection de dérive | Native (`terraform plan`) | Limitée, dépend des modules |
| Multi-fournisseur cloud | Excellent, via providers | Possible, moins naturel |
| Configuration fine d'un serveur | Faible | Excellent |
| Courbe d'apprentissage | Modérée (HCL) | Faible (YAML) |

## Ce que l'agence fait vraiment

En pratique, les deux outils cohabitent sans concurrence réelle : Terraform crée et détruit les serveurs chez Hetzner, OVH ou Scaleway selon le client, avec un seul jeu de fichiers réutilisé d'un fournisseur à l'autre grâce à l'abstraction des providers. Une fois l'adresse IP obtenue en sortie de Terraform, un inventaire Ansible généré automatiquement déclenche la configuration logicielle. L'installation de WordPress lui-même, avec ses spécificités par client, reste un sujet à part entière traité séparément.

> Demander à Terraform de configurer finement un serveur, ou à Ansible de garantir un état d'infrastructure cible, revient à utiliser un tournevis pour planter un clou : ça marche parfois, mais ce n'est pas l'outil fait pour ça.

## Notre verdict

Aucun des deux outils ne remplace l'autre sur un parc WordPress géré sérieusement. Terraform s'impose dès que le nombre de serveurs dépasse deux ou trois, ou que plusieurs fournisseurs cloud entrent en jeu. Ansible reste la meilleure option pour tout ce qui touche à la configuration logicielle du serveur une fois qu'il existe. Les agences qui choisissent l'un contre l'autre, plutôt que les deux ensemble, finissent généralement par réinventer maladroitement les fonctionnalités de celui qu'elles ont écarté.