Ansible : retour sur mes premiers pas

En janvier dernier, j’annonçais mes résolutions pour 2025, dont l’une était de me pencher sur Ansible pour découvrir comment automatiser et gérer mes serveurs plus efficacement. Après quelques semaines d’exploration, il est temps de faire un mini débrief et de partager ce que j’ai appris jusqu’ici, notamment sur la configuration et l’utilisation de playbooks concrets.

Pourquoi j’ai choisi Ansible

Je l’avais déjà évoqué, mais la raison principale qui m’a poussé à apprendre Ansible, c’est sa simplicité :

  • Agentless : pas besoin d’installer quoi que ce soit sur les serveurs cibles, tout se fait via SSH.
  • Playbooks en YAML : un format lisible, facile à maintenir, dans lequel il est naturel de décrire l’état souhaité des machines.
  • Gestion de plusieurs serveurs en parallèle : parfait pour éviter la répétition de tâches ennuyeuses.

L’idée, pour moi, c’est de pouvoir standardiser et fiabiliser la configuration de mes environnements, que ce soit pour un petit projet perso ou, à terme, des déploiements en production.

Mes premières découvertes

Depuis que j’ai commencé à mettre les mains dans Ansible, voici ce que j’ai déjà pu expérimenter :

  1. Installation et configuration de base Sur une distro Debian/Ubuntu, rien de plus simple :
    sudo apt-get update
sudo apt-get install ansible

Quelques secondes plus tard, Ansible est déjà opérationnel.

  1. Gestion de la configuration Après l’installation, la config est ultra simple. Il suffit généralement de définir :

    • Un fichier inventaire pour lister vos serveurs et les regrouper par rôles ou environnements.
    • Des fichiers playbooks pour décrire vos tâches et la configuration ciblée.

  2. Playbooks simples J’ai commencé avec des tâches basiques : installer un paquet, copier un fichier de configuration, redémarrer un service. Ça donne vite une sensation de contrôle sur son infrastructure.

  3. Inventaire personnalisé Pour décrire mes serveurs, j’ai créé un fichier d’inventaire où je peux organiser mes machines selon leurs rôles (ex. prod, Cluster Proxmox, etc.). Ça me simplifie la vie au moment de lancer les commandes.

  4. Sauvegarde et documentation Tout décrire dans des fichiers YAML me permet de garder une trace claire de chaque action effectuée. Je n’ai plus besoin de me souvenir de tel ou tel paramètre configuré à la main, tout est centralisé.

Exemple de configuration et de playbook (sécurité Nginx)

Exemple d’inventaire (hosts)

[all]
web-nginx1 ansible_host=192.168.1.10 ansible_user=root
web-nginx2 ansible_host=192.168.1.11 ansible_user=root

[prod]
web-nginx1
web-nginx2

Exemple de playbook (secure_nginx.yml)

---
- name: Installer et configurer Nginx avec des bonnes pratiques de sécurité
  hosts: prod
  become: yes

  tasks:
    - name: Installer Nginx
      apt:
        name: nginx
        state: latest

    - name: Copier le fichier de configuration sécurisée
      copy:
        content: |
          server_tokens off;
          add_header X-Frame-Options SAMEORIGIN;
          add_header X-Content-Type-Options nosniff;
          add_header X-XSS-Protection "1; mode=block";
        dest: /etc/nginx/conf.d/security.conf

    - name: Redémarrer et activer Nginx
      service:
        name: nginx
        state: restarted
        enabled: true

Pour appliquer ce playbook :

ansible-playbook -i hosts secure_nginx.yml

Ce que j’aime le plus

  • Lisibilité du YAML.
  • Mise en place rapide.
  • Sérénité sur la configuration appliquée.

Ce qui m’a moins plu

  • Compatibilité parfois difficile avec de vieux systèmes ou environnements peu maintenus.

Prochains points à explorer

  • Rôles Ansible.
  • Bonnes pratiques de structuration.
  • Intégration avec d’autres outils (CI/CD, monitoring).

Conclusion

Ces premières semaines avec Ansible m’ont déjà fait gagner du temps, et surtout de la fiabilité. Il reste quelques frictions avec des environnements anciens, mais pour automatiser et uniformiser mes configs, c’est exactement ce qu’il me fallait.