Ansible vs Terraform

Dans l’univers DevOps, les outils d’automatisation et de gestion d’infrastructure se multiplient, mais certains noms reviennent souvent en tête, comme Terraform et Ansible. Chacun de ces outils a ses adeptes et soulève régulièrement des débats : faut-il utiliser l’un ou l’autre, ou peuvent-ils être employés ensemble ?

Terraform est reconnu pour sa capacité à provisionner des infrastructures complexes sur différents environnements cloud grâce à une approche déclarative. De son côté, Ansible se distingue par sa simplicité dans la gestion de configuration, l’automatisation des tâches et son architecture sans agent.

Dans ce billet, je vais analyser en détail ces deux outils, leurs fonctionnalités respectives, leurs forces et leurs limites. Nous allons voir si ces solutions sont réellement en opposition ou si, au contraire, elles peuvent se compléter pour offrir une gestion automatisée de l’infrastructure et des configurations. En explorant leurs usages et leurs approches, il sera possible de juger s’il est pertinent de choisir entre les deux ou de les utiliser de manière conjointe.

Analyse de Terraform

Terraform est un outil d’Infrastructure as Code (IaC) développé par HashiCorp qui permet de définir, provisionner et gérer des infrastructures cloud de manière automatisée. Il adopte une approche déclarative, ce qui signifie que l’utilisateur décrit l’état final souhaité de l’infrastructure dans un fichier de configuration, et Terraform se charge de créer ou de modifier les ressources nécessaires pour atteindre cet état.

Fonctionnement de Terraform

Terraform utilise des fichiers de configuration écrits en HCL (HashiCorp Configuration Language) pour décrire l’infrastructure. Chaque ressource est définie avec des attributs spécifiques, comme les types de machines virtuelles, les réseaux, les groupes de sécurité, etc. Ces fichiers sont ensuite utilisés pour provisionner les ressources sur divers fournisseurs de cloud, tels qu’AWS, Azure, Google Cloud, mais aussi des environnements on-premises comme VMware ou OpenStack.

L’une des caractéristiques clés de Terraform est sa gestion d’un fichier d’état. Ce fichier, appelé “terraform.tfstate”, permet à Terraform de suivre l’état actuel de l’infrastructure provisionnée et de comparer cet état avec celui défini dans les fichiers de configuration. Grâce à cela, Terraform peut déterminer les actions nécessaires pour amener l’infrastructure vers l’état désiré, comme ajouter, modifier ou détruire des ressources. Cela permet une gestion efficace des changements et une réduction des erreurs manuelles.

Exemple d’utilisation :

Prenons un exemple concret où Terraform est utilisé pour provisionner une machine virtuelle sur AWS.

provider "aws" {
  region = "us-west-2"
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Dans cet exemple, Terraform définit une instance EC2 en spécifiant l’image AMI et le type d’instance. En exécutant la commande terraform apply, Terraform provisionne l’instance dans la région spécifiée (ici, us-west-2). Si des modifications sont faites au fichier de configuration, Terraform peut automatiquement ajuster l’infrastructure en fonction de ces changements lors d’une exécution future.

Avantages de Terraform

Un des grands avantages de Terraform est sa capacité à gérer des infrastructures multicloud. Cela signifie qu’il est possible, dans un même fichier de configuration, de provisionner des ressources sur plusieurs fournisseurs cloud. Par exemple, on peut créer des serveurs sur AWS et configurer une base de données sur Azure avec une seule commande.

Terraform est également particulièrement utile dans des environnements hybrides ou multienvironnements. Grâce à sa compatibilité avec de nombreux fournisseurs, il est facile d’adapter la configuration pour orchestrer une infrastructure complète sur différents environnements.

Utilisation dans un workflow DevOps

Terraform s’intègre parfaitement dans un pipeline CI/CD (intégration continue/déploiement continu) pour automatiser la gestion de l’infrastructure. Par exemple, dans un workflow DevOps classique, Terraform peut être utilisé pour :

• Provisionner un environnement de développement ou de production.
• Mettre à jour une infrastructure lors du déploiement d’une nouvelle version d’une application.
• Détruire les ressources une fois un environnement temporaire (staging ou test) n’est plus nécessaire.

La possibilité d’intégrer Terraform à des outils comme Jenkins, Gitlab CI ou GitHub Actions permet une orchestration fluide du provisionnement d’infrastructure dans le cadre d’une livraison continue.

Limites de Terraform

Malgré ses nombreux avantages, Terraform présente certaines limites. Par exemple, bien qu’il soit très efficace pour le provisionnement des ressources, il n’est pas conçu pour la gestion de configuration des machines après leur création. Cela signifie qu’il ne peut pas, à lui seul, installer des logiciels ou configurer des serveurs une fois provisionnés. C’est à ce stade qu’un outil comme Ansible devient nécessaire pour compléter Terraform et automatiser ces tâches.

Un point important à aborder concernant Terraform est l’utilisation des provisioners, en particulier le provisioner “local-exec” ou “remote-exec”, souvent utilisé pour exécuter des scripts shell directement sur les machines provisionnées. Bien que les provisioners puissent sembler pratiques pour configurer des machines ou exécuter des scripts après leur création, la documentation officielle de Terraform met en garde contre leur usage excessif.

Terraform est avant tout conçu pour la gestion déclarative de l’infrastructure, et non pour la gestion de la configuration des systèmes après leur provisionnement. Les provisioners peuvent être vus comme un mécanisme de “dernier recours” pour des actions qui ne peuvent pas être prises en charge par les ressources natives de Terraform. Cependant, ils présentent plusieurs limites importantes :

1. Imprévisibilité et échec non traçable : Les provisioners, en particulier ceux qui exécutent des scripts shell, ne s’intègrent pas bien dans le modèle déclaratif de Terraform. Si un script échoue, Terraform peut ne pas être capable de gérer proprement cet échec ou de savoir comment restaurer l’état précédent, ce qui peut entraîner des incohérences dans l’infrastructure.
2. Non-idempotence : Contrairement aux ressources natives de Terraform, qui sont idempotentes (c’est-à-dire qu’elles peuvent être appliquées plusieurs fois sans changer l’état final), les scripts shell exécutés via des provisioners ne garantissent pas cet état. Si un script est exécuté une deuxième fois, il peut potentiellement produire des résultats indésirables ou des erreurs.
3. Problèmes de gestion à grande échelle : Lorsque l’infrastructure est étendue, l’utilisation massive de provisioners pour exécuter des scripts sur de nombreux serveurs devient difficile à maintenir. De plus, Terraform n’est pas conçu pour gérer les dépendances complexes liées aux scripts shell, ce qui rend la gestion des changements et des erreurs plus délicate.

La documentation officielle de Terraform recommande fortement d’utiliser des outils dédiés à la gestion de configuration, comme Ansible, Chef, ou Puppet, pour accomplir ces tâches après le provisionnement de l’infrastructure. Ces outils sont conçus pour gérer la configuration des machines de manière idempotente, suivre l’état des systèmes, et garantir la cohérence des configurations, ce qui n’est pas le rôle premier de Terraform.

En résumé, les provisioners doivent être utilisés avec prudence. Ils sont utiles pour des actions spécifiques et uniques, mais pour la gestion à long terme des configurations ou des modifications régulières sur les systèmes, il est conseillé d’intégrer un outil comme Ansible. Ce dernier, en complément de Terraform, permet d’assurer que l’infrastructure est correctement provisionnée, et que les machines sont configurées de manière fiable et idempotente.

Analyse d’Ansible

Ansible est un outil open-source d’automatisation de la configuration, de gestion des serveurs et d’orchestration des déploiements, développé par Red Hat. Il se distingue par sa simplicité, son architecture sans agent (agentless) et son utilisation d’un langage impératif basé sur des fichiers YAML, appelés playbooks.

Fonctionnement d’Ansible

Ansible permet de déployer et configurer des systèmes à grande échelle sans nécessiter d’installation d’agents sur les serveurs gérés. Il utilise le protocole SSH (ou WinRM pour les environnements Windows) pour se connecter à distance aux machines et exécuter les tâches définies dans les playbooks.

Les playbooks sont au cœur de l’automatisation avec Ansible. Ils sont écrits en YAML, un langage lisible par les humains, ce qui les rend faciles à comprendre et à modifier. Les playbooks décrivent des tâches qui spécifient l’état dans lequel les systèmes doivent être mis. Chaque tâche est exécutée dans un ordre séquentiel et Ansible garantit que les configurations appliquées sont idempotentes, c’est-à-dire qu’elles peuvent être exécutées plusieurs fois sans provoquer de changements inutiles.

Exemple de Playbook Ansible

Voici un exemple simple de playbook Ansible qui installe et configure Apache sur une machine Debian ou Ubuntu.

---
- name: Installer et configurer Apache
  hosts: webservers
  become: true
  tasks:
    - name: Installer Apache
      ansible.builtin.apt:
        name: apache2
        state: present

    - name: Démarrer et activer Apache au démarrage
      ansible.builtin.service:
        name: apache2
        enabled: true
        state: started

Dans cet exemple, Ansible se connecte à une liste de serveurs définie dans l’inventaire (ici, les serveurs sous le groupe webservers) et exécute les tâches : installer Apache, puis démarrer le service et s’assurer qu’il est activé au démarrage. Ansible s’assure également que ces actions sont idempotentes, c’est-à-dire que l’état final sera le même, même si la tâche est exécutée plusieurs fois.

Avantages d’Ansible

1. Facilité d’utilisation : Ansible est reconnu pour sa simplicité. Il n’y a pas de dépendances complexes ni de logiciels à installer sur les systèmes gérés. Seul un accès SSH est nécessaire.
2. Architecture sans agent : Contrairement à d’autres outils de gestion de configuration comme Chef ou Puppet, Ansible ne nécessite pas d’agents installés sur les machines cibles. Cela réduit considérablement la complexité de gestion et facilite le déploiement rapide sur de nouveaux systèmes.
3. Idempotence : Les tâches dans Ansible sont conçues pour être idempotentes, ce qui signifie qu’elles peuvent être appliquées plusieurs fois sans provoquer de modifications imprévues si le système est déjà dans l’état souhaité. Cela permet de garantir que les configurations sont appliquées de manière fiable.
4. Polyvalence : Ansible peut gérer à la fois des serveurs Linux et Windows, ainsi que des équipements réseau, des containers, et même des services cloud. Cela en fait un outil flexible pour divers types d’automatisation.

Utilisation dans un Workflow DevOps

Ansible s’intègre aisément dans un pipeline CI/CD pour automatiser les processus de déploiement d’applications et la gestion de la configuration. Par exemple, dans un workflow typique, Ansible pourrait être utilisé pour :

• Configurer des serveurs avant le déploiement d’une application.
• Orchestrer le déploiement d’une nouvelle version de logiciel sur plusieurs machines en parallèle.
• Gérer les mises à jour régulières de logiciels ou de packages de sécurité sur des clusters de serveurs.

L’intégration avec des outils comme Jenkins, b CI, ou GitHub Actions permet à Ansible de déclencher des automatisations lors des étapes de build ou de déploiement, garantissant ainsi des configurations homogènes sur tous les environnements (développement, test, production).

Limites d’Ansible

Bien qu’Ansible soit extrêmement puissant pour la gestion de la configuration et l’automatisation des déploiements, il présente certaines limites, notamment en ce qui concerne la gestion de l’état.

1. Absence de gestion de l’état : Contrairement à Terraform, Ansible n’a pas de fichier d’état natif. Cela signifie qu’il ne garde pas de trace de l’état des systèmes après avoir appliqué une configuration. Chaque exécution du playbook se base uniquement sur les informations présentes à ce moment-là. Cela peut poser des problèmes lorsque les systèmes changent en dehors du contrôle d’Ansible (modifications manuelles ou via d’autres outils). Si un état change après l’exécution d’un playbook, Ansible n’a pas de mécanisme pour détecter ces changements, sauf si la tâche est explicitement ré-exécutée.
2. Moins adapté pour le provisionnement d’infrastructure : Ansible peut être utilisé pour créer des ressources sur des fournisseurs cloud via des modules spécifiques (comme ec2, azure_rm ou gcp_compute), mais cette utilisation est moins fluide et intuitive que Terraform. Ansible est optimisé pour la gestion de la configuration après le provisionnement, et n’est pas conçu pour gérer l’infrastructure à grande échelle ou pour maintenir un suivi des changements de cette infrastructure.
3. Gestion des dépendances et des rôles complexes : Ansible est extrêmement flexible, mais la gestion de configurations complexes, avec de nombreux rôles, modules et dépendances, peut parfois devenir difficile à maintenir sans une bonne organisation des playbooks. Il est également nécessaire d’avoir une structure de fichiers bien définie, ce qui peut rendre la gestion de projets Ansible plus complexe au fur et à mesure qu’ils grandissent.

Recommandation

En résumé, Ansible est un outil puissant pour la gestion de la configuration, l’installation de logiciels et l’automatisation des tâches répétitives sur des serveurs ou autres systèmes. Il est particulièrement bien adapté à des environnements où la configuration des systèmes doit être constamment maintenue et où les changements doivent être appliqués de manière idempotente.

Cependant, son absence de gestion native de l’état en fait un choix moins adapté pour le provisionnement d’infrastructures à grande échelle ou pour des scénarios où il est nécessaire de maintenir une vue continue de l’état des ressources. Dans ces cas, il est recommandé d’utiliser Ansible en complément d’un outil comme Terraform, qui excelle dans la gestion déclarative des infrastructures et le suivi des états.

Comparaison des Approches : Déclarative vs Impérative

Lorsqu’on compare Terraform et Ansible, l’une des principales différences réside dans leur approche de gestion des ressources et des configurations. Terraform adopte une approche déclarative, tandis qu’Ansible suit une approche impérative. Chacune de ces approches a ses avantages et ses inconvénients, et leur choix dépend souvent des besoins spécifiques du projet ou de l’organisation.

L’approche Déclarative de Terraform

Avec Terraform, la gestion de l’infrastructure suit un modèle déclaratif. Cela signifie que l’utilisateur définit simplement l’état final souhaité de l’infrastructure, et Terraform s’occupe de déterminer les actions nécessaires pour atteindre cet état. Cette approche repose sur le principe que l’infrastructure doit ressembler à un schéma défini à l’avance, et ce schéma est ensuite appliqué de manière déterministe.

Par exemple, si vous souhaitez qu’un serveur spécifique ait une certaine configuration (comme une machine virtuelle de type t2.micro sur AWS avec une IP publique et un certain groupe de sécurité), vous le décrivez dans un fichier de configuration HCL :

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Terraform compare alors cet état souhaité avec l’état actuel de l’infrastructure (qui est suivi dans son fichier d’état) et applique les changements nécessaires pour aligner les deux. Par exemple, si l’instance n’existe pas encore, Terraform la crée. Si elle existe mais avec des modifications (par exemple, une taille de machine différente), Terraform ajustera l’infrastructure pour qu’elle corresponde à la configuration déclarée.

Avantages de l’approche déclarative

1. Gestion simplifiée des changements : L’utilisateur n’a pas besoin de se soucier de l’ordre des opérations ou des détails spécifiques sur la manière de créer ou de supprimer des ressources. Terraform s’en charge automatiquement en fonction de l’écart entre l’état actuel et l’état désiré.
2. Vision claire de l’infrastructure : L’approche déclarative fournit une vue d’ensemble claire de ce à quoi ressemble l’infrastructure à tout moment. Cela simplifie les révisions de code, les discussions techniques et les audits de sécurité.
3. Gestion des dépendances : Terraform gère automatiquement les dépendances entre les ressources. Par exemple, si vous avez une instance EC2 qui dépend d’un sous-réseau, Terraform s’assure que le sous-réseau est créé avant l’instance.
4. Idempotence naturelle : L’état final étant décrit de manière déclarative, Terraform garantit que chaque exécution amène l’infrastructure dans l’état souhaité, quelle que soit la situation initiale.

Inconvénients de l’approche déclarative

1. Moins de flexibilité : L’approche déclarative peut sembler rigide dans certains cas, car vous décrivez l’état final plutôt que les étapes pour y parvenir. Cela peut poser problème lorsque vous avez besoin d’un contrôle granulaire sur les étapes intermédiaires.
2. Dépendance au fichier d’état : Terraform repose sur un fichier d’état (terraform.tfstate), qui doit être maintenu et sécurisé. Si ce fichier est corrompu ou perdu, Terraform peut perdre la trace de l’infrastructure, ce qui peut entraîner des erreurs lors de futures modifications.

L’approche Impérative d’Ansible

En contraste, Ansible adopte une approche impérative. Cela signifie que vous décrivez précisément chaque étape nécessaire pour configurer un système ou appliquer une modification. Chaque tâche dans un playbook Ansible représente une action spécifique, et les tâches sont exécutées dans l’ordre où elles sont définies.

Par exemple, pour installer un serveur web avec Ansible, vous devez spécifier chaque étape, comme l’installation d’Apache, la configuration du pare-feu, puis le démarrage du service :

---
- hosts: webservers
  tasks:
    - name: Installer Apache
      ansible.builtin.apt:
        name: apache2
        state: present

    - name: Démarrer Apache
      ansible.builtin.service:
        name: apache2
        state: started

Chaque tâche dans ce playbook correspond à une action impérative : “installer Apache”, “démarrer Apache”, etc. Vous dites explicitement à Ansible ce qu’il doit faire et dans quel ordre.

Avantages de l’approche impérative

1. Contrôle précis des opérations : L’approche impérative vous donne un contrôle total sur les opérations que vous souhaitez exécuter et leur ordre. Cela permet de gérer facilement des processus complexes, étape par étape.
2. Flexibilité : Ansible permet une flexibilité accrue dans la gestion de tâches spécifiques. Vous pouvez ajuster les processus au fur et à mesure, sans devoir redéfinir l’état final global.
3. Aucune dépendance à un fichier d’état : Contrairement à Terraform, Ansible n’a pas besoin de fichier d’état pour suivre l’infrastructure. Il exécute simplement les tâches définies dans le playbook chaque fois qu’il est lancé, sans avoir à maintenir une vision complète de l’infrastructure.

Inconvénients de l’approche impérative

1. Moins de clarté globale : Dans un playbook Ansible, chaque tâche représente une action, mais cela ne donne pas une vision complète de l’état final souhaité du système. Il est plus difficile de comprendre en un coup d’œil à quoi ressemble l’infrastructure ou la configuration globale.
2. Dépendance à l’ordre des tâches : L’exécution des tâches dans Ansible est séquentielle, ce qui signifie que l’ordre des actions est important. Si une tâche échoue, les suivantes peuvent ne pas être exécutées correctement. De plus, certaines tâches peuvent devoir être rejouées si elles ne sont pas exécutées dans le bon ordre.
3. Pas de gestion d’état : Comme Ansible ne garde pas de fichier d’état, il ne sait pas si une action a déjà été exécutée ou non en dehors de son exécution directe. Cela peut poser problème dans des infrastructures où plusieurs outils interviennent pour modifier les ressources. L’absence de suivi des changements rend difficile la gestion des situations où les configurations peuvent être modifiées manuellement ou par d’autres outils.

Quand utiliser l’approche Déclarative ou Impérative ?

Le choix entre ces deux approches dépend du contexte d’utilisation :

• Terraform est idéal pour les environnements où vous avez besoin de provisionner et de gérer une infrastructure complexe, avec un suivi continu de l’état des ressources. Son approche déclarative assure la cohérence de l’infrastructure et gère automatiquement les dépendances entre les ressources.
• Ansible, en revanche, est parfait pour gérer la configuration des systèmes et l’automatisation des tâches répétitives. Son approche impérative permet un contrôle plus fin sur les actions spécifiques, mais sans garantir une vue d’ensemble continue sur l’état de l’infrastructure.

Gestion des Échecs et Rollbacks

L’un des aspects critiques de l’automatisation d’infrastructures est la capacité à gérer les échecs et à effectuer des rollbacks (retours en arrière) pour restaurer un état stable en cas de problème. Si une modification ou un déploiement échoue, il est important de pouvoir revenir à un état précédent, sans perturber l’infrastructure ou les systèmes déjà en place.

Gestion des échecs et rollbacks dans Terraform

Dans Terraform, bien qu’il n’existe pas de mécanisme de rollback automatique en cas d’échec, la gestion des états permet d’éviter les modifications partielles de l’infrastructure. Lorsque Terraform applique un plan (terraform apply), il compare l’état actuel de l’infrastructure à celui défini dans son fichier d’état (terraform.tfstate). Si un échec se produit au cours de l’application d’un plan, Terraform arrête l’exécution et ne met pas à jour son fichier d’état, ce qui garantit que l’infrastructure reste cohérente avec l’état précédemment enregistré.

Cependant, s’il y a besoin d’un rollback complet, l’opérateur doit manuellement modifier la configuration ou restaurer un fichier d’état antérieur à l’échec. Cela peut être fait en réinitialisant un backup du fichier terraform.tfstate, qui est automatiquement créé lors de chaque terraform apply réussi. Terraform sauvegarde une copie de l’état précédent sous forme de fichier terraform.tfstate.backup.

Si un plan Terraform échoue ou entraîne une infrastructure instable, vous pouvez restaurer manuellement l’état précédent en remplaçant le fichier terraform.tfstate par son backup :

mv terraform.tfstate.backup terraform.tfstate

Ensuite, il suffit de réappliquer un plan Terraform :

terraform apply

Cela permet de revenir à l’état précédent avant l’échec. Cependant, cela ne se fait pas automatiquement : Terraform s’attend à ce que l’utilisateur gère manuellement les situations d’échec.

Gestion des échecs dans Ansible avec les blocks

Ansible fournit un mécanisme plus structuré pour gérer les échecs lors de l’exécution des tâches, grâce à l’utilisation de blocks de contrôle : block, rescue, et always. Ces blocs permettent de structurer les tâches en étapes distinctes et d’exécuter des actions de récupération ou des rollbacks en cas d’échec d’une tâche spécifique.

Exemple d’utilisation des blocks dans Ansible

Voici un exemple de playbook Ansible qui utilise les blocks pour gérer les échecs :

---
- hosts: webservers
  become: true

  tasks:
    - block:
        - name: Installer Apache
          ansible.builtin.apt:
            name: apache2
            state: present

        - name: Démarrer Apache
          ansible.builtin.service:
            name: apache2
            state: started

      rescue:
        - name: Désinstaller Apache en cas d'échec
          ansible.builtin.apt:
            name: apache2
            state: absent

        - name: Notifier l’échec
          ansible.builtin.debug:
            msg: "L'installation d'Apache a échoué, Apache a été désinstallé."

      always:
        - name: Récupérer l'état des services
          ansible.builtin.service_facts:

        - name: Vérifier si Apache est actif
          ansible.builtin.debug:
            msg: "Le service Apache est actif."
          when: ansible_facts.services['apache2'].state == 'running'

Explication des blocks :

1. Block : Ce bloc contient les tâches principales. Dans cet exemple, Ansible tente d’installer et de démarrer Apache. Si toutes les tâches du bloc sont réussies, l’exécution continue normalement.

2. Rescue : Si une tâche du bloc block échoue (par exemple, l’installation ou le démarrage d’Apache), les tâches du bloc rescue sont exécutées. Ici, Ansible désinstalle Apache pour restaurer le serveur à un état stable et notifie l’échec.

3. Always : Ce bloc est exécuté à la fin, que les tâches aient échoué ou non. Il est souvent utilisé pour des actions de nettoyage ou de vérification, comme vérifier l’état actuel du service Apache, même si l’exécution précédente a échoué.

Avantages des blocks Ansible

1. Gestion des erreurs structurée : Les blocks permettent de capturer les erreurs et d’exécuter des actions correctives, assurant que les systèmes restent dans un état stable, même en cas de défaillance.
2. Rollbacks partiels : Avec rescue, il est possible d’annuler partiellement ou totalement des actions si une tâche échoue. Par exemple, vous pouvez désinstaller des logiciels ou restaurer des fichiers si une configuration ne se déroule pas comme prévu.
3. Actions garanties : Le bloc always garantit que certaines tâches sont toujours exécutées, qu’il y ait des succès ou des échecs dans les blocks précédents. Cela permet d’ajouter des vérifications ou des nettoyages à la fin de chaque exécution.

Limites des Rollbacks dans Ansible et Terraform

Bien que les blocks de contrôle dans Ansible fournissent un bon mécanisme de gestion des échecs, ils ne permettent pas de revenir automatiquement à un état précédent global du système comme le ferait une infrastructure gérée via un fichier d’état (comme Terraform). De plus, en l’absence de gestion native de l’état, Ansible ne peut pas “savoir” exactement ce qui a changé entre deux exécutions, ce qui limite sa capacité à gérer des rollbacks complexes.

De même, bien que Terraform puisse restaurer des états précédents via des fichiers d’état, il ne gère pas non plus automatiquement des rollbacks complets en cas d’échec partiel d’une exécution. Le processus de récupération nécessite une intervention manuelle.

Opposition ou Complémentarité ? Une Analyse Contextuelle

Après avoir exploré les fonctionnalités respectives de Terraform et Ansible, il est essentiel de répondre à la question principale : ces outils sont-ils en opposition, ou au contraire, peuvent-ils être utilisés de manière complémentaire ? La réponse à cette question dépend largement du contexte dans lequel vous les utilisez et des objectifs que vous souhaitez atteindre. Analysons les différents cas de figure pour mieux comprendre comment choisir l’un ou l’autre, ou les combiner efficacement.

Cas où Terraform et Ansible semblent en opposition

Certaines situations peuvent donner l’impression que Terraform et Ansible sont des outils opposés, notamment lorsqu’on cherche à automatiser une tâche spécifique, mais que les deux outils semblent pouvoir accomplir le travail de manière similaire. Par exemple, Ansible propose des modules pour provisionner des ressources sur des fournisseurs cloud comme AWS, Azure, ou GCP, ce qui semble empiéter sur le domaine de compétence de Terraform.

Prenons un exemple simple avec Ansible qui provisionne une instance EC2 sur AWS :

---
- hosts: localhost
  tasks:
    - name: Provisionner une instance EC2 sur AWS
      amazon.aws.ec2:
        key_name: my_key
        instance_type: t2.micro
        image_id: ami-123456
        region: us-west-2

À première vue, on pourrait penser que cet usage se rapproche beaucoup de celui de Terraform, qui est également capable de provisionner des ressources cloud de manière similaire, comme illustré dans ce code Terraform :

provider "aws" {
  region = "us-west-2"
}

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  key_name      = "my_key"
}

Dans des scénarios aussi simples, il peut sembler que l’un des outils pourrait suffire. Si l’on ne regarde que la capacité à provisionner des ressources, Ansible peut, en effet, accomplir une tâche semblable à Terraform. Cependant, cette opposition ne tient pas sur le long terme dès qu’il s’agit de maintenir l’infrastructure ou de la faire évoluer.

Les Limites des Approches Individuelles

Les Limites de Terraform

Bien que Terraform excelle dans la gestion du provisionnement d’infrastructure, il montre rapidement ses limites lorsqu’il s’agit de gérer les configurations spécifiques sur les serveurs après leur provisionnement. Par exemple, une fois qu’une instance EC2 a été créée avec Terraform, vous devrez probablement configurer des services, installer des paquets ou mettre en place des fichiers de configuration. Terraform n’est pas conçu pour gérer ces détails de configuration post-provisionnement.

En d’autres termes, Terraform est excellent pour définir l’état des ressources d’infrastructure (machines virtuelles, réseaux, bases de données), mais il n’est pas destiné à gérer les configurations détaillées de ces systèmes après leur création.

Les Limites d’Ansible

De son côté, Ansible est un outil puissant pour la configuration et l’automatisation des tâches sur des systèmes existants. Cependant, il n’est pas aussi efficace que Terraform pour gérer le cycle de vie complet de l’infrastructure. Ansible peut provisionner des ressources, mais il n’offre pas de mécanisme aussi robuste que Terraform pour maintenir l’état des infrastructures provisionnées.

Ansible ne dispose pas d’un fichier d’état comme Terraform, ce qui signifie qu’il ne garde pas une trace précise de l’infrastructure déjà provisionnée. Cela pose problème dans des scénarios où vous devez détruire, recréer ou faire évoluer les ressources. Avec Ansible, vous devrez souvent gérer manuellement ces tâches, ce qui peut devenir fastidieux et source d’erreurs.

Complémentarité des Deux Outils

Bien que Terraform et Ansible aient des fonctionnalités qui semblent se chevaucher, ils sont en réalité complémentaires lorsqu’ils sont utilisés ensemble dans un workflow DevOps, en partie grâce à des fonctionnalités spécifiques qui facilitent leur intégration, telles que les inventaires dynamiques d’Ansible et le provider Ansible pour Terraform.

Provisionnement d’infrastructure avec Terraform

Terraform est parfaitement adapté pour créer et maintenir l’infrastructure sous-jacente, comme les machines virtuelles, les réseaux, les bases de données et les autres ressources cloud. Sa capacité à gérer les dépendances complexes entre ces ressources et à s’appuyer sur un fichier d’état pour suivre leur état assure que l’infrastructure est toujours alignée avec les définitions de configuration. Par exemple, lors du déploiement sur un cloud comme AWS, Terraform peut automatiquement créer les sous-réseaux, groupes de sécurité, et instances EC2 nécessaires.

Configuration dynamique avec Ansible et inventaires dynamiques

Une fois que Terraform a provisionné l’infrastructure, Ansible entre en jeu pour gérer la configuration des systèmes sur ces ressources. L’un des principaux atouts d’Ansible dans ce processus est sa capacité à utiliser des inventaires dynamiques.

Les inventaires dynamiques permettent à Ansible de récupérer dynamiquement la liste des hôtes (comme les serveurs EC2, les VMs, ou les containers) à partir d’une source externe, comme AWS, GCP, ou Azure. Par exemple, après que Terraform ait provisionné une infrastructure dans AWS, Ansible peut automatiquement découvrir ces nouvelles instances EC2 via un inventaire dynamique AWS, sans avoir à mettre à jour manuellement l’inventaire des hôtes.

Cela permet de maintenir à jour les inventaires des serveurs, de sorte qu’Ansible puisse configurer les machines provisionnées par Terraform dès qu’elles sont opérationnelles. Voici un exemple d’utilisation d’un inventaire dynamique AWS avec Ansible pour identifier et configurer automatiquement toutes les instances EC2 :

ansible -i aws_ec2.yaml all -m ping

Le fichier aws_ec2.yaml contient les paramètres de configuration pour l’inventaire dynamique AWS, qui récupère automatiquement les adresses IP des instances EC2 récemment créées par Terraform. Cela permet à Ansible d’exécuter ses tâches de configuration sans avoir besoin d’une intervention manuelle pour enregistrer les nouveaux hôtes.

Utilisation du provider Ansible dans Terraform

De l’autre côté, il est possible d’utiliser Ansible directement depuis Terraform grâce au provider Ansible pour Terraform. Ce provider permet d’exécuter des playbooks Ansible après le provisionnement des ressources via Terraform, garantissant ainsi une configuration automatisée dès que l’infrastructure est prête.

L’intégration du provider Ansible dans Terraform simplifie le processus de provisionnement et de configuration en unifiant les deux étapes dans un seul plan Terraform. Cela permet d’orchestrer non seulement la création des ressources (machines virtuelles, réseaux, bases de données), mais aussi la configuration des systèmes via Ansible, sans avoir à passer par des scripts séparés.

Voici un exemple simple de l’utilisation du provider Ansible dans un plan Terraform :

provider "ansible" {}

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  key_name      = "my_key"
}

resource "ansible_host" "web" {
  inventory_hostname = aws_instance.example.public_ip
  groups = ["webservers"]

....
}

Dans cet exemple, Terraform provisionne une instance EC2 sur AWS, puis utilise le provider Ansible pour exécuter un playbook qui installe Nginx sur l’instance une fois qu’elle est provisionnée. Le plan Terraform gère ainsi l’ensemble du processus, depuis le provisionnement de l’infrastructure jusqu’à la configuration de l’instance via Ansible, assurant une automatisation fluide et complète.

Complémentarité Optimale

En intégrant ces deux outils, Terraform s’occupe de l’infrastructure et Ansible de la configuration des systèmes, ce qui permet une gestion de bout en bout. Les inventaires dynamiques d’Ansible garantissent que les hôtes provisionnés sont immédiatement accessibles pour être configurés, et le provider Ansible pour Terraform simplifie l’intégration des deux outils en orchestrant à la fois le provisionnement et la configuration dans un seul flux.

Cette complémentarité permet de bénéficier des avantages de l’approche déclarative de Terraform pour gérer les ressources d’infrastructure, et de l’approche impérative d’Ansible pour configurer et maintenir ces ressources une fois créées. Ensemble, ces outils assurent une automatisation complète et cohérente du cycle de vie de l’infrastructure, tout en réduisant les erreurs manuelles et en améliorant l’efficacité des déploiements.

Conclusion : Faut-il choisir ou combiner Terraform et Ansible ?

En analysant les différences et les forces de Terraform et Ansible, il est évident que ces deux outils jouent des rôles distincts, mais complémentaires dans le monde de l’automatisation et de la gestion d’infrastructure. Au lieu de les voir en opposition, la véritable puissance de ces outils se révèle lorsque nous les utilisons ensemble.

Terraform pour le Provisionnement d’Infrastructure

Terraform excelle dans le provisionnement d’infrastructures complexes, qu’il s’agisse de machines virtuelles, de réseaux ou de bases de données, sur divers fournisseurs cloud ou environnements on-premises. Sa nature déclarative, associée à la gestion d’un fichier d’état, permet de garantir que l’infrastructure reste conforme à la configuration désirée, même au fil des changements. Sa capacité à gérer les dépendances entre les ressources et à orchestrer des infrastructures multi-clouds ou hybrides en fait un outil incontournable pour les équipes DevOps.

Cependant, bien que Terraform puisse provisionner des ressources, il n’est pas conçu pour configurer les systèmes après leur création. C’est ici que la complémentarité avec Ansible prend tout son sens.

Ansible pour la Gestion de Configuration

De son côté, Ansible est un outil incroyablement puissant pour la gestion de configuration et l’automatisation des tâches sur des systèmes existants. Son approche impérative et sa flexibilité permettent d’adapter les configurations système et d’automatiser les tâches d’administration courantes. Grâce aux inventaires dynamiques et à l’architecture sans agent, Ansible est capable de découvrir et de configurer dynamiquement des ressources, notamment celles provisionnées par Terraform.

Cependant, Ansible n’est pas conçu pour gérer l’infrastructure de bout en bout, et l’absence de fichier d’état rend difficile le suivi et la gestion des ressources d’infrastructure de manière durable. C’est pourquoi Terraform, avec son modèle déclaratif, est plus approprié pour maintenir l’état global de l’infrastructure.

Complémentarité pour une Automatisation Complète

En combinant les deux, nous tirons parti du meilleur de chaque outil. Terraform crée et maintient l’infrastructure, tandis qu’Ansible gère la configuration des systèmes une fois que les ressources sont provisionnées. En outre, grâce au provider Ansible pour Terraform, vous pouvez orchestrer à la fois le provisionnement et la configuration dans un même flux d’automatisation. Ansible peut également tirer parti des inventaires dynamiques, en se synchronisant automatiquement avec les infrastructures que Terraform provisionne, garantissant une continuité entre le déploiement des ressources et leur configuration.

Une Solution DevOps Complète

Plutôt que de choisir entre les deux, il est plus judicieux de les combiner pour maximiser l’efficacité et la robustesse de vos déploiements. Dans un pipeline CI/CD, Terraform assure que les ressources sont créées de manière cohérente, tandis qu’Ansible configure ces ressources et les maintient à jour. Cette approche offre une solution DevOps complète qui couvre tout le cycle de vie des infrastructures et des systèmes, de la création à la configuration et à la maintenance.

Résilience et Scalabilité

De plus, l’intégration des deux outils assure une résilience et une scalabilité accrues. Terraform permet de déployer des infrastructures à grande échelle, de manière reproductible et sécurisée, tandis qu’Ansible peut automatiser les tâches de configuration sur des centaines, voire des milliers de serveurs de manière fluide. Ensemble, ils permettent de gérer des infrastructures complexes dans un environnement en constante évolution, tout en garantissant que chaque ressource est correctement configurée et opérationnelle.

Conclusion Finale

En définitive, le vrai pouvoir de Terraform et Ansible réside dans leur complémentarité. Ces outils ne doivent pas être vus comme des solutions concurrentes, mais comme des éléments intégrés d’une chaîne d’automatisation moderne et robuste. En les combinant dans un workflow unifié, vous pouvez non seulement simplifier la gestion de l’infrastructure et de la configuration, mais aussi améliorer considérablement l’efficacité, la fiabilité et la reproductibilité de vos déploiements, tout en réduisant les risques d’erreurs humaines et en optimisant l’utilisation des ressources.

Ainsi, pour toute organisation cherchant à automatiser son infrastructure et à optimiser ses pratiques DevOps, l’utilisation conjointe de Terraform et d’Ansible est une stratégie qui permet d’atteindre une gestion d’infrastructure fluide, efficace et durable.

En complément de Terraform et Ansible, l’ajout de Packer peut encore renforcer l’efficacité de votre infrastructure automatisée. Packer, un autre outil de la suite HashiCorp, permet de créer des images machine préconfigurées pour différents environnements (clouds, conteneurs, machines virtuelles). Ces images peuvent ensuite être utilisées par Terraform pour provisionner des instances, et par Ansible pour appliquer des configurations spécifiques, accélérant ainsi les déploiements tout en garantissant une cohérence entre les environnements.

Avec Packer, vous pouvez créer des images optimisées dès le départ, réduisant ainsi le temps de configuration nécessaire lors de chaque déploiement. Cette synergie entre Terraform, Ansible et Packer offre une chaîne d’automatisation complète, de la création des images à la gestion de l’infrastructure et des configurations.

Question Ouverte

Pensez-vous qu’un outil capable de réunir les atouts de Terraform (provisionnement d’infrastructure) et Ansible (gestion de configuration) existe, offrant ainsi une solution unifiée, ou bien la séparation de leurs rôles restera-t-elle indispensable dans les environnements DevOps ? On peut en discuter sur mon discord.