Automatisk generering och fyllning av nätverksenhetskonfigurationselement med Nornir

Automatisk generering och fyllning av nätverksenhetskonfigurationselement med Nornir

Hej Habr!

Nyligen dök det upp en artikel här Mikrotik och Linux. Rutin och automatisering där ett liknande problem löstes med fossila medel. Och även om uppgiften är helt typisk så finns det inget liknande med den på Habré. Jag vågar erbjuda min cykel till den respekterade IT-gemenskapen.

Detta är inte den första cykeln för en sådan uppgift. Det första alternativet implementerades för flera år sedan tillbaka in ansible version 1.x.x. Cykeln användes sällan och rostade därför konstant. I den meningen att själva uppgiften inte uppstår så ofta som versioner uppdateras ansible. Och varje gång du behöver köra faller kedjan av eller hjulet. Men den första delen, att generera konfigurationer, fungerar alltid väldigt tydligt, lyckligtvis jinja2 Motorn är sedan länge etablerad. Men den andra delen - att rulla ut konfigurationer - gav vanligtvis överraskningar. Och eftersom jag måste rulla ut konfigurationen på distans till ett halvt hundra enheter, av vilka några finns tusentals kilometer bort, var det lite tråkigt att använda det här verktyget.

Här måste jag erkänna att min osäkerhet med största sannolikhet ligger i min bristande förtrogenhet med ansibleän i sina brister. Och detta är förresten en viktig punkt. ansible är ett helt separat, sitt eget kunskapsområde med sitt eget DSL (Domain Specific Language), som måste hållas på en säker nivå. Tja, det där ögonblicket ansible Det utvecklas ganska snabbt, och utan särskild hänsyn till bakåtkompatibilitet, ger det inget förtroende.

Därför implementerades en andra version av cykeln för inte så länge sedan. Den här gången på pytonorm, eller snarare på en ram skriven i pytonorm och för pytonorm med titeln Nornir

Så - Nornir är en mikroram skriven i pytonorm och för pytonorm och designad för automatisering. Samma som i fallet med ansible, för att lösa problem här krävs kompetent dataförberedelse, d.v.s. inventering av värdar och deras parametrar, men skript skrivs inte i en separat DSL, utan i samma inte särskilt gamla, men mycket bra p[i|i]ton.

Låt oss titta på vad det är med följande liveexempel.

Jag har ett filialnät med flera dussin kontor över hela landet. Varje kontor har en WAN-router som terminerar flera kommunikationskanaler från olika operatörer. Routingprotokollet är BGP. WAN-routrar finns i två typer: Cisco ISG eller Juniper SRX.

Nu är uppgiften: du måste konfigurera ett dedikerat subnät för videoövervakning på en separat port på alla WAN-routrar i filialnätverket - annonsera detta subnät i BGP - konfigurera hastighetsgränsen för den dedikerade porten.

Först måste vi förbereda ett par mallar, på grundval av vilka konfigurationer kommer att genereras separat för Cisco och Juniper. Det är också nödvändigt att förbereda data för varje punkt och anslutningsparametrar, d.v.s. samla in samma inventarier

Färdig mall för 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

Mall för 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

Mallar kommer naturligtvis inte ur tomma luften. Dessa är i huvudsak skillnader mellan de fungerande konfigurationerna som var och var efter att ha löst uppgiften på två specifika routrar av olika modeller.

Från våra mallar ser vi att för att lösa problemet behöver vi bara två parametrar för Juniper och 3 parametrar för Cisco. här är de:

  • ifname
  • ipsuffix
  • ASN

Nu måste vi ställa in dessa parametrar för varje enhet, dvs. gör samma sak lager.

för lager Vi kommer att följa dokumentationen strikt Initierar Nornir

det vill säga, låt oss skapa samma filskelett:

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

Filen config.yaml är standardkonfigurationsfilen för 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"

Vi kommer att ange huvudparametrarna i filen hosts.yaml, grupp (i mitt fall är dessa inloggningar/lösenord) i grupper.yaml, och i defaults.yaml Vi kommer inte att indikera något, men du måste ange tre minus där - vilket indikerar att det är det jaml filen är dock tom.

Så här ser hosts.yaml ut:

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

Och här är groups.yaml:

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

juniper:
    platform: junos
    username: admin2
    password: juniper2

Det här är vad som hände lager för vår uppgift. Under initiering mappas parametrar från inventeringsfiler till objektmodellen InventoryElement.

Nedanför spoilern finns ett diagram över 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"
                }
            }
        }
    }
}

Denna modell kan se lite förvirrande ut, särskilt i början. För att ta reda på det, det interaktiva läget in pytonorm.

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

Och slutligen, låt oss gå vidare till själva manuset. Jag har inget att vara särskilt stolt över här. Jag tog bara ett färdigt exempel från handledning och använde den nästan oförändrad. Så här ser det färdiga arbetsskriptet ut:

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)

Var uppmärksam på parametern dry_run=Sant in-line objektinitiering nr.
Här samma som i ansible en testkörning har genomförts där en anslutning till routern görs, en ny modifierad konfiguration förbereds, som sedan valideras av enheten (men detta är inte säkert; det beror på enhetsstödet och drivrutinsimplementeringen i NAPALM) , men den nya konfigurationen tillämpas inte direkt. För stridsanvändning måste du ta bort parametern torrkörning eller ändra dess värde till Falsk.

När skriptet körs matar Nornir ut detaljerade loggar till konsolen.

Under spoilern är resultatet av en stridskörning på två testroutrar:

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

Döljer lösenord i ansible_vault

I början av artikeln sprang jag lite på ansible, men det är inte så illa. jag tycker verkligen om dem Vault som, som är utformad för att dölja känslig information utom synhåll. Och säkert har många märkt att vi har alla inloggningar/lösenord för alla stridsroutrar gnistrande i öppen form i en fil gorups.yaml. Det är inte snyggt såklart. Låt oss skydda denna data med Vault.

Låt oss överföra parametrarna från groups.yaml till creds.yaml och kryptera den med AES256 med ett 20-siffrigt lösenord:

$ 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

Det är så enkelt. Det återstår att lära våra Nornir-skript för att hämta och tillämpa dessa data.
För att göra detta, i vårt skript efter initialiseringsraden nr = InitNornir(config_file=... lägg till följande kod:

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

Naturligtvis ska vault.passwd inte placeras bredvid creds.yaml som i mitt exempel. Men det är ok att spela.

Det var allt tills vidare. Det kommer ett par artiklar till om Cisco + Zabbix, men det här handlar inte lite om automatisering. Och inom en snar framtid planerar jag att skriva om RESTCONF i Cisco.

Källa: will.com

Lägg en kommentar