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.

L'automatisation du déploiement et de la configuration des routeurs virtuels franchit une nouvelle étape grâce aux principes DevOps et à l'intégration continue. Le lab « Using GitLab CI to run Ansible playbooks an build new IOS XE Virtual Routers » illustre l'utilisation de pipeline pour orchestrer le déploiement de routeurs Cisco IOS-XE virtuels via des playbooks Ansible.

Les points clés sont :

1. Infrastructure as Code :
   L'utilisation de fichiers YAML déclaratifs pour définir le plan d'adressage réseau et la configuration des interfaces des routeurs permet de contrôler les versions et d'assurer une reproductibilité accrue.
2. Pipeline CI multi-étapes :
   Le processus complet est divisé en plusieurs étapes (préparation, déploiement, configuration) qui sont exécutées automatiquement à chaque modification du code.
3. Inventaire dynamique :
   Un script Python génère l'inventaire Ansible à la volée, offrant ainsi flexibilité et évolutivité.
4. Gestion des secrets :
   L'intégration d'Ansible Vault sécurise les informations sensibles tout au long du pipeline.
5. Tests automatisés :
   Des vérifications de connectivité sont intégrées pour valider le déploiement.

Cette approche présente de nombreux avantages : déploiements plus rapides et plus fiables, réduction des erreurs manuelles, meilleure traçabilité des changements. Elle ouvre la voie à une gestion plus agile des infrastructures réseau, en particulier pour le trafic nord-sud où la standardisation et l'automatisation sont essentielles.

En adoptant les pratiques DevOps, les étudiants peuvent déployer et gérer leurs infrastructures avec beaucoup plus d'agilité !

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

Suite au précédent billet sur l'utilisation d'Ansible pour créer des machines virtuelles Debian GNU/Linux, voici l'édition 2025 du document de travaux pratiques « IaC Lab 2 – Using GitLab CI to run Ansible playbooks and build new Debian GNU/Linux Virtual Machines ».

Premiers pas vers l'intégration continue

Alors que le premier document (Lab 01) se concentre sur le développement avec Ansible, ce second volet introduit les étudiants à l'utilisation de GitLab CI/CD pour automatiser la création et la configuration des machines virtuelles. C'est une évolution logique dans l'approche de l'Infrastructure as Code (IaC).

Points clés de ces manipulations

• Installation et configuration de GitLab Runner sur une machine virtuelle de développement (DevNet). C'est l'étape essentielle pour permettre l'exécution des pipelines CI/CD.

• Création d'un pipeline CI multi-étapes .gitlab-ci.yml et intégration progressive de plusieurs étapes :

  • Ping des hyperviseurs
  • Préparation de l'environnement sur l'hyperviseur
  • Construction et personnalisation des machines virtuelles
  • Configuration finale des machines virtuelles

• Gestion des artefacts dans GitLab CI avec le partage des fichiers entre les différentes étapes du pipeline

• Résolution de problèmes dans le but de résoudre les échecs de pipeline

  Illustration du principe DevOps selon lequel « l'échec est normal »

Améliorations par rapport à l'édition précédente

Comme mentionné dans le billet précédent, cette nouvelle édition bénéficie des retours d'expérience des étudiants. Elle met l'accent sur :

• La gestion des délais de démarrage des machines virtuelles
• L'optimisation de la collecte des faits
• L'utilisation de pré-tâches

De plus, l'édition 2025 introduit l'utilisation de scripts Python pour gérer la configuration des ports de commutateurs et la personnalisation des machines virtuelles avec Cloud-init, simplifiant ainsi les playbooks Ansible tout en renforçant l'idempotence.

Pour conclure...

Ces supports de TP offrent aux étudiants une expérience pratique complète de l'IaC et du CI/CD. Ils essaient de se rapprocher des scénarios du monde réel où ces technologies sont de plus en plus essentielles. Ils montrent la puissance de l'automatisation dans la création et la configuration des environnements virtuels, tout en enseignant des compétences en résolution de problèmes et en gestion de pipeline.

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

Voici le lien vers l'édition 2025 du document sur l'utilisation d'Ansible pour créer des machines virtuelles Debian GNU/Linux.

Si la promesse d'idempotence d'Ansible est parfois difficile à tenir, les jeux de tests produits par les étudiants ont permis d'améliorer considérablement les playbooks. Cette nouvelle version met l'accent sur la gestion des délais de démarrage des VM, l'optimisation de la collecte des faits et l'utilisation de pré-tâches.

Grâce aux retours d'expérience des étudiants, le document offre désormais une approche plus robuste et pratique de l'Infrastructure as Code.

L'autre évolution majeure de l'année universitaire 2024-2025 concerne le passage de la configuration réseau de tous les supports de la formation en mode déclaratif.

L'édition 2025 du document utilise des scripts Python pour gérer tous les paramètres de configuration des ports de commutateurs et de la personnalisation des machines virtuelles avec Cloud-init. La répartition des rôles entre personnalisation et automatisation est ainsi complètement revue par rapport à l'édition précédente. Les playbooks Ansible se sont donc simplifiés pour la partie traitements et complexifiés pour la partie idempotence.

Voici les liens vers les dépôts Git :

• Le dépôt startup-scripts contient les codes des scripts Python, comme switch-conf.py qui permet de configurer les ports Open vSwitch sur l'hyperviseur et le script lab-startup.py qui permet de déclarer les propriétés des machines virtuelles à instancier.
• Le dépôt Lab-01-02 contient tous les codes nécessaires à la rédaction de cette nouvelle édition. Les playbooks Ansible font appel aux scripts Python.