Автогенерация и качване на елементи от конфигурации на мрежови устройства с помощта на Nornir

Автогенерация и качване на елементи от конфигурации на мрежови устройства с помощта на Nornir

Здравей, Хабр!

Наскоро се появи статия Mikrotik и Linux. Рутинни и автоматизация където подобна задача се решаваше с примитивни средства. И въпреки че задачата е напълно типична, на Хабр не се намира нищо подобно. Позволявам си да предложа на уважаваното ИТ-общество моя велосипед.

Това не е първият велосипед за подобна задача. Първият вариант беше реализиран преди няколко години на ansible версия 1.x.x. Велосипедът се използваше рядко и затова постоянно ръждясваше. В този смисъл, самата задача не възниква толкова често, колкото се обновяват версиите ansible. И всеки път, когато се наложи да пътувам, или веригата пада, или колелото се разпада. Впрочем, първата част, генерирането на конфигурации, работи винаги много точно, благодарение на jinja2 движка, който е устойчива традиция. А втората част — разгръщането на конфигурациите обикновено представя изненади. А тъй като трябва да разгръщам конфиг на половин стотина устройства, някои от които се намират на хиляди километри, да ползвам този инструмент ми беше малко некомфортно.

Тук трябва да призная, че моята несигурност по-скоро е в недостатъчното ми запознаване с ansible, отколкото в неговите недостатъци. И това, между другото, е важен момент. ansible — това е напълно отделна, собствена област на знания с собствен DSL (Domain Specific Language), който е необходимо да поддържате на увереното ниво. И другият момент е, че ansible се развива доста бързо, без особено внимание на обратна съвместимост, което не добавя увереност.

Така че не толкова отдавна беше реализиран вторият вариант на велосипеда. Този път на python, а именно на рамка, написана на python и за python с имената Nornir

И така — Nornir това е микрофреймок, написан на python и за python и предназначен за автоматизация. Както и в случая с ansible, за решаване на задачи тук е необходимо разумно подготвяне на данни, т.е. инвентаризация на хостове и техните параметри, а сценарии се пишат не на отделен DSL, а на същия не особено стар, но много добър Python.

Нека разгледаме какво представлява това на следващия жив пример.

Имам филиална мрежа с няколко десетки офиса из цялата страна. Във всеки офис има WAN-маршрутизатор, който терминира няколко канала от различни оператори. Протокол на маршрутизацията — BGP. WAN-маршрутизаторите са от два типа: Cisco ISG или Juniper SRX.

Сега задачата е: необходимо да конфигурираме на всички WAN маршрутизатори на филиалната мрежа отделна подсет за Видеонаблюдение на отделен порт — да анонсираме тази подсет в BGP — да конфигурираме лимит на скоростта на отделния порт.

Първо трябва да подготвим двойка шаблони, на базата на които ще бъдат генерирани конфигурации поотделно за Cisco и Juniper. Също така трябва да подготвим данни за всяка точка и параметри на свързването, т.е. да съберем онези инвентаризации.

Готов шаблон за 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 и три параметъра за Cisco. Ето ги:

  • ifname
  • ipsuffix
  • asn

Сега трябва да зададем тези параметри за всяко устройство, т.е. да направим онова inventory.

За inventory ще следваме точно документацията 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 няма да посочваме нищо, но трябва да включим три минуса — показващи, че това е 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 за нашата задача. При инициализация параметрите от 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"
                }
            }
        }
    }
}

Този модел може да изглежда малко объркващ, особено в началото. За да се ориентирате, много помага интерактивният режим в ipython.

 $ ipython3
Python 3.6.9 (по подразбиране, 7 ноември 2019, 10:44:02) 
Напишете 'copyright', 'credits' или 'license' за повече информация
IPython 7.1.1 -- Разширен интерактивен Python. Напишете '?' за помощ.

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):
    # Преобразува данните от инвентара в конфигурация чрез файл шаблон
    r = task.run(task=text.template_file,
                 name="Основна конфигурация",
                 template="base.j2",
                 path=f"templates/{task.host.platform}")

    # Записва компилираната конфигурация в променлива на хоста
    task.host["config"] = r.result

    # Записва компилираната конфигурация в файл
    with open(f"configs/{task.host.hostname}", "w") as f:
        f.write(r.result)

    # Разгръща тази конфигурация на устройството с NAPALM
    task.run(task=networking.napalm_configure,
             name="Зареждане на конфигурацията на устройството",
             replace=False,
             configuration=task.host["config"])

nr = InitNornir(config_file="config.yaml", dry_run=True) # задайте dry_run=False, кръстосайте пръстите и стартирайте отново

# стартирайте задачите
result = nr.run(task=config_and_deploy)
print_result(result)

Обърнете внимание на параметъра dry_run=True в реда за инициализация на обекта nr.
Тук също като в ansible е реализиран тестов прогон, при който се свързва с маршрутизатора, подготвя се нова променена конфигурация, която след това се валидира от устройството (но не е сигурно; зависи от поддръжката на устройството и реализирането на драйвера в NAPALM), но самото прилагане на новата конфигурация не се извършва. За реално приложение е необходимо да се премахне параметърът dry_run или да се смени стойността му на False.

При изпълнението на сценария Nornir дава подробни логове в конзолата.

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

конфигуриране_и_разгръщане***************************************************************
* cisco-test ** променен : Истина *******************************************
vvvv конфигуриране_и_разгръщане ** променен : Истина vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv ИНФО
---- Основна Конфигурация ** променена : Истина ------------------------------------- ИНФО
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
  описание VIDEOSURV
  ip адрес 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 позволи 10.10.222.0 0.0.0.255
access-list 111 позволи ip 10.10.222.0 0.0.0.255 всеки
---- Зареждане на конфигурацията на устройството ** променено : Истина --------------------- ИНФО
+class-map match-all VIDEO_SURV
+ match access-group 111
+policy-map VIDEO_SURV
+ class VIDEO_SURV
+interface GigabitEthernet0/1/1
+  описание VIDEOSURV
+  ip адрес 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 позволи 10.10.222.0 0.0.0.255
+access-list 111 позволи ip 10.10.222.0 0.0.0.255 всеки
^^^^ КРАЙ конфигуриране_и_разгръщане ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* srx-test ** променен : Истина *******************************************
vvvv конфигуриране_и_разгръщане ** променен : Истина vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv ИНФО
---- Основна Конфигурация ** променена : Истина ------------------------------------- ИНФО
set interfaces fe-0/0/2 unit 0 описание "Видеонаблюдение"
set interfaces fe-0/0/2 unit 0 family inet filter input limit-in
set interfaces fe-0/0/2 unit 0 family inet адрес 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
---- Зареждане на конфигурацията на устройството ** променено : Истина --------------------- ИНФО
[редактиране на интерфейси]
+   fe-0/0/2 {
+       unit 0 {
+           описание "Видеонаблюдение";
+           family inet {
+               filter {
+                   input limit-in;
+               }
+               адрес 10.10.111.254/24;
+           }
+       }
+   }
[редактиране]
+  policy-options {
+      policy-statement export2bgp {
+          term 1 {
+              from {
+                  route-filter 10.10.111.0/24 exact;
+              }
+          }
+      }
+  }
[редактиране на зони за сигурност]
     security-zone test-vpn { ... }
+    security-zone WAN {
+        интерфейси {
+            fe-0/0/2.0;
+        }
+    }
[редактиране]
+  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;
+              }
+          }
+      }
+  }
^^^^ КРАЙ конфигуриране_и_разгръщане ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Скриваме паролите в ansible_vault

В началото на статията малко критикувах ansible, но там не всичко е толкова лошо. Много ми харесват vault Това е удобно решение, предназначено за скриване на чувствителна информация от очите. Вероятно много от вас са забелязали, че всичките ни логини/пароли за всички производствени рутери блестят на открито в файла. gorups.yaml. Това определено не е красиво. Нека защитим тези данни с помощта на vault.

Преместваме параметрите от 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  
Шифроването е успешно
$ 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) # задайте dry_run=False, кръстосайте пръсти и стартирайте отново

# обогатете инвентара с данните от криптирания трезор
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))

# изпълнете задачите
...

Разбира се, vault.passwd не трябва да бъде до creds.yaml, както в моят пример. Но за да поиграете, ще свърши работа.

За сега това е всичко. На път са още няколко статии за Cisco + Zabbix, но това е малко извън автоматизацията. А в близко бъдеще планирам да напиша за RESTCONF в Cisco.

Източник: habr.com

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster