Hallo habr
Kürzlich ist hier ein Artikel von Mikrotik und Linux erschienen. Routine und Automatisierung, bei der ein ähnliches Problem mit fossilen Mitteln gelöst wurde. Und obwohl die Aufgabe ganz typisch ist, gibt es bei Habré nichts Vergleichbares. Ich wage es, mein Fahrrad der angesehenen IT-Community anzubieten.
Dies ist nicht das erste Fahrrad für diese Aufgabe. Die erste Option wurde vor einigen Jahren in Version 1.x.x implementiert. Das Fahrrad wurde selten benutzt und daher ständig verrostet. In dem Sinne, dass die Aufgabe selbst nicht so häufig auftritt wie aktualisierte Versionen von Ansible . Und jedes Mal, wenn Sie gehen müssen, wird die Kette fallen, das Rad wird herunterfallen. Der erste Teil, die Generierung von Configs, funktioniert jedoch immer sehr übersichtlich, da die Engine für jinja2 schon lange etabliert ist . Aber der zweite Teil - Configs rollen, brachte in der Regel Überraschungen. Und da ich die Konfiguration aus der Ferne auf Hunderte von Geräten ausrollen muss, von denen einige Tausende von Kilometern entfernt sind, war es ein bisschen ärgerlich, dieses Tool zu verwenden.
Hier muss ich zugeben, dass meine Unsicherheit eher in der mangelnden Vertrautheit mit mir als in seinen Mängeln liegt. Und das ist übrigens ein wichtiger Punkt. ansible ist eine völlig eigenständige Wissensdomäne mit eigener DSL (Domain Specific Language), die auf einem verlässlichen Niveau gehalten werden muss. Nun, der Moment, in dem sich Ansible recht schnell und ohne besondere Rücksicht auf die Abwärtskompatibilität entwickelt, schafft kein zusätzliches Vertrauen.
Daher wurde vor nicht allzu langer Zeit die zweite Version des Fahrrads implementiert. Diesmal in Python oder besser gesagt in einem Framework, das in Python geschrieben wurde, und für Python namens Nornir
Also - Nornir ist ein in Python und für Python geschriebenes Mikroframework, das für die Automatisierung vorgesehen ist. Wie im Fall von Ansible ist hier zur Lösung von Problemen eine kompetente Datenaufbereitung erforderlich, d.h. Inventar der Hosts und ihrer Parameter, aber die Skripte sind nicht auf einem separaten DSL geschrieben, sondern alle auf dem gleichen, nicht sehr alten, aber sehr guten Ton [und | ah].
Schauen wir uns das folgende Beispiel an.
Ich habe ein Filialnetz mit mehreren Dutzend Niederlassungen im ganzen Land. In jedem Büro gibt es einen WAN-Router, der mehrere Kommunikationskanäle von verschiedenen Betreibern terminiert. Das Routing-Protokoll ist BGP. Es gibt zwei Arten von WAN-Routern: Cisco ISG oder Juniper SRX.
Nun die Aufgabe: Es ist notwendig, ein dediziertes Subnetz für die Videoüberwachung in einem separaten Port auf allen WAN-Routern des Filialnetzes zu konfigurieren - dieses Subnetz in BGP ankündigen - die Geschwindigkeitsbegrenzung für den dedizierten Port konfigurieren.
Zunächst müssen wir einige Vorlagen vorbereiten, auf deren Grundlage Konfigurationen für Cisco und Juniper separat generiert werden. Und es ist auch notwendig, Daten für jeden Punkt und Verbindungsparameter vorzubereiten, d.h. dieses Inventar zu sammeln
Fertigvorlage 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
Vorlage 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
Vorlagen werden natürlich nicht von der Decke genommen. Dies ist im Wesentlichen der Unterschied zwischen den Arbeitskonfigurationen - er wurde nach der Lösung der Aufgabe auf zwei spezifischen Routern verschiedener Modelle.
Aus unseren Vorlagen geht hervor, dass zur Lösung des Problems zwei Parameter für Juniper und drei Parameter für Cisco ausreichen. hier sind sie:
Jetzt müssen wir diese Parameter für jedes Gerät einstellen, d.h. mache das gleiche Inventar .
Für die Inventarisierung folgen wir eindeutig der Dokumentation zu Initializing Nornir.
d.h. dasselbe Dateiskelett erstellen:
. ├── config.yaml ├── inventory │ ├── defaults.yaml │ ├── groups.yaml │ └── hosts.yaml
Config.yaml-Datei - Standard-Konfigurationsdatei
$ 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"
Wir werden die Hauptparameter in der Datei hosts.yaml , group (in meinem Fall usernames / passwords) in groups.yaml angeben , und wir werden in defaults.yaml nichts angeben, aber es müssen drei Minuspunkte vorhanden sein, um anzuzeigen, dass dies eine yaml- Datei ist wenn auch leer.
So sieht hosts.yaml aus:
--- 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
Und hier ist groups.yaml:
--- cisco: platform: ios username: admin1 password: cisco1 juniper: platform: junos username: admin2 password: juniper2
Hier ist das Inventar für unsere Aufgabe. Während der Initialisierung werden Parameter aus den Inventardateien dem InventoryElement- Objektmodell zugeordnet.
Unter dem Spoiler das InventoryElement-Modelldiagramm 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" } } } } }
Dieses Modell sieht vor allem auf den ersten Blick etwas verwirrend aus. Der interaktive Modus in ipython hilft sehr dabei, dies herauszufinden.
$ 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'
Nun, lasst uns endlich zum Skript selbst übergehen. Es gibt nichts Besonderes für mich, auf das ich stolz sein kann. Ich habe gerade das fertige Beispiel aus dem Tutorial genommen und es fast unverändert verwendet. So sieht das fertige Arbeitsskript aus:
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):
Beachten Sie den Parameter dry_run = True in der Initialisierungszeile des Objekts nr .
Hier wird genau wie in Ansible ein Testlauf durchgeführt, bei dem die Verbindung zum Router hergestellt wird, eine neue geänderte Konfiguration vorbereitet wird, die dann vom Gerät validiert wird (dies ist jedoch nicht genau; es hängt von der Unterstützung des Geräts und der Treiberimplementierung in NAPALM ab), die neue Konfiguration wird jedoch nicht direkt angewendet . Für den Kampf müssen Sie den Parameter dry_run entfernen oder seinen Wert in False ändern.
Wenn das Skript ausgeführt wird, zeigt Nornir der Konsole detaillierte Protokolle an.
Unter dem Spoiler läuft der Abschluss des Kampfes auf zwei Testroutern: 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Passwörter in ansible_vault verstecken
Am Anfang des Artikels bin ich ein bisschen auf Ansible gestoßen , aber dort ist nicht alles so schlimm. Ich mag ihren Tresor , der sensible Informationen versteckt. Und wahrscheinlich ist vielen aufgefallen, dass wir alle Benutzernamen / Passwörter für alle Kampfrouter in der Datei groups.yaml in offener Form haben . Es ist natürlich hässlich. Lassen Sie uns diese Daten mit Tresor schützen.
Wir übertragen die Parameter von groups.yaml nach creds.yaml und verschlüsseln sie mit AES256 mit einem 20-stelligen Passwort:
$ 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
So einfach. Es bleibt unserem Nornir- Skript beizubringen, diese Daten zu erhalten und zu verwenden.
Fügen Sie dazu in unserem Skript nach der Initialisierungszeile nr = InitNornir (config_file = ... den folgenden Code hinzu:
... nr = InitNornir(config_file="config.yaml", dry_run=True)
Natürlich sollte vault.passwd nicht wie in meinem Beispiel neben creds.yaml liegen. Aber es zu spielen wird genügen.
Das ist alles für jetzt. Ein paar Artikel über Cisco + Zabbix sind in Vorbereitung, aber hier geht es nicht um Automatisierung. Und in naher Zukunft werde ich in Cisco über RESTCONF schreiben.