Terraform vs. Ansible : lequel avez-vous vraiment besoin ?

Les personnes nouvelles dans Infrastructure as Code posent généralement cette question de deux façons : « quel outil devrais-je apprendre en premier » ou « pourquoi les équipes utilisent-elles les deux ». La réponse courte est que Terraform et Ansible résolvent des problèmes différents, et la plupart des environnements de production les utilisent ensemble plutôt que d'en choisir un.

À quoi Terraform sert vraiment

Terraform est un outil de provisioning. Il déclare l'infrastructure qui devrait exister : un VPC, trois instances EC2, une base de données RDS, un bucket S3 avec une politique spécifique. Vous écrivez du HCL décrivant l'état final, exécutez terraform plan pour voir ce qui va changer, puis terraform apply pour que cela se produise. Terraform conserve un fichier d'état (localement ou dans un backend comme un bucket S3 avec verrouillage DynamoDB) qui mappe votre configuration aux ID de ressources réels chez le fournisseur cloud.

La force ici est la résolution des dépendances entre les fournisseurs. Si vous dites à Terraform de créer un groupe de sécurité puis de l'attacher à une instance EC2, il figure l'ordre automatiquement. Il fonctionne aussi sur AWS, Azure, GCP, Cloudflare, Datadog et des dizaines d'autres fournisseurs selon le même workflow, ce qui importe une fois que votre infrastructure s'étend sur plus d'un fournisseur.

Terraform est mauvais pour tout ce qui se passe à l'intérieur de la machine une fois qu'elle existe. Il n'installe pas de paquets, n'édite pas de fichiers de configuration, et ne redémarre pas les services de façon continue et significative. Des provisionneurs comme remote-exec existent mais HashiCorp lui-même recommande de les éviter pour tout ce qui dépasse l'amorçage initial.

À quoi Ansible sert vraiment

Ansible est un outil de gestion de configuration. Il se connecte via SSH (ou WinRM pour Windows) et exécute des tâches sur des machines qui existent déjà : installer nginx, générer un fichier de configuration, créer un utilisateur, redémarrer un service, garantir qu'une tâche cron est présente. Les playbooks sont en YAML, et les modules sont idempotents par conception, donc exécuter le même playbook deux fois ne devrait rien changer la deuxième fois si le système correspond déjà à l'état souhaité.

Ansible n'a besoin d'aucun agent installé sur les hôtes cibles, juste Python et un accès SSH, ce qui le rend facile à adapter à une infrastructure existante. C'est aussi bon pour les tâches d'orchestration qui ne sont pas strictement du « provisioning » — redémarrages progressifs sur une flotte, étapes de déploiement bleu-vert, exécuter une migration de base de données sur un hôte puis mettre à jour un équilibreur de charge.

Où ils se chevauchent et où les gens se trompent

Les deux outils peuvent techniquement faire un peu du travail de l'autre. Ansible a des modules cloud (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) qui peuvent lancer de l'infrastructure. Terraform a des provisionneurs qui peuvent exécuter des commandes shell sur une nouvelle instance. Mais utiliser Ansible pour le provisioning signifie renoncer au suivi d'état et au workflow plan/diff de Terraform, et utiliser les provisionneurs Terraform pour la configuration signifie renoncer à la gestion de configuration idempotente et répétable.

La division pratique sur laquelle la plupart des équipes se règlent :

• Terraform construit l'infrastructure : réseaux, instances de calcul, équilibreurs de charge, bases de données gérées, rôles IAM.
• Ansible configure ce qu'il y a dessus : installations de logiciels, utilisateurs, fichiers de configuration, état des services, étapes de déploiement d'applications.

Un exemple concret de la transition

Supposons que vous mettez en place trois serveurs web derrière un équilibreur de charge sur AWS.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform crée les instances et affiche leurs adresses IP. Vous pouvez alimenter cet affichage dans un inventaire Ansible dynamique (le plugin d'inventaire amazon.aws.aws_ec2 lit les tags EC2 directement, pas besoin de copier-coller manuel) puis exécuter :

ansible-playbook -i aws_ec2.yml site.yml

où site.yml installe nginx, place la configuration de l'app, et démarre le service. Terraform ne touche jamais à nginx. Ansible ne touche jamais au VPC. Chaque outil reste dans sa zone, et chacun a son propre modèle d'état/d'idempotence qui ne rentre pas en conflit avec celui de l'autre.

Les erreurs courantes à éviter

Store Terraform state in git est l'erreur la plus courante au départ — les fichiers d'état peuvent contenir des secrets en plaintext et causer des conflits de fusion qui corrompent votre modèle d'infrastructure. Utilisez un backend distant dès le début.

Avec Ansible, l'erreur est d'écrire des playbooks qui ne sont pas vraiment idempotents — utiliser les modules shell ou command pour des choses qui ont un module approprié (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) qui gère déjà correctement la logique vérifier-puis-agir.

Si vous décidez quoi apprendre en premier : apprenez Terraform si vous faites du provisioning cloud et des configurations multi-environnements, apprenez Ansible si vous gérez la dérive de configuration sur des serveurs que vous avez déjà. La plupart des rôles DevOps s'attendent à une connaissance des deux dans la première année.

Pour plus d'informations sur la gestion d'état, les inventaires dynamiques et la construction d'un pipeline CI/CD complet autour de ces outils, consultez les segments DevOps et Cloud associés sur Korra Studio.