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.

Voici le nouveau suuport de travaux pratiques de la série : Using GitLab CI to run Ansible playbooks an build new IOS XE Virtual Routers. Il associe les playbooks Ansible et l'intégration continue avec GitLab pour lancer les routeurs virtuels Cisco c8000v.

Avec cette brique supplémentaire de la "caisse à outils" de travaux pratiques, les étudiants vont pouvoir expérimenter le passage de la zone de test virtuelle à la zone de production physique en salle.

Après une trop longue pause dans les publications de ce blog, voici une nouvelle version de l'article VPN site à site IPSec.

Cette fois-ci, l'article est complet avec 3 configurations distinctes et un dépôt Git dédié : vpn-ipsec.

• 3 routeurs Cisco CSR1000v avec le système IOS XE
• 3 routeurs Debian GNU/Linux avec la suite FRRouting
• Le VPN hétérogène avec un système différent à chaque extrémité du tunnel

Cette topologie est une figure académique classique qui ne date pas d'hier. Elle est cependant tout à fait d'actualité dans un contexte de "cloud hybride". La construction des différentes configurations est automatisée avec Ansible.

Côté Debian, j'ai pu évaluer le mode Infrastructure as Code en utilisant cloud.debian.org comme "source de tirage" de l'image .qcow2 de machine virtuelle.

Cette image est fournie avec Systemd-Networkd pour le pilotage des interfaces réseau. Une fois les 3 maquettes validées, on peut faire un bilan plutôt positif du passage à une solution totalement intégrée à systemd de la configuration réseau.

• Les points positifs

  Même si le passage du fichier de configuration unique historique /etc/network/interfaces aux fichiers de descriptions du répertoire /etc/systemd/network/ n'est pas spontané, on s'y fait assez rapidement.

  Pour mimer le contexte des routeurs "constructeurs", j'ai choisi de configurer une interface Out of Band dans un contexte de routage dédié (VRF). C'est un franc succès. Sur le plan pédagogique, ça va permettre de sensibiliser les étudiants en insistant sur le fait que les contextes VRFs ne sont pas un "produit" de tel ou tel fournisseur d'équipements matériels.

• Le point négatif

  La configuration d'un tunnel GRE via Systemd-Networkd n'est pas fonctionnelle dans un contexte hétérogène alors que la configuration manuelle avec la commande ip l'est.

  Il faut bien avouer que la mise en place d'un VPN GRE+IPSec avec deux systèmes différents en vis-à-vis ne doit pas être très courante. Au delà de la seule interface GRE, cette hétérogénéité impose une connaissance "plus fine" des configurations et des protocoles.

  Pour l'instant, j'éviterais de proposer un support de travaux pratiques de ce type aux étudiant•e•s.

Pour conclure, je suis très satisfait du déploiement de Debian en mode Infrastructure as Code et de l'utilisation des outils virt-customize et virt-resize ainsi que de la facilité de configuration de strongSwan.

La configuration IPSec de premier niveau se limite à deux fichiers : /etc/ipsec.secrets et /etc/ipsec.conf. Il faut noter que ces deux fichiers suffisent à la validation du contexte hétérogène. Voir : VPN IPSec site à site - la configuration IPSec. C'est un excellent point que l'on doit pondérer en fonction de la volumétrie de trafic qui doit transiter par le VPN.

Toute dernière remarque sur la forme, l'utilisation de HedgeDoc pour la publication de documents avec des pages multiples n'est pas idéale. Il me reste à tester le mode présentation.

Voilà, pour le moment ...

L'adage veut toujours qu'une antisèche n'ait de valeur que si on la rédige soi-même !

Dans la pratique, les étudiants cherchent toujours des antisèches toutes faites. Voici donc une nouvelle édition de l'antisèche réseau qui reprend les manipulations de base sur la lecture et la configuration d'une interface.

J'espère que cet aide-mémoire facilitera la découverte du monde mystérieux des paramètres d'une connexion réseau.