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



