
Cześć, Habr!
Niedawno pojawił się tutaj artykuł gdzie podobne zadanie rozwiązano z wykorzystaniem przestarzałych narzędzi. Choć zadanie jest całkowicie typowe, na Hackerze jakoś nie ma nic podobnego. Ośmielam się zaproponować szanowanemu społeczności IT mój własny pomysł.
To nie jest pierwszy pomysł na podobne zadanie. Pierwsza wersja została wdrożona kilka lat temu jeszcze na ansible wersji 1.x.x. Pomysł był rzadko używany i dlatego ciągle rdzewiał. W tym sensie, że samo zadanie nie pojawia się tak często, jak aktualizacje wersji ansible. I za każdym razem, gdy trzeba działać, to łańcuch spada, to koło odpada. Chociaż pierwsza część, generowanie konfiguracji — zawsze działa bardzo precyzyjnie, dzięki jinja2 ustabilizowanemu silnikowi. Ale druga część — wprowadzanie konfiguracji, zwykle przynosiła niespodzianki. A ponieważ wprowadzam konfiguracje zdalnie na kilkudziesięciu urządzeniach, z których niektóre znajdują się tysiące kilometrów stąd, korzystanie z tego narzędzia było nieco stresujące.
Trzeba przyznać, że moja niepewność raczej wynika z braku znajomości z ansible, niż z jego wad. I to, nawiasem mówiąc, jest ważny punkt. ansible — to zupełnie odrębna, własna dziedzina wiedzy z własnym DSL (Domain Specific Language), który trzeba utrzymywać na pewnym poziomie. No i to, że ansible dosyć szybko się rozwija, przy czym bez specjalnego uwzględnienia wstecznej kompatybilności, nie dodaje mi pewności.
Dlatego niedawno został zrealizowany drugi wariant pomysłu. Tym razem na python, a dokładniej na frameworku napisanym w python i dla python o nazwie
Tak więc — Nornir to mikroframework napisany w python i dla python i przeznaczony do automatyzacji. Tak jak w przypadku ansible, do rozwiązywania zadań tutaj potrzebne jest staranne przygotowanie danych, tzn. inwentaryzacja hostów i ich parametrów, a scenariusze pisze się nie w oddzielnym DSL, ale wszystko w tym samym, nieco starszym, ale bardzo sympatycznym [i|py]tonie.
Przyjrzyjmy się temu na następnym żywym przykładzie.
Mam sieć z kilkudziesięcioma biurami w całym kraju. W każdym biurze znajduje się router WAN, który termininuje kilka kanałów łączności od różnych operatorów. Protokół routingu — BGP. Routery WAN występują w dwóch typach: Cisco ISG lub Juniper SRX.
Teraz zadanie: konieczne jest skonfigurowanie na wszystkich routerach WAN w sieci oddziałowej wydzielonej podsieci dla monitoringu wideo na oddzielnym porcie — ogłoszenie tej podsieci w BGP — skonfigurowanie ograniczenia prędkości wydzielonego portu.
Najpierw musimy przygotować parę szablonów, na podstawie których będą generowane konfiguracje dla Cisco i Juniper. Należy również przygotować dane dla każdego punktu oraz parametry połączenia, czyli zebrać odpowiednie informacje.
Gotowy szablon dla 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 anySzablon dla Juniper:
$ cat templates/junos/base.j2
set interfaces {{ host.task_data.ifname }} unit 0 description "Monitoring wideo"
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 limiterSzablony, oczywiście, nie są wzięte znikąd. W zasadzie to różnice między aktualnymi konfiguracjami, które były przed rozwiązaniem postawionego zadania na dwóch konkretnych routerach różnych modeli.
Z naszych szablonów widzimy, że w celu rozwiązania problemu potrzebujemy dwóch parametrów dla Juniper i trzech parametrów dla Cisco. Oto one:
- ifname
- ipsuffix
- asn
Teraz musimy ustawić te parametry dla każdego urządzenia, czyli zrobić to, co trzeba. inventory.
Dla inventory Będziemy ściśle stosować się do dokumentacji.
czyli stworzymy taki sam szkielet plików:
.
├── config.yaml
├── inventory
│ ├── defaults.yaml
│ ├── groups.yaml
│ └── hosts.yamlPlik config.yaml — standardowy plik konfiguracyjny nornira.
$ 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"Podstawowe parametry będziemy podawać w pliku hosts.yaml, grupowe (w moim przypadku są to loginy/hasła) w groups.yaml, a w defaults.yaml nie będziemy nic podawać, ale należy wpisać trzy minusy — wskazujące, że to yaml plik, choć pusty.
Tak wygląda 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: 65111A tak wygląda groups.yaml:
---
cisco:
platform: ios
username: admin1
password: cisco1
juniper:
platform: junos
username: admin2
password: juniper2Tak to się udało inventory dla naszego zadania. Przy inicjalizacji parametry z plików inventory są mapowane na model obiektowy InventoryElement.
Pod spoiem schemat modelu 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"
}
}
}
}
}Ten model może wyglądać nieco skomplikowanie, zwłaszcza na początku. Do zrozumienia bardzo pomaga interaktywny tryb w 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'
A teraz przechodzimy do samego skryptu. Nie ma się czym specjalnie chwalić. Po prostu wziąłem gotowy przykład z i użyłem go niemal bez zmian. Oto jak wygląda gotowy działający skrypt:
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)Zwróć uwagę na parametr dry_run=True w linii inicjalizacja obiektu nr.
Tutaj, podobnie jak w ansible zrealizowany jest testowy przebieg, podczas którego następuje połączenie z routerem, przygotowywana jest nowa zmieniona konfiguracja, która następnie jest walidowana przez urządzenie (ale to nie pewne; zależy od wsparcia urządzenia i implementacji sterownika w NAPALM), jednak rzeczywiste zastosowanie nowej konfiguracji nie następuje. Aby użyć tego w produkcji, należy usunąć parametr dry_run lub zmienić jego wartość na Fałsz.
Podczas wykonywania skryptu Nornir wyświetla szczegółowe logi w konsoli.
Pod spoilerem znajduje się wynik działania testowego na dwóch testowych routerach:
config_and_deploy***************************************************************
* cisco-test ** zmieniono : True *******************************************
vvvv config_and_deploy ** zmieniono : True vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv INFO
---- Podstawowa konfiguracja ** zmieniono : 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 zezwól 10.10.222.0 0.0.0.255
access-list 111 zezwól ip 10.10.222.0 0.0.0.255 any
---- Ładowanie konfiguracji na urządzeniu ** zmieniono : 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 zezwól 10.10.222.0 0.0.0.255
+access-list 111 zezwól ip 10.10.222.0 0.0.0.255 any
^^^^ KONIEC config_and_deploy ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* srx-test ** zmieniono : True *******************************************
vvvv config_and_deploy ** zmieniono : True vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv INFO
---- Podstawowa konfiguracja ** zmieniono : 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
---- Ładowanie konfiguracji na urządzeniu ** zmieniono : 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;
+ }
+ }
+ }
+ }
^^^^ KONIEC config_and_deploy ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Ukrywamy hasła w ansible_vault
Na początku artykułu trochę się wyłamałem na ansible, ale tam nie wszystko jest takie złe. Bardzo mi się u nich vault podoba się, który ma na celu ukrycie wrażliwych informacji przed wzrokiem. I zapewne wiele osób zauważyło, że wszystkie nasze loginy/hasła do wszystkich produkcyjnych routerów lśnią w otwartym widoku w pliku gorups.yaml. To oczywiście nieestetyczne. Zabezpieczmy te dane za pomocą vault.
Przeniesiemy parametry z groups.yaml do creds.yaml i zaszyfrujemy go AES256 z 20-znakowym hasłem:
$ 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
Szyfrowanie zakończone powodzeniem
$ cat creds.yaml
$ANSIBLE_VAULT;1.1;AES256
39656463353437333337356361633737383464383231366233386636333965306662323534626131
3964396534396333363939373539393662623164373539620a346565373439646436356438653965
39643266333639356564663961303535353364383163633232366138643132313530346661316533
6236306435613132610a656163653065633866626639613537326233653765353661613337393839
62376662303061353963383330323164633162386336643832376263343634356230613562643533
30363436343465306638653932366166306562393061323636636163373164613630643965636361
34343936323066393763323633336366366566393236613737326530346234393735306261363239
35663430623934323632616161636330353134393435396632663530373932383532316161353963
31393434653165613432326636616636383665316465623036376631313162646435To takie proste. Pozostało tylko nauczyć nasz Nornir-skrypt pobierać i stosować te dane.
W tym celu w naszym skrypcie po linii inicjalizacyjnej nr = InitNornir(config_file=… dodajemy następujący kod:
...
nr = InitNornir(config_file="config.yaml", dry_run=True) # ustaw dry_run=False, trzymaj kciuki i uruchom ponownie
# wzbogacenie inwentarza danymi z zaszyfrowanego skarbca
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))
# uruchom zadania
...Oczywiście vault.passwd nie powinien leżeć obok creds.yaml, jak w moim przykładzie. Ale do zabawy wystarczy.
Na tym na razie wszystko. Wkrótce pojawi się jeszcze kilka artykułów o Cisco + Zabbix, ale to trochę nie o automatyzacji. A w niedalekiej przyszłości planuję napisać o RESTCONF w Cisco.
Źródło: habr.com
