Ansible : Premières Impressions et Retour d’Expérience

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 afin de 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 en ce qui concerne 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 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, 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.

2. 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.

3. 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.

4. 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.). Cela me simplifie la vie au moment de lancer les commandes.

5. Sauvegarde et documentation
   Le fait de 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 (Focus Sécurité Nginx)

Pour illustrer à quel point Ansible est facile à configurer et à utiliser, voilà un exemple d’inventaire suivi d’un playbook minimaliste qui met l’accent sur la 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

• [all] : liste de tous les serveurs, avec leur adresse et l’utilisateur pour s’y connecter.
• [prod] : un groupe de serveurs appartenant à l’environnement « production ».

Exemple de playbook (secure_nginx.yml)

---
- name: Installer et configurer Nginx avec des bonnes pratiques de sécurité
  hosts: prod
  become: yes  # Permet d'exécuter les tâches avec les privilèges administrateur

  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";

          # Configuration TLS (exemple, nécessite un certificat valide)
          # ssl_protocols TLSv1.2 TLSv1.3;
          # ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
          # ssl_prefer_server_ciphers on;

          # Vous pouvez inclure ces directives dans un bloc 'server' ou les faire
          # référencer via 'include /etc/nginx/conf.d/security.conf;' dans votre conf principale
        dest: /etc/nginx/conf.d/security.conf

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

Avec ce playbook, vous :

1. Installez Nginx (ou le mettez à jour vers la dernière version disponible).
2. Déployez un fichier security.conf contenant quelques directives de base pour durcir la configuration (désactivation de l’affichage de la version, ajout d’en-têtes de sécurité, etc.).
3. Redémarrez et activez Nginx pour que les changements prennent effet et persistent au redémarrage.

Pour appliquer ce playbook, lancez simplement :

ansible-playbook -i hosts secure_nginx.yml

Cette simplicité est l’une des forces majeures d’Ansible : tout est déclaratif. Vous décrivez l’état final de votre infrastructure, et Ansible se charge de s’y conformer.

Ce que J’Aime le Plus

• La lisibilité du YAML : C’est fluide, et on s’y retrouve très facilement.
• La rapidité de mise en place : On commence par un petit playbook, on l’applique, et le gain de temps est immédiat.
• Le sentiment de sérénité : On sait précisément quelle configuration est appliquée, sans risque d’oubli ou d’erreur de frappe en SSH.

Ce qui M’A (Un Peu) Déplu

Même si Ansible me plaît beaucoup, j’ai quand même noté un point de friction :

• Problèmes de compatibilité : Sur certains vieux serveurs ou systèmes d’exploitation pas à jour, Ansible ne fonctionne pas comme prévu. En réalité, ce n’est pas tant Ansible qui est en cause, mais plutôt l’infrastructure elle-même, qui devrait idéalement être à jour. Quand on se retrouve avec des vieilles versions de Debian ou des environnements de production qu’on ne peut pas couper pour les migrer, c’est tout de suite plus compliqué de faire les mises à niveau nécessaires.

Bien que cela ne soit pas un deal-breaker total, c’est un point important à considérer si vous prévoyez de l’utiliser dans une infrastructure hétérogène ou peu maintenue à jour.

Les Points Restants à Explorer

Je ne suis qu’au début du chemin. Voici ce que je souhaite approfondir dans les prochains mois :

• Les rôles Ansible : Pour structurer mes playbooks et pouvoir réutiliser des « modules de configuration » d’un projet à l’autre.
• Les bonnes pratiques : Je sais qu’il existe une communauté très active et qu’il y a sûrement des standards à respecter (nomenclature, organisation des fichiers, etc.).
• Les intégrations : Voir comment coupler Ansible à d’autres outils ou process (CI/CD, monitoring) pour aller plus loin dans l’automatisation.

Conclusion : Premiers Résultats Encourageants

En somme, cette première immersion dans Ansible est vraiment prometteuse. Je vois déjà un gain de temps et de fiabilité dans mes déploiements et configurations. Plus je creuse, plus je réalise que l’outil est puissant et qu’il peut couvrir un large éventail de cas d’usage.

La compatibilité avec les environnements plus anciens reste un point d’attention, mais rien qui ne vienne entacher l’intérêt global d’Ansible : si votre stack est à jour, l’expérience est bien plus fluide. Je continuerai à partager mes découvertes et mes retours d’expérience, histoire de progresser pas à pas tout au long de l’année.