🥇Das Inside Playbook. Netzwerkfunktionen in der 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 unter Mitwirkung der Community entwickelt. Schauen Sie vorbei — besuchen Sie die Aufgabenliste 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, beinhaltet die Red Hat Ansible Automation Platform jetzt Ansible Tower, Ansible Engine und allen Inhalt von Ansible Network. Derzeit werden die meisten beliebten Netzwerkplattformen über Ansible-Module bereitgestellt. Zum Beispiel:

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

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

Was wir gelernt haben

In den letzten vier Jahren haben wir viel über die Entwicklung einer Plattform zur Automatisierung von Netzwerken gelernt. Wir haben auch erfahren, als wie die Artefakte der Plattform in Playbooks und Rollen von Ansible von Endbenutzern verwendet werden. Und das sind unsere Erkenntnisse:

Organisationen automatisieren nicht nur Geräte eines einzelnen Anbieters, sondern vieler Anbieter.
Automatisierung ist nicht nur ein technisches Phänomen, sondern auch ein kulturelles.
Großangelegte Netzwerautomatisierung ist komplexer als sie erscheint, aufgrund grundlegender architektonischer Grundsätze beim Entwurf von Automatisierung.

Als wir vor mehr als einem Jahr über unsere langfristigen Entwicklungspläne diskutierten, baten unsere Unternehmenskunden um Folgendes:

Die Faktensammlung muss besser standardisiert und mit dem Automatisierungs-Workflow für alle Geräte abgestimmt werden.
Auch die Aktualisierung von Konfigurationen auf einem Gerät muss standardisiert und abgestimmt werden, damit Ansible-Module die zweite Hälfte des Zyklus nach der Faktensammlung bearbeiten können.
Es sind strenge und unterstützte Methoden zur Umwandlung von Gerätekonfigurationen in strukturierte Daten erforderlich. Auf dieser Grundlage kann die Quelle der Wahrheit von dem Netzwerkgerät verschoben werden.

Verbesserungen der Faktensammlung

Die Faktensammlung von Netzwerkgeräten mit Ansible erfolgt häufig willkürlich. Netzwerkplattformen sind in unterschiedlichem Maße mit Faktensammlungsfähigkeiten ausgestattet, verfügen jedoch fast nicht — oder überhaupt nicht — über Funktionen zum Parsen und zur Standardisierung der Darstellung von Daten in Schlüssel-Wert-Paaren. Lesen Sie Post Ken Celenza darüber, wie schwierig und mühsam es sein kann, Faktendaten zu analysieren und zu standardisieren.

Vielleicht haben Sie bemerkt, wie wir an der Rolle des Ansible Network Engine gearbeitet haben. Natürlich, nach 24.000 Downloads wurde die Network Engine-Rolle schnell zu einer der beliebtesten Ansible-Rollen in Ansible Galaxy für Netzwerkautomatisierungsskripte. Bevor wir viel davon in Ansible 2.8 übertragen haben, um uns auf das vorzubereiten, was in Ansible 2.9 benötigt wird, hat diese Ansible-Rolle den ersten Satz von Werkzeugen bereitgestellt, um bei der Analyse von Befehlen, der Verwaltung von Teams und dem Sammeln von Daten für Netzwerkgeräte zu helfen.

Wenn Sie mit der Verwendung von Network Engine vertraut sind, ist dies ein sehr effizienter Weg, um Fakten zu sammeln, zu analysieren und Daten für die Verwendung in Ansible zu standardisieren. Der Nachteil dieser Rolle besteht darin, dass Sie eine ganze Reihe von Parsern für jede Plattform und für alle Netzwerkaktivitäten erstellen müssen. Um zu verstehen, wie schwierig es ist, Parser zu erstellen, bereitzustellen und zu warten, werfen Sie einen Blick auf über 1200 Parser von den Jungs von Cisco.

Kurz gesagt, für eine skalierbare Automatisierung ist es sehr wichtig, Fakten von Geräten zu erhalten und sie in Schlüssel-Wert-Paare zu normalisieren. Dies ist jedoch schwierig, wenn Sie viele Anbieter und Netzwerkplattformen haben.

Jeder Netzwerkfakten-Modul 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 jedem Release eines aktualisierten Netzwerkmoduls das Faktenmodul verbessert, um Daten über diesen Abschnitt der Konfiguration bereitzustellen. Das heißt, die Entwicklung von Fakten und Modulen erfolgt jetzt im Einklang, und sie teilen sich immer eine gemeinsame Datenstruktur.

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_resourceszu sammeln und umzuwandeln. Die Ressourcennamen entsprechen den Modulnamen, was sehr praktisch ist.

Während des Sammelns von Fakten:

Mit dem Schlüsselwort gather_facts kann die aktuelle Konfiguration des Geräts zu Beginn des Playbooks extrahiert werden, und dann kann sie während des gesamten Playbooks verwendet werden. Geben Sie die einzelnen Ressourcen an, die vom Gerät extrahiert werden sollen.

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

Möglicherweise haben Sie in diesen Beispielen etwas Neues bemerkt, nämlich — gather_facts: true jetzt verfügbar für die native Erfassung von Fakten für Netzwerkgeräte.

Verwendung des Moduls für Netzwerkfakten direkt:

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

Das Playbook gibt folgende Fakten zur 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 sie in strukturierte Daten umwandelt, um sie in Form von Standard-Schlüssel-Wert-Paaren für nachfolgende Aufgaben und Operationen zu verwenden.

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

Ressourcenmodule

Wir haben Fakten extrahiert, die Daten normalisiert, sie in ein standardisiertes internes Schema für Datenstrukturen umgesetzt und eine bereitgestellte Quelle der Wahrheit erhalten. Hurra! Das ist natürlich großartig, aber wir müssen dennoch einen Weg finden, um Schlüssel-Wert-Paare zurück in eine bestimmte Konfiguration zu transformieren, die von der spezifischen Plattform des Geräts erwartet wird. Nun benötigen wir Module für bestimmte Plattformen, um diesen neuen Anforderungen an Faktensammlung und Normalisierung gerecht zu werden.

Was ist ein Ressourcenmodul? Die Abschnitte der Gerätekonfiguration können als Ressourcen betrachtet werden, die dieses Gerät bereitstellt. Netzwerkressourcenmodule sind absichtlich auf eine Ressource beschränkt, die wie Bausteine stapelbar sind, um komplexe Netzwerkdienste zu konfigurieren. Dadurch werden die Anforderungen und Spezifikationen für das Ressourcenmodul auf natürliche Weise vereinfacht, da das Ressourcenmodul lesen kann und und einen bestimmten Netzwerkdienst auf dem Netzwerkgerät konfigurieren.

Um zu erklären, was das Ressourcenmodul macht, betrachten wir ein Beispiel-Playbook, das eine identische Operation mit neuen Netzwerkressourcenfakten und dem Modul eos_l3_interface.

- name: Beispiel für das Zurückdrücken von Fakten an das Gerät.
  hosts: arista
  gather_facts: false
  tasks:
  - name: arista eos-Fakten erfassen
    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 die Konfiguration unverändert bleibt
    assert:
      that: not result.changed

Wie Sie sehen, wurden die gesammelten Daten vom Gerät direkt an das entsprechende Ressourcenmodul übergeben, ohne dass eine Umwandlung stattfand. Beim Ausführen des Playbooks werden die Werte vom Gerät abgerufen und mit den erwarteten verglichen. In diesem Beispiel entsprechen die erhaltenen Werte den erwarteten (das heißt, die Konfigurationsabweichung wird überprüft), und es wird eine Nachricht ausgegeben, ob sich die Konfiguration geändert hat.

Der ideale Weg, um Konfigurationsabweichungen zu erkennen, besteht darin, Fakten in Ansible-Variablen zu speichern und diese regelmäßig zusammen mit dem Ressourcenmodul im Prüfmodus zu verwenden. Dies ist eine einfache Methode, um zu erkennen, ob jemand die Werte manuell geändert hat. In den meisten Fällen erlauben Organisationen manuelle Änderungen und Konfigurationen, obwohl viele Operationen ü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 angesehen werden kann) werden die Module und Fakten gleichzeitig in allen unterstützten Netzwerkbetriebssystemen weiterentwickelt. Wir glauben, dass wenn Ansible die Konfiguration einer Ressource auf einer Netzwerkplattform unterstützt, wir sie überall unterstützen sollten. Dies vereinfacht die Nutzung der Ressourcenmodule, denn der Netzwerkautomatisierungsingenieur kann jetzt Ressourcen (z. B. LLDP) in allen Netzwerkbetriebssystemen mit nativen und unterstützten Modulen konfigurieren.

2) Ressourcenmodule enthalten jetzt den Statuswert.

merged: die Konfiguration wurde 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 Ressourcenausgaben werden entfernt;
zu verwenden, in dem das Datum und die Uhrzeit der logischen Löschung des Eintrags gespeichert sind. Nach der logischen Löschung wird der markierte Eintrag von der Quelle in den Empfänger übertragen (entsprechend der oben beschriebenen Logik).: die Ressourcenkonfiguration wird standardmäßig entfernt/wiederhergestellt.

3) Die Ressourcenmodule umfassen nun stabile Rückgabewerte. Wenn das Modul für die Netzwerkressource die notwendigen Änderungen am Netzwerkgerät vorgenommen (oder vorgeschlagen) hat, gibt es dieselben Schlüssel-Wert-Paare im Playbook zurück.

before: Konfiguration am Gerät in Form von strukturierten Daten vor der Aufgabe;
nach: Wenn sich das Gerät geändert hat (oder sich ändern kann, wenn der Prüfmodus verwendet wird), wird die resultierende Konfiguration in Form von strukturierten 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, aber wir hoffen, dass Sie am Ende besser verstehen, was Unternehmensanwender über die Sammlung von Fakten, die Daten-Normalisierung und den Konfigurationszyklus der Automatisierungsplattform anfordern. Warum benötigen sie diese Verbesserungen? Viele Organisationen befinden sich zurzeit auf einem Weg der digitalen Transformation, um ihre IT-Umgebungen flexibler und wettbewerbsfähiger zu gestalten. Ob das gut oder schlecht ist, viele Netzwerkingenieure entwickeln sich zum Netzwerkentwickler – aus eigenem Interesse oder auf Anweisung der Vorgesetzten.

Organisationen erkennen, dass die Automatisierung einzelner Netzwerkvorlagen das Problem der Fragmentierung nicht löst und die Effizienz nur bis zu einem bestimmten Punkt steigert. Die Red Hat Ansible Automation Platform bietet strenge und normierende Datenmodelle für Ressourcen, um programmgesteuert auf die Basisdaten am Netzwerkgerät zuzugreifen. Das bedeutet, dass Benutzer schrittweise von individuellen Konfigurationsmethoden zu modernen Methoden mit Fokus auf Technologien (z. B. IP-Adressen, VLAN, LLDP usw.) übergehen, anstatt sich auf spezielle Implementierungen der Anbieter zu stützen.

Bedeutet das, dass die Tage von vertrauenswürdigen und getesteten Modulen für Teams und Konfigurationen gezählt sind? Keineswegs. Die erwarteten Module für Netzwerkressourcen werden nicht in allen Fällen und nicht für jeden Anbieter anwendbar sein, weshalb Netzwerkingenieure die Module für Teams und Konfigurationen weiterhin für bestimmte Implementierungen benötigen werden. Das 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 leichter fallen, ihre Konfiguration in strukturierte Schlüssel-Wert-Paare zu konvertieren, die als leicht verständliche Quelle der Wahrheit fungieren werden. Durch die Verwendung strukturierter Schlüssel-Wert-Paare kann man von der Ausführung von Konfigurationen auf jedem Gerät zu der Arbeit mit unabhängigen strukturierten Daten übergehen und Netzwerke in den Vordergrund eines „Infrastructure as Code“-Ansatzes bringen.

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 daran erinnern, wie wir den gesamten Arbeitsumfang aufgeteilt haben.

Wir haben 7 Kategorien identifiziert und jedem bestimmte Netzwerkressourcen zugewiesen:

Hinweis: Die in Fettdruck hervorgehobenen Ressourcen waren für Ansible 2.9 geplant und umgesetzt.
Basierend auf dem Feedback von Unternehmenskunden und der Community war es sinnvoll, zunächst die Module zu behandeln, die mit Protokollen von Netzwerktopologien, Virtualisierung und Schnittstellen verbunden sind.
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 heißt, wir integrieren die benötigten Funktionen und Möglichkeiten direkt in Ansible, um die Standardisierung bei der Entwicklung von Netzwerkmodulen zu unterstützen und die Arbeit der Nutzer auf Rolle- und Playbook-Ebene in Ansible zu erleichtern. Um die Entwicklung von Ressourcenmodulen zu erweitern, hat das Ansible-Team das Tool Module Builder veröffentlicht.

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

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