🏗️ Infrastructure as Code : Pourquoi Ansible en 2025 ?

📚 Prérequis

• Connaissances de base en administration système Linux
• Familiarité avec le concept d’Infrastructure as Code
• Curiosité pour l’automatisation des déploiements

---

Dans le paysage IaC de 2025, les options ne manquent pas : Terraform, Pulumi, CDK, Chef, Puppet, SaltStack… Alors pourquoi Ansible reste-t-il un choix pertinent ? Dans cet article, nous explorons les forces d’Ansible et quand l’utiliser (ou pas).

---

🤔 Le Paysage IaC en 2025

Avant d’argumenter pour Ansible, comprenons le paysage :

Outils de Provisioning (Infrastructure)

• Terraform : Standard de facto pour le cloud (AWS, GCP, Azure)
• Pulumi : IaC en langages de programmation (Python, Go, TypeScript)
• OpenTofu : Fork open-source de Terraform

Outils de Configuration Management

• Ansible : Agentless, YAML, SSH
• Puppet : Agent, DSL propriétaire, mature
• Chef : Agent, Ruby, flexible
• SaltStack : Agent optionnel, YAML/Python

La réalité : Ces outils ne sont pas en compétition directe. Ils répondent à des besoins différents.

🔀 Ansible vs Terraform : Complémentaires, Pas Concurrents

Aspect	Terraform	Ansible
Spécialité	Provisionner l’infrastructure	Configurer les serveurs
Paradigme	Déclaratif (état désiré)	Procédural avec idempotence
Gestion d’état	State file obligatoire	Pas de state (ou inventaire dynamique)
Agent requis	Non	Non (SSH/WinRM)
Langage	HCL	YAML
Forces	APIs cloud, dépendances	Configuration système, orchestration

Workflow Typique

1. Terraform crée : VMs, réseaux, load balancers, Buckets S3, bases de données managées, Certificats SSL, DNS

2. Ansible configure : Installation de Docker, PostgreSQL, Nginx, Déploiement d’applications, Configuration de sécurité (firewall, utilisateurs), Orchestration de services

Best practice : Utilisez Terraform pour l’infrastructure cloud et Ansible pour la configuration.

✅ Les Forces d’Ansible

1. Agentless

Ansible fonctionne via SSH (Linux) ou WinRM (Windows). Pas d’agent à installer, maintenir ou sécuriser sur chaque serveur.

• ✅ Réduction de la surface d’attaque
• ✅ Pas de gestion de versions d’agent
• ✅ Fonctionne sur tout ce qui a SSH

2. YAML Lisible

Les playbooks Ansible sont en YAML, lisibles même par des non-développeurs :

- name: Install and configure Nginx
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
    
    - name: Start nginx
      systemd:
        name: nginx
        state: started
        enabled: true

Comparez avec Puppet ou Chef, et la lisibilité d’Ansible est évidente.

3. Courbe d’Apprentissage Douce

Un administrateur système peut écrire des playbooks Ansible productifs en quelques heures. Les concepts de base (inventaire, playbook, task, handler) sont intuitifs.

4. Écosystème Riche

• Ansible Galaxy : Des milliers de rôles prêts à l’emploi
• Collections : Modules maintenus par les éditeurs (AWS, Azure, VMware…)
• Ansible Automation Platform : Version entreprise de Red Hat

5. Orchestration Multi-Serveurs

Ansible excelle dans l’orchestration coordonnée entre plusieurs serveurs :

- name: Rolling update without downtime
  hosts: webservers
  serial: 1  # Un serveur à la fois
  
  tasks:
    - name: Remove from load balancer
      community.general.haproxy:
        state: disabled
        host: "{{ inventory_hostname }}"
      delegate_to: loadbalancer
    
    - name: Update application
      apt:
        name: myapp
        state: latest
    
    - name: Re-add to load balancer
      community.general.haproxy:
        state: enabled
        host: "{{ inventory_hostname }}"
      delegate_to: loadbalancer

⚠️ Les Limites d’Ansible

Soyons honnêtes, Ansible n’est pas parfait :

1. Pas de Gestion d’État Distribuée

Contrairement à Terraform, Ansible ne sait pas « ce qui existe déjà » de manière native. Il exécute des tâches sans état global.

Solution : Utilisez des inventaires dynamiques (AWS, GCP, Azure) ou le check mode.

2. Performance sur Grands Parcs

SSH vers 1000 serveurs prend du temps. Les outils avec agents (Puppet, Salt) sont plus rapides à grande échelle.

Solution : Utilisez forks élevé, pipelining, ou Ansible Pull.

3. YAML Verbeux

Pour des logiques complexes, le YAML devient difficile à maintenir.

Solution : Refactorisez en rôles, utilisez des filtres Jinja2, ou considérez des modules custom.

---

🎯 Quand Utiliser Ansible ?

✅ Idéal pour :

• Configuration de serveurs (OS, packages, fichiers)
• Déploiement d’applications
• Orchestration multi-serveurs (rolling updates, maintenance)
• Automatisation des tâches opérationnelles
• Environnements hybrides (cloud + on-premise)
• Équipes ops sans background développement

❌ Moins adapté pour :

• Provisioning d’infrastructure cloud pure (préférez Terraform)
• Très grands parcs (10 000+ serveurs) avec besoin de temps réel
• Logiques métier complexes (préférez Python/Go)

🔧 Gestion des Secrets avec Ansible Vault

Un point souvent négligé : la gestion sécurisée des secrets.

Chiffrer un fichier de variables

# Créer un fichier vault
ansible-vault create secrets.yml

# Éditer un fichier existant
ansible-vault edit secrets.yml

# Chiffrer un fichier existant
ansible-vault encrypt vars/production.yml

Utilisation dans un playbook

# vars/secrets.yml (chiffré)
db_password: "supersecret123"
api_key: "abcd1234efgh5678"

# Exécution avec déchiffrement
ansible-playbook playbook.yml --ask-vault-pass

# Ou avec un fichier de mot de passe
ansible-playbook playbook.yml --vault-password-file .vault_pass

Best practice : Intégrez le vault password dans votre CI/CD via une variable d’environnement sécurisée.

🚀 Ansible en 2025 : Plus Pertinent que Jamais

Malgré la montée de Kubernetes et du serverless, Ansible reste incontournable pour :

• Bootstrapping : Préparer des VMs avant le déploiement Kubernetes
• Configuration OS : Même les nodes K8s ont besoin de configuration système
• Environnements hybrides : Le monde réel a du legacy
• Simplicité : Pas tout le monde a besoin de la complexité K8s

---

📦 Nos Rôles Ansible : Qualité Production

Nous développons des rôles Ansible pour les cas d’usage les plus courants en production :

• docker_engine : Installation Docker avec toutes les bonnes pratiques
• grafana_prometheus_loki : Stack d’observabilité complète
• harbor_trivy : Registry privé avec scan de vulnérabilités
• keycloak_ha : SSO haute disponibilité
• nginx_modsecurity : WAF avec OWASP CRS
• postgres_ha : PostgreSQL haute disponibilité

Tous nos rôles sont :

• ✅ Testés avec Molecule sur Debian 12/13 et Ubuntu 22.04/24.04
• ✅ Idempotents et reproductibles
• ✅ Documentés (README + Day-1/Day-2 guides)
• ✅ Maintenus et mis à jour

Prêt à industrialiser vos déploiements ? Découvrez notre catalogue de rôles Ansible.

---

📖 Glossaire

• IaC (Infrastructure as Code) : Pratique de gérer l’infrastructure via du code versionné plutôt que manuellement
• Agentless : Caractéristique d’un outil ne nécessitant pas l’installation d’un agent sur les serveurs cibles
• HCL (HashiCorp Configuration Language) : Langage de configuration utilisé par Terraform
• State File : Fichier où Terraform stocke l’état de l’infrastructure qu’il gère
• Ansible Vault : Fonctionnalité de chiffrement des secrets dans Ansible
• Inventaire Dynamique : Liste de serveurs générée automatiquement depuis le cloud (AWS, GCP, Azure)
• Pipelining : Optimisation Ansible réduisant le nombre de connexions SSH

Merci d’avoir suivi cette série d’articles ! N’hésitez pas à nous contacter pour toute question technique sur l’automatisation de votre infrastructure.