Exercice 1 : Audit et configuration de base d'un parc de serveurs

Introduction et objectifs de l'audit de serveurs avec Ansible

Cet premier exercice pratique vous plonge au coeur de l'administration système automatisée avec Ansible. L'objectif principal est de vous familiariser avec les tâches fondamentales d'audit et de configuration de base sur un ensemble de serveurs. Vous apprendrez à collecter des informations essentielles sur l'état de vos machines et à garantir une configuration minimale homogène, des compétences indispensables pour tout administrateur systèmes ou ingénieur DevOps.

Au terme de cet exercice, vous serez capable de structurer un inventaire Ansible simple, d'utiliser efficacement les commandes ad-hoc pour des vérifications rapides et ciblées, et de rédiger un playbook pour automatiser l'installation de paquets logiciels essentiels. Cette démarche vous permettra de comprendre concrètement comment Ansible interagit avec les noeuds gérés et comment il assure l'état désiré de votre infrastructure.

Nous allons simuler la gestion d'un petit parc de serveurs. Même si vous travaillez avec des machines virtuelles locales pour cet exercice, les principes et les commandes restent identiques pour des environnements de production plus vastes. Préparez votre noeud de contrôle Ansible et assurez-vous d'avoir accès (via SSH avec clés) à au moins deux noeuds gérés pour une expérience optimale.

Etape 1 : Mettre en place votre inventaire Ansible

La première étape cruciale dans toute opération Ansible est la définition de votre infrastructure cible. C'est le rôle du fichier d'inventaire. Ce fichier, généralement au format INI ou YAML, liste les hôtes sur lesquels Ansible va opérer. Pour cet exercice, nous allons créer un inventaire simple contenant au moins deux noeuds gérés.

Créez un fichier nommé inventory.ini dans votre répertoire de travail. A l'intérieur de ce fichier, vous allez définir un groupe d'hôtes, par exemple [webservers], et y lister vos machines. Pour chaque machine, vous pouvez spécifier son adresse IP ou son nom d'hôte résolvable, ainsi que d'autres variables de connexion si nécessaire.

Voici un exemple de contenu pour votre fichier inventory.ini, en supposant que vous avez deux serveurs nommés server1 et server2 accessibles via les adresses IP 192.168.1.101 et 192.168.1.102, et que vous vous connectez avec l'utilisateur ansible_user :

[webservers]
server1 ansible_host=192.168.1.101
server2 ansible_host=192.168.1.102

[all:vars]
ansible_user=votre_utilisateur_ssh
ansible_ssh_private_key_file=~/.ssh/votre_cle_privee

N'oubliez pas de remplacer votre_utilisateur_ssh par le nom d'utilisateur réel et ~/.ssh/votre_cle_privee par le chemin vers votre clé SSH privée si elle n'est pas la clé par défaut (id_rsa). Si la connexion SSH sans mot de passe est déjà configurée pour l'utilisateur courant avec la clé par défaut, les lignes ansible_user et ansible_ssh_private_key_file sous [all:vars] peuvent ne pas être nécessaires ou être adaptées.

Etape 2 : Utiliser les commandes Ad-Hoc pour l'audit initial

Les commandes ad-hoc d'Ansible sont parfaites pour exécuter des tâches rapides et ponctuelles sans avoir besoin d'écrire un playbook complet. Elles sont particulièrement utiles pour l'audit initial et la collecte d'informations. Nous allons les utiliser pour vérifier l'état de nos serveurs.

Pour commencer, vérifions la connectivité avec nos noeuds gérés en utilisant le module ping. Exécutez la commande suivante depuis votre noeud de contrôle, en remplaçant inventory.ini par le nom de votre fichier d'inventaire si différent :

ansible webservers -i inventory.ini -m ping

Vous devriez obtenir une réponse "pong" pour chaque serveur, confirmant qu'Ansible peut s'y connecter. Ensuite, vérifions le temps de fonctionnement (uptime) de chaque serveur avec le module command :

ansible webservers -i inventory.ini -m command -a "uptime"

Continuons notre audit en vérifiant l'espace disque disponible. La commande df -h est classiquement utilisée pour cela :

ansible webservers -i inventory.ini -a "df -h"

Notez que si le module n'est pas spécifié avec -m, Ansible utilise par défaut le module command. Enfin, essayons de vérifier la présence d'un paquet spécifique, par exemple nginx. La méthode varie légèrement selon le gestionnaire de paquets de vos noeuds gérés (apt pour Debian/Ubuntu, yum ou dnf pour RHEL/CentOS/Fedora). Avec apt, on pourrait tenter :

ansible webservers -i inventory.ini -m apt -a "name=nginx state=present" --check --become

L'option --check simule l'action sans la réaliser, et --become est nécessaire si l'utilisateur de connexion n'a pas les droits pour interroger les paquets. Pour une simple vérification de présence, une commande comme dpkg -s nginx (Debian) ou rpm -q nginx (RPM) via le module command ou shell peut aussi être utilisée, mais elle sera moins portable et moins idempotente qu'un module dédié.

Etape 3 : Ecrire un playbook pour la configuration de base

Après avoir exploré nos serveurs avec des commandes ad-hoc, il est temps d'automatiser une configuration de base en utilisant un playbook. L'objectif est de s'assurer que certains paquets logiciels essentiels, tels que curl, vim, et htop, sont installés sur tous les noeuds du groupe webservers.

Créez un fichier nommé ensure_packages.yml et ajoutez-y le contenu suivant. Ce playbook utilise le module approprié pour la gestion des paquets (ici, apt pour les systèmes basés sur Debian/Ubuntu ; adaptez avec yum ou dnf si vos noeuds utilisent un autre gestionnaire). L'utilisation de become: true permet d'exécuter les tâches avec des privilèges élevés, nécessaires pour l'installation de logiciels.

Voici le contenu du playbook ensure_packages.yml :

---
- name: Assurer la présence des paquets de base
  hosts: webservers
  become: true
  tasks:
    - name: Mettre à jour le cache apt (pour Debian/Ubuntu)
      apt:
        update_cache: yes
      when: ansible_os_family == "Debian"

    - name: Installer les paquets essentiels
      package:
        name:
          - curl
          - vim
          - htop
        state: present

Ce playbook cible le groupe webservers. La première tâche met à jour le cache des paquets (spécifique ici pour les systèmes Debian/Ubuntu et conditionnée par la variable ansible_os_family). La seconde tâche utilise le module générique package qui tente de déterminer le gestionnaire de paquets approprié. Il s'assure que les paquets curl, vim, et htop sont présents (state: present). Si vos serveurs utilisent un autre système, vous pourriez avoir besoin d'adapter la tâche de mise à jour du cache ou de spécifier directement le module yum ou dnf.

Pour exécuter ce playbook, utilisez la commande :

ansible-playbook -i inventory.ini ensure_packages.yml

Observez attentivement la sortie. Ansible vous indiquera si des modifications (changed) ont été apportées à vos systèmes (paquets installés) ou si tout était déjà conforme (ok). C'est une démonstration de l'idempotence d'Ansible : réexécuter le playbook ne devrait normalement plus entraîner de changements si les paquets sont déjà installés.

Vérification et synthèse de l'exercice d'audit et configuration

Une fois votre playbook exécuté, il est judicieux de vérifier que les actions ont eu l'effet escompté. Vous pouvez, par exemple, vous connecter en SSH à l'un de vos noeuds gérés et tenter d'exécuter htop ou curl --version pour confirmer leur installation. Alternativement, vous pouvez réutiliser des commandes ad-hoc spécifiques pour vérifier la présence des paquets, comme nous l'avions esquissé précédemment, ou simplement relancer le playbook : s'il n'indique aucun changement, c'est que la configuration est bien en place.

Cet exercice vous a permis de mettre en oeuvre plusieurs concepts clés d'Ansible. Vous avez appris à :

• Créer et structurer un fichier d'inventaire pour définir vos cibles.
• Utiliser les commandes ad-hoc pour des inspections rapides et des actions ponctuelles.
• Rédiger un playbook simple mais fonctionnel pour automatiser une tâche de configuration courante.
• Comprendre l'importance de l'idempotence et de l'utilisation des modules Ansible appropriés.
• Interpréter la sortie d'Ansible pour suivre l'état des opérations.

Les compétences acquises ici constituent une base solide pour aborder des scénarios d'automatisation plus complexes. N'hésitez pas à modifier l'inventaire, à ajouter d'autres paquets à installer, ou à explorer d'autres modules via des commandes ad-hoc. L'expérimentation est une excellente manière de renforcer votre compréhension d'Ansible et de ses capacités. Vous êtes maintenant mieux préparé pour l'exercice suivant, qui portera sur le déploiement d'une application web.