Un lab économique pour le Network as Code

Lab économique pour le Network as Code

Dernière modification le 31 juillet 2021

Pratiquer le Network as Code, qui se décline en différentes appellations dans la littérature (NetDevOps, NetOps, Infrastructure as Code, Intent Based Networking, …), fait appel à un simulateur réseau pour monter rapidement un environnement sans pour autant posséder tout le matériel nécessaire.

Si le but recherché est d’accéder à un équipement ou deux pour s’entrainer à la pratique du langage de commande (EOS, IOS, NXOS, Junos…), d’une technologie réseau (VXLAN, EVPN/VXLAN, MLAG,…) ou de techniques et technologies d’automatisation (Ansible, Python/Nornir, RESTCONF, NETCONF, gNMI/gRPC, …), il existe de nombreuses solutions qui peuvent s’accommoder de peu de ressources. Mais lorsqu’il s’agit de monter un véritable lab pour reproduire un environnement de simulation complet, on se rend compte qu’il faut rapidement disposer de ressources CPU et RAM importantes. La quantité nécessaire dépasse facilement les ressources disponibles sur une machine de développement ou d’enseignement.

Pourtant il peut s’avérer pratique d’être autonome et de ne dépendre ni d’un serveur additionnel, ni d’une ressource internet, sans pour autant mettre sa machine en surchauffe. Croyez moi, un MacBook Pro qui chauffe pendant la saison d’été c’est très désagréable pour les poignets et plus globalement pour la température ambiante.

Pour monter un environnement de virtualisation sur le MacBook, rien n’est plus rapide et léger que Multipass de Canonical. C’est la méthode recommandée pour créer des machines virtuelles Ubuntu sur Ubuntu. Il est conçu pour les développeurs qui souhaitent un nouvel environnement Ubuntu avec une seule commande et fonctionne sous Linux, Windows et macOS. Multipass utilise la virtualization native de chaque système d’exploitation sur lequel il est installé : Hyper-V sur Windows, HyperKit sur macOS et KVM sur Linux, pour une surcharge minimale et un temps de démarrage le plus rapide possible.

Continuer la lecture de « Un lab économique pour le Network as Code »

Documenter du code Python

Documenter code Python

Lorsqu’il s’agit de documenter des développements, il existe plusieurs méthodes. Soyons direct, l’approche qui consiste à réaliser un document n’a aucune pérennité. Dès les premières phases de refactoring ou d’amélioration, la documentation ne sera pas mise à jour.

L’approche qui consiste à utiliser un Wiki est déjà plus souple et permet à plusieurs développeurs de collaborer sur la construction documentaire. Cependant, idéalement, il convient de limiter les changements d’environnements qu’un développeur peut être amené à faire pour mener à bien sa mission. Il y a deux environnements dans lequel le développeur évolue depuis son IDE (Integrated Development Environment).

Il y a tout d’abord le répertoire qui contient l’ensemble de l’arborescence du produit et qui se traduit sur le serveur de versioning par une branche dans un repository. Le format le plus utilisé est le markdown qui permet de créer des fichiers documentaires un peu agrémentés de mises en pages, sachant que par convention, un serveur de versioning affiche automatiquement le fichier README.md du répertoire visité.

Le deuxième environnement est le code lui-même, dans lequel il est naturel pour le développeur, d’intégrer au moins des commentaires qui lui permettront de retrouver la logique utilisée lorsqu’il se replongera, plus tard, dans le code. Comme défini dans PEP 8 (Style Guide for Python Code), les commentaires peuvent être de type « Block Comments » ou « Inline Comments ».

Continuer la lecture de « Documenter du code Python »

Intent-Based Networking

Intent-Based Networking

Dernière modification le 17 juin 2021

Vous vous souvenez des étapes de l’implémentation DevOps pour les infrastructures réseaux déjà présentées dans cet article. Bien que tout ceci puisse vous faire penser à du marketing ou même à du buzzword, il s’agit bien de réalités terrains qui sont concrètement mises en oeuvre avec des étapes intermédiaires supplémentaires.

Etapes Automatisation
Source Juniper Networks

Si nous remontons dans l’histoire, le scripting n’est pas un phénomène nouveau. Dès le début de ma carrière, j’utilisai déjà le scripting pour automatiser les déploiements. Il s’agissait de programmes écrits en perl (1987) ou en Visual Basic (1991) finalement associé avec SecureCRT (1995) dont l’objectif était d’envoyer des commandes CLI sur les équipements et d’analyser les réponses (méthode appelée Screen Scraping). Ce qui a changé avec le temps, c’est le fait d’utiliser des protocoles de communication optimisés (NETCONF, RESTCONF ou gNMI) et des formats de données adaptés (XML, JSON ou protobuf), pour parler de « Human-driven Automation ».

Bien que de nombreuses idées fondamentales des approches DevOps, comme les pratiques Lean, le mode Agile ou le cycle Plan-Do-Check-Act de la roue de Deming, ont été popularisés dans les années 1990, le terme DevOps que nous connaissons est né en 2009. Après avoir été appliqué aux développement, puis au système, le DevOps a finalement été appliqué au réseau. Le mouvement NetDevOps avait pour objectif de supprimer le goulot d’étranglement que représentait le réseau dans les cycles rapides d’adaptation imposés par les applications et les infrastructures de serveurs en mouvements permanents pour suivre les besoins métiers et marchés. Le NetDevOps propose l’idée de considérer l’infrastructure réseau en tant que IaC (Infrastructure as Code) ou plus spécifiquement NaC (Network as Code), avec tous les principes techniques, technologiques, méthodologiques, organisationnels et humains sous-jacents. Le NetDevOps a apporté un tournant dans les nouveaux profils de compétences nécessaires à son application concrète.

Continuer la lecture de « Intent-Based Networking »

Containerlab, topologie de lab sur Docker

Containerlab

Avec le nombre croissant de switchs virtuels conteneurisés, le besoin de les exécuter facilement dans des topologies de simulation augmente. Je l’avais déjà évoqué en présentant le cEOS-lab Arista, les outils d’orchestration de conteneurs tels que docker-compose ne conviennent pas, car ils ne permettent pas de créer facilement des connexions entre les conteneurs pour définir une topologie.

Containerlab fournit une interface IaaC (Infrastructure as a Code) sous forme d’un langage de commande pour l’orchestration et la gestion des simulations réseau basées sur des conteneurs. Il démarre les conteneurs, construit un câblage virtuel entre eux pour créer des topologies et gère le cycle de vie des simulations.

Containerlab se concentre sur les NOS (Network Operating System) conteneurisés qui sont généralement utilisés pour tester les fonctionnalités réseau, tels que :

  • Nokia SR-Linux
  • Arista cEOS
  • Azure SONiC
  • Juniper cRPD
Continuer la lecture de « Containerlab, topologie de lab sur Docker »

Nautobot Inventory dynamique

Nautobot Inventory

Nautobot est une plateforme utilisée en tant que Source de Vérité et d’automatisation réseau extensible et flexible. Que ce soit pour mettre en place une automatisation Python ou Ansible, il est possible et judicieux d’utiliser Nautobot en tant qu’inventory.

Pour programmer en Python, l’utilisation du Framework Nornir est un standard pour l’automatisation réseau. Il existe le plugin nornir-nautobot qui permet de faciliter la connexion à la Source de Vérité et de filtrer les équipements sur lesquels on souhaite travailler.

Continuer la lecture de « Nautobot Inventory dynamique »

Sonde H5 audits sur simulateur

H5 audits EVE-NG

L’utilisation d’un simulateur est un élément incontournable pour une approche NetDevOps. Il est clair que tout constructeur ou fournisseur de logiciel incapable de passer sur un simulateur tel que EVE-NG, pour s’inscrire dans une infrastructure virtualisée, ne peut pas prétendre jouer dans la cours du SDN (Software Defined Network).

Lorsqu’il est question d’analyser le trafic au sein d’une infrastructure simulée, EVE-NG Pro dispose nativement de Wireshark pour effectuer des captures sur les liens inter-équipements. Mon souhait était de pouvoir aller plus loin dans l’analyse avec une sonde virtuelle.

L’avantage d’avoir un constructeur français de sondes, dont la recherche et développement est accessible, est d’avoir réussi à exprimer et défendre ce besoin et d’avoir été entendu. Je remercie Frédéric GUILLOIS (President H5 Audits) et Lionel BARRERE (Chief Technical Officer H5 Audits) de m’avoir écouté et d’avoir mis au point la réponse à ma demande.

Continuer la lecture de « Sonde H5 audits sur simulateur »

GraphQL et Nautobot

GraphQL Nautobot

GraphQL est un langage de requête et un environnement d’exécution côté serveur pour les API (Application Programming Interface) qui s’attache à fournir aux clients les données qui ont été demandées. Utilisé à la place de REST, GraphQL permet aux développeurs de créer des requêtes qui extraient les données de plusieurs sources à l’aide d’une seule requête API. Les requêtes GraphQL renvoient toujours des résultats prévisibles. Alors que les API REST typiques nécessitent un chargement à partir de plusieurs URL, les API GraphQL obtiennent toutes les données dont l’application a besoin en une seule demande. De plus, avec GraphQL, les équipes chargées de la maintenance des API peuvent librement ajouter ou retirer des champs sans perturber les requêtes existantes.

GraphQL a été développé par Facebook, qui a commencé à l’utiliser pour les applications mobiles en 2012. La spécification de GraphQL est devenue Open Source en 2015. Elle est désormais supervisée par la GraphQL Foundation.

Un service GraphQL est créé en définissant des types et des champs sur ces types, puis en fournissant des fonctions pour chaque champ sur chaque type. Par exemple, un service GraphQL qui indique qui est l’utilisateur connecté (me) ainsi que le nom de cet utilisateur peut ressembler à ceci :

type Query {
  me: User
}
 
type User {
  id: ID
  name: String
}

Avec des fonctions pour chaque champ sur chaque type :

function Query_me(request) {
  return request.auth.user;
}
 
function User_name(user) {
  return user.getName();
}
Continuer la lecture de « GraphQL et Nautobot »

Ansible 3.0.0

Ansible 3.0.0

La version 3.0.0 du package communautaire Ansible marque la fin de la restructuration de l’écosystème Ansible. Ce travail achève ce qui a commencé en 2019 pour restructurer le projet Ansible et façonner la manière dont le contenu Ansible est livré.

Dans Ansible 2.9 et les versions antérieures, chaque plugin et module se trouvait dans le projet Ansible (https://github.com/ansible/ansible) lui-même. Lorsque vous installiez le package « ansible », vous aviez le langage, le runtime et tout le contenu (modules et autres plugins). Au fil du temps, le succès d’Ansible a créé des problèmes d’évolutivité. Les utilisateurs devaient attendre plusieurs mois pour un contenu mis à jour.

Au cours du cycle de développement d’Ansible 2.10, la communauté Ansible a migré avec succès la plupart des modules et plugins vers les collections. Les collections, ainsi que les modules et plugins qu’elles contiennent, peuvent désormais être développées, mises à jour et publiées indépendamment d’Ansible lui-même. Le package de la communauté Ansible 2.10 comprenait ansible-base 2.10 ainsi que toutes les collections qui contiennent des modules et des plugins qui ont été migrés hors du référentiel d’origine. Depuis Ansible 2.10, les utilisateurs de la communauté avaient deux options: continuer à installer tout avec le package de communauté Ansible, ou installer ansible-base, puis ajouter les collections sélectionnées individuellement.

Continuer la lecture de « Ansible 3.0.0 »

Nautobot – Network to Code

Nautobot NTC

La solution communautaire NetBox a été supportée pendant plusieurs années par la société Network to Code qui a finalement décidé de procéder à un fork de manière à créer un nouveau produit appelé Nautobot avec une nouvelle orientation stratégique : proposer une plateforme d’automatisation avec un support de qualité.

Source de vérité flexible
À la base, Nautobot est une source de vérité qui définit l’état qui est prévu pour le réseau (Intent-Based Networking).


Plateforme de données extensible pour l’automatisation de réseau
Nautobot est plus que de la documentation du réseau. Nautobot propose des intégrations et une extensibilité pour véritablement alimenter des solutions d’automatisation de réseau. Nautobot possède des API de plateforme robustes qui incluent des API RESTful (HTTP) traditionnelles, des API GraphQL, des webhooks basés sur les événements et de nombreuses fonctionnalités d’extensibilité pour permettre une plus grande automatisation du réseau. Nautobot utilise également son extensibilité pour agréger des systèmes de données disparates créant une source unique de vérité pour les solutions d’automatisation de réseau.


Plateforme pour les applications d’automatisation de réseau
La plateforme d’applications Nautobot fournit une architecture à partir de laquelle des applications d’automatisation de réseau peuvent être créées. Les applications Nautobot sont des augmentations ou des ajouts flexibles et personnalisés. Grâce à la plateforme d’applications Nautobot, les entreprises peuvent fournir des extensions et des applications d’automatisation de réseau personnalisables 65 à 70% plus rapidement.

Continuer la lecture de « Nautobot – Network to Code »

YANG Suite

YANG Suite

On attendait le remplaçant de YANG Explorer et il vient de sortir. YANG Suite remplace l’interface flash par du HTML5 et permet d’aborder l’automatisation réseau à l’aide de modèles YANG en navigant dans les modules depuis une interface graphique, en créant des requêtes RPC pour interagir avec les équipements et en testant la télémétrie à l’aide de gRPC.

L’usage de conteneurs Docker facilite grandement la mise en place de YANG Suite. Sur la base d’une machine virtuelle Ubuntu 20.04 à jour, Docker est installé :

sudo apt update
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"
sudo apt update
sudo apt install docker-ce
sudo apt install docker-compose
sudo usermod -aG docker ${USER}
sudo reboot

L’installation la plus simple de YANG Suite, consiste à cloner le dépôt de GitHub.

git clone https://github.com/CiscoDevNet/yangsuite
cd yangsuite/docker/
./gen_test_certs.sh

Par défaut, YANG Suite, ou plus exactement Django, est configuré pour répondre aux requêtes sur l’adresse locale 127.0.0.1. Afin de permettre un accès depuis le réseau sur l’adresse IP de la machine virtuelle, il conviendra de modifier le fichier docker-compose.yml avant le premier lancement pour changer la valeur d’une des lignes environment de la manière suivante : DJANGO_ALLOWED_HOSTS=*.

Continuer la lecture de « YANG Suite »