Automatisation réseau avec Ansible : playbooks pour la configuration de commutateurs, les sauvegardes et les rollbacks

L’automatisation du réseau avec Ansible est, dans de nombreuses équipes informatiques, la clé pour rendre reproductibles et auditables les modifications récurrentes de commutateurs, les sauvegardes régulières de configuration et les procédures de retour contrôlé. Ce guide pratique s’adresse aux administrateurs, ingénieurs systèmes et opérateurs et explique pas à pas les prérequis, les pièges typiques, des exemples concrets de playbooks et des stratégies sûres de vérification et de repli.

Pourquoi l’automatisation réseau ? Objectifs et termes essentiels

L’automatisation réseau réduit les erreurs manuelles, accélère les déploiements et améliore la traçabilité. Dans cet article, nous utilisons Ansible comme outil d’orchestration. Ansible est un outil d’automatisation sans agent : le nœud de contrôle (Ansible‑Control‑Node) se connecte via SSH ou des plugins de connexion réseau spécifiques aux équipements et exécute des tâches déclaratives (playbooks).

Termes importants en une phrase : Playbook (fichier YAML contenant des tâches), Inventory (liste d’équipements), plugins de connexion (p. ex. network_cli pour les commutateurs), idempotence (répétabilité sans effets de bord) et rollback (restauration d’une configuration antérieure).

Aperçu rapide des exigences opérationnelles

• Nœud de contrôle : Ansible 2.15+ ou une version 2.x moderne ; Python et les collections nécessaires (p. ex. ansible.netcommon, community.general, éventuellement des collections fournisseurs comme cisco.ios).
• Accès : accès SSH avec privilèges suffisants (éventuellement mot de passe enable/privilege). Les équipements réseau doivent être joignables depuis le nœud de contrôle.
• Inventaire : inventaires propres et group_vars pour les identifiants ; les secrets doivent être gérés via Ansible Vault ou un backend de secrets (p. ex. HashiCorp Vault).
• Environnement de test : laboratoire ou staging avec un ou quelques équipements pour vérifier les playbooks avant mise en production.

Automatisation réseau avec Ansible : structure de base d’un Inventory

Un inventory traçable est la base. Voici un exemple INI simple que de nombreuses équipes utilisent encore :

[switches]
sw-core-01 ansible_host=10.0.1.10 ansible_network_os=ios
sw-access-01 ansible_host=10.0.1.20 ansible_network_os=ios

[all:vars]
ansible_user=netadmin
ansible_connection=network_cli
ansible_become=yes
ansible_become_method=enable

Explication : ansible_network_os aide Ansible à choisir le module et la gestion des invites appropriés ; network_cli est le plugin de connexion pour des commutateurs basés sur CLI. De préférence, les données sensibles (mots de passe, clés SSH) ne doivent pas figurer dans l’inventory, mais être gérées via Vault ou un gestionnaire d’identifiants Ansible.

Playbook : collecter la sauvegarde de configuration

Les sauvegardes sont la composante la plus sous-estimée. Voici un playbook robuste qui récupère la configuration en cours et la conserve localement sur le nœud de contrôle. Il utilise le module générique ansible.netcommon.cli_command (compatible avec de nombreux fournisseurs) et enregistre la sortie via une action locale.

---
- name: Collect running-config backups from switches
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Get running configuration
      ansible.netcommon.cli_command:
        command: show running-config
      register: running_cfg

    - name: Ensure backup directory exists on control node
      local_action:
        module: file
        path: "backups/{{ inventory_hostname }}"
        state: directory
        mode: '0750'

    - name: Save running configuration to control node
      local_action:
        module: copy
        content: "{{ running_cfg.stdout[0] | default('') }}n"
        dest: "backups/{{ inventory_hostname }}/{{ inventory_hostname }}-{{ ansible_date_time.iso8601_basic }}.cfg"
        mode: '0640'

Pourquoi ainsi ? Le playbook sépare les données de l’équipement (récupérées via SSH) et le stockage des sauvegardes (local sur le nœud de contrôle). Cela simplifie la vérification, la gestion de versions et l’archivage sécurisé. Veillez au format du timestamp (ISO8601) et aux permissions de fichiers sécurisées.

Vérifier avant de démarrer

• Vérifiez l’accès de test : exécutez une commande ad‑hoc simple :

ansible switches -m ansible.netcommon.cli_command -a "command='show version'" -i inventory.ini

Si cela échoue, vérifiez : version d’Ansible, plugin de connexion, accès réseau, identifiants et détection du prompt (timeout, mot de passe enable).

Playbook : modification de configuration (push) avec diff et Check‑Mode

Pour les playbooks de modification, privilégiez des approches modulaires et idempotentes. De nombreuses collections fournisseur (p. ex. cisco.ios.ios_config) implémentent des logiques idempotentes. Si cela n’est pas possible, utilisez cli_config avec –check ou les options de diff.

---
- name: Deploy interface description to access switches
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Apply interface configuration lines
      ansible.netcommon.cli_config:
        lines:
          - interface GigabitEthernet1/0/48
          - description "PRD: uplink to router"
          - switchport mode access
          - switchport access vlan 100
      register: cfg_result

    - name: Show diff when changed
      debug:
        var: cfg_result.diff

Exécutez d’abord les opérations sur un groupe d’appareils de test, puis par lots. Lors des tests, utilisez ansible-playbook --check --diff pour minimiser les risques ; notez que tous les modules réseau ne prennent pas en charge le Check‑Mode intégralement.

Stratégies de rollback : types et mise en œuvre

Le rollback n’est pas une action universelle pour tous les équipements. Il existe trois approches pragmatiques :

1. Restauration native du fournisseur (recommandée) : utilisez les fonctions intégrées à l’équipement comme configure replace (prise en charge par de nombreux Cisco IOS‑XE) ou les rollbacks Junos. Elles sont souvent atomiques et réduisent les transitions incohérentes.
2. Pousser la dernière sauvegarde connue bonne : téléchargez le fichier de sauvegarde et appliquez-le ligne par ligne via cli_config. C’est plus universel, mais peut générer des états intermédiaires incohérents.
3. Comparaison de configuration et revert sélectif : identifiez uniquement les lignes modifiées et appliquez des corrections ciblées. Plus exigeant, mais moins risqué dans des environnements hétérogènes.

Exemple : rollback simple (push du fichier sauvegardé)

---
- name: Rollback config by pushing saved file content
  hosts: switches
  gather_facts: no
  connection: network_cli
  vars:
    rollback_file: "backups/{{ inventory_hostname }}/{{ inventory_hostname }}-20260728T120000Z.cfg"
  tasks:
    - name: Read rollback file on control node
      local_action:
        module: slurp
        src: "{{ rollback_file }}"
      register: rollback_raw

    - name: Decode rollback content
      set_fact:
        rollback_text: "{{ rollback_raw.content | b64decode }}"

    - name: Apply rollback configuration via CLI
      ansible.netcommon.cli_config:
        lines: "{{ rollback_text.split('n') }}"
      register: rb_result

    - name: Debug apply result
      debug:
        var: rb_result

Attention : Cette méthode écrit pratiquement toutes les lignes. Testez-la dans un environnement de laboratoire. Des problèmes surviennent si la sauvegarde enregistrée contient des commandes de console propriétaires, des états d’interfaces temporaires ou des entrées non persistantes.

Règles d’exploitation sécurisées et liste de contrôle avant les modifications

Avant chaque modification, les vérifications suivantes doivent être automatisées ou documentées :

• Sauvegarde disponible et testée (voir le playbook).
• Fenêtre de changement définie et parties prenantes informées.
• Exécution de test en mode Check ou sur un appareil de staging.
• Sérialité : déployer les modifications en petits lots (serial: 1–5 dans Ansible) pour éviter des pannes massives.
• Validation : après la modification, exécuter des contrôles automatisés (Ping, BGP‑Neighbors, VLAN‑Membership).
• Playbook de rollback prêt à portée de main et procédure de RESTauration testée disponible.

Pièges typiques et comment les résoudre

1) Problèmes d’authentification et d’invite

Symptômes : timeouts, invites inattendues, absence de droits Enable. Causes : ansible_connection incorrect, absence d’escalade de privilèges, chaînes d’invite différentes. Solution : définir group_vars pour ansible_become, ansible_become_password ou utiliser des clés SSH et effectuer un test ad‑hoc (par ex. show version). Configurez, si nécessaire, les paramètres de timeout et vérifiez les chaînes d’invite interactives dans ansible.cfg.

2) Absence d’idempotence

Si vous utilisez des commandes CLI brutes, les actions ne sont souvent pas idempotentes (modification à chaque exécution). Mieux : modules de configuration spécifiques au fournisseur (p. ex. cisco.ios.ios_config) qui effectuent une comparaison d’état. Si ce n’est pas possible, développez vos propres logiques de comparaison (diff avant/après, hachages).

3) Le parallélisme provoque des perturbations réseau

Des modifications massives et simultanées peuvent violer des dépendances (p. ex. STP, LACP). Utilisez dans Ansible serial dans vos plays ou des exécutions par rôle via des tags. Exemple:

- hosts: switches
  serial: 3
  tasks:
    - name: Apply change
      ...

4) Sauvegardes incomplètes

Certains équipements ne fournissent que des parties de la configuration ou nécessitent des commandes spécifiques pour la persistance. Vérifiez régulièrement les sauvegardes via des tests de RESTauration automatisés en laboratoire.

Validation et supervision après modification

Les contrôles automatisés sont obligatoires. Exemples de vérifications à exécuter immédiatement après une modification :

• Accessibilité ICMP des chemins critiques.
• Statut des voisins (BGP/OSPF) pour les routeurs adjacents.
• Vérification des VLAN et de l’état des ports pour les ports d’accès concernés.
• Surveiller les métriques SNMP/télémétrie (latence, taux d’erreurs) – les anomalies indiquent des problèmes potentiels.

Un petit exemple montrant comment réaliser un contrôle post‑changement sous forme de playbook :

---
- name: Post-change validation
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Check interface up status
      ansible.netcommon.cli_command:
        command: show interfaces status
      register: intf_status

    - name: Fail if critical port is down
      fail:
        msg: "Critical interface down on {{ inventory_hostname }}"
      when: "'Gi1/0/48' in intf_status.stdout[0] and 'notconnect' in intf_status.stdout[0]"

Audit, Archivierung und Retention

Les sauvegardes doivent être versionnées, vérifiées et archivées. Une approche recommandée combine un Git‑Repository pour les sauvegardes textuelles (uniquement pour les fichiers de configuration) avec un stockage d’objets pour l’archivage à long terme (p. ex. S3). Vérifiez les points suivants :

• Intégrité : contrôles de hachage réguliers.
• Politique de rétention : définir les durées de conservation légales/contractuelles.
• Contrôle d’accès : qui est autorisé à déclencher une RESTauration ? (Role‑Based Controls)

Praxisbeispiel: Minimaler Workflow für einen Change

1. Mettre à jour le playbook dans le dépôt, créer un Merge Request avec revue.
2. Exécuter un dry‑run (–check) sur le switch de staging.
3. Créer une sauvegarde automatique avant le changement.
4. Déployer le changement en petits lots avec monitoring en temps réel.
5. Exécuter les post‑checks automatiquement ; en cas d’erreur, déclencher un rollback automatique.

Troubleshooting: Wichtige Prüfsequenz

1. Test de connexion : tâche ad‑hoc comme ci‑dessus (show version).
2. Vérifier les logs : le mode verbeux d’Ansible -vvv affiche le dialogue SSH et la détection du prompt.
3. Problèmes de prompt/expect : vérifier que le prompt du module (ansible_network_os) est correctement défini.
4. Timeouts : augmentez ansible_connection_timeout dans group_vars si nécessaire.
5. Tester le rollback au préalable : effectuer un RESTore dans un environnement isolé.

Netzwerkautomation mit Ansible: CI/CD, Secrets und Telemetrie integrieren

L’intégration dans des pipelines CI/CD rend les changements traçables et auditables. Un flux typique : Merge Request → lint/Tests unitaires automatiques des playbooks → dry‑run dans un lab → étape d’approbation → déploiement séquentiel. Utilisez pour les secrets Ansible Vault ou un système de gestion des secrets dédié (p. ex. HashiCorp Vault). Vault permet des identifiants dynamiques et réduit le risque de mots de passe persistants.

La télémétrie (p. ex. gNMI, streaming telemetry, SNMP Traps) complète l’automatisation par des métriques en temps réel. Après un changement, les alertes de télémétrie doivent être automatiquement associées au contexte du changement (Change‑ID, Run‑ID) — ainsi vous identifiez si une alerte est causée par la modification.

Beispiel: CI‑Step, der ein Playbook im Check‑Mode ausführt

#!/bin/bash
# CI step: run playbook in check mode and fail on changes
ansible-playbook -i inventory.ini change_playbook.yml --check --diff
if [ $? -ne 0 ]; then
  echo "Check mode failed or would change devices" >&2
  exit 1
fi

Atomicere Rollbacks: Vendor‑native Replace

Si votre plateforme prend en charge configure replace ou une procédure équivalente de replace atomique, utilisez‑la. Cela réduit le risque d’états intermédiaires. Exemple pour Cisco IOS‑XEs avec un module fournisseur (exemple conceptuel) :

---
- name: Atomic replace from candidate file (vendor-specific)
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Replace running-config atomically
      cisco.ios.ios_config:
        src: "backups/{{ inventory_hostname }}/candidate.cfg"
        replace: yes
        save_when: modified

Remarque: les paramètres portent des noms différents selon la vendor‑Collection. Vérifiez la documentation de votre vendor‑Collection et testez intensivement la procédure en environnement de laboratoire.

Surveillance : listes de contrôle, savoir opérationnel et bonnes pratiques

Pour une exploitation durable, les mécanismes de supervision et de vérification sont essentiels. Recommandations :

• Tests de RESTauration automatisés au minimum trimestriels dans un environnement isolé.
• Vérifications de différences après chaque sauvegarde : générez un hash (p. ex. SHA256) et enregistrez‑le comme métadonnée.
• Joindre le contexte de changement à la supervision : Run‑ID, Commit‑Hash, opérateur, numéro de ticket.
• Playbooks d’alerte : en cas d’alarme critique, rollback automatique ou déclenchement d’escalade selon la politique.

Exemple : génération de hash et enregistrement des métadonnées après une sauvegarde :

sha256sum backups/sw-core-01/sw-core-01-20260728T120000Z.cfg > backups/sw-core-01/metadata.txt
echo "commit: $GIT_COMMIT" >> backups/sw-core-01/metadata.txt
echo "run_id: $CI_RUN_ID" >> backups/sw-core-01/metadata.txt

Runbook d’urgence : RESTauration manuelle et accès OOB

Si le rollback automatique échoue, un runbook clair est nécessaire. Résumé :

1. Vérifier la console OOB (console server, IPMI/Redfish) — garantit l’accès si le réseau est inaccessible.
2. Identifier la dernière sauvegarde intacte (vérifier les métadonnées : timestamp, version SW).
3. Charger le rollback localement sur la console ou l’appliquer via TFTP/USB.
4. Vérifications de base : interfaces up, routage/voisins, ACLs critiques.
5. Vérifications post‑opératoires détaillées et clôture du ticket après succès confirmé.

Conclusion : conseils pratiques pour l’exploitation

L’automatisation réseau avec Ansible apporte transparence et rapidité — à condition d’investir dans l’hygiène de l’inventaire, la discipline des sauvegardes, des procédures de rollback testées et une stratégie de déploiement progressive. Utilisez des modules vendor‑spécifiques lorsque c’est pertinent, automatisez les scripts de validation et maintenez des règles strictes d’accès et de rétention. Pour des équipements hétérogènes, des stratégies pragmatiques de sauvegarde et de rollback sélectif sont le choix le plus sûr.

Point de départ concret : créez un playbook de sauvegarde comme ci‑dessus, testez‑le sur un switch de staging, puis étendez progressivement vos playbooks de changement avec le Check‑Mode, les sorties diff et des rollouts sérialisés. Complétez cela par du CI/CD, une intégration de télémétrie et des tests de RESTauration réguliers afin de réduire durablement les risques opérationnels.

Les Ansible Playbooks et la configuration des switches sont également importants pour ce sujet. L’article situe clairement ces aspects et montre ce qui compte au quotidien.