L’aéroport Nice Côte d’Azur est le deuxième aéroport de France avec 14.5 millions de passagers par an et un réseau de plus de 120 destinations, en majorité à l’international.
Salt, de la société SaltStack, est un sujet dont je n’ai pas parlé depuis plus d’un an car le support de Python3 pour le « Syslog Engine » n’était pas fonctionnel et nécessitait d’utiliser un environnement de développement spécifique.
Entre le fait que ce problème soit réglé et que SaltStack ait été rachetée par VMWare, c’est le bon moment pour proposer un rappel sur cette solution qui ne manque pas d’intérêt pour faire du « Human-driven Automation », du « Event-driven Automation » et du « Machine-driven Automation » avec un outil structurant.
Salt utilise un modèle de communication serveur-agent, bien qu’il fonctionne aussi en tant qu’utilitaire de gestion de serveur unique autonome, et offre également la possibilité de s’exécuter sans agent via SSH.
Le composant serveur s’appelle « Salt master » et l’agent s’appelle « Salt minion ». Le « Salt master » est responsable de l’envoi des commandes aux « Salt minions », puis de l’agrégation et de l’affichage des résultats de ces commandes. Un seul « Salt Master » peut gérer des milliers de systèmes. Salt communique avec les systèmes gérés à l’aide d’un modèle « publish-subscribe ». Les connexions sont initiées par le « Salt Minion », ce qui signifie que vous n’avez pas besoin d’ouvrir de ports entrants sur ces systèmes (réduisant ainsi le vecteur d’attaque). Le « Salt Master » utilise les ports 4505 et 4506, qui doivent être ouverts pour accepter les connexions entrantes.
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.
Webinar 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 vendredi 5 juin 2020.
Outre une évaluation de connaissance dans le domaine du NetDevOps et plus particulièrement de l’automatisation réseau, l’objectif du Webinar était de proposer une présentation théorique de certains sujets parfois illustrés d’une démonstration visant à préparer une séance de travaux pratiques pour permettre aux étudiants de mettre en place leur propre plateforme de simulation et d’automatisation.
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.
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.
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 :
Comme déjà évoqué, il existe plusieurs façons d’accéder aux informations et de les configurer sur des équipements Juniper Networks. Une de ces méthodes est de passer par les API REST (Representational State Transfer). Comme pour le CLI et NETCONF, les connexions REST, appelée parfois RESTful, se font au travers du process mgd. REST est considéré comme étant stateless car aucun contexte client n’est stocké sur le serveur entre les requêtes. Chaque requête contient toutes les informations nécessaires pour executer la requête et l’état de la session est conservé sur le client.
Pour des constructeurs du monde de l’automatisation, accéder aux informations de configurations est souvent synonyme d’analyser les chaînes de caractères retournées pour les formater à l’affichage et y chercher des éléments ciblés. Par exemple, le module Python TextFSM a été mis au point pour permettre l’accès par programme aux informations renvoyées par l’interface de ligne de commande (CLI) des équipements réseau.
Dans le cas de Juniper Networks, Junos possède un ensemble complet d’API : API XML (accessible localement ou à distance en utilisant le protocole sécurisé NETCONF), API REST et API JET. Il existe donc plusieurs façons d’accéder avec certitude et de façon structurée aux éléments souhaités.
Les processus les plus importants pour l’automatisation de Junos sont les processus de service mgd et JET (jsd). Mgd gère les demandes d’automatisation impliquant l’API XML de Junos, YANG, l’API REST et certaines fonctions SNMP. Le processus de service JET (jsd) gère les demandes d’automatisation qui utilisent l’API JET (Juniper Extension Toolkit). Le processus de gestion (mgd) est au cœur de toute automatisation Junos basée sur NECTONF. L’interface de ligne de commande de Junos est également gérée par le biais de mgd.
JSNAPy est un outil Open Source mis à disposition par Juniper. Il permet de valider la configuration d’un équipement et de comparer l’état d’une configuration avant et après une modification.
L’action peut être réalisée sur la configuration actuelle (snapcheck) ou sur le couple de configurations « avant et après » (PRE et POST).
Cet outil possède sa propre interface CLI pour être utilisé de façon autonome. Il est également possible de faire fonctionner JSNAPy à partir du modules Ansible galaxy juniper_junos_jsnapy ou directement à partir de scripts Python.
tests_include:
- test_interfaces_terse
test_interfaces_terse:
- rpc: get-interface-information
- iterate:
xpath: //physical-interface
id: './name'
tests:
- no-diff: description
err: "Test Failed! description for <{{id_0}}> got changed, before it was <{{pre['description']}}>, now it is <{{post['description']}}>"
info: "Test succeeded! description for <{{id_0}}> did not change, before it was <{{pre['description']}}>, now it is <{{post['description']}}>"
J’ai demandé une amélioration car le nom des fichiers snapshots est constitué avec l’adresse IP mais pas avec le port, et il n’est pas possible de changer le nom du fichier depuis un playbook Ansible utilisant juniper_junos_jsnappy. Lorsque JSNAPy est utilisé en environnement de simulation Vagrant, tous les devices ont la même adresse IP, ce n’est que le port qui les différencient. A suivre…