Die bevorstehende Veröffentlichung von Red Hat Ansible Engine 2.9 bringt spannende Verbesserungen, von denen einige in diesem Artikel besprochen werden. Wie immer haben wir offen und mit Unterstützung der Community an der Entwicklung von Ansible Network-Verbesserungen gearbeitet. Seien Sie dabei – schauen Sie vorbei und studieren Sie den Entwicklungsplan für auf der Wiki-Seite für .
Wie wir kürzlich angekündigt haben, Enthält jetzt Ansible Tower, Ansible Engine und alle Ansible Network-Inhalte. Heutzutage werden die meisten gängigen Netzwerkplattformen durch Ansible-Module implementiert. Zum Beispiel:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Wacholder Junos
- VyOS
Eine vollständige Liste der Plattformen, die von Red Hat über das Ansible Automation-Abonnement vollständig unterstützt werden, finden Sie unter .
Was haben wir gelernt?
In den letzten vier Jahren haben wir viel über die Entwicklung einer Netzwerkautomatisierungsplattform gelernt. Das haben wir auch gelernt als Plattformartefakte werden von Endbenutzern in Ansible-Playbooks und -Rollen verwendet. Und das haben wir herausgefunden:
- Unternehmen automatisieren Geräte nicht nur eines, sondern vieler Anbieter.
- Automatisierung ist nicht nur ein technisches Phänomen, sondern auch ein kulturelles.
- Die Automatisierung von Netzwerken im großen Maßstab ist aufgrund der grundlegenden Architekturprinzipien des Automatisierungsdesigns schwieriger als es scheint.
Als wir vor über einem Jahr unsere langfristigen Wachstumspläne besprachen, fragten unsere Firmenkunden Folgendes:
- Die Faktenerfassung muss besser standardisiert und auf die Automatisierungsabläufe auf allen Geräten abgestimmt werden.
- Auch die Aktualisierung von Konfigurationen auf dem Gerät muss standardisiert und konsistent sein, damit Ansible-Module die zweite Hälfte des Zyklus nach dem Sammeln von Fakten bewältigen können.
- Wir benötigen strenge und unterstützte Methoden zur Umwandlung der Gerätekonfiguration in strukturierte Daten. Auf dieser Grundlage kann die Quelle der Wahrheit vom Netzwerkgerät verschoben werden.
Faktenverbesserungen
Das Sammeln von Fakten von Netzwerkgeräten mithilfe von Ansible erfolgt oft nach dem Zufallsprinzip. Webbasierte Plattformen verfügen über unterschiedliche Möglichkeiten zur Faktenerfassung, verfügen jedoch nur über geringe oder gar keine Funktionen zum Parsen und Standardisieren der Darstellung von Daten in Schlüssel-Wert-Paaren. Lesen Ken Celenza darüber, wie schwierig und schmerzhaft es sein kann, Faktendaten zu analysieren und zu standardisieren.
Möglicherweise haben Sie bemerkt, dass wir an der Rolle „Ansible Network Engine“ arbeiten. Natürlich hat sich die Network Engine-Rolle 24 Downloads später schnell zu einer der beliebtesten Ansible-Rollen in Ansible Galaxy für Netzwerkautomatisierungsszenarien entwickelt. Bevor wir einen Großteil davon in Ansible 2.8 verschoben haben, um uns auf die Anforderungen in Ansible 2.9 vorzubereiten, stellte diese Ansible-Rolle die ersten Tools bereit, die beim Parsen von Befehlen, beim Verwalten von Befehlen und beim Sammeln von Daten für Netzwerkgeräte helfen.
Wenn Sie wissen, wie man Network Engine verwendet, ist dies eine sehr effiziente Möglichkeit, Faktendaten für die Verwendung in Ansible zu sammeln, zu analysieren und zu standardisieren. Der Nachteil dieser Rolle besteht darin, dass Sie für jede Plattform und für alle Netzwerkaktivitäten eine ganze Reihe von Parsern erstellen müssen. Um zu verstehen, wie schwierig es ist, Parser zu erstellen, zu versenden und zu warten, werfen Sie einen Blick auf von den Jungs von Cisco.
Kurz gesagt, ist es für die Automatisierung im großen Maßstab von entscheidender Bedeutung, Fakten von Geräten zu erhalten und sie in Schlüssel-Wert-Paare zu normalisieren. Dies ist jedoch schwierig, wenn Sie über viele Anbieter und Netzwerkplattformen verfügen.
Jedes Netzwerk-Faktenmodul in Ansible 2.9 kann jetzt die Konfiguration eines Netzwerkgeräts analysieren und strukturierte Daten zurückgeben – ohne zusätzliche Bibliotheken, Ansible-Rollen oder benutzerdefinierte Parser.
Seit Ansible 2.9 wird jedes Mal, wenn ein aktualisiertes Netzwerkmodul veröffentlicht wird, das Faktenmodul verbessert, um Daten über diesen Abschnitt der Konfiguration bereitzustellen. Das heißt, die Entwicklung von Fakten und Modulen erfolgt nun im gleichen Tempo und sie werden immer eine gemeinsame Datenstruktur haben.
Die Konfiguration von Ressourcen auf einem Netzwerkgerät kann auf zwei Arten abgerufen und in strukturierte Daten umgewandelt werden. Auf beide Arten können Sie eine bestimmte Liste von Ressourcen mithilfe eines neuen Schlüsselworts sammeln und umwandeln gather_network_resources. Die Ressourcennamen stimmen mit den Modulnamen überein, was sehr praktisch ist.
Beim Sammeln von Fakten:
Verwendung eines Schlüsselworts gather_facts Sie können die aktuelle Gerätekonfiguration zu Beginn des Playbooks abrufen und sie dann im gesamten Playbook verwenden. Geben Sie die einzelnen Ressourcen an, die vom Gerät abgerufen werden sollen.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueMöglicherweise ist Ihnen bei diesen Beispielen etwas Neues aufgefallen, nämlich – gather_facts: true ist jetzt für die native Faktenerfassung für Netzwerkgeräte verfügbar.
Direkte Verwendung des Netzwerkfaktenmoduls:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesDas Playbook gibt die folgenden Fakten über die Schnittstelle zurück:
ansible_facts:
ansible_network_resources:
interfaces:
- enabled: true
name: Ethernet1
mtu: '1476'
- enabled: true
name: Loopback0
- enabled: true
name: Loopback1
- enabled: true
mtu: '1476'
name: Tunnel0
- enabled: true
name: Ethernet1
- enabled: true
name: Tunnel1
- enabled: true
name: Ethernet1Beachten Sie, wie Ansible die native Konfiguration vom Arista-Gerät abruft und sie in strukturierte Daten umwandelt, um sie als Standard-Schlüssel-Wert-Paare für nachgelagerte Aufgaben und Vorgänge zu verwenden.
Schnittstellenfakten können zu gespeicherten Ansible-Variablen hinzugefügt und sofort oder später als Eingabe für ein Ressourcenmodul verwendet werden eos_interfaces ohne zusätzliche Bearbeitung oder Konvertierung.
Ressourcenmodule
Also extrahierten wir die Fakten, normalisierten die Daten, fügten sie in ein standardisiertes internes Datenstrukturdiagramm ein und erhielten eine fertige Quelle der Wahrheit. Hurra! Das ist natürlich großartig, aber wir müssen die Schlüssel-Wert-Paare trotzdem irgendwie wieder in die spezifische Konfiguration umwandeln, die die spezifische Geräteplattform erwartet. Wir benötigen jetzt plattformspezifische Module, um diese neuen Anforderungen an die Erfassung und Normalisierung von Fakten zu erfüllen.
Was ist ein Ressourcenmodul? Sie können sich die Konfigurationsabschnitte eines Geräts als von diesem Gerät bereitgestellte Ressourcen vorstellen. Netzwerkressourcenmodule sind bewusst auf eine einzelne Ressource beschränkt und können wie Bausteine gestapelt werden, um komplexe Netzwerkdienste zu konfigurieren. Dadurch werden die Anforderungen und Spezifikationen für ein Ressourcenmodul natürlich vereinfacht, da das Ressourcenmodul lesen kann и Konfigurieren Sie einen bestimmten Netzwerkdienst auf einem Netzwerkgerät.
Um zu erklären, was ein Ressourcenmodul tut, schauen wir uns ein Beispiel-Playbook an, das einen idempodenten Vorgang unter Verwendung neuer Fakten und Module zu Netzwerkressourcen zeigt eos_l3_interface.
- name: example of facts being pushed right back to device.
hosts: arista
gather_facts: false
tasks:
- name: grab arista eos facts
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: ensure that the IP address information is accurate
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: ensure config did not change
assert:
that: not result.changedWie Sie sehen, werden die vom Gerät gesammelten Daten ohne Konvertierung direkt an das entsprechende Ressourcenmodul übertragen. Beim Start ruft das Playbook Werte vom Gerät ab und vergleicht sie mit den erwarteten. In diesem Beispiel sind die zurückgegebenen Werte wie erwartet (d. h. es wird auf Konfigurationsabweichungen geprüft) und es wird gemeldet, ob sich die Konfiguration geändert hat.
Der ideale Weg, Konfigurationsdrift zu erkennen, besteht darin, Fakten in gespeicherten Ansible-Variablen zu speichern und sie regelmäßig mit dem Ressourcenmodul im Inspektionsmodus zu verwenden. Dies ist eine einfache Methode, um festzustellen, ob jemand die Werte manuell geändert hat. In den meisten Fällen lassen Organisationen Änderungen und Konfigurationen manuell zu, obwohl viele Vorgänge über Ansible Automation ausgeführt werden.
Wie unterscheiden sich die neuen Ressourcenmodule von den bisherigen?
Für einen Netzwerkautomatisierungsingenieur gibt es drei Hauptunterschiede zwischen den Ressourcenmodulen in Ansible 3 und früheren Versionen.
1) Für eine bestimmte Netzwerkressource (die auch als Konfigurationsabschnitt betrachtet werden kann) entwickeln sich Module und Fakten auf allen unterstützten Netzwerkbetriebssystemen gleichzeitig. Wir sind der Meinung, dass, wenn Ansible die Ressourcenkonfiguration auf einer Netzwerkplattform unterstützt, wir sie überall unterstützen sollten. Dies vereinfacht die Verwendung von Ressourcenmodulen, da ein Netzwerkautomatisierungsingenieur jetzt eine Ressource (z. B. LLDP) auf allen Netzwerkbetriebssystemen mit nativen und unterstützten Modulen konfigurieren kann.
2) Ressourcenmodule enthalten jetzt einen Statuswert.
merged: Die Konfiguration wird mit der bereitgestellten Konfiguration zusammengeführt (Standard);replaced: Die Ressourcenkonfiguration wird durch die bereitgestellte Konfiguration ersetzt;overridden: Die Ressourcenkonfiguration wird durch die bereitgestellte Konfiguration ersetzt; unnötige Ressourceninstanzen werden gelöscht;deleted: Die Ressourcenkonfiguration wird gelöscht/auf den Standardwert zurückgesetzt.
3) Ressourcenmodule enthalten jetzt stabile Rückgabewerte. Wenn das Netzwerkressourcenmodul die erforderlichen Änderungen am Netzwerkgerät vorgenommen (oder vorgeschlagen) hat, gibt es dieselben Schlüssel-Wert-Paare an das Playbook zurück.
before: Konfiguration auf dem Gerät in Form strukturierter Daten vor der Aufgabe;after: Wenn sich das Gerät geändert hat (oder sich ändern kann, wenn der Testmodus verwendet wird), wird die resultierende Konfiguration als strukturierte Daten zurückgegeben;commands: Alle Konfigurationsbefehle werden auf dem Gerät ausgeführt, um es in den gewünschten Zustand zu bringen.
Was bedeutet das alles? Warum ist es wichtig?
In diesem Beitrag werden viele komplexe Konzepte behandelt, aber wir hoffen, dass Sie am Ende besser verstehen, was Unternehmenskunden in Bezug auf Erfassung, Datennormalisierung und Schleifenkonfiguration für eine Automatisierungsplattform verlangen. Aber warum brauchen sie diese Verbesserungen? Viele Unternehmen streben heute eine digitale Transformation an, um ihre IT-Umgebungen agiler und wettbewerbsfähiger zu machen. Im Guten wie im Schlechten werden viele Netzwerkingenieure entweder aus Eigeninteresse oder auf Geheiß des Managements zu Netzwerkentwicklern.
Unternehmen erkennen, dass die Automatisierung einzelner Netzwerkvorlagen das Problem der Silos nicht löst und die Effizienz nur bis zu einem gewissen Grad steigert. Die Red Hat Ansible Automation Platform bietet strenge und normative Ressourcendatenmodelle zur programmgesteuerten Verwaltung der zugrunde liegenden Daten auf einem Netzwerkgerät. Das heißt, Benutzer geben nach und nach einzelne Konfigurationsmethoden zugunsten modernerer Methoden auf, bei denen der Schwerpunkt auf Technologien (z. B. IP-Adressen, VLANs, LLDP usw.) und nicht auf einer bestimmten Anbieterimplementierung liegt.
Bedeutet das, dass die Tage zuverlässiger und bewährter Befehlsmodule und Konfigurationen gezählt sind? Auf keinen Fall. Die erwarteten Netzwerkressourcenmodule werden nicht in allen Fällen oder für jeden Anbieter anwendbar sein, sodass die Befehls- und Konfigurationsmodule weiterhin von Netzwerkingenieuren für bestimmte Implementierungen benötigt werden. Der Zweck von Ressourcenmodulen besteht darin, große Jinja-Vorlagen zu vereinfachen und unstrukturierte Gerätekonfigurationen in ein strukturiertes JSON-Format zu normalisieren. Mit Ressourcenmodulen wird es für bestehende Netzwerke einfacher, ihre Konfiguration in strukturierte Schlüssel-Wert-Paare umzuwandeln, die eine leicht lesbare Quelle der Wahrheit darstellen. Durch die Verwendung strukturierter Schlüssel-Wert-Paare können Sie von der Ausführung von Konfigurationen auf jedem Gerät zur Arbeit mit unabhängigen strukturierten Daten übergehen und Netzwerke in den Vordergrund eines Infrastructure-as-Code-Ansatzes rücken.
Welche Ressourcenmodule werden in Ansible Engine 2.9 enthalten sein?
Bevor wir Ihnen im Detail erzählen, was in Ansible 2.9 passieren wird, erinnern wir uns daran, wie wir den gesamten Arbeitsumfang aufgeteilt haben.
Wir haben 7 Kategorien identifiziert und jeder einzelne spezifische Netzwerkressourcen zugewiesen:
Hinweis: Fett gedruckte Ressourcen wurden in Ansible 2.9 geplant und implementiert.
Aufgrund des Feedbacks von Unternehmenskunden und der Community war es logisch, sich zunächst mit den Modulen zu befassen, die sich auf Netzwerktopologieprotokolle, Virtualisierung und Schnittstellen beziehen.
Die folgenden Ressourcenmodule wurden vom Ansible Network-Team entwickelt und entsprechen den von Red Hat unterstützten Plattformen:
Die folgenden Module werden von der Ansible-Community entwickelt:
exos_lldp_global- von Extreme Networks.nxos_bfd_interfaces- von Cisconxos_telemetry- von Cisco
Wie Sie sehen, passt das Konzept der Ressourcenmodule in unsere plattformzentrierte Strategie. Das heißt, wir integrieren die notwendigen Fähigkeiten und Funktionen in Ansible selbst, um die Standardisierung bei der Entwicklung von Netzwerkmodulen zu unterstützen und auch die Arbeit der Benutzer auf der Ebene von Ansible-Rollen und Playbooks zu vereinfachen. Um die Entwicklung von Ressourcenmodulen zu erweitern, hat das Ansible-Team das Module Builder-Tool veröffentlicht.
Pläne für Ansible 2.10 und höher
Sobald Ansible 2.9 veröffentlicht ist, werden wir an den nächsten Ressourcenmodulen für Ansible 2.10 arbeiten, die zur weiteren Konfiguration der Netzwerktopologie und -richtlinien verwendet werden können, z. B. . Der Entwicklungsplan kann noch angepasst werden. Wenn Sie also Kommentare haben, melden Sie diese bitte an .
Ressourcen und erste Schritte
Source: habr.com