Réseaux : comment les configurer à l’aide des pipelines CI/CD

Le flux de travail actuel et ses limites

Imaginons un réseau de campus simple avec quelques switches d’accès et un switch de distribution. Quelqu’un émet un ticket pour créer un nouveau réseau local virtuel (VLAN). Les ingénieurs qui effectuent ces modifications manuellement préparent probablement les configurations, créent de nouveaux VLAN, les ajoutent aux ports de jonction, créent des interfaces virtuelles de commutation (SVI) sur le commutateur principal et paramètrent toutes les configurations Hot Standby Router Protocol/Virtual Router Redundancy Protocol.

En général, une personne examine et approuve ensuite les modifications. Enfin, un ingénieur applique les configurations aux appareils, effectue des contrôles a posteriori pour s’assurer que les modifications n’ont rien endommagé d’autre et documente ces contrôles dans un ticket à titre de preuve.

Ce processus manuel fonctionne, mais certains problèmes surgissent :

• Les ingénieurs doivent définir le processus.
• Quelqu’un peut oublier un appareil lors de l’ajout des VLAN.
• Les contrôles a posteriori sont tous manuels.
• Les ingénieurs doivent prévoir du temps pour effectuer les tâches et vérifier que toutes les liaisons montantes sont actives.

De nombreux ingénieurs savent ce qui se passe s’ils oublient d’inclure la commande add lors de l’ajout d’un nouveau VLAN à l’interface trunk.

Un aperçu des pipelines CI/CD

L’approche CI/CD revient à un processus de développement logiciel qui construit, teste et déploie automatiquement les modifications apportées à une base de code. La partie CI permet aux entreprises d’utiliser un référentiel partagé pour suivre la façon dont le code est construit et testé. Il permet de maintenir les bases de code à jour et d’identifier et de corriger rapidement les erreurs qui surviennent. La partie CD déploie ensuite automatiquement les modifications validées sur les équipements du réseau. Les nouvelles configurations et les mises à jour peuvent ainsi être mises en œuvre rapidement et de manière fiable.

Cette approche peut également s’appliquer à l’infrastructure réseau. En utilisant les principes CI/CD, les administrateurs réseau peuvent automatiser une grande partie des tâches manuelles liées à la gestion des configurations réseau, ce qui réduit le risque d’erreur humaine et accélère les modifications du réseau.

Voyons comment l’approche CI/CD fonctionne dans un contexte de réseau et discutons de certains des avantages qu’elle peut apporter.

Flux de travail CI/CD appliqué aux réseaux

L’approche CI/CD permet aux ingénieurs d’abstraire la plupart des configurations en utilisant différentes méthodes. L’une des méthodes les plus simples consiste à utiliser Ansible et Jinja2. Voici quelques étapes possibles :

1. Définir les paramètres de configuration dans un simple fichier YAML.
2. Créer un modèle de configuration à l’aide de Jinja2.
3. Utiliser Ansible pour générer la configuration et l’envoyer aux appareils.

Ansible est également doté de modules intégrés qui éliminent la nécessité de gérer des modèles personnalisés. Les ingénieurs réseau peuvent également choisir d’utiliser Python, qui offre plus de flexibilité à long terme. De nombreuses bibliothèques Python sont disponibles pour travailler avec les équipements de réseau, comme Nornir, Napalm et Netmiko.

La plupart des fournisseurs proposent également des options de test. Vous vous souvenez de tous les tests manuels que les ingénieurs réseau avaient l’habitude d’effectuer ? Ils peuvent désormais utiliser des bibliothèques Python spécifiques pour automatiser ces tests. Par exemple, Cisco propose PyATS, un cadre de test qui aide à superviser les vérifications préalables et postérieures. PyATS peut prendre un instantané avant un changement, en prendre un autre après le changement et montrer les différences.

Arista propose également un cadre de test (Arista Network Test Automation), dans lequel les ingénieurs peuvent définir des tests, par exemple vérifier que toutes les liaisons montantes ou tous les SVI sont opérationnels ou s’assurer qu’une route spécifique se trouve dans la table de routage.

Enfin, les ingénieurs réseau ont besoin d’un outil pour gérer la partie CI/CD de l’équation. De nombreuses options existent, parmi lesquelles Jenkins, GitHub Actions et GitLab. Chacun de ces outils présente des avantages, mais l’exemple ci-dessous se concentre sur GitLab.

Les pipelines CI/CD en réseau permettent aux ingénieurs de tout assembler dans une séquence d’étapes automatisées. Au lieu d’exécuter manuellement des prétests, d’appliquer des configurations et d’exécuter à nouveau des contrôles a posteriori, les ingénieurs définissent chaque étape de manière automatisée dans la configuration du pipeline.

Dans un pipeline CI/CD, les ingénieurs créent des étapes et des tâches. Chaque étape peut comporter un ou plusieurs travaux. Par exemple, il est possible de créer une étape pour les prétests, une autre pour les changements de configuration et une dernière pour les contrôles a posteriori. Chaque tâche s’exécute dans l’ordre – d’abord les prétests, puis la configuration et enfin les contrôles a posteriori –, ce qui garantit que tout se déroule dans le bon ordre, sans intervention manuelle.

Les ingénieurs peuvent même aller plus loin en automatisant le processus de gestion du changement. En fonction des résultats du pipeline, ils peuvent automatiquement mettre à jour les tickets ou la documentation, ce qui rend l’ensemble du flux de travail plus fluide et plus efficace.

Utiliser GitLab pour créer un VLAN

Examinons un exemple rapide de gestion de VLAN sur des périphériques réseau à l’aide d’Ansible et d’un pipeline CI/CD. Si vous souhaitez une explication plus approfondie de ce fonctionnement, consultez ma série d’articles de blog sur le CI/CD en réseau.

Ici, nous restons simples avec un pipeline CI/CD de base qui automatise la création d’un VLAN. Au lieu de nous connecter manuellement au commutateur pour créer des VLAN, nous utilisons Ansible. Ansible stocke la liste des VLAN dans un fichier YAML et dispose d’un playbook simple qui les crée. Nous utilisons GitLab comme plateforme CI/CD. Le flux de travail est le suivant :

1. Recevoir une demande de création d’un nouveau VLAN.
2. Extraire le dernier dépôt Git et créer une nouvelle branche.
3. Mettre à jour le fichier YAML en ajoutant le nouveau VLAN, puis s’engager à pousser la branche vers GitLab.
4. Définir un test qui vérifie si l’ID du VLAN est dans la plage allouée.
5. Demander au réviseur d’examiner la modification et d’approuver la demande de fusion.
6. Exécuter le playbook et créer le VLAN.

Voici l’exemple de fichier YAML qui contient tous les VLAN.

vlans:
  - vlan_id: 10
    name: cctv
  - vlan_id: 11
    name: voip

Voici le playbook pour créer les VLANs.

---
- name: "VLAN Playbook"
  hosts: switches
  gather_facts: no

  vars_files:
    - vlans.yml

  tasks:
    - name: Create VLANs
      arista.eos.eos_vlans:
        config: "{{ vlans }}"

Voici la procédure de validation pour s'assurer que les ID VLAN se situent dans la bonne plage.

---
- name: "VLAN Validation Playbook"
  hosts: localhost
  gather_facts: no

  vars_files:
    - vlans.yml

  tasks:
    - name: Validate VLAN IDs are between 1 and 100
      assert:
        that:
          - vlan.vlan_id >= 10
          - vlan.vlan_id <= 100
      loop: "{{ vlans }}"
      loop_control:
        loop_var: vlan

Voici la configuration du pipeline CI/CD de GitLab.

default:
  image: python:3.10

stages:
  - test
  - deploy

test:
  stage: test
  before_script:
    - pip install ansible paramiko
  script:
    - ansible-playbook pre_test.yml

deploy:
  stage: deploy
  before_script:
    - pip install ansible paramiko
  script:
    - ansible-playbook create_vlan.yml
  only:
    - main

Dans cette configuration de pipeline, nous utilisons une image Python 3.10 par défaut pour exécuter les tâches. Le pipeline se compose de deux étapes : test et deploy. Dans la phase test, le pipeline installe les bibliothèques Ansible et Paramiko nécessaires avant d’exécuter un playbook – pre_test.yml – pour valider les configurations.

Une fois les tests réussis, l’étape deploy s’exécute. Ici, les mêmes bibliothèques sont installées, et un autre playbook – create_vlan.yml – s’exécute pour créer les VLAN sur les appareils. L’étape deploy est configurée pour s’exécuter uniquement lorsque les changements sont fusionnés dans la branche main. Cela permet de s’assurer que les déploiements n’ont lieu qu’une fois les modifications approuvées.

N’oubliez pas de commencer modestement et de poursuivre votre développement. Il est presque impossible d’avoir un pipeline CI/CD réseau entièrement fonctionnel et prêt à être déployé du premier coup.