Consultant & Tech Lead Sénior
Python est un langage de programmation interprété qui permet de travailler rapidement et d’intégrer les systèmes plus efficacement.
Dernière modification le 8 juillet 2020
Webinar Python pour l’Université de Nice Côte d’Azur organisé par Stéphane FRATI, Responsable parcours Licence Pro CyberDéf – Département Réseaux et Télécommunications (RT), le mercredi 24 juin 2020.
L’objectif du Webinar était de proposer une approche de l’automatisation de réseau avec le langage Python, en mettant en évidence un certains nombre de libertés apportées par l’utilisation de librairies spécialisées.
Lorsque l’objectif est d’utiliser Python 3 pour automatiser l’accès aux équipements Arista, le framework Python Nornir apporte une aide précieuse. Pour les connexions, Nornir peut utiliser NAPALM, Netmiko, Paramiko ou Netconf.
La librairie NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) est indiqué pour se connecter aux équipements Arista. Il s’appuie sur la librairie pyeapi avec un bon niveau de support des fonctionnalités.
Fichier de configuration Nornir :
---
core:
num_workers: 100
inventory:
plugin: nornir.plugins.inventory.simple.SimpleInventory
options:
host_file: "inventory/hosts.yaml"
group_file: "inventory/groups.yaml"
defaults_file: "inventory/defaults.yaml"
Continuer la lecture de « Arista et le framework Nornir » 
Outre la capacité de Zero-touch Provisioning, le NOS (Network Operating System) EOS d’Arista propose plusieurs possibilités d’automatisation. Nombre de ces possibilités peuvent s’expérimenter sur les commutateurs virtuels proposés sous forme de conteneur (cEOS-lab) ou de machine virtuelle (vEOS-lab).
L’Event Manager est une fonctionnalité des commutateurs Arista qui permet d’exécuter des scripts Bash lorsque certains événements système se produisent. Les Event handlers permettent le déclenchement d’un trigger et d’une action. De plus, il est possible de définir un delay de sorte qu’une durée configurée s’écoule après le déclenchement et avant que l’action ne soit prise.
EOS signifie Extensible Operating System, et à ce titre il est possible d’étendre le système avec des collections de fichiers. Ces fichiers sont regroupés sous la forme d’un package appelé RPM (RedHat Package Manager ou RPM Package Manager). Le package prend en charge la gestion des dépendances. Lorsque plusieurs RPMs sont impliqués, ils sont regroupés dans une collection appelée SWIX (SoftWare Image Extension) et accompagnée d’un manifest.
Continuer la lecture de « Automatisation Arista »
Dernière modification le 1 avril 2020
Afin de profiter de la période de confinement pour améliorer les connaissances et revenir dans le circuit économique avec des méthodes encore plus efficaces, je vous propose une série de Webinars gratuits sur l’Automatisation Réseau.
Régulièrement, nous prendrons un sujet et nous le regarderons ensemble. L’objectif n’est pas seulement de participer de manière passive, mais aussi d’essayer soit même de le mettre en place en se faisant assister de la communauté présente dans le webinar.
Rejoignez la communauté Slack du NetDevOps Accelerator.
Continuer la lecture de « Free Webinar Python et Ansible avec Arista »
Dernière modification le 30 mars 2020
Afin de profiter de la période de confinement pour améliorer les connaissances et revenir dans le circuit économique avec des méthodes encore plus efficaces, je vous propose une série de Webinars gratuits sur l’Automatisation Réseau.
Régulièrement, nous prendrons un sujet et nous le regarderons ensemble. L’objectif n’est pas seulement de participer de manière passive, mais aussi d’essayer soit même de le mettre en place en se faisant assister de la communauté présente dans le webinar.
Rejoignez la communauté Slack du NetDevOps Accelerator.
Continuer la lecture de « Free Webinar Python et Ansible avec ALE »
Dernière modification le 15 mars 2020
Arista EOS propose des interfaces programmables pour les applications. Ces interfaces peuvent être exploitées par des applications exécutées sur le commutateur ou externes à EOS. L’interface API EOS (eAPI) permet aux applications et aux scripts d’avoir un contrôle programmatique complet sur EOS, avec une syntaxe stable et facile à utiliser. Une fois l’API activée, le commutateur accepte les commandes utilisant la syntaxe CLI d’Arista et répond avec une sortie sérialisée en JSON et servie via HTTP.
Le client envoie une requête HTTP POST au serveur, en utilisant le protocole JSON-RPC 2.0. La requête spécifie :
Le serveur traite la demande et collecte un modèle de données structuré, sérialisé en JSON, pour chaque commande. Si une commande renvoie une erreur, le champ JSON-RPC 2.0 « errors » sera correctement défini, sinon la réponse est placée dans le champ « result ».
localhost>enable localhost#configure localhost(config)#management api http-commands localhost(config-mgmt-api-http-cmds)#no shutdown localhost(config-mgmt-api-http-cmds)#end localhost#write memoryContinuer la lecture de « Arista eAPI ou EOS API »
Contrairement à JavaScript ou Go, Python n’est pas un langage dont l’exécution asynchrone a été intégrée dès le départ. Pendant longtemps, l’exécution simultanée en Python ne pouvait être réalisée qu’en utilisant le multithreading ou le multiprocessing, ou en ayant recours à des bibliothèques spécialisées telles que eventlet, gevent ou Twisted.
Mais tout a changé quand asyncio a été ajouté à la bibliothèque standard pour prendre en charge du multitâche coopératif. Plus tard, la syntaxe async/await a été ajoutée dans Python 3.5. Grâce à cela, nous avions des coroutines natives indépendantes de l’implémentation sous-jacente, ce qui a ouvert la ruée vers l’asynchrone en Python.
ASGI (Asynchronous Server Gateway Interface) est une sorte de successeur de WSGI ( Web Server Gateway Interface), destiné à fournir une interface normalisée entre les serveurs Web compatibles async , les frameworks et les applications Python.
Là où WSGI fournissait une norme pour les applications Python synchrones, ASGI en fournit une pour les applications asynchrones et synchrones, avec une implémentation apportant une compatibilité descendante avec WSGI et de nombreux serveurs et frameworks d’application.
Dernière modification le 7 décembre 2020
Il existe de nombreuses solutions pour effectuer les tests unitaires TDD (Test Driven Development) dans le cadre des mises au point NetDevOps, mais Robot Framework est mon framework d’automatisation open source générique préféré pour effectuer les tests d’acceptation ATDD (Acceptance Test Driven Development). Ses capacités de test peuvent être étendues avec des librairies implémentées en Python ou en Java. Initialement, le framework a été développé par Nokia Networks. Aujourd’hui, il est sponsorisé par la Robot Framework Foundation.
Dans la mesure où on parle de « Network as Code » ou « Infrastructure as Code », c’est que l’on considère que tout ce qui est nécessaire pour activer l’infrastructure existe sous forme logicielle. Dans le monde du logiciel, les approches Agile et DevOps sont largement adoptées. On sait que les tests sont une partie importante de l’approche Agile pour la « Definition of Done » d’une « User Story ». Pour réaliser une « User Story », il est généralement nécessaire de la découper en tâches. Il n’existe pas qu’une seule façon de concevoir les choses, mais en ce qui me concerne, je considère que les tests qui valident une tâche doivent rester au plus proche de celle-ci. Il s’agit, le plus souvent, de tests unitaires. Si j’utilise Ansible pour réaliser la tâche, alors les tests permettant de dire que la tâche est bien terminée sont intégrés à ses Playbooks.
Continuer la lecture de « Robot Framework »
Dernière modification le 28 mars 2020
Depuis plusieurs années, il y a une absence de module réseau pour Alcatel-Lucent Enterprise dans Ansible. Lorsque j’avais travaillé sur le module alcatel_aos pour Netmiko, l’idée était de permettre de faire de l’automatisation en utilisant le langage Python. L’adjonction du framework Nornir offrait une structuration du code qui reprenait certaines logiques d’Ansible. Trois ans plus tard, force est de constater qu’une grande majorité de personnes partent plus facilement sur le chemin du « Human-driven Automation » avec un outil comme Ansible et son pseudo langage en YAML qu’avec un langage direct comme Python qui reste réservé aux personnes plus expérimentées dans le développement.
C’est pour combler ce manque que j’ai écrit les modules ale_aos pour Ansible, en restant le plus générique possible afin de laisser plus de souplesse dans l’utilisation de ces modules. Ils sont disponibles dans la Galaxy Ansible, et attendent vos tests et propositions d’amélioration, le dépôt officiel des modules de la Galaxy étant dans un Github public. La licence utilisée permet toutes les améliorations sur la branche master des Network Modules, mais n’autorise pas la redistributions des forks, afin d’éviter la perte d’énergie (licence Attribution-NonCommercial-NoDerivatives 4.0 International / CC BY-NC-ND 4.0).
Continuer la lecture de « Ansible ALE Galaxy »
Dernière modification le 11 janvier 2020
Lorsqu’on aborde l’automatisation de réseau Junos, on peut avoir l’impression qu’il y des méthodes redondantes, tellement il y a de possibilités. Juniper Networks a intégré les concepts utilisés dans l’automatisation très tôt dans le système Junos et l’approche « Network as Code » est même ancrée dans l’ADN de l’entreprise.
Chacune des approches a sa raison d’être et de persister. On peut aisément penser que si des méthodes en avaient remplacé d’autres, du ménage aurait fait depuis longtemps dans le système Junos.
Voici ma vision sur la façon de répondre à certaines situations qui pourraient être rencontrées :
Continuer la lecture de « Automatisation Juniper Networks »