Automatisk generering og påfyldning af netværksenhedskonfigurationselementer ved hjælp af Nornir

Automatisk generering og påfyldning af netværksenhedskonfigurationselementer ved hjælp af Nornir

Hej Habr!

For nylig dukkede en artikel op her Mikrotik og Linux. Rutine og automatisering hvor et lignende problem blev løst ved hjælp af fossile midler. Og selvom opgaven er helt typisk, er der ikke noget lignende ved den på Habré. Jeg tør tilbyde min cykel til det respekterede IT-miljø.

Dette er ikke den første cykel til sådan en opgave. Den første mulighed blev implementeret for flere år siden tilbage i ansible version 1.x.x. Cyklen blev sjældent brugt og rustede derfor konstant. I den forstand at selve opgaven ikke opstår så ofte som versioner opdateres ansible. Og hver gang du skal køre, falder kæden af, eller hjulet falder af. Den første del, der genererer konfigurationer, fungerer dog altid meget tydeligt, heldigvis jinja2 Motoren er længe etableret. Men den anden del, udrulning af konfigurationerne, bragte normalt overraskelser. Og da jeg skal udrulle konfigurationen eksternt til et halvt hundrede enheder, hvoraf nogle er placeret tusindvis af kilometer væk, var det lidt kedeligt at bruge dette værktøj.

Her må jeg indrømme, at min usikkerhed højst sandsynligt ligger i min manglende kendskab til ansibleend i sine mangler. Og dette er i øvrigt en vigtig pointe. ansible er et helt separat, sit eget vidensområde med sit eget DSL (Domain Specific Language), som skal opretholdes på et sikkert niveau. Nå, det øjeblik det ansible Det udvikler sig ret hurtigt, og uden særlig hensyntagen til bagudkompatibilitet, tilføjer det ikke tillid.

Derfor blev der for ikke så længe siden implementeret en anden version af cyklen. Denne gang på python, eller rettere på en ramme skrevet i python og for python berettiget Nornir

Så - Nornir er en mikroramme skrevet i python og for python og designet til automatisering. Det samme som i tilfældet med ansible, for at løse problemer her kræves kompetent dataforberedelse, dvs. opgørelse over værter og deres parametre, men scripts er ikke skrevet i en separat DSL, men i samme ikke særlig gamle, men meget gode p[i|i]ton.

Lad os se på, hvad det er ved at bruge følgende live-eksempel.

Jeg har et filialnetværk med flere dusin kontorer i hele landet. Hvert kontor har en WAN-router, der afslutter flere kommunikationskanaler fra forskellige operatører. Routing-protokollen er BGP. WAN-routere kommer i to typer: Cisco ISG eller Juniper SRX.

Nu er opgaven: du skal konfigurere et dedikeret undernet til videoovervågning på en separat port på alle WAN-routere i filialnetværket - annoncere dette undernet i BGP - konfigurere hastighedsgrænsen for den dedikerede port.

Først skal vi forberede et par skabeloner, på grundlag af hvilke konfigurationer vil blive genereret separat for Cisco og Juniper. Det er også nødvendigt at udarbejde data for hvert punkt og forbindelsesparametre, dvs. samle det samme inventar

Klar skabelon til 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

Skabelon til 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

Skabeloner kommer selvfølgelig ikke ud af den blå luft. Disse er i det væsentlige forskelle mellem de arbejdskonfigurationer, der var og var efter at have løst opgaven på to specifikke routere af forskellige modeller.

Ud fra vores skabeloner ser vi, at for at løse problemet behøver vi kun to parametre til Juniper og 3 parametre til Cisco. her er de:

  • hvisnavn
  • ipsuffiks
  • ASN

Nu skal vi indstille disse parametre for hver enhed, dvs. gøre det samme opgørelse.

for opgørelse Vi vil nøje følge dokumentationen Initialisering af Nornir

det vil sige, lad os skabe det samme filskelet:

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

Config.yaml-filen er standard nornir-konfigurationsfilen

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

Vi vil angive hovedparametrene i filen hosts.yaml, gruppe (i mit tilfælde er disse logins/adgangskoder) i grupper.yaml, og i defaults.yaml Vi vil ikke angive noget, men du skal indtaste tre minusser der - hvilket indikerer, at det er det yaml filen er dog tom.

Sådan ser hosts.yaml ud:

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

Og her er groups.yaml:

---
cisco:
    platform: ios
    username: admin1
    password: cisco1

juniper:
    platform: junos
    username: admin2
    password: juniper2

Dette er, hvad der skete opgørelse til vores opgave. Under initialisering afbildes parametre fra lagerfiler til objektmodellen InventoryElement.

Under spoileren er et diagram over InventoryElement-modellen

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"
                }
            }
        }
    }
}

Denne model kan se lidt forvirrende ud, især i starten. For at finde ud af det, skal den interaktive tilstand ind 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'

Og endelig, lad os gå videre til selve manuskriptet. Jeg har ikke noget at være særlig stolt af her. Jeg tog lige et færdigt eksempel fra tutorial og brugte den næsten uændret. Sådan ser det færdige arbejdsscript ud:

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)

Vær opmærksom på parameteren dry_run=Sandt in-line objektinitialisering nr.
Her det samme som i ansible der er implementeret en testkørsel, hvor der oprettes forbindelse til routeren, en ny ændret konfiguration udarbejdes, som derefter valideres af enheden (men dette er ikke sikkert; det afhænger af enhedsunderstøttelsen og driverimplementeringen i NAPALM) , men den nye konfiguration anvendes ikke direkte. Til kampbrug skal du fjerne parameteren tørt løb eller ændre dens værdi til False.

Når scriptet udføres, udsender Nornir detaljerede logfiler til konsollen.

Under spoileren er resultatet af en kampkørsel på to testroutere:

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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Skjul adgangskoder i ansible_vault

I begyndelsen af ​​artiklen gik jeg lidt overbord ansible, men det er ikke så slemt. Jeg kan virkelig godt lide dem Vault som, som er designet til at skjule følsomme oplysninger ude af syne. Og sikkert mange har bemærket, at vi har alle logins/adgangskoder til alle kamproutere funklende i åben form i en fil gorups.yaml. Det er selvfølgelig ikke kønt. Lad os beskytte disse data med Vault.

Lad os overføre parametrene fra groups.yaml til creds.yaml og kryptere det med AES256 med en 20-cifret adgangskode:

$ 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

Så enkelt er det. Det er tilbage at lære vores Nornir-script for at hente og anvende disse data.
For at gøre dette, i vores script efter initialiseringslinjen nr = InitNornir(config_file=... tilføje følgende kode:

...
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
...

Selvfølgelig skal vault.passwd ikke være placeret ved siden af ​​creds.yaml som i mit eksempel. Men det er ok at spille.

Det er alt for nu. Der er et par flere artikler om Cisco + Zabbix på vej, men dette handler ikke en smule om automatisering. Og i den nærmeste fremtid planlægger jeg at skrive om RESTCONF i Cisco.

Kilde: www.habr.com

Tilføj en kommentar