Consultant & Tech Lead Sénior
Outils, technologies et méthodes applicables au NetDevOps, NetOps, Infrastructure as Code, Network as Code.
Certifié Coach DevOps
Dernière modification le 11 janvier 2020
Les étapes alpha et bêta sont terminées, mon Appliance Automation v2.0 est finie. Le brevet prévoyait déjà une fragmentation de la solution. Dans la version v1.0, ce sont les fonctions qui étaient fragmentées, mais la solution matérielle reposait sur un serveur unique. Dans la version v2.0, la partie matérielle a été répartie sur plusieurs serveurs, ce qui rend la solution facilement évolutive par ajout de modules.
Dernière modification le 11 janvier 2020
La version 2.0 de mon appliance EVE-NG reprend le même serveur bare metal pour faire tourner EVE-NG, mais rajoute un étage sur la base d’un autre serveur, fabriqué à partir du concept de ma nouvelle « Appliance Automation », proposant une fonction DHCP pour distribuer des adresses IP aux personnes utilisant l’appliance via une connexion filaire ou Wi-Fi 5 (vitesse 1,3 Gbps en 5 GHz avec un canal de 80 MHz).
Dernière modification le 10 août 2021
Au début des années 2010, je cherchai une solution pour construire un générateur de trafic Ethernet à haut débit pour des tailles de paquets de 64 octets et le moins cher possible afin de mettre en œuvre le RFC2544. Après de nombreuses approches et de nombreux développements qui n’ont abouti à rien de significatif, c’est en 2014 que la question du générateur de trafic pour tester les matériels en maquette est devenue cruciale. La référence dans ce domaine était Ixia, mais ceux qui connaissent les prix comprennent que ce n’était pas une solution accessible à tout le monde. Dans le domaine commercial, un de ses concurrents intéressant et dont j’ai suivi la progression était Xena. L’avantage de ces solutions n’était pas tant la puissance des générateurs mais le niveau d’intégration et de finition de la couche logicielle qui permettait de lancer facilement des tests conformes aux standards.
Continuer la lecture de « Générateur de trafic »
Dernière modification le 11 janvier 2020
L’époque des matériels actifs de spare utilisés pour faire un incubateur servant à simuler un réseau est totalement révolue pour tous les constructeurs leaders du domaine de l’automatisation. Les simulateurs réseau permettent de réaliser virtuellement un réseau.
Il ne faut pas confondre un simulateur et un émulateur. Un simulateur permet de faire tourner une version virtuelle d’un matériel actif (commutateur, routeur, firewall, …) grâce à la virtualization, alors qu’un émulateur reproduit un comportement sans pour autant avoir des versions virtuelles des appareils. Pour illustrer ces propos avec deux exemples très connus, GNS3 est un simulateur alors que Packet Tracer est un émulateur.
Une question fréquente consiste à se demander quel est le meilleur simulateur… Je pense qu’il n’y a pas de réponse valide à cette question. Tout dépend de l’usage qu’on est amené à en faire et au contexte dans lequel on l’utilise. Personnellement j’en utilise trois en fonction des objectifs.
Continuer la lecture de « Simulateurs réseau »
Dernière modification le 11 janvier 2020
Docker est un système de gestion de conteneurs incontournable dans le domaine du NetDevOps. La notion de conteneur est utilisée pour faire tourner une application de manière isolée et légère sur l’hôte sur lequel Docker est installé. L’accès aux services internes au conteneur se fait par une redirection de ports sur l’hôte qui fait tourner Docker.
La première préoccupation qui apparaît, avec la notion de conteneur, est la persistance des données. En effet, lorsque le conteneur est détruit, les données sont détruites avec lui. Si ce comportement peut être voulu pour repartir facilement d’une base vierge, il est des cas dans lesquels on veut garder l’historique des données. Pour palier à cela, il est facile d’utiliser la notion de volume, en les stockant dans un répertoire spécifique du serveur hôte Docker plutôt que dans le système de fichiers par défaut du conteneur. Ce stockage externe, appelé volume de données, permet de rendre les données indépendantes de la vie du conteneur, soit en le créant de toute pièce, soit en faisant une correspondance entre un répertoire source existant sur l’hôte et le répertoire destination dans le conteneur. Le volume permet également de partager ces données entre plusieurs conteneurs sur un même hôte.
Continuer la lecture de « Docker »
Dernière modification le 15 août 2019
NetDevOps Accelerator #1 Toulouse, le 22 juin 2019, a été l’occasion de concevoir un concept visant à accélérer l’adoption de l’approche NetDevOps dans le domaine du réseau. L’approche a mis en avant l’attitude « tous acteurs » et a proposé la fin de la théorie sur slide et des pseudos spécialistes qui n’en sont pas…
Articulée autour des partenaires HarryCow, Juniper Networks et Packet, cette journée a permis de créer une plateforme de simulation vQFX à l’aide de Vagrant afin d’exécuter des approches :
Dernière modification le 21 avril 2020
Racheté par Red Hat en octobre 2015, Ansible est Open Source pour sa version ligne de commande et web dans une approche communautaire et payant pour sa version entreprise.
Il est possible de prévoir une interface graphique sur Ansible sous la forme d’une version communautaire AWX ou d’une version supportée par Red Hat Ansible Tower. Dans tous les cas, c’est un choix qu’il est préférable de faire dès le départ pour éviter d’avoir à copier/coller un certain nombre de contenus de fichiers à l’intérieur de l’interface graphique.
Salt est le produit de prédilection pour réaliser le niveau « Event-driven automation », tout en étant aussi capable de faire le niveau « Human-driven automation ». Il est écrit en Python et fonctionne selon le principe de client-serveur.
Traditionnellement, Salt utilise un serveur centralisé (Master) qui utilise du tunnel crypté, à l’aide du transport ZeroMQ, vers les clients (Minions). Le Minion est installé sur la cible et si cela n’est pas possible alors un Proxy est installé sur un Minion pour adresser une cible. Le Proxy va utiliser un protocole approprié, comme NETCONF, pour communiquer avec la cible.
A partir de la version 2016.11, au niveau du Proxy, Salt possède quatre possibilités, proposant chacune des modules pour piloter l’équipement cible :
Dernière modification le 11 janvier 2020
Le mouvement DevOps a pris naissance dans le monde de l’édition logicielle. NetDevOps, parfois nommé NetOps, est une transposition de ce modèle dans le monde du réseau. Le rapprochement entre les équipes de développement et d’exploitation, ayant des objectifs différents pour ne pas dire antinomiques, au sein d’une même équipe est un concept qui se marie bien avec le modèle Agile et traduit des éléments qui y sont abordés. Ce mouvement met en valeur les notions d’Intégration Continue ou « Continuous Integration » (CI), de Livraison Continue ou « Continuous Delivery » (CD) et de Déploiement Continu ou « Continuous Deployment » (CD). L’Intégration Continue consiste à mettre en place une plateforme sur laquelle les modifications sont poussées et soumises à des jeux de tests unitaires afin d’être packagées dans un référentiel central utilisé pour le déploiement sur l’ensemble des environnements. Cette plateforme offre l’avantage de proposer un contexte standardisé et beaucoup plus neutre que les postes de travail personnalisés de chaque développeur sur lesquels il pourrait exister des contournements des règles de base de qualité et avec lesquels on ne pourrait pas garantir la répétabilité des processus. Le principe de l’Intégration continue induit que la configuration est, à tout moment, potentiellement livrable, mais elle ne peut pas passer en production sans l’aval des équipes opérationnelles. La différence entre la Livraison Continue et le Déploiement Continu se situe uniquement sur le fait qu’après la Livraison une approbation manuelle est nécessaire pour passer en Déploiement, alors que lorsqu’on parle de Déploiement Continu c’est que la mise en production est automatisée. Dans les deux cas, l’objectif est la mise en production sans incident ni régression. C’est à ce stade que les tests d’acceptation sont nécessaires, avant mise en production, afin de garantir le bon fonctionnement de l’ensemble d’un point de vu utilisateur final.
Continuer la lecture de « DevOps »
Pour les constructeurs leaders du domaine de l’automatisation de réseau, la librairie NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) fournit des fonctions abouties. Une matrice de compatibilité permet de savoir sur quels constructeurs, les fonctions proposées sont supportées. Un des avantages est de pouvoir écrire des scripts qui effectuent une même tâche sur plusieurs types d’équipements différents sans avoir à prendre en compte les spécificités de chacun des systèmes. Avec quelques lignes en Python, il est possible de simuler le comportement idempotent d’Ansible.
Pour accéder aux équipements, NAPALM s’appuie sur les librairies suivantes :
NAPALM est une librairie présente dans de nombreux frameworks d’automatisation comme Ansible, Salt ou Nornir.
Outre NAPALM, deux autres librairies sont disponibles :