16 commentaires
Le problème de Terraform, c'est l'abstraction. Dès que tu veux faire un truc un peu spécifique que le provider ne supporte pas nativement, tu es coincé. Avec Ansible, tu écris un module custom en Python et c'est réglé.
Entièrement d'accord avec l'auteur. Le terraform plan est indispensable pour dormir tranquille. Ansible ne te donne aucune visibilité sur ce qui va être détruit avant de lancer l'exécution.
Vous oubliez la simplicité de la courbe d'apprentissage. Pour une petite équipe, apprendre le hcl et gérer le backend S3, c'est une barrière à l'entrée. Un playbook simple, tout le monde comprend.
Le vrai débat n'est pas l'un contre l'autre, mais l'usage complémentaire. Terraform pour le IaaS, Ansible pour le paramétrage OS et les middlewares.
L'immuabilité c'est bien sur le papier, mais en cas de patch de sécurité critique en urgence, un playbook Ansible est beaucoup plus rapide à déployer qu'une nouvelle image complète.
La gestion du state est le talon d'Achille de Terraform. Si tu perds ton fichier d'état, tu es dans une galère sans nom. Ansible n'a pas ce risque.
Et pour le multi-cloud ? Le provider AWS de Terraform est top, mais dès que tu mélanges avec du GCP, ça devient complexe à gérer dans un seul repo.
Je pense qu'on tourne en rond. L'outil dépend de la maturité de l'équipe. Si tu as des devs qui veulent gérer l'infra, Terraform est plus proche de leur logique de code.
Laisser une réponse
Vous devez être connecté pour poster un message !
Je vois encore trop d'équipes essayer de tout faire avec Ansible. Pour moi, utiliser Ansible pour provisionner des ressources cloud est une erreur stratégique monumentale en 2024. Terraform est fait pour le cycle de vie de l'infra, point barre.
Pourquoi s'obstiner à gérer des états complexes avec des playbooks qui finissent par être des usines à gaz ? Est-ce que vous trouvez vraiment que la gestion du state via des fichiers distants ou le
terraform.tfstateest plus pénible que de maintenir l'idempotence sur des centaines de tâches Ansible ?