J'ai essayé d'utiliser PyEZ et JSNAPy. C'est une suite de. Cette fois, je présenterai le contenu de l'utilisation de PyEZ.
PyEZ est une bibliothèque Python pour la configuration des routeurs JUNOS. Au fait, il semble qu'une bibliothèque Ruby appelée RubyEZ soit également disponible.
La communication avec le routeur utilise NET CONF over SSH et est conçue pour fonctionner sur le port TCP 830 recommandé par la RFC par défaut.
PyEZ semble être disponible à partir de la version 11.4 de JUNOS. Par rapport au cas d'autres fabricants, l'outil d'automatisation peut être utilisé uniquement avec la nouvelle version du système d'exploitation dans de nombreux cas, mais avec la combinaison de JUNOS + PyEZ, il peut être utilisé avec le routeur JUNOS qui a déjà été introduit et exploité sur de nombreux sites d'exploitation. Par conséquent, on peut dire qu'il s'agit d'un outil facile à utiliser en raison du faible seuil d'introduction. (Dans le site d'exploitation du réseau réel, afin d'éviter la détérioration des performances et les défauts, de nombreuses organisations peuvent adopter uniquement la version du système d'exploitation avec des bogues morts. "Le nouveau système d'exploitation ne peut pas être utilisé à moins que les bogues ne soient morts." "Résultats J'imagine qu'il peut y avoir des cas où l'examen et l'introduction de l'automatisation seront reportés de plusieurs années.)
Je n'ai pas essayé toutes les fonctionnalités, mais il semble que je peux presque le faire manuellement avec PyEZ. Si vous trouvez quelque chose que vous ne pouvez pas faire en utilisant PyEZ, veuillez partager vos résultats.
La compréhension sera plus rapide si vous continuez en regardant les articles / documents suivants. Ils sont disposés dans l'ordre qui a été utile.
Blog d'introduction au japonais
PyEZ Github
Document officiel de Juniper
Ici, Python 2.7.10 est utilisé comme serveur exécutant l'outil et Firefly comme routeur JUNOS.
Tout d'abord, installez PyEZ avec la commande pip. La dernière version 2.0.1 est utilisée ici.
pip install junos-eznc
pip list
junos-eznc (2.0.1)
En outre, du côté du routeur JUNOS, saisissez les paramètres pour activer NETCONF.
Informations sur le routeur
root@firefly1> show version
Hostname: firefly1
Model: firefly-perimeter
JUNOS Software Release [12.1X47-D20.7]
Configuration activée NETCONF
system {
services {
netconf {
ssh;
}
}
}
}
Configurez simplement le routeur comme ci-dessus et il commencera à écouter TCP 830 pour NETCONF sur SSH.
root@firefly1> show system connections | grep 830
tcp4 0 0 *.830 *.* LISTEN
Le programme de configuration minimum pour que PyEZ fonctionne est illustré ci-dessous. Ici, le nom d'hôte passe de firefly1 à firefly1_changed_by_PyEZ.
set_firefly1_change_hostname.Extrait de la partie réglage PyEZ de py uniquement
#! /usr/bin/env python
# -*- coding: utf-8 -*-
from jnpr.junos import Device
from jnpr.junos.utils.config import Config
#Définir les informations à contrôler
dev1 = Device(
host="192.168.34.16",
user="user1",
password="password1"
)
dev1.open()
#Établir une session
dev1.open()
dev1.bind(cu=Config)
#Afficher le nom d'hôte
print "Hostname : ",
print dev1.facts["hostname"]
#Verrouillé pour que les paramètres ne soient pas modifiés par rapport aux autres sessions
dev1.cu.lock()
#Fichier de configuration(./configs/change_hostname.conf")Lis
#À ce stade, la configuration candidate est uniquement mise à jour et la validation n'a pas été exécutée.
conf_filename = "./configs/change_hostname.conf"
dev1.cu.load(path=conf_filename, format="text", merge=True)
#Effectuez une vérification de validation. Jugez s'il y a un problème avec les paramètres.
print "Commit Check : ",
if dev1.cu.commit_check() :
print "OK"
else:
print "Error"
#Confiez à l'utilisateur le choix de s'engager ou non(Bien sûr, un commit automatique est également possible)
print "Do you commit? y/n"
choice = raw_input().lower()
if choice == "y":
#Exécutez la validation.
dev1.cu.commit()
print "Commit candidate config : OK"
else:
#Revenir en arrière sans exécuter la validation. La configuration candidate est supprimée.
dev1.cu.rollback()
print "Rollback : OK"
#Déverrouillage de session
dev1.cu.unlock()
#Fin de session
dev1.close()
:./configs/change_hostname.conf
system {
host-name firefly1_changed_by_PyEZ;
}
Avec le programme ci-dessus, il est possible de soumettre la configuration de changement de nom d'hôte.
En tant que code de démonstration, celui implémenté avec la partie d'affichage ajoutée est publié sur github. https://github.com/taijiji/sample_pyez/blob/master/set_firefly1_change_hostname.py
Le résultat de l'exécution est le suivant.
J'ai pu changer le nom d'hôte en utilisant la même procédure d'exécution que le réglage manuel. Bien sûr, j'ai pu confirmer que le nom d'hôte du routeur réel a été modifié.
Vérifiez le nom d'hôte sur le routeur
root@firefly1_changed_by_PyEZ>
root@firefly1_changed_by_PyEZ> show version
Hostname: firefly1_changed_by_PyEZ
Model: firefly-perimeter
JUNOS Software Release [12.1X47-D20.7]
Auparavant, nous utilisions un fichier de configuration généré statiquement à l'avance, mais avec PyEZ, il est possible de créer une partie de la variable de fichier de configuration comme indiqué ci-dessous en utilisant le moteur de modèle.
interfaces {
{{ if_name }} {
unit 0 {
description {{ if_description }};
family inet {
address {{ if_address_ipv4 }}/{{ if_subnet_ipv4 }};
}
}
}
}
Lors de l'utilisation de la configuration statique, il est nécessaire de préparer / gérer des fichiers de configuration similaires à chaque fois pour définir des paramètres avec plusieurs paramètres tels que l'interface et le voisin BGP, et par conséquent, il est nécessaire de gérer un grand nombre de fichiers de configuration. Sortira. En intégrant ici la variable / modèle du fichier de configuration, vous pouvez réduire la cible du fichier de configuration à gérer.
PyEZ utilise Jinaja2, qui est l'un des moteurs de modèles, pour créer la variable du fichier de configuration. J'ai déjà présenté Jinja2 sur mon blog, veuillez donc vous y référer ici. Comment utiliser Template Engine for Network Engineer
Ici, seule la différence par rapport à l'exemple d'utilisation de PyEZ 1 est introduite. Veuillez vérifier sur github l'exemple de code de la démo que vous avez réellement écrite. https://github.com/taijiji/sample_pyez/blob/master/set_firefly1_add_interface.py
set_firefly1_add_interface.Extrait de py
dev1 = Device(
host="192.168.34.16",
user="user1",
password="password1"
)
dev1.open()
# interface ge-0/0/Afficher les paramètres de 2 au format RPC
if_info = dev1.rpc.get_interface_information(
interface_name='ge-0/0/2',
terse=True)
print etree.tostring(if_info)
#Spécifiez le nom du fichier de modèle
template_filename = "./configs/add_interface.jinja2"
#Spécifiez des variables dans le fichier modèle
add_if_param = {
'if_name' : 'ge-0/0/2',
'if_description' : 'add_by_PyEZ',
'if_address_ipv4' : '192.168.35.1',
'if_subnet_ipv4' : '30'
}
#Chargez la configuration à l'aide du fichier modèle
dev1.cu.load(
template_path=template_filename,
template_vars=add_if_param,
format="text",
merge=True
)
#Valider la configuration
dev1.cu.commit()
:./configs/add_interface.jinja2
interfaces {
{{ if_name }} {
unit 0 {
description {{ if_description }};
family inet {
address {{ if_address_ipv4 }}/{{ if_subnet_ipv4 }};
}
}
}
}
Ceci est le résultat de l'exécution du programme de démonstration.
Résultat d'exécution
% python set_firefly1_add_interface.py
##### Operation : Start #######
Connecting to device : OK
Hostname : firefly1
Interfaces ge-0/0/2 :
##############################
<interface-information style="terse">
<physical-interface>
<name>
ge-0/0/2
</name>
<admin-status>
up
</admin-status>
<oper-status>
up
</oper-status>
</physical-interface>
</interface-information>
##############################
Load config :
OK
Target template : ./configs/add_interface.jinja2
##############################
interfaces {
ge-0/0/2 {
unit 0 {
description add_by_PyEZ;
family inet {
address 192.168.35.1/30;
}
}
}
}
##############################
Diff :
##############################
[edit interfaces]
+ ge-0/0/2 {
+ unit 0 {
+ description add_by_PyEZ;
+ family inet {
+ address 192.168.35.1/30;
+ }
+ }
+ }
##############################
Commit Check : OK
Do you commit? y/n
y
Commit candidate config : OK
Interfaces ge-0/0/2 :
##############################
<interface-information style="terse">
<physical-interface>
<name>
ge-0/0/2
</name>
<admin-status>
up
</admin-status>
<oper-status>
up
</oper-status>
<logical-interface>
<name>
ge-0/0/2.0
</name>
<admin-status>
up
</admin-status>
<oper-status>
up
</oper-status>
<description>
add_by_PyEZ
</description>
<filter-information>
</filter-information>
<address-family>
<address-family-name>
inet
</address-family-name>
<interface-address>
<ifa-local emit="emit">
192.168.35.1/30
</ifa-local>
</interface-address>
</address-family>
</logical-interface>
</physical-interface>
</interface-information>
##############################
##### Operation : End #####
C'est un peu difficile à comprendre car l'acquisition d'informations par PyEZ est au format XML-RPC, mais vous pouvez voir que l'adresse IP et la description sont définies sur ge-0 / 0/2, ce qui n'était pas avant le paramétrage.
Si vous le vérifiez avec un routeur réel, vous pouvez voir qu'il est défini comme suit.
Vérifier avec le routeur
root@firefly1> show configuration interfaces ge-0/0/2
unit 0 {
description add_by_PyEZ;
family inet {
address 192.168.35.1/30;
}
}
Cette fois, nous avons introduit PyEZ en mettant l'accent sur les exemples d'utilisation. J'ai essayé certaines des fonctionnalités non présentées dans cet article, veuillez donc vous référer à l'exemple de code sur Github. https://github.com/taijiji/sample_pyez
La prochaine fois, je présenterai JSNAPy. J'ai essayé d'utiliser PyEZ et JSNAPy. Partie 3: J'ai essayé d'utiliser JSNAPy
Recommended Posts