🥇 The Inside Playbook. Netzwerkfunktionen im neuen Ansible Engine 2.9

In der kommenden Ausgabe von Red Hat Ansible Engine 2.9 erwarten Sie beeindruckende Verbesserungen, von denen einige in diesem Artikel beschrieben werden. Wie gewohnt haben wir die Verbesserungen für Ansible Network offen entwickelt, mit Unterstützung der Community. Schauen Sie vorbei – besuchen Sie die Taskboard auf GitHub und erkunden Sie den Entwicklungsplan für die Veröffentlichung von Red Hat Ansible Engine 2.9 auf der Wiki-Seite für Ansible Network.

Wie wir kürzlich angekündigt haben, umfasst die Red Hat Ansible Automation Platform jetzt Ansible Tower, Ansible Engine und den gesamten Inhalt von Ansible Network. Derzeit werden die meisten beliebten Netzwerkplatformen über Ansible-Module umgesetzt. Zum Beispiel:

Arista EOS
Cisco IOS
Cisco IOS XR
Cisco NX-OS
Juniper Junos
VyOS

Eine vollständige Liste der Plattformen, die durch das Ansible Automation-Abonnement von Red Hat vollständig unterstützt werden, wurde hier veröffentlicht.

Was wir gelernt haben

In den letzten vier Jahren haben wir viel über die Entwicklung einer Automatisierungsplattform für Netzwerke gelernt. Außerdem haben wir erfahren, als wie die Artefakte der Plattform in Playbooks und Rollen von Ansible auf der Benutzerseite verwendet werden. Und das haben wir herausgefunden:

Organisationen automatisieren nicht nur Geräte eines einzelnen Anbieters, sondern vieler Anbieter.
Automatisierung ist nicht nur ein technisches Phänomen, sondern auch ein kulturelles.
Die großflächige Automatisierung von Netzwerken ist komplexer, als es scheint, aufgrund grundlegender architektonischer Prinzipien der Automatisierungsdesigns.

Als wir vor über einem Jahr über unsere langfristigen Entwicklungspläne diskutierten, wünschten sich unsere Unternehmenskunden Folgendes:

Die Faktensammlung muss besser standardisiert und mit dem Automatisierungsworkflow für alle Geräte abgestimmt werden.
Auch das Aktualisieren von Konfigurationen auf Geräten muss standardisiert und koordiniert werden, damit die Ansible-Module die zweite Hälfte des Zyklus nach der Faktensammlung verarbeiten können.
Strenge und unterstützte Methoden zur Umwandlung der Gerätekonfiguration in strukturierte Daten sind erforderlich. Auf dieser Grundlage kann die Quelle der Wahrheit von Netzwerkgeräten verschoben werden.

Verbesserungen in der Faktensammlung

Die Faktensammlung von Netzwerkgeräten mit Ansible erfolgt oft willkürlich. Netzwerkplattformen sind in unterschiedlichem Maße mit Funktionen zur Faktensammlung ausgestattet, jedoch haben sie kaum — oder sogar gar keine — Möglichkeiten zur Analyse und Standardisierung der Datenpräsentation in Schlüssel-Wert-Paaren. Lesen Sie Beitrag Ken Celenza erläutert, wie schwierig und mühsam es sein kann, Fakten zu analysieren und zu standardisieren.

Vielleicht haben Sie bemerkt, wie wir an der Rolle Ansible Network Engine gearbeitet haben. Nach 24.000 Downloads ist die Rolle Network Engine schnell zu einer der beliebtesten Ansible-Rollen in Ansible Galaxy für Automatisierungsszenarien geworden. Bevor wir vieles davon in Ansible 2.8 übertragen haben, um uns auf die Anforderungen in Ansible 2.9 vorzubereiten, bot diese Ansible-Rolle eine erste Sammlung von Werkzeugen zur Unterstützung beim Parsen von Befehlen, beim Verwalten von Teams und beim Sammeln von Daten für Netzwerkgeräte.

Wenn Sie mit der Verwendung des Network Engine vertraut sind, ist dies eine sehr effektive Methode zum Sammeln, Parsen und Standardisieren von Fakten zur Nutzung in Ansible. Nachteil dieser Rolle ist, dass für jede Plattform und für alle Netzwerkaktivitäten eine Vielzahl von Parsern erstellt werden muss. Um zu verstehen, wie kompliziert es ist, Parser zu entwickeln, bereitzustellen und zu warten, schauen Sie sich die über 1200 Parser von den Kollegen bei Cisco an.

Kurz gesagt, für umfangreiche Automatisierung ist es entscheidend, Fakten von Geräten zu erfassen und sie in Schlüssel-Wert-Paare zu normalisieren. Dies wird jedoch erschwert, wenn Sie mit vielen Anbietern und Netzwerkplattformen arbeiten.

Jedes Netzwerk-Faktenmodul in Ansible 2.9 kann jetzt die Konfiguration eines Netzwerkgeräts analysieren und strukturierte Daten zurückgeben – ganz ohne zusätzliche Bibliotheken, Ansible-Rollen oder benutzerdefinierte Parser.

Ab Ansible 2.9 wird bei jeder Veröffentlichung eines aktualisierten Netzwerkmoduls das Faktenmodul verbessert, um Daten zu diesem Abschnitt der Konfiguration bereitzustellen. Das bedeutet, dass sich die Entwicklung von Fakten und Modulen nun im gleichen Tempo vollzieht und sie immer eine gemeinsame Datenstruktur haben werden.

Die Konfiguration von Ressourcen auf einem Netzwerkgerät kann auf zwei Arten extrahiert und in strukturierte Daten umgewandelt werden. Beide Methoden ermöglichen es, eine bestimmte Liste von Ressourcen mit dem neuen Schlüsselwort gather_network_resources. Die Ressourcennamen entsprechen den Modulnamen, was sehr praktisch ist.

Während der Faktenzusammenstellung:

Mit dem Schlüsselwort gather_facts Sie können die aktuelle Gerätekonfiguration am Anfang des Playbooks extrahieren und dann während des gesamten Playbooks verwenden. Geben Sie die einzelnen Ressourcen an, die von dem Gerät extrahiert werden sollen.

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

Vielleicht haben Sie etwas Neues in diesen Beispielen bemerkt, nämlich — gather_facts: true jetzt verfügbar für die native Faktensammlung von Netzwerkgeräten.

Verwendung des Moduls für Netzwerkfakten direkt:

- name: Schnittstellenkonfigurationsfakten sammeln
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

Das 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: Ethernet1

Beachten Sie, wie Ansible die native Konfiguration vom Arista-Gerät extrahiert und in strukturierte Daten umwandelt, die als Standard-Schlüssel-Wert-Paare für nachfolgende Aufgaben und Operationen verwendet werden.

Interface-Fakten können in Ansible-Variablen gespeichert und sofort oder später als Eingabewerte für das Ressourcenmodul verwendet werden. eos_interfaces ohne zusätzliche Verarbeitung oder Umwandlung.

Ressourcenmodule

Wir haben also die Fakten extrahiert, die Daten normalisiert, in ein standardisiertes internes Datenschema eingepflegt und somit eine vertrauenswürdige Quelle erhalten. Hurra! Das ist natürlich großartig, aber wir müssen die Schlüssel-Wert-Paare immer noch in eine spezifische Konfiguration zurückverwandeln, die die jeweilige Geräteeplattform erwartet. Jetzt benötigen wir Module für bestimmte Plattformen, um diesen neuen Anforderungen an die Faktensammlung und Normalisierung gerecht zu werden.

Was ist ein Ressourcenmodul? Die Konfigurationselemente eines Geräts können als Ressourcen angesehen werden, die dieses Gerät bereitstellt. Netzwerkressourcenmodule sind absichtlich auf eine Ressource begrenzt und können wie Bausteine gestapelt werden, um komplexe Netzwerkdienste zu konfigurieren. Infolgedessen werden die Anforderungen und Spezifikationen für das Ressourcenmodul auf natürliche Weise vereinfacht, da das Ressourcenmodul lesen kann. und einen bestimmten Netzwerkdienst auf einem Netzwerkgerät konfigurieren.

Um zu erklären, was das Ressourcenmodul macht, betrachten wir ein Beispiel für ein Playbook, das eine identische Operation mit den neuen Fakten des Netzwerkressourcenmoduls und dessen Modul zeigt. eos_l3_interface.

- name: Beispiel für Fakten, die direkt an das Gerät zurückgeschoben werden.
  hosts: arista
  gather_facts: false
  tasks:
  - name: Erfassen der Arista EOS-Fakten
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - name: Sicherstellen, dass die IP-Adressinformationen korrekt sind
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - name: Sicherstellen, dass sich die Konfiguration nicht geändert hat
    assert:
      that: not result.changed

Wie Sie sehen, werden die vom Gerät gesammelten Daten direkt an das entsprechende Ressourcenmodul ohne Umwandlung übertragen. Beim Ausführen des Playbooks werden die Werte vom Gerät abgerufen und mit den erwarteten verglichen. In diesem Beispiel stimmen die erhaltenen Werte mit den Erwartungen überein (d.h. es erfolgt eine Überprüfung der Konfigurationsabweichungen), und es wird eine Meldung ausgegeben, ob sich die Konfiguration geändert hat.

Der ideale Weg, um Abweichungen in der Konfiguration zu erkennen, besteht darin, Fakten in Ansible-Variablen zu speichern und diese regelmäßig zusammen mit dem Ressourcenmodul im Überprüfungsmodus zu verwenden. Dies ist eine einfache Methode, um zu sehen, 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 durchgeführt werden.

Was unterscheidet die neuen Ressourcenmodule von den vorherigen?

Für einen Netzwerkautomatisierungsingenieur gibt es 3 Hauptunterschiede der Ressourcenmodule in Ansible 2.9 im Vergleich zu früheren Versionen.

1) Für eine bestimmte Netzwerkressource (die auch als Konfigurationsabschnitt betrachtet werden kann) werden Module und Fakten in allen unterstützten Netzwerkbetriebssystemen gleichzeitig entwickelt. Wir sind der Meinung, dass wenn Ansible die Ressourcenkonfiguration auf einer Netzwerkplattform unterstützt, wir dies überall unterstützen sollten. Dies vereinfacht die Verwendung von Ressourcenmodulen, da der Netzwerkautomatisierungsingenieur jetzt eine Ressource (z. B. LLDP) in allen Netzwerkbetriebssystemen mit nativen und unterstützten Modulen konfigurieren kann.

2) Ressourcenmodule enthalten jetzt den Statuswert.

zusammengeführt: die Konfiguration wurde mit der bereitgestellten Konfiguration (Standard) zusammengeführt;
ersetzt: die Ressourcen-Konfiguration wird durch die bereitgestellte Konfiguration ersetzt;
überschrieben: die Ressourcen-Konfiguration wird durch die bereitgestellte Konfiguration ersetzt; überflüssige Ressourceninstanzen werden entfernt;
deleted: die Ressourcen-Konfiguration wird auf die Standard- oder Wiederherstellungskonfiguration zurückgesetzt.

3) Ressourcenmodule enthalten jetzt stabile Rückgabewerte. Wenn das Netzwerkmodul die erforderlichen Änderungen am Netzwerkgerät vorgenommen (oder vorgeschlagen) hat, gibt es dieselben Schlüssel-Wert-Paare im Playbook zurück.

before: die Konfiguration auf dem Gerät in Form strukturierter Daten vor der Aufgabe;
nach: wenn das Gerät verändert wurde (oder verändert werden könnte, wenn der Prüfmodus verwendet wird), wird die resultierende Konfiguration in Form strukturierter Daten zurückgegeben;
Befehle: alle Konfigurationsbefehle, die auf dem Gerät ausgeführt werden, um es in den gewünschten Zustand zu versetzen.

Was bedeutet das alles? Warum ist das wichtig?

In diesem Beitrag werden viele komplexe Konzepte beschrieben, doch wir hoffen, dass Sie schließlich besser verstehen, warum Unternehmenskunden nach der Erfassung von Fakten, der Normalisierung von Daten und der Konfiguration von Zyklen für Automatisierungsplattformen fragen. Aber warum benötigen sie diese Verbesserungen? Derzeit befinden sich viele Organisationen in einem digitalen Transformationsprozess, um ihre IT-Umgebungen flexibler und wettbewerbsfähiger zu gestalten. Ob dies gut oder schlecht ist, viele Netzwerkingenieure entwickeln sich zu Netzwerkentwicklern – entweder aus eigenem Interesse oder auf Anweisung ihrer Vorgesetzten.

Organisationen erkennen, dass die Automatisierung einzelner Netzwerkvorlagen das Problem der Zersplitterung nicht löst und die Effizienz nur bis zu einem gewissen Grad steigert. Die Red Hat Ansible Automation Platform bietet strenge und normierte Datenmodellen von Ressourcen, um die grundlegenden Daten auf Netzwerkgeräten programmgesteuert zu verwalten. Das bedeutet, dass Benutzer allmählich von individuellen Konfigurationsmethoden zu moderneren Ansätzen übergehen, die einen Schwerpunkt auf Technologien (wie IP-Adressen, VLAN, LLDP usw.) und nicht auf spezifische Implementierungen von Anbietern legen.

Bedeutet das, dass die Tage der zuverlässigen und bewährten Module für Teams und Konfigurationen gezählt sind? Keineswegs. Die erwarteten Netzwerkressourcenmodule werden nicht in allen Fällen und für jeden Anbieter anwendbar sein, sodass die Module für Teams und Konfigurationen weiterhin von Netzwerkingenieuren für bestimmte Implementierungen benötigt werden. Ziel der Ressourcenmodule ist es, große Jinja-Vorlagen zu vereinfachen und unstrukturierte Gerätekonfigurationen in ein strukturiertes JSON-Format zu normalisieren. Mit Ressourcenmodulen wird es bestehenden Netzwerken erleichtert, ihre Konfiguration in strukturierte Schlüssel-Wert-Paare umzuwandeln, die eine leicht verständliche Quelle der Wahrheit darstellen. Durch die Verwendung strukturierter Schlüssel-Wert-Paare kann der Übergang von Konfigurationen, die auf jedem Gerät ausgeführt werden, zur Arbeit mit unabhängigen strukturierten Daten vollzogen werden, was die Netzwerke bei dem Ansatz "Infrastruktur als Code" in den Vordergrund rückt.

Welche Ressourcenmodule werden in Ansible Engine 2.9 verfügbar sein?

Bevor wir im Detail erläutern, was in Ansible 2.9 enthalten sein wird, lassen Sie uns einen Rückblick darauf werfen, wie wir den Umfang der Arbeiten aufgeteilt haben.

Wir haben 7 Kategorien erstellt und jeder Kategorie bestimmte Netzwerkressourcen zugewiesen:

Hinweis: Die fett hervorgehobenen Ressourcen wurden in Ansible 2.9 eingeplant und implementiert.
Basierend auf dem Feedback von Unternehmenskunden und der Community war es sinnvoll, zunächst die Module zu behandeln, die sich mit Netzwerkprotokollen, Virtualisierung und Schnittstellen befassen.
Die folgenden Ressourcenmodule wurden vom Ansible Network-Team entwickelt und entsprechen den Plattformen, die von Red Hat unterstützt werden:

Die folgenden Module wurden von der Ansible-Community entwickelt:

exos_lldp_global – von Extreme Networks.
nxos_bfd_interfaces – von Cisco
nxos_telemetry – von Cisco

Wie Sie sehen, fügt sich das Konzept der Ressourcenmodule in unsere plattformorientierte Strategie ein. Das bedeutet, dass wir die notwendigen Funktionen direkt in Ansible integrieren, um die Standardisierung bei der Entwicklung von Netzwerkmodulen zu unterstützen und die Arbeit der Benutzer auf der Ebene von Rollen und Playbooks in Ansible zu erleichtern. Um die Entwicklung von Ressourcenmodulen zu erweitern, hat das Ansible-Team das Tool Module Builder veröffentlicht.

Die Pläne für Ansible 2.10 und darüber hinaus

Nach der Veröffentlichung von Ansible 2.9 widmen wir uns dem nächsten Satz von Ressourcenmodulen für Ansible 2.10, die zur weiteren Anpassung der Netzwerk-Topologie und -Politik verwendet werden können, zum Beispiel ACL, OSPF und BGP. Der Entwicklungsplan kann weiterhin angepasst werden, also lassen Sie es uns wissen, wenn Sie Kommentare haben, in der Ansible Network-Community.