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.