Pipeline CI/CD

Pipeline CI-CD

DevOps est une nouvelle façon d’approcher la manière dont on conçoit, on exploite et on délivre les services IT. J’ai eu souvent l’occasion de le dire et de l’écrire, mais réaliser des programmes ne fait pas du programmeur un DevOps et encore moins de la société qui l’emploie une société DevOps.

Entrer dans le monde DevOps implique de focaliser sur les objectifs, les personnes, les processus et les outils à mettre en oeuvre. Cet article se voulant plutôt orienté technique, il focalisera sur des éléments appartenant aux domaines des processus et des outils. Dans les processus DevOps, l’approche CI/CD (Continuous Integration / Continuous Delivery ou Deployment) est fondamentale. Le schéma proposé ci-dessus illustre le pipeline du « Continuous Integration » et met en évidence la différence subtile entre « Continuous Delivery » et « Continuous Deployment » et les deux premières étapes vont être expliquées.

Généralement associé à un gestionnaire de versioning, on utilise un outil d’intégration continue comme Jenkins, CircleCI ou l’intégration continue disponible dans GitLab pour mettre en place le pipeline proposé dans l’illustration de cet article.

Continuer la lecture de « Pipeline CI/CD »

Arista et le framework Nornir

Arista pyeapi Napalm Nornir

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 »

Automatisation Arista

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 de « Automatisation Arista »

Free Webinar Python et Ansible avec Arista

Webinar 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 »

Arista et automatisation Ansible

Arista 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 de « Arista et automatisation Ansible »

Arista eAPI ou EOS API

Arista eAPI

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 de « Arista eAPI ou EOS API »

Switch virtuel Arista cEOS-lab

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 de « Switch virtuel Arista cEOS-lab »

Switch virtuel Arista vEOS-lab

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.

vEOS-lab EVE-NG
Continuer la lecture de « Switch virtuel Arista vEOS-lab »