Bonjour, Habr!
Récemment, un article de Mikrotik et Linux a glissé ici . Routine et automatisation où un problème similaire a été résolu par des moyens fossiles. Et bien que la tâche soit tout à fait typique, rien de semblable ne se trouve sur Habré à ce sujet. J'ose offrir mon vélo à la communauté informatique réputée.
Ce n'est pas le premier vélo pour cette tâche. La première option a été implémentée il y a plusieurs années sur la version ansible 1.x.x. Le vélo était rarement utilisé et donc constamment rouillé. En ce sens que la tâche elle-même ne se produit pas aussi souvent que les versions mises à jour de ansible . Et chaque fois que vous devez partir, la chaîne tombera, la roue tombera. Cependant, la première partie, la génération de configs - fonctionne toujours très clairement, car le moteur est établi depuis longtemps pour jinja2 . Mais la deuxième partie - le déploiement des configs, en règle générale, a apporté des surprises. Et comme je dois déployer la configuration à distance au sol de centaines d'appareils, dont certains sont à des milliers de kilomètres, c'était un peu ennuyeux d'utiliser cet outil.
Ici, je dois admettre que mon insécurité réside plutôt dans le manque de familiarité avec moi ansible que dans ses lacunes. Et cela, soit dit en passant, est un point important. ansible est un domaine de connaissances complètement séparé et propre avec son propre DSL (Domain Specific Language), qui doit être maintenu à un niveau fiable. Eh bien, le moment où ansible se développe assez rapidement, et sans égard particulier à la compatibilité descendante, n'ajoute pas de confiance.
Par conséquent, il n'y a pas si longtemps, la deuxième version du vélo a été mise en œuvre. Cette fois en python , ou plutôt, dans un framework écrit en python et pour python appelé Nornir
Donc - Nornir est un microframework écrit en python et pour python et destiné à l'automatisation. Comme dans le cas d' ansible , pour résoudre les problèmes, une préparation compétente des données est requise ici, c'est-à -dire inventaire des hôtes et de leurs paramètres, mais les scripts ne sont pas écrits sur une DSL séparée, mais tous sur le même ton pas très ancien, mais très bon [et | ah].
Voyons ce que c'est dans l'exemple vivant suivant.
J'ai un réseau d'agences avec plusieurs dizaines de bureaux à travers le pays. Dans chaque bureau, il y a un routeur WAN qui termine plusieurs canaux de communication provenant de différents opérateurs. Le protocole de routage est BGP. Il existe deux types de routeurs WAN: Cisco ISG ou Juniper SRX.
Maintenant, la tâche: il est nécessaire de configurer un sous-réseau dédié pour la vidéosurveillance dans un port séparé sur tous les routeurs WAN du réseau de succursales - annoncer ce sous-réseau en BGP - configurer la limite de vitesse pour le port dédié.
Tout d'abord, nous devons préparer quelques modèles, en fonction des configurations qui seront générées séparément pour Cisco et Juniper. Et il est également nécessaire de préparer des données pour chaque point et paramètres de connexion, c'est-à -dire pour collecter cet inventaire
Modèle prêt pour Cisco:
$ cat templates/ios/base.j2 class-map match-all VIDEO_SURV match access-group 111 policy-map VIDEO_SURV class VIDEO_SURV police 1500000 conform-action transmit exceed-action drop interface {{ host.task_data.ifname }} description VIDEOSURV ip address 10.10.{{ host.task_data.ipsuffix }}.254 255.255.255.0 service-policy input VIDEO_SURV router bgp {{ host.task_data.asn }} network 10.40.{{ host.task_data.ipsuffix }}.0 mask 255.255.255.0 access-list 11 permit 10.10.{{ host.task_data.ipsuffix }}.0 0.0.0.255 access-list 111 permit ip 10.10.{{ host.task_data.ipsuffix }}.0 0.0.0.255 any
Modèle pour Juniper:
$ cat templates/junos/base.j2 set interfaces {{ host.task_data.ifname }} unit 0 description "Video surveillance" set interfaces {{ host.task_data.ifname }} unit 0 family inet filter input limit-in set interfaces {{ host.task_data.ifname }} unit 0 family inet address 10.10.{{ host.task_data.ipsuffix }}.254/24 set policy-options policy-statement export2bgp term 1 from route-filter 10.10.{{ host.task_data.ipsuffix }}.0/24 exact set security zones security-zone WAN interfaces {{ host.task_data.ifname }} set firewall policer policer-1m if-exceeding bandwidth-limit 1m set firewall policer policer-1m if-exceeding burst-size-limit 187k set firewall policer policer-1m then discard set firewall policer policer-1.5m if-exceeding bandwidth-limit 1500000 set firewall policer policer-1.5m if-exceeding burst-size-limit 280k set firewall policer policer-1.5m then discard set firewall filter limit-in term 1 then policer policer-1.5m set firewall filter limit-in term 1 then count limiter
Bien entendu, les modèles ne sont pas extraits du plafond. Il s'agit essentiellement de la différence entre les configurations de travail: elle est devenue après avoir résolu la tâche sur deux routeurs spécifiques de modèles différents.
D'après nos modèles, nous voyons que pour résoudre le problème, deux paramètres pour Juniper et 3 paramètres pour Cisco suffisent. les voici:
Maintenant, nous devons définir ces paramètres pour chaque appareil, c'est-à -dire faire le même inventaire .
Pour l' inventaire, nous suivrons clairement la documentation Initialisation de Nornir.
c'est-à -dire créer le même squelette de fichier:
. ├── config.yaml ├── inventory │ ├── defaults.yaml │ ├── groups.yaml │ └── hosts.yaml
Fichier config.yaml - fichier de configuration standard de nornir
$ cat config.yaml --- core: num_workers: 10 inventory: plugin: nornir.plugins.inventory.simple.SimpleInventory options: host_file: "inventory/hosts.yaml" group_file: "inventory/groups.yaml" defaults_file: "inventory/defaults.yaml"
Nous allons spécifier les principaux paramètres dans le fichier hosts.yaml , grouper (dans mon cas, les noms d'utilisateur / mots de passe) dans groups.yaml , et nous ne spécifierons rien dans defaults.yaml , mais il doit y avoir trois inconvénients pour indiquer qu'il s'agit d'un fichier yaml bien que vide.
Voici Ă quoi ressemble hosts.yaml:
--- srx-test: hostname: srx-test groups: - juniper data: task_data: ifname: fe-0/0/2 ipsuffix: 111 cisco-test: hostname: cisco-test groups: - cisco data: task_data: ifname: GigabitEthernet0/1/1 ipsuffix: 222 asn: 65111
Et voici groups.yaml:
--- cisco: platform: ios username: admin1 password: cisco1 juniper: platform: junos username: admin2 password: juniper2
Voici l' inventaire de notre tâche. Lors de l'initialisation, les paramètres des fichiers d'inventaire sont mappés au modèle d'objet InventoryElement .
Sous le spoiler, le diagramme du modèle InventoryElement print(json.dumps(InventoryElement.schema(), indent=4)) { "title": "InventoryElement", "type": "object", "properties": { "hostname": { "title": "Hostname", "type": "string" }, "port": { "title": "Port", "type": "integer" }, "username": { "title": "Username", "type": "string" }, "password": { "title": "Password", "type": "string" }, "platform": { "title": "Platform", "type": "string" }, "groups": { "title": "Groups", "default": [], "type": "array", "items": { "type": "string" } }, "data": { "title": "Data", "default": {}, "type": "object" }, "connection_options": { "title": "Connection_Options", "default": {}, "type": "object", "additionalProperties": { "$ref": "#/definitions/ConnectionOptions" } } }, "definitions": { "ConnectionOptions": { "title": "ConnectionOptions", "type": "object", "properties": { "hostname": { "title": "Hostname", "type": "string" }, "port": { "title": "Port", "type": "integer" }, "username": { "title": "Username", "type": "string" }, "password": { "title": "Password", "type": "string" }, "platform": { "title": "Platform", "type": "string" }, "extras": { "title": "Extras", "type": "object" } } } } }
Ce modèle peut sembler un peu déroutant, surtout au début. Le mode interactif dans ipython aide beaucoup à le comprendre.
$ ipython3 Python 3.6.9 (default, Nov 7 2019, 10:44:02) Type 'copyright', 'credits' or 'license' for more information IPython 7.1.1 -- An enhanced Interactive Python. Type '?' for help. In [1]: from nornir import InitNornir In [2]: nr = InitNornir(config_file="config.yaml", dry_run=True) In [3]: nr.inventory.hosts Out[3]: {'srx-test': Host: srx-test, 'cisco-test': Host: cisco-test} In [4]: nr.inventory.hosts['srx-test'].data Out[4]: {'task_data': {'ifname': 'fe-0/0/2', 'ipsuffix': 111}} In [5]: nr.inventory.hosts['srx-test']['task_data'] Out[5]: {'ifname': 'fe-0/0/2', 'ipsuffix': 111} In [6]: nr.inventory.hosts['srx-test'].platform Out[6]: 'junos'
Enfin, passons au script lui-même. Il n'y a rien de spécial dont je puisse être fier. Je viens de prendre l'exemple fini du tutoriel et de l'utiliser avec presque aucun changement. Voici à quoi ressemble le script de travail terminé:
from nornir import InitNornir from nornir.plugins.tasks import networking, text from nornir.plugins.functions.text import print_title, print_result def config_and_deploy(task):
Notez le paramètre dry_run = True dans la ligne d'initialisation de l'objet nr .
Ici, tout comme dans ansible , un test est implémenté dans lequel la connexion au routeur est établie, une nouvelle configuration modifiée est préparée, qui est ensuite validée par l'appareil (mais ce n'est pas exact; cela dépend du support de l'appareil et de la mise en œuvre du pilote dans NAPALM), mais la nouvelle configuration n'est pas directement appliquée . Pour une utilisation en combat, vous devez supprimer le paramètre dry_run ou remplacer sa valeur par False .
Lorsque le script s'exécute, Nornir affiche des journaux détaillés sur la console.
Sous le spoiler, la conclusion du combat se déroule sur deux routeurs de test: config_and_deploy*************************************************************** * cisco-test ** changed : True ******************************************* vvvv config_and_deploy ** changed : True vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv INFO ---- Base Configuration ** changed : True ------------------------------------- INFO class-map match-all VIDEO_SURV match access-group 111 policy-map VIDEO_SURV class VIDEO_SURV police 1500000 conform-action transmit exceed-action drop interface GigabitEthernet0/1/1 description VIDEOSURV ip address 10.10.222.254 255.255.255.0 service-policy input VIDEO_SURV router bgp 65001 network 10.10.222.0 mask 255.255.255.0 access-list 11 permit 10.10.222.0 0.0.0.255 access-list 111 permit ip 10.10.222.0 0.0.0.255 any ---- Loading Configuration on the device ** changed : True --------------------- INFO +class-map match-all VIDEO_SURV + match access-group 111 +policy-map VIDEO_SURV + class VIDEO_SURV +interface GigabitEthernet0/1/1 + description VIDEOSURV + ip address 10.10.222.254 255.255.255.0 + service-policy input VIDEO_SURV +router bgp 65001 + network 10.10.222.0 mask 255.255.255.0 +access-list 11 permit 10.10.222.0 0.0.0.255 +access-list 111 permit ip 10.10.222.0 0.0.0.255 any ^^^^ END config_and_deploy ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * srx-test ** changed : True ******************************************* vvvv config_and_deploy ** changed : True vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv INFO ---- Base Configuration ** changed : True ------------------------------------- INFO set interfaces fe-0/0/2 unit 0 description "Video surveillance" set interfaces fe-0/0/2 unit 0 family inet filter input limit-in set interfaces fe-0/0/2 unit 0 family inet address 10.10.111.254/24 set policy-options policy-statement export2bgp term 1 from route-filter 10.10.111.0/24 exact set security zones security-zone WAN interfaces fe-0/0/2 set firewall policer policer-1m if-exceeding bandwidth-limit 1m set firewall policer policer-1m if-exceeding burst-size-limit 187k set firewall policer policer-1m then discard set firewall policer policer-1.5m if-exceeding bandwidth-limit 1500000 set firewall policer policer-1.5m if-exceeding burst-size-limit 280k set firewall policer policer-1.5m then discard set firewall filter limit-in term 1 then policer policer-1.5m set firewall filter limit-in term 1 then count limiter ---- Loading Configuration on the device ** changed : True --------------------- INFO [edit interfaces] + fe-0/0/2 { + unit 0 { + description "Video surveillance"; + family inet { + filter { + input limit-in; + } + address 10.10.111.254/24; + } + } + } [edit] + policy-options { + policy-statement export2bgp { + term 1 { + from { + route-filter 10.10.111.0/24 exact; + } + } + } + } [edit security zones] security-zone test-vpn { ... } + security-zone WAN { + interfaces { + fe-0/0/2.0; + } + } [edit] + firewall { + policer policer-1m { + if-exceeding { + bandwidth-limit 1m; + burst-size-limit 187k; + } + then discard; + } + policer policer-1.5m { + if-exceeding { + bandwidth-limit 1500000; + burst-size-limit 280k; + } + then discard; + } + filter limit-in { + term 1 { + then { + policer policer-1.5m; + count limiter; + } + } + } + } ^^^^ END config_and_deploy ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Masquage des mots de passe dans ansible_vault
Au début de l'article, je suis tombé un peu sur ansible , mais tout n'est pas si mal là -bas. J'aime beaucoup leur coffre - fort , conçu pour cacher les informations sensibles à l'abri des regards. Et probablement beaucoup ont remarqué que nous avons tous les noms d'utilisateur / mots de passe pour tous les routeurs de bataille étincelants sous forme ouverte dans le fichier groups.yaml . C'est moche, bien sûr. Protégeons ces données avec le coffre-fort .
Nous transférons les paramètres de groups.yaml vers creds.yaml et les chiffrons avec AES256 avec un mot de passe à 20 chiffres:
$ cd inventory $ cat creds.yaml --- cisco: username: admin1 password: cisco1 juniper: username: admin2 password: juniper2 $ pwgen 20 -N 1 > vault.passwd ansible-vault encrypt creds.yaml --vault-password-file vault.passwd Encryption successful $ cat creds.yaml $ANSIBLE_VAULT;1.1;AES256 39656463353437333337356361633737383464383231366233386636333965306662323534626131 3964396534396333363939373539393662623164373539620a346565373439646436356438653965 39643266333639356564663961303535353364383163633232366138643132313530346661316533 6236306435613132610a656163653065633866626639613537326233653765353661613337393839 62376662303061353963383330323164633162386336643832376263343634356230613562643533 30363436343465306638653932366166306562393061323636636163373164613630643965636361 34343936323066393763323633336366366566393236613737326530346234393735306261363239 35663430623934323632616161636330353134393435396632663530373932383532316161353963 31393434653165613432326636616636383665316465623036376631313162646435
Si simple. Il reste à apprendre à notre script Nornir pour obtenir et utiliser ces données.
Pour ce faire, dans notre script, après la ligne d'initialisation nr = InitNornir (config_file = ... ajoutez le code suivant:
... nr = InitNornir(config_file="config.yaml", dry_run=True)
Bien sûr, vault.passwd ne doit pas se trouver à côté de creds.yaml comme dans mon exemple. Mais pour jouer, ce sera suffisant.
C'est tout pour l'instant. Quelques articles sur Cisco + Zabbix arrivent, mais ce n'est pas un peu l'automatisation. Et dans un avenir proche, je prévois d'écrire sur RESTCONF dans Cisco.