Les manipulations proposées dans le support de travaux pratiques DevNet Lab 9 – Configure Open vSwitch using the Python ovsdbapp library, s'inscrivent dans le domaine de la programmabilité des réseaux. Associée à l'automatisation, la programmation des topologies d'interconnexion de réseaux est devenue indispensable pour répondre aux besoins d'agilité, de fiabilité et d'évolutivité des infrastructures modernes.

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.

Dans un monde où l'agilité et la conformité en matière de sécurité sont de plus en plus exigées dans les infrastructures DevOps, le développement de tests automatisés est devenu crucial. On doit constamment s'assurer que les systèmes sont sécurisés, stables et conformes aux normes établies, tout en maintenant une vitesse de déploiement élevée. C'est ici que les outils de test automatisé entrent en jeu, permettant de vérifier rapidement et efficacement l'état des infrastructures et des applications. Cependant, de nombreux défis doivent être relevés pour mettre en œuvre ces tests. En voici deux illustrations.

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.

Parmi les principes DevOps, la recherche de l'idempotence, qui consiste à s'assurer que les traitements automatisés n'ont pas d'effets secondaires indésirables et peuvent être répétés sans altérer le résultat final est un objectif vraiment très intéressant.

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.