Die bevorstehende Version von Red Hat Ansible Engine 2.9 wartet mit beeindruckenden Verbesserungen auf Sie, von denen einige in diesem Artikel beschrieben werden. Wie üblich haben wir mit Unterstützung der Community offen Verbesserungen für Ansible Network entwickelt. Beitreten - Sehen Sie sich das Task Board auf GitHub an und lesen Sie den Entwicklungsplan für die Veröffentlichung von Red Hat Ansible Engine 2.9 auf der Wiki-Seite für Ansible Network .
Wie kürzlich angekündigt, enthält die Red Hat Ansible Automation Platform jetzt Ansible Tower, Ansible Engine und alle Inhalte von Ansible Network. Die gängigsten Netzwerkplattformen werden jetzt über 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 Ansible Automation vollständig unterstützt werden, finden Sie hier .
Was haben wir gelernt?
In den letzten vier Jahren haben wir viel über die Entwicklung einer Plattform für die Netzwerkautomatisierung gelernt. Wir haben auch gelernt, wie Endbenutzer Plattformartefakte in Ansible-Playbooks und -Rollen spielen. Und hier ist, was wir herausgefunden haben:
- Unternehmen automatisieren Geräte nicht nur von einem, sondern von vielen Anbietern.
- Automatisierung ist nicht nur ein technisches, sondern auch ein kulturelles Phänomen.
- Die groß angelegte Automatisierung von Netzwerken ist aufgrund der grundlegenden Architekturprinzipien des Automatisierungsdesigns komplizierter als es scheint.
Als wir vor über einem Jahr über unsere langfristigen Entwicklungspläne diskutierten, forderten unsere Firmenkunden Folgendes an:
- Die Erfassung von Fakten muss besser standardisiert und an den Automatisierungsworkflow für jedes Gerät angepasst werden.
- Das Aktualisieren von Konfigurationen auf dem Gerät muss ebenfalls standardisiert und harmonisiert werden, damit Ansible-Module die zweite Hälfte des Zyklus nach dem Sammeln der Fakten verarbeiten.
- Wir benötigen strenge und unterstützte Methoden, um die Gerätekonfiguration in strukturierte Daten umzuwandeln. Auf dieser Basis kann die Wahrheitsquelle von einem Netzwerkgerät verschoben werden.
Faktenverbesserungen
Das Sammeln von Fakten von Netzwerkgeräten mit Ansible erfolgt häufig nach dem Zufallsprinzip. Netzwerkplattformen sind in unterschiedlichem Maße mit der Fähigkeit ausgestattet, Fakten zu sammeln, haben jedoch fast keine oder gar keine Funktionen zum Parsen und Standardisieren der Darstellung von Daten in Schlüssel-Wert-Paaren. Lesen Sie in Ken Celenzas Beitrag, wie schwierig und schmerzhaft es ist, Fakten zu analysieren und zu standardisieren.
Möglicherweise haben Sie bemerkt, wie wir an der Rolle der Ansible Network Engine gearbeitet haben. Natürlich wurde die Network Engine-Rolle 24.000 Downloads später schnell zu einer der beliebtesten Rollen von Ansible in Ansible Galaxy für Netzwerkautomatisierungsszenarien. Bevor wir einen Großteil davon auf Ansible 2.8 migrierten, um uns auf die Anforderungen von Ansible 2.9 vorzubereiten, stellte diese Ansible-Rolle die ersten Tools zur Verfügung, die das Parsen von Befehlen, die Befehlsverwaltung und die Datenerfassung für Netzwerkgeräte unterstützen.
Wenn Sie Network Engine gut beherrschen, ist dies eine sehr effiziente Methode zum Sammeln, Analysieren und Standardisieren von Faktendaten für die Verwendung mit Ansible. 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, schauen Sie sich die über 1200 Parser der Mitarbeiter von Cisco an.
Kurz gesagt, für eine groß angelegte Automatisierung ist es sehr wichtig, Fakten von Geräten zu empfangen und sie in Schlüssel-Wert-Paare zu normalisieren. Dies ist jedoch schwierig zu erreichen, wenn Sie viele Anbieter und Netzwerkplattformen haben.
Jedes Netzwerk-Faktmodul 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.
Ab Ansible 2.9 wird mit jeder Version des aktualisierten Netzwerkmoduls das Faktmodul verbessert, um Informationen zu diesem Konfigurationsabschnitt bereitzustellen. Das heißt, die Entwicklung von Fakten und Modulen erfolgt jetzt im gleichen Tempo und sie werden immer eine gemeinsame Datenstruktur haben.
Die Ressourcenkonfiguration auf einem Netzwerkgerät kann auf zwei Arten extrahiert und in strukturierte Daten konvertiert werden. Auf beide Arten können Sie eine bestimmte Liste von Ressourcen mit dem neuen gather_network_resources kompilieren und konvertieren. Ressourcennamen entsprechen Modulnamen, und dies ist sehr praktisch.
Zum Zeitpunkt der Erfassung der Fakten:
Mit dem gather_facts Sie die aktuelle Gerätekonfiguration am Anfang des Playbooks extrahieren und 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: True
Möglicherweise stellen Sie in diesen Beispielen etwas Neues fest, nämlich gather_facts: true jetzt für die native gather_facts: true für Netzwerkgeräte verfügbar.
Direktes Verwenden des Network Facts-Moduls:
- name: collect interface configuration facts eos_facts: gather_subset: min gather_network_resources: - interfaces
Das Playbook gibt die folgenden Fakten über die Benutzeroberfläche 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: Ethernet1
Beachten Sie, wie Ansible die native Konfiguration vom Arista-Gerät abruft und in strukturierte Daten konvertiert, um sie als Standardschlüssel-Wert-Paare für nachfolgende Aufgaben und Vorgänge zu verwenden.
Schnittstellenfakten können zu gespeicherten Ansible-Variablen hinzugefügt und sofort oder später als Eingabe für das Ressourcenmodul eos_interfaces ohne zusätzliche Verarbeitung oder Konvertierung verwendet werden.
Ressourcenmodule
Also haben wir die Fakten extrahiert, die Daten normalisiert, sie in ein standardisiertes internes Schema der Datenstruktur eingegeben und eine fertige Quelle der Wahrheit gefunden. Hurra! Das ist natürlich großartig, aber wir müssen die Schlüssel-Wert-Paare trotzdem irgendwie wieder in die spezifische Konfiguration konvertieren, die eine bestimmte Geräteplattform erwartet. Jetzt benötigen wir Module für bestimmte Plattformen, um diese neuen Anforderungen an das Sammeln und Normalisieren von Fakten zu erfüllen.
Was ist ein Ressourcenmodul? Die Gerätekonfigurationsabschnitte können als die von diesem Gerät bereitgestellten Ressourcen betrachtet werden. Netzwerkressourcenmodule sind absichtlich auf eine Ressource beschränkt und können wie Bausteine gestapelt werden, um komplexe Netzwerkdienste zu konfigurieren. Infolgedessen werden die Anforderungen und Spezifikationen für das Ressourcenmodul natürlich vereinfacht, da das Ressourcenmodul einen bestimmten Netzwerkdienst auf einem Netzwerkgerät lesen und konfigurieren kann.
Um zu erklären, was das Ressourcenmodul tut, schauen wir uns ein Beispiel eines Playbooks an, das eine idempoente Operation unter Verwendung neuer Fakten aus einer Netzwerkressource und dem Modul 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.changed
Wie Sie sehen, werden die vom Gerät gesammelten Daten ohne Konvertierung direkt an das entsprechende Ressourcenmodul übertragen. Beim Start ruft das Playbook die Werte vom Gerät ab und vergleicht sie mit den erwarteten. In diesem Beispiel entsprechen die erhaltenen Werte den erwarteten Werten (dh die Konfigurationsabweichungen werden überprüft) und eine Meldung wird angezeigt, wenn sich die Konfiguration geändert hat.
Ein idealer Weg, um Konfigurationsabweichungen zu erkennen, besteht darin, die Fakten in gespeicherten Ansible-Variablen zu speichern und sie regelmäßig mit dem Ressourcenmodul im Prüfmodus zu verwenden. Dies ist eine einfache Methode, um festzustellen, ob jemand die Werte manuell geändert hat. In den meisten Fällen erlauben Organisationen manuelle Änderungen und Konfigurationen, obwohl viele Vorgänge über Ansible Automation ausgeführt werden.
Wie unterscheiden sich neue Ressourcenmodule von früheren?
Für einen Netzwerkautomatisierungsingenieur gibt es drei Hauptunterschiede zwischen Ressourcenmodulen in Ansible 2.9 und früheren Versionen.
1) Für eine bestimmte Netzwerkressource (die auch als Konfigurationsabschnitt betrachtet werden kann) werden die Module und Fakten in allen unterstützten Netzwerkbetriebssystemen gleichzeitig entwickelt. Wir sind der Meinung, dass Ansible, wenn es die Ressourcenkonfiguration auf einer einzelnen Netzwerkplattform unterstützt, diese überall unterstützen sollte. Dies vereinfacht die Verwendung von Ressourcenmodulen, da ein Netzwerkautomatisierungstechniker jetzt eine Ressource (z. B. LLDP) in 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. überschüssige Ressourceninstanzen werden gelöscht;deleted : Die Ressourcenkonfiguration wird standardmäßig gelöscht / wiederhergestellt.
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 von strukturierten Daten vor der Aufgabe;after : Wenn sich das Gerät geändert hat (oder sich ändern kann, wenn der Überprüfungsmodus verwendet wird), wird die resultierende Konfiguration in Form strukturierter Daten zurückgegeben.commands : Alle Konfigurationsbefehle, die auf dem Gerät ausgeführt werden, um es in den gewünschten Zustand zu bringen.
Was bedeutet das alles? Warum ist das wichtig?
Dieser Beitrag beschreibt viele komplexe Konzepte, aber wir hoffen, dass Sie am Ende besser verstehen, dass Unternehmenskunden nach Fakten, Datennormalisierung und Schleifenkonfiguration für die Automatisierungsplattform fragen. Aber warum brauchen sie diese Verbesserungen? Viele Unternehmen befassen sich derzeit mit der digitalen Transformation, um ihre IT-Umgebungen flexibler und wettbewerbsfähiger zu gestalten. Ob gut oder schlecht, viele Netzwerktechniker werden zu Netzentwicklern, entweder aus eigenem Interesse oder auf Geheiß von Managern.
Unternehmen wissen, dass die Automatisierung einzelner Netzwerkvorlagen das Fragmentierungsproblem nicht löst und die Effizienz nur bis zu einer bestimmten Grenze erhöht. 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, wobei der Schwerpunkt auf Technologien (z. B. IP-Adressen, VLAN, LLDP usw.) und nicht auf einer bestimmten Herstellerimplementierung liegt.
Bedeutet dies, dass die Tage zuverlässiger und bewährter Befehlsmodule und -konfigurationen gezählt sind? Auf keinen Fall. Die erwarteten Netzwerkressourcenmodule sind nicht in allen Fällen und nicht für jeden Anbieter anwendbar, sodass die Netzwerktechniker für bestimmte Implementierungen weiterhin die Befehls- und Konfigurationsmodule benötigen. 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 vorhandene Netzwerke einfacher sein, ihre Konfiguration in strukturierte Schlüssel-Wert-Paare umzuwandeln, die eine leicht lesbare Quelle der Wahrheit darstellen. Wenn Sie strukturierte Schlüssel-Wert-Paare verwenden, können Sie von laufenden Konfigurationen auf jedem Gerät zur Arbeit mit unabhängigen strukturierten Daten wechseln und Netzwerke mit dem Ansatz „Infrastruktur als Code“ in den Vordergrund rücken.
Welche Ressourcenmodule werden in Ansible Engine 2.9 angezeigt?
Bevor wir detailliert erklären, was in Ansible 2.9 passieren wird, erinnern wir uns daran, wie wir den gesamten Arbeitsaufwand aufgeteilt haben.
Wir haben 7 Kategorien identifiziert und jeder bestimmte Netzwerkressourcen zugewiesen:
Hinweis: In Ansible 2.9 wurden mutige Ressourcen geplant und implementiert.
Basierend auf dem Feedback 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 Plattformorientierungsstrategie. Das heißt, wir nehmen die erforderlichen Features und Funktionen in Ansible selbst auf, um die Standardisierung bei der Entwicklung von Netzwerkmodulen zu unterstützen und die Arbeit der Benutzer auf der Ebene der Ansible-Rollen und Playbooks zu vereinfachen. Um die Entwicklung von Ressourcenmodulen zu erweitern, hat das Ansible-Team das Tool Module Builder veröffentlicht.
Pläne ab Ansible 2.10
Nach der Veröffentlichung von Ansible 2.9 werden wir uns mit den folgenden Ressourcenmodulen für Ansible 2.10 befassen, mit denen die Topologie und die Netzwerkrichtlinie weiter konfiguriert werden können, z. B. ACL, OSPF und BGP . Der Entwicklungsplan kann weiterhin angepasst werden. Wenn Sie also Kommentare haben, melden Sie diese der Ansible Network-Community .
Ressourcen und erste Schritte
Pressemitteilung der Ansible Automation Platform
Ansible Automation Platform Blog
Die Zukunft der Inhaltsbereitstellung bei Ansible
Überlegungen zum Ändern der Ansible-Projektstruktur