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 :
- On souhaite développer une application dimensionnante avec une forte maîtrise des actions et une autonomie de réaction aux évènements :
- On va utiliser JET (Juniper Extension Toolkit) pour permettre de passer par le process jsd qui ne contrôlera que la syntaxe. Toutes les vérifications seront laissées sous la responsabilité de l’application qui aura une capacité d’action et une vitesse d’execution très supérieure au process mgd en attaquant directement une « Ephemeral Configuration Database ».
- On veut réaliser du « Human-driven Automation » avec une équipe de personnes peu expérimentées en développement :
- On va employer un outil structurant et facile d’accès comme Ansible. Il permet d’encadrer les méthodes de travail de l’équipe et utilise un pseudo-langage en YAML.
- On veut réaliser du « Human-driven Automation » avec une équipe de personnes confirmées qui aiment Ansible mais qui en ont assez de ses contraintes et de ses difficultés pour déboguer les playbooks :
- On va utiliser directement Python avec le Framework Nornir et la librairie NAPALM. Pour réaliser des scripts utilisables en ligne de commande, on rajoutera avantageusement le package Click. Si on souhaite habiller les scripts avec une interface web, on se tournera vers le micro framework Flask ou vers le framework full-stack Django.
- On souhaite faire du « Human-driven Automation », du « Event-driven Automation » et du « Machine-driven Automation » avec un outil structurant :
- On va utiliser Salt en mettant en place des « Proxy Minions », le « Junos Syslog Engine » et des « Salt Reactors » afin de constituer une « Event-Driven Infrastructure » (EDI).
- On possède un environnement uniforme Junos et on souhaite avoir accès à un niveau de détail que des scripts Off-box ne permettent pas d’atteindre, par exemple sur de l’Event-driven :
- On va utiliser des scripts On-box en SLAX ou en Python (Op, Commit, Event, SNMP) pour avoir accès à un niveau de finesse qu’il serait impossible d’égaler depuis l’externe. On a un grand nombre d’équipements et les scripts ont des variations d’un équipement à l’autre ? Ansible et son moteur de templates Jinja2 seront votre ami pour gérer tout ça depuis un point central !
- On souhaite réaliser une application web qui va accéder à des équipements de différents constructeurs :
- L’utilisation de REST pourra fournir une réponse adaptée car c’est la méthode la plus répandue chez d’autres constructeurs.
- Vous ne connaissez pas Ansible, Salt et Python, mais vous avez une expérience en langage Ruby :
- Vous pourrez utiliser Puppet, Chef ou même développer directement en langage Ruby en utilisant le framework RubyEZ.
Dans cette longue liste, je n’ai pas parlé de « Self-driving Automation ». Juniper Networks travaille dessus avec ses offres commerciales. Pour ma part, je fais des expérimentations en Python/TensorFlow dont je parlerai bientôt hors cadre Junos.