Gilbert MOISIO – Page 8 – Gilbert MOÏSIO

2 avril 20203 avril 2020

Automatisation Arista

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.

Continuer la lecture

30 mars 20201 avril 2020

Free Webinar Python et Ansible avec 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

22 mars 202030 mars 2020

Free Webinar Python et Ansible avec ALE

Dernière modification le 30 mars 2020

Rejoignez la communauté Slack du NetDevOps Accelerator.

Continuer la lecture

12 mars 20204 avril 2020

Arista et automatisation Ansible

Dernière modification le 4 avril 2020

Les modules officiels Arista EOS sont intégrés dans les Network Modules natifs et supportés par la Network Team d’Ansible.

Network Modules natifs Ansible :

eos_banner – Manage multiline banners on Arista EOS devices
eos_bgp – Configure global BGP protocol settings on Arista EOS
eos_command – Run arbitrary commands on an Arista EOS device
eos_config – Manage Arista EOS configuration sections
eos_eapi – Manage and configure Arista EOS eAPI
eos_facts – Collect facts from remote devices running Arista EOS
eos_interfaces – Manages interface attributes of Arista EOS interfaces
eos_l2_interfaces – Manages Layer-2 interface attributes of Arista EOS devices
eos_l3_interfaces – Manages L3 interface attributes of Arista EOS devices
eos_lacp – Manage Global Link Aggregation Control Protocol (LACP) on Arista EOS devices
eos_lacp_interfaces – Manage Link Aggregation Control Protocol (LACP) attributes of interfaces on Arista EOS devices
eos_lag_interfaces – Manages link aggregation groups on Arista EOS devices
eos_lldp – Manage LLDP configuration on Arista EOS network devices
eos_lldp_global – Manage Global Link Layer Discovery Protocol (LLDP) settings on Arista EOS devices
eos_lldp_interfaces – Manage Link Layer Discovery Protocol (LLDP) attributes of interfaces on Arista EOS devices
eos_logging – Manage logging on network devices
eos_static_route – Manage static IP routes on Arista EOS network devices
eos_system – Manage the system attributes on Arista EOS devices
eos_user – Manage the collection of local users on EOS devices
eos_vlans – Manage VLANs on Arista EOS devices
eos_vrf – Manage VRFs on Arista EOS network devices

Continuer la lecture

11 mars 202015 mars 2020

Arista eAPI ou EOS API

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 :

La méthode à utiliser (pour l’instant « runCmds »)
Une liste de commande à executer, par exemple [‘show interfaces’] ou [‘configure’, ‘interface Ethernet 1’, ‘shutdown’]
Un numéro de version, spécifiant à quelle révision du modèle de sortie le script doit s’attendre (pour l’instant, toujours « 1 »)

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 memory

Continuer la lecture

10 mars 2020

Switch virtuel Arista cEOS-lab

cEOS-lab est une version conteneurisée de vEOS-lab avec les mêmes limitations fonctionnelles liées au fait que certaines fonctions EOS s’appuient directement sur les capacités des ASICs. Comparé à vEOS-lab, cEOS-lab présente tous les avantages d’un conteneur, comme une empreinte beaucoup plus légère d’environ 470 Mo de RAM par périphérique à sa création, une taille d’image plus petite et une plus grande portabilité.

Le test est lancé nativement sur mon MacBook Pro avec Docker Desktop 2.2.0.3 et Docker Engine 19.03.5.

# importer l'image cEOS-lab tar.xz
docker import cEOS-lab-4.23.2F.tar.xz ceosimage:4.23.2F

# créer une instance Docker avec les variables d'environnement nécessaires
docker create --name=ceos1 --privileged -e INTFTYPE=eth -e ETBA=1 -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e CEOS=1 -e EOS_PLATFORM=ceoslab -e container=docker -p 2000:22/tcp -i -t ceosimage:4.23.2F /sbin/init systemd.setenv=INTFTYPE=eth systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker

Les options utilisées ont les significations suivantes :

–name=ceos1
Il s’agit d’un flag Docker qui permet de créer le conteneur avec le nom ceos1.
–privileged
Il s’agit d’un flag Docker qui lance le conteneur en mode privilégié.
-e INTFTYPE=eth
Il s’agit d’un flag cEOS qui indique à l’OS de libeller les interfaces avec eth.
-e ETBA=1
Il s’agit d’un flag cEOS qui indique à EOS d’utiliser un Data Plane basé sur du logiciel.
-e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1
Il s’agit d’un flag cEOS qui indique à EOS de ne pas lancer le ZTP au boot.
-e CEOS=1
Il s’agit d’un flag cEOS qui indique à EOS qu’il s’agit de cEOS et non d’un EOS classique.
-e EOS_PLATFORM=ceoslab
Il s’agit d’un flag cEOS qui indique le type de plateforme. La valeur de ce flag a changé avec les versions.
-e container=docker
Il s’agit d’un flag cEOS qui indique qu’il s’agit d’un conteneur Docker, car il en existe d’autres types.
-p 2000:22/tcp
Il s’agit d’un flag Docker qui expose le port 22 pour être utilisé par SSH, sachant qu’on pourrait exposer aussi le port 443 pour l’utiliser avec eAPI.
-i -t ceosimage:4.23.2F
Il s’agit d’un flag Docker pour indiquer l’image à utiliser.
/sbin/init
Il s’agit d’un flag Docker qui indique la commande à utiliser pour lancer le conteneur, en lui associant les paramètres d’environnements nécessaires.

Continuer la lecture

9 mars 202014 mars 2020

Switch virtuel Arista vEOS-lab

Dernière modification le 14 mars 2020

vEOS-lab permet d’utiliser le système EOS des commutateurs Arista sous forme d’une VM. Le système EOS porté à l’origine par Linux Fedora 18, est passé en CentOS 7.5 depuis la release 4.23.0F.

vEOS-lab permet la conception de réseaux et la validation des images EOS, le développement et les tests rapides d’EOS, ainsi que la mise en place de structure de formation et de training. Il ne faut pas le confondre avec vEOS Router qui est un produit NFV (Network Functions Virtualization) s’appuyant sur DPDK pour offrir plusieurs gigabits de débit dans des environnements cloud virtuels et publics.

Comme je l’ai déjà expliqué, mes trois outils de simulation préférés sont EVE-NG, GNS3 et Vagrant/VirtualBox. Chacun a ses avantages et inconvénients, mais EVE-NG a ma préférence dans le domaine professionnel lorsqu’il est nécessaire d’être démonstratif et visuel.

Continuer la lecture

10 février 202012 février 2020

Network Source of Truth (NSoT)

Dernière modification le 12 février 2020

L’automatisation réseau et plus généralement l’approche NetDevOps nécessite une source de vérité pour stocker les informations de référence. L’automatisation du réseau doit connaître l’infrastructure sur laquelle elle agit. Cette connaissance nécessite des données complètes sur la configuration et l’état de ce réseau.

Une étude menée par EMA (Enterprise Management Associates), « Enterprise Network Automation for 2020 and Beyond », a révélé que 98% des initiatives d’automatisation de réseau d’entreprise ont une certaine conscience de l’intérêt d’une source de vérité réseau, et 41% des entreprises considèrent leur source de vérité comme indispensable à l’automatisation. Cette recherche, basée sur une enquête auprès de 250 professionnels de l’informatique directement impliqués dans une initiative formelle d’automatisation de réseau, a révélé que les entreprises qui réussissent avec l’automatisation de réseau sont plus susceptibles de considérer la source de vérité comme essentielle.

Pour l’avoir moi-même observé, si aucune source de vérité n’est explicitement définie et respectée, il y aura toujours quelqu’un pour faire une modification en dehors du processus d’automatisation. Le jour où une reconstruction est lancée par automatisation, il manquera un élément dans la configuration…

Continuer la lecture

3 février 20203 février 2020

DevOps

DevOps est un processus de développement, de livraison et d’exploitation logicielle. Il existe de nombreuses définitions de DevOps dans des ouvrages et sur Internet qui sont imprécises et parfois déroutantes.
Une autre variante trompeuse, est de se limiter à voir DevOps comme une intersection du travail et des personnes dans une organisation informatique, entre les développeurs de logiciels, les testeurs de logiciels et les personnes responsables de la production.

La meilleure approche pour le définir, est de voir DevOps comme du développement itératif de logiciel en mode Agile avec des cadres d’amélioration continue des processus tels que Scrum, Lean, ITIL, …
Pour autant, il ne faut pas considérer que DevOps est un sur-ensemble amélioré et combiné de ces méthodologies et techniques.
La façon simple de s’en convaincre est qu’aucune de ces méthodologies et cadres, hormis Agile et Scrum, n’ont été introduits pour résoudre spécifiquement les problèmes de l’industrie du logiciel.
De nombreuses pratiques et principes DevOps ont été dérivés des sept principes du mouvement Lean après avoir été adaptés, expérimentés, validés et affinés pour le développement, la livraison et l’exploitation de logiciels.

Continuer la lecture

27 janvier 2020

Python WSGI ou ASGI

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.

Continuer la lecture