Génération et remplissage automatiques des éléments de configuration des périphériques réseau à l'aide de Nornir

Génération et remplissage automatiques des éléments de configuration des périphériques réseau à l'aide de Nornir

Hé Habr !

Récemment, un article est apparu ici Mikrotik et Linux. Routine et automatisation où un problème similaire a été résolu en utilisant des moyens fossiles. Et bien que la tâche soit tout à fait typique, elle n’a rien de semblable chez Habré. J'ose offrir mon vélo à la communauté informatique respectée.

Ce n'est pas le premier vélo pour une telle tâche. La première option a été mise en œuvre il y a plusieurs années ansible version 1.x.x. Le vélo était rarement utilisé et donc constamment rouillé. Dans le sens où la tâche elle-même ne se pose pas aussi souvent que les versions sont mises à jour ansible. Et chaque fois que vous devez conduire, la chaîne tombe ou la roue tombe. Cependant, la première partie, générer les configurations, fonctionne toujours très clairement, heureusement Jinja2 Le moteur est établi depuis longtemps. Mais la deuxième partie – le déploiement des configurations – apportait généralement des surprises. Et comme je dois déployer la configuration à distance sur une demi-centaine d'appareils, dont certains sont situés à des milliers de kilomètres, utiliser cet outil était un peu ennuyeux.

Ici, je dois admettre que mon incertitude réside très probablement dans mon manque de familiarité avec ansibleque dans ses défauts. Et c’est d’ailleurs un point important. ansible est un domaine de connaissances complètement distinct, avec son propre DSL (Domain Specific Language), qui doit être maintenu à un niveau de confiance. Eh bien, à ce moment-là ansible Il se développe assez rapidement et, sans égard particulier à la rétrocompatibilité, n'ajoute pas de confiance.

C’est pourquoi il n’y a pas si longtemps, une deuxième version du vélo a été mise en œuvre. Cette fois sur python, ou plutôt sur un cadre écrit en python et pour python intitulé Nornier

Donc - Nornier est un microframework écrit en python et pour python et conçu pour l'automatisation. La même chose que dans le cas de ansible, pour résoudre les problèmes ici, une préparation compétente des données est nécessaire, c'est-à-dire inventaire des hôtes et de leurs paramètres, mais les scripts ne sont pas écrits dans un DSL séparé, mais dans le même p[i|i]ton pas très ancien, mais très bon.

Regardons ce que c'est en utilisant l'exemple réel suivant.

Je dispose d'un réseau d'agences avec plusieurs dizaines de bureaux à travers le pays. Chaque bureau dispose d'un routeur WAN qui termine plusieurs canaux de communication provenant de différents opérateurs. Le protocole de routage est BGP. Les routeurs WAN sont disponibles en deux types : Cisco ISG ou Juniper SRX.

Maintenant la tâche : vous devez configurer un sous-réseau dédié à la vidéosurveillance sur un port séparé sur tous les routeurs WAN du réseau de succursales - annoncer ce sous-réseau dans BGP - configurer la limite de vitesse du port dédié.

Tout d'abord, nous devons préparer quelques modèles, sur la base desquels les configurations seront générées séparément pour Cisco et Juniper. Il est également nécessaire de préparer les données pour chaque point et les paramètres de connexion, c'est-à-dire collecter le même 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 sortent pas de nulle part. Il s'agit essentiellement de différences entre les configurations de travail qui étaient et étaient 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, nous n'avons besoin que de deux paramètres pour Juniper et de 3 paramètres pour Cisco. Les voici:

  • sinom
  • suffixe ips
  • asn

Nous devons maintenant définir ces paramètres pour chaque appareil, c'est-à-dire faire la même chose inventaire.

Pour inventaire Nous suivrons strictement la documentation Initialisation de Nornir

autrement dit, créons le même squelette de fichier :

.
├── config.yaml
├── inventory
│   ├── defaults.yaml
│   ├── groups.yaml
│   └── hosts.yaml

Le fichier config.yaml est le 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 indiquerons les principaux paramètres dans le fichier hôtes.yaml, groupe (dans mon cas, ce sont des identifiants/mots de passe) dans groupes.yamlet valeurs par défaut.yaml Nous n'indiquerons rien, mais vous devez y entrer trois moins - indiquant que c'est yaml le fichier est vide cependant.

Voici à quoi ressemble le fichier 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

C'est ce qui s'est passé inventaire pour notre tâche. Lors de l'initialisation, les paramètres des fichiers d'inventaire sont mappés au modèle objet Élément d'inventaire.

Sous le spoiler se trouve un 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 paraître un peu déroutant, surtout au début. Pour le comprendre, le mode interactif dans python.

 $ 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'

Et enfin, passons au script lui-même. Je n’ai pas de quoi être particulièrement fier ici. Je viens de prendre un exemple tout fait de Didacticiel et je l'ai utilisé presque inchangé. 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):
    # Transform inventory data to configuration via a template file
    r = task.run(task=text.template_file,
                 name="Base Configuration",
                 template="base.j2",
                 path=f"templates/{task.host.platform}")

    # Save the compiled configuration into a host variable
    task.host["config"] = r.result

    # Save the compiled configuration into a file
    with open(f"configs/{task.host.hostname}", "w") as f:
        f.write(r.result)

    # Deploy that configuration to the device using NAPALM
    task.run(task=networking.napalm_configure,
             name="Loading Configuration on the device",
             replace=False,
             configuration=task.host["config"])

nr = InitNornir(config_file="config.yaml", dry_run=True) # set dry_run=False, cross your fingers and run again

# run tasks
result = nr.run(task=config_and_deploy)
print_result(result)

Faites attention au paramètre dry_run=Vrai initialisation de l'objet en ligne nr.
Ici la même chose que dans ansible un test a été réalisé au cours duquel une 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 certain ; cela dépend de la prise en charge de l'appareil et de l'implémentation 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 fonctionnement à sec ou changez sa valeur en Faux.

Lorsque le script est exécuté, Nornir génère des journaux détaillés sur la console.

Sous le spoiler se trouve le résultat d’une exécution de combat 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Cacher les mots de passe dans ansible_vault

Au début de l'article, j'ai couru un peu sur ansible, mais ce n'est pas si grave. Je les aime vraiment Voûte comme, qui est conçu pour cacher les informations sensibles hors de vue. Et probablement beaucoup ont remarqué que nous avons tous les identifiants/mots de passe de tous les routeurs de combat étincelants sous forme ouverte dans un fichier. gorups.yaml. Ce n'est pas joli, bien sûr. Protégeons ces données avec Voûte.

Transférons les paramètres de groups.yaml vers creds.yaml et chiffrons-les 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

C'est si simple. Il reste à enseigner à nos Nornier-script pour récupérer et appliquer 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) # set dry_run=False, cross your fingers and run again

# enrich Inventory with the encrypted vault data
from ansible_vault import Vault
vault_password_file="inventory/vault.passwd"
vault_file="inventory/creds.yaml"
with open(vault_password_file, "r") as fp:
    password = fp.readline().strip()   
    vault = Vault(password)
    vaultdata = vault.load(open(vault_file).read())

for a in nr.inventory.hosts.keys():
    item = nr.inventory.hosts[a]
    item.username = vaultdata[item.groups[0]]['username']
    item.password = vaultdata[item.groups[0]]['password']
    #print("hostname={}, username={}, password={}n".format(item.hostname, item.username, item.password))

# run tasks
...

Bien entendu, vault.passwd ne doit pas être situé à côté de creds.yaml comme dans mon exemple. Mais c'est bien pour jouer.

C'est tout pour le moment. Il y a quelques autres articles à venir sur Cisco + Zabbix, mais il ne s'agit pas ici d'automatisation. Et dans un avenir proche, je prévois d'écrire sur RESTCONF dans Cisco.

Source: habr.com

Ajouter un commentaire