Aller au contenu
Mathis Vila

projets but3 r511-ansible

BUT3 · R511 Terminé

Automatisation avec Ansible

J'ai mis en place un nœud de contrôle Ansible et deux nœuds gérés, puis automatisé leur configuration avec une série de playbooks.

Année
BUT3 · S5
Module
R511 Virtualisation et automatisation des réseaux
Type
TP
Date
15/09/2026
Équipe
seul
Mon rôle
Auteur unique : réalisation de l'ensemble du travail

Contexte et objectif

Ce travail de la ressource R511 (Virtualisation et automatisation des réseaux) visait à mettre en œuvre un environnement d'automatisation complet : un nœud de contrôle exécutant Ansible et deux nœuds gérés, puis une série de playbooks appliqués à ces derniers. La maquette repose sur trois machines virtuelles Debian 13 sous Hyper-V. Le sujet étant rédigé pour Ubuntu, plusieurs adaptations ont été nécessaires.

Ce que j'ai réalisé

  • J'ai construit trois VM à deux cartes réseau : eth0 en DHCP pour l'accès Internet, eth1 en adressage statique sur un commutateur interne Hyper-V dédié au réseau d'administration.
  • J'ai installé Ansible sur le seul nœud de contrôle, créé le fichier ansible.cfg et déclaré l'inventaire aux formats INI et YAML.
  • J'ai mis en place l'authentification SSH par clé RSA de 4096 bits, puis validé la chaîne avec le module ping.
  • J'ai exécuté les cinq playbooks du sujet : installation de paquets, commandes shell, variable passée en ligne de commande, mise à jour du système, tâches asynchrones.

Difficultés rencontrées et solutions

  • Perte totale de connectivité des trois machines, causée par la directive hwaddress ether, incompatible avec les cartes virtuelles Hyper-V : j'ai relancé dhcpcd manuellement, puis réécrit le fichier sans cette directive.
  • Échec de become (« sudo: not found ») sur l'image minimale : j'ai déployé le paquet sudo avec Ansible lui-même.
  • Paquet ntpdate retiré de Debian 13 : remplacé par ntpsec-ntpdate.
  • Connexion SSH de root refusée par défaut : autorisée sur les nœuds gérés, choix limité au laboratoire.

Résultats

  • ansible-core 2.19.11 sur Python 3.13.5, réponse « pong » des deux nœuds gérés.
  • Idempotence : changed=1 à la première exécution, changed=0 à la seconde.
  • Mise à jour appliquée sur les deux nœuds en cinq minutes environ.
  • Exécution asynchrone : le playbook rend la main en 4,3 secondes.

Ce que j'en retiens

Un playbook décrit un état à atteindre et non une suite d'actions. Il n'est pas universel d'une distribution à l'autre, et une architecture sans agent conserve des prérequis (SSH, clé, Python, élévation de privilèges). L'incident réseau m'a appris à ne modifier que la section concernée d'un fichier de configuration et à le sauvegarder au préalable.

Technologies

  • Ansible
  • YAML
  • SSH
  • Debian 13
  • Hyper-V
  • PowerShell
  • MobaXterm
  • APT
  • Jinja2
  • nmap
  • ifupdown
  • dhcpcd

En images

Nœud de contrôle : version d'Ansible installée
Nœud de contrôle : version d'Ansible installée
Exécution de playbooks sur les deux nœuds gérés
Exécution de playbooks sur les deux nœuds gérés
Commande ad hoc exécutée sur tous les nœuds
Commande ad hoc exécutée sur tous les nœuds
Playbook lançant un scan nmap et affichant son résultat
Playbook lançant un scan nmap et affichant son résultat