Lassen Sie uns angesichts der in Ansible Engine 2.6 implementierten signifikanten Verbesserungen sowie der Veröffentlichung von Ansible Tower 3.3 und der jüngsten Version von Ansible Engine 2.7 die Aussichten für die Netzwerkautomatisierung genauer betrachten.
In diesem Beitrag:
- Httpapi Verbindungs-Plugin.
- Unterstützung für Arista eAPI und Cisco NX-API.
- Neue Netzwerkautomatisierungsmodule.
- net_get und net_put.
- netconf_get, netconf_rpc und netconf_config.
- cli_command und cli_config.
- Verbesserte Ansible Tower-Weboberfläche.
- Verwalten Sie Anmeldeinformationen in Ansible Tower, wenn Sie mit Netzwerkgeräten arbeiten.
- Verwenden verschiedener Versionen von Ansible in Tower gleichzeitig
Vergessen Sie nicht, dass die Veröffentlichung jeder neuen Version von Ansible von einem Update
des Portierungshandbuchs begleitet wird , das den Übergang zur neuen Version erheblich erleichtert.
HTTPAPI-Verbindungs-Plugin
Verbindungs-Plugins ermöglichen es Ansible, eine Verbindung zu Zielhosts herzustellen und dann Aufgaben auf diesen auszuführen. Ab Ansible 2.5 ist ein neues Plugin dieses Typs namens network_cli erschienen. Die Verwendung des Provider-Parameters entfällt und die Ausführungsreihenfolge von Netzwerkmodulen wird standardisiert. Dadurch werden Playbooks für Netzwerkgeräte jetzt genauso ausgeführt, ausgeführt und funktionieren wie Playbooks für Linux-Hosts. Bei Ansible Tower verschwindet wiederum der Unterschied zwischen Netzwerkgeräten und Hosts, und es muss nicht mehr zwischen Benutzernamen und Kennwörtern für Netzwerkgeräte und Computer unterschieden werden. Dies wurde
hier ausführlicher besprochen, aber kurz gesagt, die Anmeldekennwörter für den Linux-Server und den Switch Arista EOS oder den Cisco-Router können jetzt auf ähnliche Weise verwendet und gespeichert werden.
In Ansible 2.5 war die Verbindung über eAPI- und NX-API-Methoden nur mit der alten Anbietermethode möglich. Ansible 2.6 hat diese Einschränkung nicht mehr und Sie können die httpapi-Verbindungsmethode auf hoher Ebene frei verwenden. Mal sehen, wie das gemacht wird.
Sie müssen zuerst die eAPI- oder NX-API auf dem Netzwerkgerät aktivieren, damit Sie dann die httpapi-Methode verwenden können. Dies kann vom entsprechenden Ansible-Team problemlos durchgeführt werden. Hier erfahren Sie beispielsweise, wie Sie eAPI auf einem Arista EOS-Switch aktivieren.
[user@rhel7]$ ansible -m eos_eapi -c network_cli leaf01 leaf01 | SUCCESS => { "ansible_facts": { "eos_eapi_urls": { "Ethernet1": [ "https://192.168.0.14:443" ], "Management1": [ "https://10.0.2.15:443" ] } }, "changed": false, "commands": [] }
Bei Verbindung mit einem echten Arista EOS-Switch zeigt der Befehl show management api http-command an, dass die API aktiviert ist:
leaf01# show management api http-commands Enabled: Yes HTTPS server: running, set to use port 443 <<<rest of output removed for brevity>>>
Das folgende Ansible Playbook-Skript führt einfach den Befehl show version aus und gibt dann im Debug-Bereich nur die Version aus der JSON-Ausgabe der Aufgabe zurück.
--- - hosts: leaf01 connection: httpapi gather_facts: false tasks: - name: type a simple arista command eos_command: commands: - show version | json register: command_output - name: print command output to terminal window debug: var: command_output.stdout[0]["version"]
Das Ausführen dieses Skripts führt zu folgendem Ergebnis:
[user@rhel7]$ ansible-playbook playbook.yml PLAY [leaf01]******************************************************** TASK [type a simple arista command] ********************************* ok: [leaf01] TASK [print command output to terminal window] ********************** ok: [leaf01] => { "command_output.stdout[0][\"version\"]": "4.20.1F" } PLAY RECAP*********************************************************** leaf01 : ok=2 changed=0 unreachable=0 failed=0
HINWEIS: Arista eAPI unterstützt keine abgekürzten Versionen von Befehlen (z. B. "show ver" anstelle von "show version2"), daher müssen Sie alle schreiben. Weitere Informationen zum httpapi-Verbindungs-Plugin finden Sie in der Dokumentation.
Neue Netzwerkautomatisierungsmodule
Ansible 2.6 und Version 2.7, die im Oktober veröffentlicht wurden, bieten sieben neue Module für die Netzwerkautomatisierung.
- net_get - Kopiert eine Datei von einem Netzwerkgerät auf Ansible Controller.
- net_put - Kopiert eine Datei von Ansible Controller auf ein Netzwerkgerät.
- netconf_get - Ruft Konfigurations- / Statusdaten von einem Netzwerkgerät mit aktiviertem NETCONF ab.
- netconf_rpc - Führt Vorgänge auf einem Netzwerkgerät mit aktiviertem NETCONF aus.
- netconf_config - netconf- Gerätekonfiguration: Mit dem Modul kann der Benutzer eine XML-Datei an netconf-Geräte senden und prüfen, ob sich die Konfiguration geändert hat.
- cli_command - Führt den Befehl cli auf Netzwerkgeräten mit einer Befehlsschnittstelle (cli) aus.
- cli_config - Sendet (Push-) Textkonfiguration über network_cli an Netzwerkgeräte.
net_get und net_put
Die Module net_get und net_put sind nicht an die Geräte eines bestimmten Herstellers gebunden und kopieren einfach Dateien vom Netzwerkgerät auf Geräte unter Verwendung von Standard-SCP- oder SFTP-Übertragungsprotokollen (angegeben durch den Protokollparameter). Beide Module erfordern die Verwendung der Verbindungsmethode network_cli und funktionieren auch nur, wenn scp (pip install scp) auf dem Controller installiert und SCP oder SFTP auf dem Netzwerkgerät aktiviert ist.
Wir gehen davon aus, dass wir im Beispiel mit unserem Playbook bereits den folgenden Befehl auf dem Leaf01-Gerät ausgeführt haben:
leaf01#copy running-config flash:running_cfg_eos1.txt Copy completed successfully.
So sieht ein Playbook mit zwei Aufgaben aus (das erste kopiert die Datei vom Leaf01-Gerät und das zweite kopiert die Datei auf das Leaf01-Gerät):
--- - hosts: leaf01 connection: network_cli gather_facts: false tasks: - name: COPY FILE FROM THE NETWORK DEVICE TO ANSIBLE CONTROLLER net_get: src: running_cfg_eos1.txt - name: COPY FILE FROM THE ANSIBLE CONTROLLER TO THE NETWORK DEVICE net_put: src: temp.txt
netconf_get, netconf_rpc und netconf_config
- netconf_get - Ruft Konfigurations- / Statusdaten von einem Netzwerkgerät mit aktiviertem NETCONF ab.
- netconf_rpc - Führt Vorgänge auf einem Netzwerkgerät mit aktiviertem NETCONF aus.
- netconf_config - netconf- Gerätekonfiguration: Mit dem Modul kann der Benutzer eine XML-Datei an netconf-Geräte senden und prüfen, ob sich die Konfiguration geändert hat.
Netzwerkverwaltungsprotokoll NETCONF (Network Configuration Protocol) wird von der IETF entwickelt und standardisiert. Gemäß RFC 6241 kann NETCONF zum Installieren, Bearbeiten und Löschen von Netzwerkgerätekonfigurationen verwendet werden. NETCONF ist eine Alternative zur SSH-Befehlszeile (network_cli) und zu APIs wie der Cisco NX-API oder Arista eAPI (httpapi).
Um die neuen netconf-Module zu demonstrieren, aktivieren wir netconf zunächst auf Juniper-Routern mit dem Modul
junos_netconf . Netconf wird nicht von allen Netzwerkgeräten unterstützt. Überprüfen Sie daher Ihre Dokumentation, bevor Sie es verwenden.
[user@rhel7 ~]$ ansible -m junos_netconf juniper -c network_cli rtr4 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] } rtr3 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] }
Juniper Networks bietet den Junos XML API Explorer für
Betriebs-Tags und für
Konfigurations-Tags an . Betrachten Sie das Beispiel der Betriebsanforderung, die Juniper Networks in seiner
Dokumentation verwendet, um die RPC-Anforderung für eine bestimmte Schnittstelle
zu veranschaulichen.
<rpc> <get-interface-information> <interface-name>ge-2/3/0</interface-name> <detail/> </get-interface-information> </rpc> ]]>]]>
Es ist leicht in Ansible Playbook zu übersetzen. get-interface-information ist ein RPC-Aufruf, und zusätzliche Parameter werden als Schlüssel-Wert-Paare angegeben. In diesem Beispiel gibt es nur einen Parameter - Schnittstellenname - und auf unserem Netzwerkgerät möchten wir nur em1.0 betrachten. Wir verwenden den Registerparameter, der für die Aufgabe festgelegt wurde, nur um die Ergebnisse zu speichern. Daher verwenden wir das Debug-Modul und zeigen die Ergebnisse auf dem Terminalbildschirm an. Mit dem Modul netconf_rpc können Sie auch XML-Ausgaben direkt in JSON übersetzen.
--- - name: RUN A NETCONF COMMAND hosts: juniper gather_facts: no connection: netconf tasks: - name: GET INTERFACE INFO netconf_rpc: display: json rpc: get-interface-information content: interface-name: "em1.0" register: netconf_info - name: PRINT OUTPUT TO TERMINAL WINDOW debug: var: netconf_info
Nach dem Start des Playbooks erhalten wir Folgendes:
ok: [rtr4] => { "netconf_info": { "changed": false, "failed": false, "output": { "rpc-reply": { "interface-information": { "logical-interface": { "address-family": [ { "address-family-flags": { "ifff-is-primary": "" }, "address-family-name": "inet", "interface-address": [ { "ifa-broadcast": "10.255.255.255", "ifa-destination": "10/8", "ifa-flags": { "ifaf-current-preferred": "" }, "ifa-local": "10.0.0.4" }, <<<rest of output removed for brevity>>>
Weitere Informationen finden Sie im
Juniper Platform Guide und in der
NETCONF-Dokumentation .
cli_command und cli_config
- cli_command - führt einen Befehl auf Netzwerkgeräten über deren Befehlszeilenschnittstelle aus (falls vorhanden).
- cli_config - Sendet (Push-) Textkonfiguration über network_cli an Netzwerkgeräte.
Die in Ansible Engine 2.7 enthaltenen Module cli_command und cli_config sind ebenfalls nicht an die Geräte eines bestimmten Herstellers gebunden und können zur Automatisierung verschiedener Netzwerkplattformen verwendet werden. Sie basieren auf dem Wert der Variablen ansible_network_os (in der Inventardatei oder im Ordner group_vars festgelegt), um das gewünschte cliconf-Plugin zu verwenden. Eine Liste aller Werte der Variablen ansible_network_os finden Sie in der
Dokumentation . In dieser Version von Ansible können Sie die alten Module weiterhin für bestimmte Plattformen verwenden. Nehmen Sie sich also Zeit, um vorhandene Playbooks neu zu schreiben. Weitere Informationen finden Sie in den
offiziellen Portierungshandbüchern .
Mal sehen, wie diese Module in Ansible Playbook verwendet werden. Dieses Playbook kann auf zwei Cisco Cloud Services Routern (CSR) -Systemen ausgeführt werden, auf denen IOS-XE ausgeführt wird. Die Variable ansible_network_os in der Inventardatei ist auf ios festgelegt.
<config snippet from inventory> [cisco] rtr1 ansible_host=34.203.197.120 rtr2 ansible_host=34.224.60.230 [cisco:vars] ansible_ssh_user=ec2-user ansible_network_os=ios
So werden cli_config und cli_command verwendet:
--- - name: AGNOSTIC PLAYBOOK hosts: cisco gather_facts: no connection: network_cli tasks: - name: CONFIGURE DNS cli_config: config: ip name-server 8.8.8.8 - name: CHECK CONFIGURATION cli_command: command: show run | i ip name-server register: cisco_output - name: PRINT OUTPUT TO SCREEN debug: var: cisco_output.stdout
Und hier ist die Ausgabe dieses Spielbuchs:
[user@rhel7 ~]$ ansible-playbook cli.yml PLAY [AGNOSTIC PLAYBOOK] ********************************************* TASK [CONFIGURE DNS] ************************************************* ok: [rtr1] ok: [rtr2] TASK [CHECK CONFIGURATION] ******************************************* ok: [rtr1] ok: [rtr2] TASK [PRINT OUTPUT TO SCREEN] **************************************** ok: [rtr1] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } ok: [rtr2] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } PLAY RECAP ********************************************************** rtr1 : ok=3 changed=0 unreachable=0 failed=0 rtr2 : ok=3 changed=0 unreachable=0 failed=0
Bitte beachten Sie, dass diese Module
idempotent sind , solange Sie die entsprechende Syntax für die entsprechenden Netzwerkgeräte verwenden.
Verbesserte Ansible Tower-Schnittstelle
Die Weboberfläche in Red Hat Ansible Tower 3.3 ist komfortabler und funktionaler geworden und ermöglicht weniger Klicks bei der Ausführung verschiedener Aufgaben.
Die Verwaltung von Anmeldeinformationen, der Aufgabenplaner, Inventarskripte, die rollenbasierte Zugriffskontrolle, Benachrichtigungen und vieles mehr werden jetzt im Hauptmenü auf der linken Seite des Bildschirms gesammelt und sind mit einem Klick verfügbar. Auf dem Bildschirm "Jobansicht anzeigen" werden sofort wichtige zusätzliche Informationen angezeigt: Wer hat die Aufgabe wann gestartet? Welches Inventar wurde während seiner Implementierung entwickelt? Aus welchem Projekt wurde das Spielbuch entnommen?
Verwalten Sie Anmeldeinformationen für Netzwerkgeräte in Ansible Tower
Red Hat Ansible Tower 3.3 erleichtert die Verwaltung von Anmeldekennwörtern für Netzwerkgeräte erheblich. In der neuen Weboberfläche befindet sich der Befehl Anmeldeinformationen sofort im Hauptmenü in der Gruppe Ressourcen.
Ansible Tower 3.3 hat einen speziellen sogenannten "Netzwerk" -Typ für Anmeldeinformationen (Netzwerk) hinterlassen, der die Umgebungsvariablen ANSIBLE_NET_USERNAME und ANSIBLE_NET_PASSWORD festlegt, die in der alten Anbietermethode verwendet wurden. All dies funktioniert weiterhin, wie in der
Dokumentation beschrieben , sodass Sie die vorhandenen Ansible Playbooks-Skripte verwenden können. Für die neuen Verbindungsmethoden auf hoher Ebene httpapi und network_cli wird der Typ der Netzwerkanmeldeinformationen jedoch nicht mehr benötigt, da Ansible jetzt mit Kennwortanmeldungen genauso funktioniert wie mit Herstellen einer Verbindung zu Netzwerkgeräten und damit beim Herstellen einer Verbindung zu Linxu-Hosts. Daher müssen Sie für Netzwerkgeräte jetzt den Anmeldeinformationstyp des Computers auswählen. Wählen Sie ihn einfach aus und geben Sie Ihr Anmeldekennwort ein oder geben Sie einen SSH-Schlüssel ein.
HINWEIS: Ansible Tower verschlüsselt das Kennwort unmittelbar nach dem Speichern der Anmeldeinformationen.
Dank der Verschlüsselung können Anmeldeinformationen sicher an andere Benutzer und Gruppen delegiert werden - sie werden das Kennwort einfach nicht sehen oder erkennen. Weitere Informationen zur Funktionsweise von Anmeldeinformationen, zur Verwendung der Verschlüsselung und zu anderen Anmeldeinformationstypen (z. B. Amazon AWS, Microsoft Azure und Google GCE) finden Sie in der
Ansible Tower-Dokumentation .
Eine detailliertere Beschreibung von Red Hat Ansible Tower 3.3 finden Sie
hier .
Verwenden verschiedener Versionen von Ansible in Tower gleichzeitig
Angenommen, wir möchten, dass einige Playbooks über Ansible Engine 2.4.2 und andere über Ansible Engine 2.6.4 ausgeführt werden. Tower verfügt über ein spezielles virtualenv-Tool zum Erstellen von Python-Sandboxen, um Konflikte mit widersprüchlichen Abhängigkeiten und unterschiedlichen Versionen zu vermeiden. Mit Ansible Tower 3.3 können Sie virtualenv auf verschiedenen Ebenen festlegen - Organisation, Projekt oder Jobvorlage. So sieht die Jobvorlage aus, die wir in Ansible Tower zum Sichern unseres Netzwerks erstellt haben.
Wenn Sie über mindestens zwei virtuelle Umgebungen verfügen, wird im Ansible Tower-Hauptmenü das Popup-Menü Ansible Environment angezeigt, in dem Sie einfach angeben können, welche Version von Ansible bei der Ausführung der Aufgabe verwendet werden soll.
Wenn Sie eine Mischung aus Playbooks zur Automatisierung des Netzwerks haben, von denen einige die alte Anbietermethode (Ansible 2.4 und frühere Versionen) verwenden und andere neue httpapi- oder network_cli-Plugins (Ansible 2.5 und höher) verwenden, können Sie jede Aufgabe einfach zuweisen Ansible Version. Darüber hinaus ist diese Funktion hilfreich, wenn Entwickler und Produktion unterschiedliche Versionen von Ansible verwenden. Mit anderen Worten, Sie können Tower sicher aktualisieren, ohne sich Sorgen machen zu müssen, dass Sie danach zu einer beliebigen Version von Ansible Engine wechseln müssen, was die Flexibilität bei der Automatisierung verschiedener Arten von Netzwerkgeräten und -umgebungen sowie von Nutzungsszenarien erheblich erhöht.
Weitere Informationen zur Verwendung von virtualenv finden Sie in der
Dokumentation .