Module 4 : Approche NetDevOps et Orchestration globale

Module 4 Module 4

Infrastructure as Code appliquée au réseau

Déclaratif vs impératif

Comparaison entre l’approche impérative et l’approche déclarative Comparaison entre l’approche impérative et l’approche déclarative Impératif : suite d’actions ordonnées. Déclaratif : un état désiré, l’outil calcule les actions.

  • Impératif : décrire la suite d’actions à exécuter (« crée cette interface, puis ajoute cette route »).
  • Déclaratif : décrire l’état final souhaité ; l’outil détermine les actions nécessaires pour l’atteindre.
# Déclaratif : l'état souhaité
interfaces:
  eth0:
    address: 192.168.10.1/24

Les TP précédents (Modules 2 et 3) étaient majoritairement impératifs (appels séquentiels POST/PATCH). Ce module introduit une logique déclarative.

État désiré et idempotence

  • Idempotence : appliquer plusieurs fois la même configuration produit le même résultat, sans erreur ni doublon (déjà pratiqué au Module 2 en vérifiant l’existant avant création).
  • État désiré : la configuration cible, comparée à l’état réel de l’équipement à chaque exécution.

Dérive de configuration (config drift)

Dérive de configuration : état déclaré vs état réel dans le temps Dérive de configuration : état déclaré vs état réel dans le temps Un changement manuel hors-bande fait diverger l’état réel de l’état déclaré ; l’IaC détecte l’écart et corrige.

Écart entre la configuration déclarée (dans le code) et la configuration réellement appliquée sur l’équipement (modification manuelle non tracée, panne, etc.). Une approche IaC permet de la détecter en comparant état désiré et état réel.

Source de vérité et inventaire

Source de vérité (source of truth)

Le référentiel qui fait foi pour la configuration attendue d’un parc d’équipements — typiquement un dépôt Git (lien avec le Module 1) contenant des fichiers de configuration ou des variables.

Inventaire

Liste structurée des équipements à gérer, avec leurs attributs (adresse IP, plateforme, identifiants, groupe) :

routers:
  hosts:
    r1:
      hostname: 192.168.1.1
      platform: cisco_ios
    r2:
      hostname: 192.168.1.2
      platform: vyos

Templating

Pipeline de templating : template + variables → configuration générée Pipeline de templating : template + variables → configuration générée Le moteur Jinja2 fusionne un modèle (.j2) et des variables pour produire une configuration CLI concrète.

Séparer la structure de la configuration (le modèle) des valeurs (les variables), avec un moteur de templates comme Jinja2 :

interface {{ iface }}
 ip address {{ ip }} {{ mask }}
from jinja2 import Template
t = Template(open("interface.j2").read())
print(t.render(iface="GigabitEthernet1", ip="192.168.1.1", mask="255.255.255.0"))

Automatiser sans API moderne

Le problème

Beaucoup d’équipements (réseaux legacy, certains commutateurs d’accès) n’exposent ni REST, ni NETCONF/RESTCONF : seule la CLI via SSH est disponible.

Screen scraping

  • envoyer des commandes CLI comme le ferait un opérateur humain,
  • analyser le texte retourné (parsing) pour en extraire des informations,
  • fragile : un changement de format d’affichage (mise à jour de l’OS) peut casser le parsing.

Limites

  • pas de structure garantie (contrairement à JSON/XML),
  • latence plus élevée (émulation d’une session interactive),
  • mais reste indispensable pour le parc installé qui n’a pas d’API moderne.

Des bibliothèques comme Netmiko standardisent cette approche en gérant les spécificités de chaque plateforme (prompts, pagination, modes de configuration).

Orchestration multi-constructeurs

Le besoin

Exécuter une même tâche sur un parc hétérogène (MikroTik, VyOS, Cisco…) sans écrire un script différent pour chaque constructeur.

Modèle tâche + inventaire (Nornir)

Nornir : inventaire et tâche convergent vers une exécution parallèle Nornir : inventaire et tâche convergent vers une exécution parallèle Inventaire (le « quoi ») et tâche (le « comment ») sont découplés ; Nornir exécute en parallèle sur chaque hôte.

  • un inventaire décrit le « quoi » (les équipements et leurs attributs),
  • une tâche décrit le « comment » (l’action à exécuter),
  • le framework exécute la tâche sur chaque hôte de l’inventaire, en parallèle.
from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_command

nr = InitNornir(config_file="config.yaml")
result = nr.run(task=netmiko_send_command, command_string="show version")

Avantages

  • exécution parallèle (gain de temps sur un grand parc),
  • code découplé de l’inventaire (le même script s’applique à 2 ou 200 équipements),
  • extensible par plugins (nornir_netmiko, nornir_napalm, nornir_jinja2…).

À retenir

  • IaC déclaratif : décrire l’état désiré, pas la suite d’actions.
  • La dérive de configuration se détecte en comparant l’état désiré à l’état réel.
  • Source de vérité (Git) + inventaire structuré + templating (Jinja2) forment le socle du NetDevOps.
  • Sans API moderne, le screen scraping (Netmiko) reste la seule option.
  • Nornir sépare inventaire et tâches pour orchestrer un parc hétérogène en parallèle.