Etape 3 : Ecrire un playbook pour s'assurer que des paquets essentiels (ex: `curl`, `vim`, `htop`) sont installés sur tous les noeuds

Passer des commandes Ad-Hoc aux Playbooks pour l'automatisation

Après avoir utilisé les commandes ad-hoc pour des vérifications ponctuelles, il est temps de passer à un niveau supérieur d'automatisation avec les playbooks Ansible. Un playbook est un fichier YAML qui décrit un ensemble de configurations, de déploiements ou d'orchestrations à appliquer à un groupe d'hôtes. Contrairement aux commandes ad-hoc, les playbooks sont conçus pour être réutilisables, versionnables et pour gérer des scénarios plus complexes.

L'objectif de cette étape est d'écrire un playbook simple mais fondamental : s'assurer que certains paquets logiciels considérés comme essentiels (par exemple, curl pour les transferts de données en ligne de commande, vim comme éditeur de texte en console, et htop pour le monitoring interactif des processus) sont installés sur tous les noeuds de notre groupe lab_servers. Cela garantit une base logicielle commune sur l'ensemble de notre parc.

Nous allons aborder la structure de base d'un playbook, l'utilisation du module de gestion de paquets approprié, et comment exécuter ce playbook pour appliquer la configuration souhaitée de manière idempotente.

Structure d'un Playbook Ansible et définition des tâches

Un playbook Ansible est écrit en YAML (YAML Ain't Markup Language), un format de sérialisation de données lisible par l'homme. L'indentation (généralement deux espaces) est cruciale en YAML pour définir la structure hiérarchique.

Un playbook est une liste de "jeux" (plays). Chaque jeu définit un ensemble de tâches à exécuter sur un groupe d'hôtes spécifié. Voici la structure de base du playbook que nous allons créer. Nommons ce fichier install_core_packages.yml :

---
- name: Installation des paquets essentiels
  hosts: lab_servers
  become: true
  tasks:
    # Les tâches seront définies ici

Décortiquons cette structure :

• --- : Indique le début d'un document YAML (optionnel pour un seul document, mais bonne pratique).
• - name: Installation des paquets essentiels : C'est le nom du jeu. Il est descriptif et apparaîtra dans la sortie d'Ansible lors de l'exécution.
• hosts: lab_servers : Spécifie que ce jeu s'applique à tous les hôtes du groupe lab_servers défini dans notre inventaire. Vous pourriez aussi mettre all pour cibler tous les hôtes de l'inventaire.
• become: true : Indique que les tâches de ce jeu doivent être exécutées avec des privilèges élevés (équivalent à sudo). L'installation de paquets nécessite généralement ces droits.
• tasks: : Définit le début de la liste des tâches à exécuter dans ce jeu. Chaque tâche sera un élément de cette liste, commençant par un tiret -.

Maintenant, ajoutons les tâches pour installer nos paquets. Nous utiliserons le module package, qui est un module générique capable de détecter et d'utiliser le gestionnaire de paquets natif du système cible (apt, yum, dnf, etc.). C'est un bon choix pour la portabilité. Nous voulons que les paquets curl, vim, et htop soient présents (state: present).

Ecriture du Playbook pour installer les paquets

Complétons notre playbook install_core_packages.yml avec les tâches spécifiques. Pour installer plusieurs paquets avec le module package, nous pouvons lui passer une liste. Il est aussi de bonne pratique, surtout pour les gestionnaires comme apt, de s'assurer que le cache des paquets est à jour avant de tenter une installation.

---
- name: Installation des paquets essentiels
  hosts: lab_servers
  become: true
  tasks:
    - name: Mettre à jour le cache des paquets (ex: pour apt)
      ansible.builtin.package:
        update_cache: yes
      when: ansible_os_family == "Debian" or ansible_os_family == "Ubuntu"
      # Pour les systèmes RedHat-like, la mise à jour du cache est souvent implicite
      # ou gérée différemment. Cette tâche peut être adaptée ou omise selon les cibles.

    - name: Installer curl, vim, et htop
      ansible.builtin.package:
        name:
          - curl
          - vim
          - htop
        state: present

Quelques explications sur les tâches ajoutées :

• Première tâche : Mettre à jour le cache des paquets
  • name: Mettre à jour le cache des paquets (ex: pour apt) : Nom descriptif de la tâche.
  • ansible.builtin.package: : Utilisation du FQCN (Fully Qualified Collection Name) pour le module package. C'est une bonne pratique.
  • update_cache: yes : C'est un paramètre spécifique à certains gestionnaires de paquets sous-jacents (comme apt lorsqu'il est utilisé par package) pour rafraîchir la liste des paquets disponibles.
  • when: ansible_os_family == "Debian" or ansible_os_family == "Ubuntu" : C'est une conditionnelle. Cette tâche ne s'exécutera que si le noeud géré appartient à la famille d'OS Debian ou Ubuntu (où apt update est courant). Pour d'autres familles comme RedHat, yum/dnf gère souvent cela différemment. Le module package lui-même est assez intelligent, mais un update_cache explicite peut être nécessaire ou souhaitable. Vous pourriez également utiliser directement le module apt si vous ciblez uniquement des systèmes Debian/Ubuntu, ce qui rendrait update_cache: yes plus direct.
• Seconde tâche : Installer curl, vim, et htop
  • name: Installer curl, vim, et htop : Nom descriptif.
  • ansible.builtin.package: : Module utilisé.
  • name: : Paramètre pour spécifier le(s) paquet(s).
    • - curl
    • - vim
    • - htop : Nous passons une liste de noms de paquets.
  • state: present : Indique que nous voulons que ces paquets soient installés. S'ils le sont déjà, Ansible ne fera rien (idempotence). S'ils manquent, ils seront installés.

Ce playbook est maintenant prêt à être exécuté. Il est simple, mais il illustre les concepts clés : cibler des hôtes, élever les privilèges, et exécuter des tâches séquentielles en utilisant des modules Ansible avec leurs paramètres.

Exécution et vérification du Playbook

Pour exécuter votre playbook, utilisez la commande ansible-playbook depuis votre noeud de contrôle, en spécifiant votre fichier d'inventaire et le fichier du playbook :

ansible-playbook -i my_inventory.ini install_core_packages.yml

Ansible va alors :

1. Lire le fichier d'inventaire pour identifier les hôtes dans lab_servers.
2. Se connecter à chaque hôte.
3. Exécuter le jeu "Installation des paquets essentiels".
4. Pour chaque tâche du jeu :
   1. Afficher le nom de la tâche.
   2. Exécuter le module avec les paramètres spécifiés (en devenant root grâce à become: true).
   3. Rapporter le statut : ok si aucune modification n'a été nécessaire ou si la tâche a réussi sans changer l'état ; changed si la tâche a modifié l'état du système (par exemple, un paquet a été installé) ; failed si une erreur s'est produite ; skipped si une conditionnelle (when) n'a pas été remplie.
5. Afficher un résumé (PLAY RECAP) indiquant le nombre de tâches ok, changed, failed, etc., pour chaque hôte.

Si c'est la première fois que vous exécutez ce playbook sur des serveurs où ces paquets manquent, vous devriez voir un statut changed pour la tâche d'installation des paquets. Si vous le réexécutez immédiatement après, cette même tâche devrait afficher ok, car les paquets sont déjà présents. C'est la démonstration de l'idempotence d'Ansible.

Pour vérifier manuellement, vous pouvez vous connecter en SSH à l'un de vos noeuds gérés et essayer d'exécuter curl --version, vim --version, ou htop. Ils devraient maintenant être disponibles. Cette étape vous a permis de franchir un cap important en utilisant les playbooks pour automatiser des configurations de base de manière fiable et reproductible.