Auteur/autrice : Gilbert MOISIO

Consultant Sénior en Infrastructures Réseaux et Méthodologies, Conférencier, Formateur, Coach NetDevOps, Membre de Jurys d’Examens. Impliqué dans des projets de recherche et de développement, membre d'organismes de standardisation et de normalisation. Passionné par l'acquisition des connaissances et leur partage qui est un accélérateur d'apprentissage personnel, que ce soit dans les technologies, dans les méthodologies ou dans les matières composant le socle de base nécessaire au franchissement des différents niveaux de compétences.
Publié le

NetDevOps Accelerator

NetDevOps Accelerator Toulouse

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…

Groupe NetDevOps Accelerator Toulouse

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 :

  • Python Netmiko
  • Juniper PyEZ
  • Juniper JSNAPy
  • Ansible
  • Salt
Publié le

Salt Junos proxy

Salt Junos proxy

Dernière modification le 12 août 2019

Le Master étant prévu pour piloter plusieurs Minions, il n’est pas rare de les voir installés sur des serveurs différents. Pour un lab, il est acceptable d’installer le Master et le Minion qui va porter les Proxies sur le même serveur.

Chaque équipement à administrer avec Salt aura son propre Proxy.

J’ai suggéré un portage de « Syslog Engine » pour Python 3 qui n’est pas encore opérationnel. Lorsque je suis amené à utiliser Salt, c’est avec Ubuntu 16.04 et Python2.7, autant dire que je n’y touche que si je veux faire de l’Event-driven Automation.

Affaire à suivre…

Publié le

Ansible Juniper galaxy

Ansible Galaxy

Dernière modification le 15 avril 2020

Appliqué à Juniper Junos, il existe trois façon d’utiliser Ansible. Depuis la version 2.7.10, des modules réseau agnostiques sont disponibles. L’utilisation des modules cli_command et cli_config à la place de eos_config, ios_config, et junos_config permettent de réaliser des playbooks agnostiques.

Depuis la version 2.1, Ansible est livré avec de nombreux modules réseau spécifiques pour les constructeurs, dont ceux de Juniper s’appuyant sur la librairie Python ncclient, et supportés par la communauté Ansible. En version 2.8, les modules disponibles pour Junos sont les suivants :

Continuer la lecture de « Ansible Juniper galaxy »
Publié le

Ansible

Ansible stack

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.

Ansible, Ansible Engine, AWX et Tower Red Hat
Continuer la lecture de « Ansible »
Publié le

Salt

Saltstack

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 :

  • NAPALM proxy
  • Junos proxy
  • Cisco NXOS
  • Cisco NOS
Publié le

DevOps

Automatisation DevOps

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 »
Publié le

PyEZ

Juniper PyEZ automatisation

Dernière modification le 11 janvier 2020

PyEZ, de son vrai nom junos-eznc, est un micro framework proposé en Open Source par Juniper afin de faciliter l’accès, à l’aide du protocole NETCONF, aux équipement tournant Junos . Comme le montre l’image, indépendamment de l’accès direct par le langage Python, ce micro framework est utilisé par d’autres outils comme Ansible, Salt ou JSNAPy.

Junos PyEZ est un package jnpr.junos qui contient les modules suivants :

  • device: Defines the Device class, which represents the device running Junos OS and enables you to connect to and retrieve facts from the device.
  • exception: Defines exceptions encountered when accessing, configuring, and managing devices running Junos OS.
  • factory: Contains code pertaining to Tables and Views, including the loadyaml() function, which is used to load custom Tables and Views.
  • facts: A dictionary-like object of read-only facts about the device. These facts are accessed using the facts attribute of a Device object instance.
  • op: Includes predefined operational Tables and Views that can be used to filter output for common operational commands.
  • resources: Includes predefined configuration Tables and Views representing specific configuration resources, which can be used to programmatically configure devices running Junos OS.
  • transport: Contains code used by the Device class to support the different connection types.
  • utils: Includes configuration utilities, file system utilities, shell utilities, software installation utilities, and secure copy utilities.
Continuer la lecture de « PyEZ »
Publié le

Napalm

Python Napalm

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 :

  • EOS : pyeapi
  • Junos : junos-eznc
  • IOS-XR : pyIOSXR
  • NX-OS : pynxos
  • NX-OS SSH : netmiko
  • IOS : netmiko

NAPALM est une librairie présente dans de nombreux frameworks d’automatisation comme Ansible, Salt ou Nornir.

Outre NAPALM, deux autres librairies sont disponibles :

  • napalm-logs : bibliothèque Python qui écoute les messages syslog des périphériques réseau et renvoie les données structurées selon les modèles OpenConfig ou IETF YANG.
  • napalm-yang : YANG (RFC6020) est un langage de modélisation de données, c’est un moyen de définir l’apparence des données. La bibliothèque napalm-yang fournit un cadre d’utilisation des modèles définis avec YANG dans le contexte de la gestion de réseau. Il fournit des mécanismes pour transformer les données / configuration natives en YANG et inversement.
Publié le

Nornir

Python framework nornir

Dernière modification le 11 janvier 2020

Nornir est un framework d’automatisation écrit en Python. Ce qui le différencie des autres frameworks c’est que vous utilisez le langage Python pour faire fonctionner nornir et non un autre langage comme c’est le cas avec des frameworks tels que Ansible ou Salt. La connexion aux équipements peut s’appuyer sur Napalm, Netmiko ou Paramiko.

Même s’il peut donner le sentiment de partir d’une feuille blanche, il est tout de même extrêmement efficace lorsqu’il s’agit de faire du « Human-driven Automation ». En effet, il automatise de nombreuses tâches en ayant un code très concis, et il permet l’usage d’un outil de debug comme ipdb. Ceux qui ont pratiqué suffisamment Ansible comprendront l’avantage lorsqu’on cherche la raison d’un dysfonctionnement dans le code.

Continuer la lecture de « Nornir »
Publié le

Switch virtuel vQFX

Switch virtuel Juniper vQFX

Dernière modification le 11 janvier 2020

Le switch virtuel Juniper vQFX, mis à disposition gratuitement pour les clients et les partenaires aux formats box, qcow2 et vmdk , peut être utilisé en mode light (Routing Engine uniquement) ou en mode full (Routing Engine et Packet Forwarding Engine). En mode full, le vQFX est constitué de deux machines virtuelles qui forment le Control Plane (RE) et le Data Plane (PFE).

Switch virtuel Juniper vQFX Light et Full

Les deux premières interfaces des VMs sont réservées pour le management Out-of-Band et l’interconnexion des deux VMs. L’interface em2 de la VM RE est réservée. En revanche, la VM RE supporte 12 interfaces supplémentaires pour le trafic Data Plane.

Continuer la lecture de « Switch virtuel vQFX »