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).
Automatisation On-box
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.
Il existe deux types d’agents (process Linux qui tourne sur EOS) qui interopèrent avec la SysDB. Les agents EOS sont écrits par Arista et les agents SDK sont réalisés en utilisant le SDK écrit en langage C++ et en le consommant avec le langage Python. Un agent contient une boucle d’événement à l’intérieur de laquelle on trouve les méthodes (fonctions en programmation objet).
Automatisation Off-box
Le système d’automatisation Ansible est le plus utilisé et Arista propose trois façons d’interagir avec les équipements. Il existe deux façons de se connecter à un équipement Arista avec Ansible : en utilisant le CLI sur SSH ou en utilisant eAPI sur HTTP(S). L’utilisation de SSH fait appel au paramètre ansible_connection: network_cli, alors que l’utilisation de HTTP(S) adopte ansible_connection: httpapi ou ansible_connection: local avec transport: eapi dans le dictionnaire provider.
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. Le client envoie une requête HTTP POST au serveur, en utilisant le protocole JSON-RPC 2.0. Le serveur traite la demande et collecte un modèle de données structuré, sérialisé en JSON, pour chaque commande.
Python permet d’utiliser différentes librairies pour interagir avec les équipements. jsonrpclib (Python 2.7) et jsonrpclib-pelix (Python 3) sont des librairies qui implémentent la spécification JSON-RPC. Python requests est une librairie HTTP très connue pour envoyer des requêtes au format JSON. Ces dernières peuvent être mises au point sur l’interface web « Simple eAPI request editor » du commutateur.
La librairie Open Source Arista pyeapi est certainement le meilleur choix, car elle fournit à la fois un client pour envoyer et recevoir des commandes via eAPI, ainsi qu’une API pour travailler directement avec les ressources EOS. Pour utiliser cette librairie, je suis partisan de lui adjoindre le framework d’automatisation Nornir é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 systèmes tels que Ansible. Une fois dans Nornir, la librairie NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) est le meilleur choix pour s’interfacer avec la librairie pyeapi.