Автогенерація та заливка елементів конфігурацій мережевих пристроїв за допомогою Nornir

Автогенерація та заливка елементів конфігурацій мережевих пристроїв за допомогою Nornir

Привіт, Хабре!

Нещодавно тут проскочила стаття Mikrotik та Linux. Рутина та автоматизація де подібне завдання вирішували викопними засобами. І хоча завдання цілком типове, на Хабре про неї якось нічого подібного і не знаходиться. Насмілюсь запропонувати шановній ІТ-спільноті свій велосипед.

Це не перший велосипед для такого завдання. Перший варіант був реалізований кілька років тому ще на ansible версії 1.x.х. Велосипед використовувався рідко і тому постійно іржавів. У тому сенсі, що саме завдання виникає не так часто, як оновлюються версії ansible. І щоразу коли треба їхати, то ланцюг спаде, то колесо відвалиться. Втім перша частина, генерація конфігів - відпрацьовує завжди дуже чітко, добре jinja2 двигун давно усталений. А ось друга частина — розкочування конфігів, як правило, давала сюрпризи. А оскільки розкочувати конфіг мені доводиться віддалено на півсотні пристроїв, деякі з яких знаходяться в тисячах кілометрів, то користуватися цим інструментом було трохи сикотно.

Тут треба визнати, що моя невпевненість, скоріше криється в недостатньому знайомстві мене з ansible, ніж у його недоліках. І це, до речі, важливий момент. ansible - Це абсолютно окрема, своя власна область знань зі своїм власним DSL (Domain Specific Language), який необхідно підтримувати на певному рівні. Ну і той момент, що ansible досить швидко розвивається, причому без особливого огляду на зворотну сумісність, впевненості не додає.

Тому нещодавно було реалізовано другий варіант велосипеда. Цього разу на пітон, а точніше на фреймворку, написаному на пітон і для пітон під назвою Nornir

Отже - Nornir це мікрофреймок, написаний на пітон і для пітон та призначений для автоматизації. Так само як і у випадку з ansible, На вирішення завдань тут потрібна грамотна підготовка даних тобто. інвентаризації хостів та їх параметрів, а ось сценарії пишуться не на окремому DSL, а все на тому ж не дуже старому, але дуже доброму п[і|ай] тоні.

Давайте розглянемо, що воно таке на наступному живому прикладі.

Є в мене мережа філій з кількома десятками офісів по всій країні. У кожному офісі існує WAN-маршрутизатор, який термінує кілька каналів зв'язку різних операторів. Протокол маршрутизації – BGP. WAN-маршрутизатори бувають двох типів: Cisco ISG чи Juniper SRX.

Тепер завдання: необхідно налаштувати на всіх WAN-маршрутизаторах філіальної мережі виділену підмережу для відеоспостереження в окремому порту - анонсувати цю підмережу в BGP - налаштувати обмеження швидкості виділеного порту.

Спочатку нам необхідно підготувати пару шаблонів, на основі яких генеруватимуться конфігурації окремо за Cisco та Juniper. Також необхідно підготувати дані з кожної точці і параметри підключення тобто. зібрати те саме inventory

Готовий шаблон для 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

Шаблон для 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

Шаблони, звичайно, беруться не зі стелі. Це по суті diff-и між робочими конфігураціями було-стало після вирішення поставленого завдання на двох конкретних маршрутизаторах різних моделей.

З наших шаблонів ми бачимо, що нам для вирішення завдання достатньо двох параметрів для Juniper та 3 параметри для Cisco. ось вони:

  • ifname
  • ipsuffix
  • асн

Тепер необхідно задати ці параметри кожному за пристрою, тобто. зробити те саме інвентаризація.

Для інвентаризація будемо чітко дотримуватись документації Initializing Nornir

тобто створимо такий же файловий скелет:

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

Файл config.yaml – стандартний файл конфігурації 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"

Основні параметри будемо вказувати у файлі hosts.yaml, групові (у моєму випадку це логіни/паролі) в groups.yaml, А в defaults.yaml нічого вказувати не будемо, але туди необхідно вписати три мінуси — вказівки на те, що це ямл файл хоч і порожній.

Ось так виглядає 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

А ось так groups.yaml:

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

juniper:
    platform: junos
    username: admin2
    password: juniper2

Ось таке впало інвентаризація для нашого завдання. При ініціалізації параметри з файлів inventory мапяться на об'єктну модель InventoryElement.

Під спойлером схема моделі 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"
                }
            }
        }
    }
}

Ця модель може виглядати трохи заплутаною, особливо спочатку. Для того щоб розібратися дуже допомагає інтерактивний режим пітон.

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

Ну і нарешті переходимо до скрипту. Тут мені особливо пишатися нема чим. Я просто взяв готовий приклад з туторіалу і майже без змін його використав. Ось так виглядає готовий робочий скрипт:

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)

Зверніть увагу на параметр dry_run=True у рядку ініціалізація об'єкта nr.
Тут так само як і в ansible реалізований тестовий прогін, при якому відбувається з'єднання з маршрутизатором, готується нова змінена конфігурація, яка потім валідується пристроєм (але це не точно; залежить від підтримки пристроєм та реалізації драйвера в NAPALM), але безпосередньо застосування нової конфігурації не відбувається. Для бойового застосування необхідно усунути параметр сухий_біг або змінити його значення на Помилковий.

При виконанні сценарію Nornir видає до консолі докладні логи.

Під спойлером виведення бойового прогону на двох тестових машрутизаторах:

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

Ховаємо паролі в ansible_vault

На початку статті я трохи наїхав на ansibleале там не все так погано. Дуже мені в них склепіння подобається, який призначений для приховування чутливої ​​інформації з очей геть. І напевно багато хто помітив, що у нас всі логіни/паролі до всіх бойових маршрутизаторів сяють у відритому вигляді у файлі gorups.yaml. Некрасиво це звичайно. Давайте захистимо ці дані за допомогою склепіння.

Перенесемо параметри з groups.yaml в creds.yaml і зашифруємо його AES256 з 20-значним паролем:

$ 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

Так просто. Залишилося навчити наш Nornir-Скрипт діставати та застосовувати ці дані.
Для цього у нашому скрипті після рядка ініціалізації nr = InitNornir(config_file=… додаємо наступний код:

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

Зрозуміло, vault.passwd не повинен лежати поряд з creds.yaml як у моєму прикладі. Але для погратись зійде.

На цьому поки що все. На підході ще кілька статей про Cisco + Zabbix, але це трохи не про автоматизацію. А в недалекому майбутньому планую написати про RESTCONF у Cisco.

Джерело: habr.com

Додати коментар або відгук