Pour les entreprises qui hébergent principalement leurs services dans des systèmes "legacy", le mouvement vers l’Infrastructure-as-code pose la question du choix des outils. Terraform et Ansible sont des outils couramment utilisés dans ce domaine. Mais, quand, comment utiliser Terraform, Ansible? Et devons-nous utiliser les deux?
Remarque importante : cet article ignore intentionnellement Kubernetes et les outils de provisionnement cloud natifs et leur couche d’infrastructure abstraite avancée.
Tout d’abord, remontons un peu dans le temps.
Wikipedia:
"Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. The IT infrastructure managed by this process comprises both physical equipment, such as bare-metal servers, as well as virtual machines, and associated configuration resources…"
Depuis l’origine, le but de l’IaC est de déployer une infrastructure avec des fichiers (description déclarative) représentant des ressources (c’est-à-dire des composants, des variables, etc.). Idéalement, pour suivre les modifications, les fichiers se trouvent dans un dépot de code source.
De nombreux outils existent pour effectuer cette tâche, Ansible et Terraform en font partie.
Mais, avant de comparer, revenons rapidement sur les paradigmes couramment mentionnés dans l’IaC
Lorsqu’on souhaite changer un élément d’une infrastructure existante.
Mutable Dans une infrastructure Mutable : on le met à jour.
Immutable Dans une infrastructure Immutable : on le detruit et on le recrée
Imperatif Specifie le Comment faire? C’est un workflow, une procédure
Declaratif Décrit le Quoi faire? C’est un modéle
Terraform est un outil déclaratif : il atteindra l’état souhaité. Vous trouverez ci-dessous un exemple de provisionnement d’un conteneur Nginx avec Docker et Terraform:
Terraform HCL:
Ansible est un outil impératif, au niveau du module. Il fournit, à plus grande échelle, l’orchestration de modules. Boucle, condition de test, attendre, répétition, détection d’erreur… sont possibles. De la même manière que le langage de codage.
Ansible Yaml :
Terraform
Terraform charge tous les fichiers, binaires, configurations et modules requis. Une fois que tout est configuré, Terraform compare l’état persisté et les objets dans l’infrastructure réelle. Ensuite, Terraform exécute les commandes à appliquer sur cette infrastructure. Enfin, un nouvel état est enregistré.
La communication entre l’interface de ligne de commande Terraform et les hôtes ciblés dépend des fournisseurs. Le protocole entre Terraform et les plugins fournisseurs est gRPC. Les plugins fournisseurs utilisent leur propre API pour interagir avec l’infrastructure.
Ansible
Ansible obtient les dépendances requises pour chaque playbook. Ensuite, il récupère la liste des hôtes cibles à partir de l’inventaire et joue les commandes. Il n’y a pas d’état centralisé, un mécanisme de mise en cache permet l’optimisation et la relecture eventuelle.
La communication avec les hôtes se fait par défaut à l’aide du protocole SSH. Pour le cloud, les plugins Ansible (aws, azure, gcp,…) communiquent avec l’infrastructure de la même manière que les fournisseurs Terraform (via les services web).
Les deux outils disposent d’un registre public pour étendre leur capacité.
Terraform Registry est recent avec approximativement 1500 fournisseurs.
Ansible Galaxy dispose d’un grand nombre d’extensions (rôles, plugins, collections,…), avec environ 30 000 éléments.
Structure de fichiers
Terraform a une structure légère. Des conventions simples sont appliquées.
Ansible a une structure de dossiers/fichiers yml pouvant mener à un projet complexe.
La priorité des variables dans Ansible témoigne de la structure complexe que vous pouvez atteindre.
| Ansible | Terraform | |
|---|---|---|
| Objectif de l’outil | Aider la configuration d’infrastructure à partir de code. | Gerer une infrastructure pour atteindre consistence et predictabilité des déploiements |
| Infrastructure | Mutable: Immutable possible.Depend des modules et de la manière de coder | Immutable: Mise-à-jour de l’infra possible également |
| Language | Yaml, JSON | HCL (DSL Hashicorp), JSON |
| Provisioning | Oui | Oui |
| Configuration | Oui | Oui |
| Orchestration | Oui, bonne capacité d’orchestration des ressources | Oui, partiellement automatique: Depend de l’implémentation des fournisseurs |
| Etat | Non: Un etat existe par module, il est découver pendant l’execution | Oui centralisé: Il est toujours possible d’utiliser Terraform sans état. |
| Idempotence | Depend des modules | Oui |
| Sans Agent | Oui | Oui |
| Cooperation avec d’autres outils | Oui | Oui |
| Language Source | Python | Go |
| Installation | Facile, plusieurs binaires | Facile, un binaire |
| Source Code | https://github.com/ansible/ansible | https://github.com/hashicorp/terraform |
| Language (voir Pulumi qui supporte Python, Go…) | Yaml | HCL or JSON |
| Documentation | Excellente | Excellente |
| OSS Licence | Apache | MPL |
| Popularité (google trends) | Bon | Bon |
| Activité (Github) | Commiters (5K) Stars (50K) | Commiters (1.5K) Stars (30K) |
| Last month: | Last month: | |
| 16 merged Pull Request | 67 merged Pull Request | |
| 25 closed issues | 93 closed issues | |
| Commits/y last 1y: | Commits/y last 1y: | |
| 1230 (24 commits/week) | 1636 (31 commits/week) |
Google Trend : global Search
Google Trend : par pays
| Ansible | Terraform | |
|---|---|---|
| Editeur (VSCode) | Plugin Ansible RedHat (5K installed) | Plugin Terraform Hashicorp (+1.2M installed) |
| Dependency Management | Lors de l’utilisation de modules prêts à l’emploi ou du développement d’éléments : Collections améliore la gestion des dépendances. Aucun depot spécifique n’est nécessaire, les Collections prennent en charge Git et le controle de version | Les fournisseurs publics et les modules sont bien gérés. Meme si Git est pris en charge pour les Modules, pour déployer, un registre privé reste utiler (c’est-à-dire Cloudsmith, Terraform Cloud,…) JFrog, Nexus ne supportent pas encore Terraform |
| Build and run | Préférable d’utiliser les containers | Préférable d’utiliser les containers |
| Orchestration | Vous pouvez enchaîner les tâches Ansible, manuellement. De nombreuses possibilités de controles existent | Terraform gère automatiquement la dépendance et l’orchestration,… jusqu’à ce que vous ayez besoin de lier explicitement des tâches |
| Google Cloud GCP | GCP Ansible Plugin a 171 fonctions supportées | GCP Terraform Providers a 929 fonctions supportées (ce n’est pas 100% de couverture) |
| GCP BigQuery | Ansible implémente SEULEMENT 2 objets: dataset, table | Terraform implémente pratiquement toute l’API: connection, dataset, dataset_access, dataset_iam, data_transfer, job, routine, reservation, table, table_iam |
| AWS | Ansible offre un support faible d’AWS, SEULS ~30 services | Terraform implémente 800 fonctions couvrant bien les services AWS |
| BigIp | Bon support | Bon support |
| OpenStack | Bon support | Bon support |
| | Ansible | Terraform | |
|---|---|---|---|
| Test | Jinja test: Outils externes | no test: Outils externes: Terratest | |
| Securité | pas de RBAC c’est un CLI. Vault builtin existe pour faire de l’encryption | pas de RBAC c’est un CLI. Les données sensibles peuvent etre masquées.Attention à la commande "terraform destroy" qui peut supprimer toute une infrastructure | |
| CICD | Jenkins Ansible & Tower / AWX GitLab GitHub actions (Lint…) | GitLab Jenkins GitHub actions (Lint, Test…) | |
| Interface Web (collaboration, audit, jobs,…) | Tower (AWX version Open Source) | Terraform Cloud (jusqu’à 5 utilisateurs). Terraform Enterprise |
Terraform et Ansible sont des CLI, il est recommandé d’exécuter le code dans l’outil CICD et/ou dans un conteneur pour lier au contexte de l’entreprise (droits d’accès, configurations, secrets…)
Terraform autorise de détruire toute l’infrastructure en une seule commande : « terraform destroy », il est fortement recommandé de protéger l’accès à l’interface de ligne de commande.
FORCE
ANSIBLE
TERRAFORM
FAIBLESSE
ANSIBLE
TERRAFORM
Comment choisir le bon outil?
C’est la première question à se poser : à quelle couche voulez-vous dédier votre outil?
Terraform est le meilleur outil pour la gestion des ressources Cloud
Evaluer vos besoins:
Ansible a plus de flexibilité et un énorme support sur les systèmes "legacy".
Êtes-vous prêt à adopter des pratiques édictées dans GitOps?
Terraform n’est pas suffisant pour implémenter GitOps, Ansible est en retrait, notamment sans implémention d’état centralisé.
Le scénario pour avoir les deux ensemble est également couramment utilisé.
Exemple "reconstruire une infrastructure entière à partir de zéro" :