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

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

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

Тут надо признать, что моя неуверенность, скорей кроется в недостаточном знакомсте меня с ansible, чем в его недостатках. И вот это, кстати, важный момент. ansible — это совершенно отдельная, своя собственная область знаний со своим собственным DSL (Domain Specific Language), который необходимо поддерживать на уверенном уровне. Ну и тот момент, что ansible достаточно быстро развивается, причем без особой оглядки на обратную совместимость, уверенности не добавляет.

Поэтому не так давно был реализован второй вариант велосипеда. На это раз на python, а точнее на фреймворке, написанном на python и для python под названием Nornir

Итак — Nornir это микрофреймок, написанный на python и для python и предназначенный для автоматизации. Так же как и в случае с 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
• asn

Теперь нам необходимо задать эти параметры для каждого устройства, т.е. сделать то самое inventory.

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

т.е создадим такой же файловый скелет:

.
+-- config.yaml
+-- inventory
¦   +-- defaults.yaml
¦   +-- groups.yaml
¦   L-- 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.

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 (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), но непосредственно применения новой конфигурации не происходит. Для боевого применения необходимо убрать параметр dry_run либо сменить его значение на False.

При выполнении сценария 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, но там не все так плохо. Очень мне у них vault нравится, который предназначен для сокрытия чуствительной информации с глаз долой. И наверное многие заметили, что у нас все логины/пароли ко всем боевым маршрутизаторам сверкают в отрытом виде в файле gorups.yaml. Некрасиво это конечно. Давайте защитим эти данные с помощью vault.

Перенесем параметры из groups.yaml в creds.yaml, и зашифруем его AES256 c 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.