Agence de développement Ansible

C'est quoi Ansible ?

Créé en 2012 par Michael DeHaan et racheté par Red Hat en 2015, Ansible est un outil d'automatisation d'infrastructure agentless. Il s'appuie sur SSH pour configurer serveurs, équipements réseau, conteneurs et même services cloud à partir de playbooks YAML. NASA, Cisco, Verizon ou TomTom l'utilisent pour piloter des parcs hétérogènes, du laptop dev à la salle blanche.

Ansible a démocratisé l'Infrastructure as Code en supprimant l'agent et en privilégiant un YAML lisible par un humain.

Pourquoi utiliser Ansible ?

Sa simplicité d'adoption masque une puissance réelle, surtout pour la configuration au-dessus de l'infrastructure brute.

• Agentless. Pas de démon à installer sur les cibles, seul SSH (ou WinRM) est requis. Adoption immédiate sur l'existant.
• YAML déclaratif. Les playbooks décrivent l'état désiré, lisibles par un sysadmin comme par un dev. Documentation et code à la fois.
• Idempotence. Rejouer un playbook ne casse rien, l'outil n'agit que si l'état réel diffère de l'état désiré.
• Écosystème de modules. Plus de mille collections officielles, gestion de paquets, services, fichiers, utilisateurs, cloud, réseau, conteneurs.
• Rôles réutilisables. Galaxy permet de partager des bricks (Nginx, PostgreSQL, Redis), accélérant les bootstraps de projet.
• Push model. Vous gardez le contrôle du moment d'exécution, idéal pour les environnements sensibles ou réglementés.

Ansible face aux autres approches

L'IaC se découpe en deux grandes familles, provisioning d'infra et configuration management. Voici les compromis.

Ansible en pratique

Voici un playbook qui prépare un serveur web Linux avec utilisateur dédié, Nginx et un service systemd.

---
- name: Configure web server
  hosts: web
  become: true
  vars:
    app_user: koul
    app_dir: /opt/koul-app

  tasks:
    - name: Ensure base packages
      ansible.builtin.apt:
        name: [nginx, curl, git, ufw]
        state: present
        update_cache: true

    - name: Create application user
      ansible.builtin.user:
        name: "{{ app_user }}"
        shell: /bin/bash
        home: "{{ app_dir }}"
        create_home: true

    - name: Render nginx site
      ansible.builtin.template:
        src: nginx-site.conf.j2
        dest: /etc/nginx/sites-available/app.conf
        owner: root
        mode: "0644"
      notify: Reload nginx

    - name: Enable site
      ansible.builtin.file:
        src: /etc/nginx/sites-available/app.conf
        dest: /etc/nginx/sites-enabled/app.conf
        state: link

  handlers:
    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

Pour quels projets ?

Ansible reste pertinent même à l'ère des conteneurs et du cloud, dès qu'il y a une couche serveur à gérer.

1. Serveurs VPS et bare-metal. Hardening, déploiement applicatif, gestion d'utilisateurs et sauvegardes pour des stacks Symfony ou Laravel.
2. Bootstrap d'infrastructure cloud. Configuration post-Terraform sur AWS ou GCP, mise en place de Docker et des outils ops.
3. Environnements réglementés. Conformité, audit, traçabilité. Le YAML versionné et l'exécution push facilitent la justification.

Notre approche chez Koul

Nous utilisons Ansible en complément de Terraform et OpenTofu, principalement pour la configuration logicielle. Notre méthode.

• Rôles modulaires. Une bibliothèque interne de rôles (Nginx, PostgreSQL, Redis, monitoring) versionnée et testée.
• Inventaires dynamiques. Génération automatique depuis le cloud provider, pas de saisie manuelle des IP.
• CI/CD intégrée. Lint des playbooks, dry-run, exécution déclenchée par pipeline GitLab.
• Observabilité post-déploiement. Vérifications automatiques après run, alertes Grafana sur la dérive de configuration.

Avec Ansible, l'infrastructure devient un texte qu'on lit, qu'on relit, et qu'on rejoue sans crainte.