Que vous soyez habitué aux systèmes Debian GNU/Linux ou administrateur réseau Cisco IOS XE, ces trois nouveaux supports de TP vous plongent au cœur des pratiques DevOps modernes.

1. Une reproductibilité garantie avec Astral uv

L'une des innovations majeures de cette année est l'adoption du gestionnaire de paquets Astral uv.

• Rapidité et fiabilité :
  Finis les problèmes de versions divergentes entre les environnements de développement et de test. Grâce au fichier pyproject.toml, l'ensemble de la chaîne d'outils Ansible est verrouillé de manière déterministe.

• Intégration CI/CD allégée :
  Les pipelines GitLab CI sont simplifiés. Au lieu d'alourdir l'infrastructure avec des images Docker pour exécuter Ansible, nous utilisons une chaîne allégée directement pilotée par uv. Cette approche garantit des traitements idempotents tout en réduisant considérablement le temps de démarrage des tâches (jobs).

2. Des playbooks optimisés et « data-driven »

Le code des playbooks a été entièrement revu. L'objectif ? Une séparation stricte entre les données déclaratives et les procédures d'exécution.

• Modularité :
  Les configurations sont désormais plus lisibles et faciles à maintenir.

  ---
  vrouter:
    vm_name: r2
    os: iosxe
    master_image: "{{ image_name }}"
    force_copy: false
    tapnumlist: [6, 7, 8]
  
  router_host_id: "{{ vrouter.tapnumlist[0] | int }}"
  
  interfaces:
    - interface_type: GigabitEthernet
      interface_id: 2
      description: --> VLAN 230
      enabled: true
      vlan_id: 230
    - interface_type: GigabitEthernet
      interface_id: 3
      description: --> VLAN 800
      enabled: true
      vlan_id: 800
  
  default_routes: "{{ inband_vlans[0].default_routes }}"
  

• Calcul d'adressage intelligent :
  L'utilisation de modules avancés, comme nthost, permet de calculer automatiquement les plans d'adressage IPv4 et IPv6, optimisant ainsi grandement les traitements. Cette approche permet de réduire les erreurs humaines et de déployer rapidement des topologies complexes (VM Linux ou routeurs IOS XE), en modifiant simplement une variable de groupe.

  ---
  inband_vlans:
    - vlan: 230
      subnet4: 10.0.228.0/22
      subnet6: 2001:678:3fc:e6::/64
      default_routes:
        ipv4_next_hop: 10.0.228.1
        ipv6_next_hop: 2001:678:3fc:e6::1
    - vlan: 800
      subnet6: 2001:db8:320::/64
  

3. Gestion des secrets : trouver l'équilibre entre sécurité et simplicité

Cette édition maintient volontairement une « entorse » aux bonnes pratiques académiques concernant la gestion des secrets pour cette édition.

• Simplification pédagogique :
  Plutôt que d'introduire un coffre-fort numérique tiers (type HashiCorp Vault), nous conservons l'usage d'Ansible Vault.

• Le coût du partage :
  Ce choix engendre toutefois un coût opérationnel, car les secrets doivent être partagés entre le compte du développeur et celui du GitLab Runner. En revanche, il permet de se concentrer sur l'essentiel, c'est-à-dire la logique de déploiement de l'infrastructure, sans multiplier les dépendances logicielles.

4. Pourquoi étudier ces supports ?

Que vous souhaitiez construire des machines Debian à partir d'images cloud ou orchestrer des routeurs virtuels via des pipelines CI/CD complets, cette série 2026 vous permettra d'apprendre à passer d'une administration manuelle à une gestion d'infrastructure entièrement automatisée.

Prêt à automatiser ? Découvrez les trois volets de la série :

• Lab 1 – Construction de VMs Debian avec Ansible  —  GitLab repository
• Lab 2 – Automatisation GitLab CI pour les VMs Linux  —  GitLab repository
• Lab 3 – Déploiement de routeurs IOS XE via GitLab CI  —  GitLab repository

Récemment, ce script a commencé à produire des erreurs sur l’une de mes passerelles sous Debian testing. Plutôt que de corriger les expressions rationnelles et de multiplier les outils tiers, j’ai choisi de m’appuyer sur le module standard ipaddress de Python pour manipuler proprement adresses et réseaux IPv4/IPv6.

Après quelques heures de travail assisté par l’IA, j’ai le plaisir de vous présenter un fork en Python, entièrement réécrit et optimisé, de l’outil nft-blacklist. Ce code a pour objectif de gérer rapidement et de manière robuste des listes noires de grande taille d’adresses IP pour un pare-feu basé sur nftables.

Pourquoi un fork ? Genèse de la réécriture

Avec la multiplication des tentatives d’attaques automatisées, des outils comme fail2ban utilisés seuls ne suffisent plus. Il devient nécessaire de mieux contrôler les performances et l’utilisation des ressources sur les serveurs exposés à Internet (VPS, passerelles, serveurs d’applications, etc.).

C’est dans ce contexte que j’ai réécrit l’intégralité du script en Python 3, en m’appuyant sur un fichier de configuration au format TOML. L’objectif est triple : améliorer les performances, renforcer la robustesse et rendre le code plus simple à maintenir.

Voici le workflow synthétique du nouveau script :

Principales optimisations du fork Python

Le fork, disponible à l’adresse https://github.com/platu/nft-blacklist, se distingue par plusieurs optimisations clés par rapport au script shell initial.

1. Parallélisation des téléchargements

Script shell initial : les listes de sources sont téléchargées séquentiellement, l’une après l’autre. Si une seule source est lente, tout le processus est ralenti.

Fork Python : grâce au module concurrent.futures, le script télécharge toutes les listes noires en parallèle. L’utilisation d’une unique requests.Session() permet en outre de réutiliser les connexions TCP/TLS (connection pooling), ce qui réduit fortement le temps passé en I/O réseau, surtout avec de longues listes. On peut ainsi obtenir un gain de performance de l’ordre de 10x à 50x sur cette phase.

2. Validation robuste des adresses

Script shell initial : l’analyse repose sur des expressions régulières et des outils comme awk ou grep, sensibles aux variations de format des fichiers. La validation des adresses IP reste assez basique.

Fork Python : le module standard ipaddress assure une analyse et une validation strictes. Chaque ligne est interprétée comme adresse ou réseau IPv4/IPv6, et seules les entrées valides sont conservées. Les lignes vides et les commentaires sont filtrés proprement, ce qui évite les mauvaises surprises.

3. Consolidation et déduplication des listes

Script shell initial : les doublons sont généralement éliminés via un simple sort | uniq. Il n’y a pas de consolidation native des réseaux (par exemple fusionner 1.2.3.0/24 et 1.2.3.4/32 qui se chevauchent).

Fork Python : le script déduplique instantanément toutes les adresses à l’aide d’un set() Python performant. Surtout, il utilise ipaddress.collapse_addresses() pour fusionner et consolider les réseaux redondants. Le résultat est un jeu de règles nftables beaucoup plus compact, qui consomme moins de mémoire et réduit le nombre de comparaisons effectuées par le pare-feu.

4. Application atomique et rapidité

Script shell initial : beaucoup de scripts shell appliquent les règles élément par élément, ou génèrent de multiples fichiers temporaires. En cas d’erreur de type File exists, ils basculent dans un mode de secours (fallback) souvent très lent.

Fork Python : le script génère en mémoire (via stdin) un fichier de configuration complet et optimisé, puis l’applique en une seule transaction atomique avec la commande nft -f. En cas de succès, la mise à jour du pare-feu est instantanée et cohérente. En cas d’erreur, l’état précédent est préservé. Le mode de secours a été réécrit pour ne traiter que les blocs défaillants, faisant passer cette phase de plusieurs minutes à quelques secondes.

5. Code propre, typage et journalisation

Script shell initial : un script shell qui grossit peut rapidement devenir difficile à lire et à faire évoluer, avec des lignes mêlant sed, awk et substitutions diverses.

Fork Python : le code est écrit en Python typé (type hints) afin de faciliter la relecture et la détection d’erreurs. Il s’appuie sur le module standard logging pour s’intégrer proprement avec le journal système et offrir un diagnostic clair en cas de problème.

Prérequis et intégration

Le script cible principalement les environnements GNU/Linux disposant de nftables (par exemple Debian/Ubuntu récentes) et d’un Python 3 à jour. Un exemple de fichier de configuration TOML est fourni dans le dépôt Git, afin de faciliter l’intégration avec votre propre jeu de règles.

Conclusion

Ce fork Python de nft-blacklist constitue une évolution importante du projet initial. Il est plus rapide, plus robuste et génère des règles nftables nettement plus optimisées, ce qui contribue à préserver les ressources de votre serveur tout en améliorant votre surface de défense.

N’hésitez pas à tester ce nouvel outil et à me faire part de vos retours sur le dépôt GitHub : https://github.com/platu/nft-blacklist.

• L'adoption de pratiques déclaratives (YAML, Cloud-init, Incus) améliore considérablement la reproductibilité des travaux pratiques, mais crée un fossé entre les étudiants qui structurent leur démarche et ceux qui se contentent de copier-coller des configurations.
• L'utilisation non contextualisée de l'IA, comme ChatGPT, conduit certains étudiants à exécuter des commandes incohérentes et déconnectées des énoncés.
• Dans une logique inspirée de DevOps, les évaluations doivent exiger le contexte complet d'exécution (environnements, déclarations, artefacts de preuve) ainsi que des méthodes de sélection et de validation des sources.

Après avoir migré la gestion des machines virtuelles vers le mode déclaratif basé sur des fichiers YAML (voir le code du script lab-startup.py), j'ai ajouté l'utilisation de Cloud-init en septembre dernier.

La dernière révision du support de travaux pratiques intitulé « Start unprivileged Incus containers on top of Open vSwitch in a few steps » illustre bien cette évolution. Les premières parties proposent de réaliser les opérations de mise en place de la topologie ci-dessous une à une, tandis que la dernière partie les réalise en mode déclaratif.

Les travaux pratiques ont beaucoup gagné en reproductibilité. Cette évolution met toutefois en lumière un écart croissant entre les étudiants qui structurent mieux le développement des déclarations et ceux qui se contentent de copier-coller des configurations sans comprendre les opérations d'administration système attendues.

Le paradoxe de l'abstraction déclarative

Cette approche marque une rupture avec les pratiques impératives classiques. Auparavant, chaque commande était exécutée en observant son effet ; aujourd'hui, les fichiers YAML décrivent un état attendu sans détailler les étapes. Cette abstraction constitue un véritable progrès pour l'industrialisation et la reproductibilité.

Sur le plan pédagogique, elle crée toutefois un piège. Les étudiants les plus investis l'utilisent pour mieux structurer le séquencement des opérations. D'autres, en revanche, utilisent les salons Discord comme des « marketplaces YAML » et récupèrent des configurations toutes faites, au détriment de l'objectif central, à savoir analyser un problème, choisir les actions nécessaires et construire une solution cohérente.

L'IA conversationnelle : un faux ami pédagogique !

L'utilisation d'agents conversationnels tels que ChatGPT amplifie cette dérive. L'analyse des logs des hyperviseurs révèle des tentatives d'exécution de commandes incohérentes, totalement déconnectées des énoncés des travaux pratiques. Le problème n'est pas que les étudiants commettent des erreurs — l'erreur fait pleinement partie du processus d'apprentissage —, mais qu'ils exécutent des instructions sans rapport avec le contexte pédagogique, ce qui témoigne d'une absence totale d'attention et de réflexion.

Au lieu de l'utiliser comme assistant pour approfondir leur compréhension, quelques étudiants sollicitent l'IA sans la moindre contextualisation. Ils obtiennent ainsi des réponses génériques (j'aurais envie d'écrire « hallucinées ») qui ne correspondent ni à l'environnement de formation ni aux objectifs pédagogiques. L'IA devient alors un obstacle à l'apprentissage.

Le contexte de la formation initiale ne facilite pas les choses

Les ressources documentaires sont largement accessibles en ligne, et les solutions aux exercices pratiques sont disponibles publiquement. Cette accessibilité, combinée à la facilité d'interroger des agents conversationnels, supprime toute incitation à fournir un effort de contextualisation et de sélection précise des sources.

Il est donc nécessaire d'insister davantage sur deux points : la sélection des documents et la validation de l'applicabilité des réponses, notamment via des méthodologies telles que la génération augmentée par recherche (RAG), qui ancrent l'IA dans un corpus précis. C'est un axe de progression identifié pour les prochains modules.

Je sais depuis longtemps que l'enseignement des opérations doit privilégier des évaluations en conditions réelles, avec un temps limité. En revanche, je suis beaucoup plus sceptique quant au recours systématique au dépannage de systèmes volontairement altérés. En effet, la restitution basée sur la justification des choix techniques et la résolution de problèmes peut être réalisée en totalité par une IA.

Affaire à suivre...

Dans le prolongement du paradigme DevOps, le code produit par les étudiants dans le cadre d'un projet de développement doit désormais être livré avec son contexte d'exécution complet (environnements virtuels Python, dépendances et paramètres). La restitution des opérations d'administration système doit quant à elle inclure les éléments de preuve (artéfacts) permettant de générer des tests unitaires, ainsi que les sources déclaratives ayant conduit aux résultats observés. Jusqu'à présent, je demande aux étudiants de fournir un compte rendu des résultats importants au format Markdown sur un canal Mattermost. Il faut faire évoluer cette pratique. Affaire à suivre donc.

Le protocole NFS (Network File System) vient de célébrer son 40e anniversaire ! Depuis 1984, il a profondément transformé l'accès aux fichiers en réseau. Il est devenu incontournable pour tous les administrateurs de systèmes Unix et Linux. À cette occasion, le support de travaux pratiques « Introduction au système de fichiers réseau NFSv4 » a été entièrement révisé et enrichi pour répondre aux enjeux de la sécurité et de l'administration moderne.

Un support pédagogique complet, pensé pour la pratique

Ce document propose une exploration progressive du protocole NFSv4, des bases des appels RPC aux montages dynamiques sous Linux. Le plan guide pas à pas à travers les étapes suivantes :

• l'identification et la configuration des services réseau historiques, tels que rpcbind et portmapper ;
• la mise en place d'une maquette minimaliste de type NAS avec exportation d'arborescences et création de comptes utilisateurs locaux ;
• le paramétrage des montages manuels et automatisés via autofs ;
• le contrôle des permissions et de la cohérence des identités locales et distantes, à l'aide de tests sur différentes valeurs UID/GID.

Nouveauté 2025 : la sécurité avancée NFS, de bout en bout

Le cœur de cette nouvelle édition réside dans une nouvelle section consacrée à la sécurité. Avec l’adoption croissante de NFS dans des contextes sensibles (cloud, intelligence artificielle, clusters scientifiques), la sécurisation n’est plus une option.

• La configuration de Kerberos V5 est désormais détaillée pour permettre une authentification stricte des identités avec la gestion des éléments principaux (realm, keytab, etc.).
• Le chiffrement TLS sur RPC (RFC 9289) : le guide explique comment activer le chiffrement de bout en bout avec TLS grâce au démon tlshd, offrant ainsi une protection contre les interceptions de trafic réseau.
• Les étapes de déploiement intégrées sont décrites, de la génération des identités et des certificats à la configuration sur le client et le serveur, allant jusqu'à la validation des communications.

Vous apprendrez à capturer et à analyser le trafic réseau afin de distinguer un flux NFS en clair d'un flux protégé par Kerberos et TLS, ainsi qu'à vérifier pas à pas l'authentification dans les journaux Kerberos.

Enfin, la conclusion ouvre la voie au prochain défi incontournable : la gestion centralisée des identités via un annuaire LDAP – indispensable pour industrialiser NFS dans les grandes infrastructures.

Pour développer vos compétences et découvrir NFS comme vous ne l'avez jamais administré, (re)découvrez ce support de travaux pratiques, un classique renouvelé à l'image des 40 ans d'innovation du protocole NFS !

Le support « Introduction au système de fichiers réseau NFSv4 » est disponible en version PDF.

Relevez le défi ! L'association Kerberos et TLS permet de décentraliser le stockage tout en le rapprochant de l'utilisateur, sans compromettre la protection des données.

Voici une brève introduction aux trois supports de cours utilisés dans le module Administration Système et Réseaux.

Présentation 1 : Bases du Stockage Réseau - Quand le Stockage Devient une Fonction Réseau

Ce premier support de cours pose les bases du stockage moderne et explique comment cette fonction est passée d'un système local à un service réseau à part entière.

Trois objectifs essentiels :

• Maîtriser les familles de stockage : comprendre les trois modes d'accès fondamentaux (bloc, fichier et objet), ainsi que les technologies associées (DAS, SAN et NAS), du SCSI traditionnel aux solutions NVMe les plus récentes.
• Gérer les volumes logiques : développer une compétence en matière d'abstraction du stockage physique avec les solutions LVM, ZFS et Btrfs, afin d'assurer une flexibilité, une résilience et des performances optimales.
• Évaluer les enjeux d'usage : analyser les critères de choix (capacité, disponibilité, évolutivité) et comprendre l'impact de la virtualisation sur les performances, notamment l'effet « I/O Blender ».

Présentation 2 : Systèmes de Fichiers Réseau et Stockage Objet - L'Art du partage intelligent

Cette deuxième présentation approfondit les mécanismes de partage et d'accès aux données via les réseaux, en se concentrant sur les protocoles NFS et SMB, ainsi que sur les architectures de stockage objet.

Trois objectifs importants :

• Comparer les systèmes de fichiers distribués : décrire les protocoles NFSv4.2 et SMB 3.1.1, ainsi que leurs mécanismes de sécurité avancés (chiffrement AES, authentification Kerberos) et les architectures parallèles comme pNFS.
• Décrire le stockage objet : introduire l'architecture Ceph avec la séparation données/métadonnées, les algorithmes CRUSH de placement intelligent et la réplication distribuée.
• Associer la sécurité et les performances : intégrer le chiffrement en transit et au repos, gérer les topologies backend/frontend et minimiser l'impact de la latence réseau sur l'expérience utilisateur.

Présentation 3 : Gestion Réseau des Identités - Entrer dans l'ère de l'identité numérique

Trois objectifs à mettre en avant :

• Moderniser l'authentification : migrer des méthodes traditionnelles (mots de passe + SMS/TOTP) vers les standards FIDO2 et l'authentification comportementale par IA, en intégrant les protocoles OAuth 2.0 et OpenID Connect.
• Centraliser la gestion des identités : déployer des solutions LDAP et Active Directory avec SSSD pour unifier l'accès aux magasins d'identités hétérogènes et assurer la continuité de service en mode déconnecté.
• Découvrir la gestion des identités et des accès natifs au cloud : présenter le cloud-native IAM avec fédération d'identités, tokens JWT et conformité réglementaire (RGPD, NIS2) intégrée dès la conception.

La compréhension approfondie des briques fonctionnelles du stockage réseau et de la gestion d'identité s'impose aujourd'hui comme une compétence stratégique pour les futurs ingénieurs. Disposer d'une vision claire et précise de ces mécanismes permet non seulement de consolider les bases techniques, mais aussi de gagner en autonomie dans le choix, le déploiement et l'administration d'infrastructures critiques. Cette démarche est d'autant plus cruciale dans une perspective d'émancipation numérique, où l'ambition de bâtir des solutions de cloud souverain – libres des dépendances vis-à-vis des géants du secteur – devient un enjeu majeur pour assurer la résilience, la sécurité et l'indépendance technologique des organisations.

Les 3 points forts du Lab 11 – Build a Sample Web App in a Podman Container

1. Maîtrise de l’automatisation avec Bash
   Le Lab 11 débute par un court rappel des bases du scripting Bash, indispensable pour automatiser la création de fichiers, la manipulation de répertoires et l'exécution de tâches répétitives.
2. Développement et conteneurisation d’une application web Python
   Les étudiants développent une application web minimale en Python/Flask, puis l'enrichissent avec des fichiers statiques (HTML/CSS) afin de simuler une expérience utilisateur. La suite du TP les guide dans la création d’un Dockerfile et l’utilisation de Podman pour construire et exécuter l’application dans un conteneur, ce qui permet de se familiariser avec le packaging d’applications.
3. Cycle complet : build, run, inspect, clean
   Le TP ne se contente pas de la simple exécution : il propose une démarche complète incluant la construction, l’inspection, l'accès interactif au conteneur, l'arrêt et la suppression contrôlée des ressources. Cette approche permet de découvrir le cycle de vie d’une application conteneurisée ainsi que la reproductibilité de sa construction.

Les 3 points forts du Lab 12 – Build a Sample Web App CI/CD Pipeline Using Jenkins

1. Introduction pratique à CI/CD avec Jenkins
   Le Lab 12 s'appuie sur le travail réalisé dans le Lab 11 pour aborder la gestion de code source avec GitLab, puis l'automatisation des builds et des tests via Jenkins. L'installation, la configuration et la sécurisation des accès Jenkins/agent sont détaillées, ce qui permet de rendre l'infrastructure reproductible et de se rapprocher des bonnes pratiques.
2. Orchestration complète du pipeline : build, test et déploiement persistant
   L’étudiant crée des jobs Jenkins pour construire et tester l’application dans un conteneur Podman, puis intègre ces étapes dans un pipeline déclenché à chaque modification du code. L'utilisation d'un service Quadlet (systemd) garantit que le conteneur reste actif après la fin du job Jenkins, assurant ainsi la persistance du service.
3. Contrôle qualité automatisé et diagnostic intégré
   Le pipeline intègre des scripts de test automatisés qui vérifient non seulement l'état du conteneur, mais aussi l'accessibilité réelle de l'application web. Des diagnostics détaillés (logs, statuts systemd, etc.) sont collectés en cas d’échec, ce qui illustre l'importance du feedback rapide et de la traçabilité dans une démarche DevOps.

L'importance d’une démarche CI/CD avec reconstruction complète à chaque exécution

La mise en place d’un pipeline CI/CD qui reconstruit l'application et son environnement à chaque exécution garantit la cohérence, la sécurité et la reproductibilité du déploiement. À chaque modification du code source, le pipeline :

• Récupère la dernière version depuis le gestionnaire de sources (GitLab)
• Reconstruit intégralement l'image conteneurisée (Podman)
• Déploie l'application dans un environnement propre, géré par systemd (Quadlet)
• Exécute des tests automatisés pour valider le bon fonctionnement

Cette approche élimine les effets de bord liés à des environnements incomplets, réduit les risques d’erreurs humaines et accélère la détection des régressions. Elle s’inscrit dans les bonnes pratiques DevOps, où l'automatisation et la reconstruction systématique sont des gages de qualité et de rapidité de livraison.

Pour conclure

La progression proposée dans ces deux travaux pratiques illustre l'équilibre à trouver entre les métiers du développement et des opérations. Ils insistent sur la reconstruction complète, la persistance des services, l'intégration des tests et la gestion des erreurs. Cette démarche reflète les exigences du monde professionnel, où la robustesse, la traçabilité et l'automatisation sont des critères essentiels pour l'industrialisation des applications.

Le mode BEET (Bound End-to-End Tunnel) combine les avantages des modes tunnel et transport d'IPSec : il réduit la surcharge d'en-tête typique du mode tunnel tout en conservant une structure adaptée à la traduction d'adresses (NAT). Cette approche permet d'optimiser les performances (chiffrement ESP en transport) et de simplifier la gestion des adresses grâce à des associations de sécurité (SA) prédéfinies. Il garantit la résilience face aux changements d'adressage des fournisseurs d'accès internet (FAI).

L'utilisation des interfaces Xfrm Linux permet de découpler la gestion des associations de sécurité (SA) du routage de paquets. L'objectif est de simplifier la gestion des tunnels. Associées au mode BEET, ces interfaces Xfrm associent chaque SA à un identifiant d'interface unique. Cette abstraction facilite également le filtrage via nftables.

Côté sécurité et conformité, le guide privilégie les certificats auto-signés Ed25519/X25519, offrant une sécurité post-quantique (NIST Level 1) tout en restant compatible avec les normes X.509. Le choix de chacha20poly1305 et SHA-384 assure un chiffrement robuste, même sur du matériel limité sans gestion du matériel TPM.

Pour le filtrage, Nftables offre une gestion unifiée du trafic chiffré/déchiffré avec des règles spécifiques (meta ipsec exists) qui permettent de filtrer uniquement les paquets traités par IPSec. Il est toutefois toujours nécessaire de régler manuellement le MSS clamping pour adapter la taille des segments TCP et éviter la fragmentation. L'utilisation des règles de masquerading assure une traduction d’adresses transparente pour les flux sortants des extrémités du VPN.

Cette architecture démontre qu'il est possible de déployer un VPN solide à moindre coût, en s'appuyant sur des outils open source comme strongSwan et nftables. En combinant BEET, Xfrm et des standards cryptographiques modernes, elle offre une alternative aux solutions cloud propriétaires, avec pour objectif la mise en place d'infrastructures de services autonomes. La modularité des configurations permet par ailleurs une adaptation aisée à des cas d’usage variés, allant des objets connectés industriels aux déploiements hybrides.

Si vous recherchez l'autohébergement en dehors de la sphère des fournisseurs d'accès Internet, cette solution de VPN en mode BEET est faite pour vous. N'hésitez pas à me faire part de vos retours sur le document.

La problématique étant posée, nous sommes à nouveau confrontés à des défis de taille !

• Nos étudiants, bien que débutants, ont été habitués à l'approche impérative (séquence d'instructions propres à chaque constructeur). Le passage à une approche déclarative, qui décrit l'état souhaité sans tenir compte des équipements cibles représente un changement de paradigme important.
• Dans le domaine de la formation, on privilégie souvent des solutions qui escamotent l'infrastructure physique sous-jacente - underlay network - qui assure la connectivité de base, pour se concentrer sur l'abstraction d'infrastructure - overlay network - qui offre une grande flexibilité pour les applications et les services. À force de recourir à tous ces faux-semblants, les étudiants ont du mal à changer de contexte, et certains pensent même que c'est impossible.

Si l'on fait le choix de ne pas former de jeunes narco-dépendants aux grands fournisseurs du cloud public, on n'a pas d'autre solution que de se plonger dans les opérations avec un niveau d'exigence élevé en matière d'automatisation.

C'est ainsi que le support de travaux pratiques DevNet Lab 9 propose de produire un code Python de configuration des ports d'un commutateur virtuel Open vSwitch (unique pour débuter) à partir du contenu d'un fichier de déclaration YAML.

Les manipulations s'appuient sur un scénario concret : dans le contexte d'une infrastructure cloud privée, des hyperviseurs sont déployés avec chacun un commutateur de distribution Open vSwitch nommé dsw-host. Un grand nombre d'interfaces tap sont provisionnées et déclarées comme ports de commutateur. Lorsque les étudiants démarrent leurs premiers travaux pratiques, ils se voient attribuer des ensembles de ces interfaces pour exécuter des machines virtuelles ou des routeurs. Il s'agit donc de programmer les topologies réseau d'interconnexion entre le monde virtuel et le monde physique.

Les objectifs du laboratoire sont simples :

• Établir une connexion sécurisée au serveur de base de données OVSDB à l'aide d'un premier script Python
• Lister les commutateurs existants et récupérer les attributs détaillés d'un port particulier
• Charger et appliquer des configurations réseau depuis un fichier YAML vers les ports du commutateur
• Vérifier manuellement les configurations appliquées sur l'hyperviseur afin d'assurer la cohérence entre l'état déclaré et la configuration réseau réelle

La progression des manipulations est organisée en trois parties principales, chacune apportant un niveau supplémentaire de maîtrise :

1. Mise en place de l'environnement
   Cette première partie analyse les conditions nécessaires pour établir un canal de communication sécurisé entre le code Python et le service ovsdb-server exécuté sur l'hyperviseur. Les étudiants apprennent à utiliser la fonctionnalité LocalForward d'OpenSSH pour créer un tunnel sécurisé vers le socket Unix du service.
2. Exploration interactive avec Python
   Dans cette deuxième partie, les étudiants apprennent progressivement à interagir avec la base de données Open vSwitch. Ils commencent par une simple liste des commutateurs disponibles, puis récupèrent les attributs détaillés d'un port spécifique, et enfin analysent les configurations VLAN (mode access ou trunk).
3. Évolution vers une approche déclarative
   La troisième partie introduit l'approche déclarative avec YAML comme source de vérité pour la configuration souhaitée. Les étudiants développent un script capable de charger cette configuration et de l'appliquer aux ports du commutateur. Ils implémentent également un mode "dry-run" pour prévisualiser les changements sans les appliquer.

Cette approche progressive permet aux étudiants de comprendre d'abord les mécanismes sous-jacents avant d'aborder les concepts plus avancés de programmabilité réseau. Néanmoins, elle comporte certaines limitations.

• L'environnement de laboratoire requiert le maintien d'une connexion SSH active entre le système de développement et l'hyperviseur.
• La courbe d'apprentissage associée à la programmation Python et aux concepts de réseaux virtualisés est assez abrupte pour les débutants.
• Les concepts de cache et d'optimisation des requêtes introduits dans la dernière partie peuvent être difficiles à appréhender sans une solide compréhension préalable de Python.

Heureusement, les étudiants de première année de Master ont déjà parcouru un long chemin dans le domaine du développement. Malgré ces limitations, ce laboratoire est une opportunité de progresser dans la compréhension pratique de la programmabilité réseau moderne, alignée sur les pratiques DevOps actuelles.

Ces manipulations constituent une première étape vers la maîtrise de la programmabilité réseau. Elles posent les fondements nécessaires pour aborder des sujets plus avancés comme l'orchestration multi-équipements ou switch fabric.

Les compétences acquises permettent non seulement d'automatiser des tâches répétitives, mais aussi d'adopter une approche plus systématique et fiable de la gestion des infrastructures réseau - ne serait-ce que pour réaliser les manipulations suivantes. La transition vers le « réseau en tant que code » (Network as Code) représente un changement de paradigme aussi important que celui du DevOps pour les applications et les services.

Pour commencer, trop nombreux sont les systèmes qui ne produisent pas de données structurées, ce qui rend difficile l'automatisation ou l'évaluation de la conformité. Les tests automatisés nécessitent des jeux de données structurés et reproductibles pour fonctionner efficacement. On se retrouve donc contraint de développer en interne ou d'investir dans des outils capables de transformer les données non structurées en données exploitables.

Ensuite, la courbe d'apprentissage est très raide, surtout pour les débutants. Quand Cisco met à disposition pyATS et son extension Genie, une plateforme pour automatiser les tests sur les infrastructures réseau, arriver à une bonne compréhension des concepts de programmation tout en ayant une connaissance des spécificités des protocoles réseau demande un investissement conséquent. Cela ralentit l'adoption et l'utilisation efficace de ces outils.

Le Lab 17 Automated testing with pyATS and Genie est une tentative de réponse aux défis posés par l'automatisation des tests.

Les manipulations débutent par la mise en place d'une maquette avec deux routeurs qui échangent des réseaux avec le protocole OSPFv3. L'objectif de cette maquette est d'illustrer les trois états à tester.

• L'état attendu de l'infrastructure correspond à un échange de tous les réseaux connus des deux routeurs hub et spoke.
• L'état configuré correspond au fait qu'une configuration correcte a été appliquée sur chaque routeur individuellement.
• Le test de l'état opérationnel vérifie que les échanges de réseaux entre les deux routeurs sont corrects.

La progression des manipulations qui suivent la mise en place de la maquette passe par les étapes suivantes :

1. La génération de données structurées avec un tout premier code Python qui valide la communication avec un routeur à l'aide de pyATS.
2. Le test de l'état configuré avec un script Python unique qui présente la syntaxe d'une classe dont chaque méthode est un test.
3. Le test de l'état opérationnel avec un découpage en plusieurs fichiers : job, trigger et datafiles qui permettent d'accéder à un code plus efficace et réutilisable.

Si vous acceptez de vous plonger dans le scénario proposé vous verrez que ce support de travaux pratiques vous fera avancer dans la compréhension du fonctionnement et des mécanismes des tests automatisés. Ainsi, vous aurez une représentation plus précise des bénéfices apportés par la formalisation des jeux de tests.

Pour autant, il ne s'agit pas de « vendre du rêve ». Les limites de l'exercice sont bien visibles.

• Si on présente la transformation en données structurées des éléments de configuration d'un routeur, on n'utilise pas cette représentation pour les tests qui suivent. L'utilisation des données structurées engendrerait un coût supplémentaire pour le développement des tests qui suivent et rendrait le document encore plus volumineux.
• Si le protocole OSPFv3 associé aux familles d'adresses IPv4 et IPv6 est intéressant dans le sens où il utilise un mécanisme d'échange unique pour les deux familles et allège la configuration, il demeure nécessaire de maîtriser son fonctionnement pour rédiger correctement les méthodes de test.

Pour conclure, on peut dire que tout est affaire de compromis. Les étudiants peuvent aboutir à des résultats satisfaisants et mesurables avec les tableaux de bord du service web intégré à pyATS en un temps raisonnable.

L'objectif suivant est de transposer cette démarche de construction de tests à d'autres contextes, tels que le très classique « triangle OSPF » et l'intégration dans les phases d'un pipeline GitLab CI.

Après plusieurs sessions de formation, il apparaît toutefois que cet objectif a un coût en termes de développement. En effet, créer un Playbook Ansible aux traitements idempotents nécessite souvent d'augmenter significativement la quantité de code afin de garantir que chaque étape du processus soit exécutée de manière prévisible et reproductible. Pour les étudiants qui débutent dans l'automatisation, cela ne facilite pas l'apprentissage.

Voici les liens vers deux supports de travaux pratiques qui illustrent la hauteur de la marche à franchir entre placer une ou deux tâches dans un Playbook Ansible et garantir un traitement reproductible conforme avec l'état attendu de l'infrastructure cible.

Le lab « Use Ansible to Back Up and Configure a c8000v Router » propose une introduction à la création de Playbooks Ansible.

Le lab « Using Ansible to automate the installation of web services on Incus containers » utilise à nouveau Ansible pour automatiser la gestion de conteneurs à partir d'un inventaire dynamique. L'installation et la configuration de services web servent ensuite de prétexte pour manipuler les fichiers de configuration et valider le fonctionnement de ces services.

Les points clés sont :

1. L'idempotence et le développement
   Les traitements montrent l'importance de l'idempotence dans l'automatisation, tout en illustrant les conséquences sur la complexité du code.
2. Ansible et l'automatisation
   Ansible s'est imposé comme un outil de référence en matière d'automatisation et ses modules occupent une place essentielle.
3. Sensibilisation aux concepts DevOps
   L'objectif principal est de sensibiliser les étudiants aux concepts clés de l'automatisation DevOps, notamment la déclaration précise de l'état attendu d'une infrastructure IaaS.

Prenons l'exemple du lancement de conteneurs. Dans un contexte procédural, on écrirait le code de la commande de lancement dans un script Bash exécuté via SSH. Dans la liste des tâches Ansible ci-dessous, on commence par obtenir la liste des conteneurs attendus, puis on ne crée que ceux qui n'existent pas (when item.rc !=0) et on lance ceux qui ont l'état 'STOPPED'. Le code idempotent contient 3 tâches.

  tasks:
    - name: CHECK CONTAINERS STATE
      ansible.builtin.shell:
        cmd: set -o pipefail && incus ls --format csv -c n,s | grep {{ item }}
        executable: /bin/bash
      register: container_states
      with_inventory_hostnames:
        - containers
      changed_when: false
      failed_when: false
      check_mode: false

    - name: LAUNCH INCUS CONTAINERS
      ansible.builtin.command:
        cmd: incus launch {{ container_image }} "{{ item.item }}"
      loop: "{{ container_states.results }}"
      when: item.rc != 0 # Container not found
      register: containers_created
      changed_when: containers_created is changed

    - name: START STOPPED CONTAINERS
      ansible.builtin.command:
        cmd: incus start "{{ item.item }}"
      loop: "{{ container_states.results }}"
      when: item.rc == 0 and 'STOPPED' in item.stdout
      register: containers_started
      changed_when: containers_started is changed

À travers cet exemple, on voit que l'idempotence constitue le fil conducteur pédagogique qui unifie les deux supports de travaux pratiques tout en servant de critère d'évaluation de la qualité des automatisations développées.

Dans le Lab 15 sur la configuration des routeurs, les étudiants découvrent progressivement que l'idempotence ne peut être atteinte qu'en reprenant l'édition du code des playbooks vers une approche plus modulaire et spécialisée - passant d'une simple tâche ios_config à une structure plus sophistiquée utilisant des modules dédiés comme ios_interfaces et ios_l3_interfaces. Cette progression illustre parfaitement la trajectoire d'apprentissage visée : comprendre que l'état déclaratif d'une infrastructure nécessite un investissement en termes de conception logicielle.

De même, le Lab 16 sur l'installation des serveurs Web dans des conteneurs Incus pousse les étudiants à développer une logique conditionnelle élaborée pour vérifier l'état actuel avant toute modification, comme l'illustrent les tâches de gestion des conteneurs qui déterminent si un conteneur doit être créé ou simplement démarré. Ces exercices pratiques transforment un concept théorique - l'idempotence - en compétence technique concrète. Ils permettent ainsi aux étudiants de comprendre par la pratique que la déclaration précise de l'état attendu d'une infrastructure IaaS exige une réflexion approfondie sur les conditions préalables, les états intermédiaires et les résultats finaux de chaque opération d'automatisation.

En conclusion, l'objectif de l'édition 2025 des supports de travaux pratiques du module d'automatisation DevOps est de montrer aux étudiants l'importance de l'idempotence et de la précision dans la déclaration de l'état attendu d'une infrastructure. En utilisant des outils comme Ansible, ces supports pratiques proposent une approche concrète pour comprendre comment gérer efficacement les infrastructures automatisées.

Vous êtes invités à explorer ce document et à partager vos retours. Votre expérience contribuera à l'amélioration continue de ces ressources pédagogiques.