Verwenden von Ansible zum Abrufen oder Vergleichen von Junos OS-Konfigurationen

Wenn Sie das juniper.device.config Modul zum Abrufen der Konfiguration verwenden, müssen Sie den retrieve Parameter in die Argumentliste des Moduls aufnehmen. Der retrieve Parameter gibt die Konfigurationsdatenbank an, aus der die Daten abgerufen werden sollen. Sie können die folgenden Werte festlegen retrieve , um Konfigurationsdaten aus der jeweiligen Datenbank zurückzugeben:

• retrieve: 'candidate': Ruft Daten aus der Kandidatenkonfiguration ab.

• retrieve: 'committed': Ruft Daten aus der festgeschriebenen Konfiguration ab.

Committed-Konfigurationsdatenbank

Mit dem folgenden Playbook wird die vollständige bestätigte Konfiguration im Textformat für jedes Gerät in der Bestandslistengruppe abgerufen:

Konfigurationsdatenbank für Kandidaten

Mit dem folgenden Playbook wird die vollständige Kandidatenkonfiguration im Textformat für jedes Gerät in der Bestandslistengruppe abgerufen. Das Modul gibt einen Fehler zurück, wenn die Datenbank gesperrt oder geändert ist.

Sie können nicht nur die vollständige Junos OS-Konfiguration abrufen, sondern auch bestimmte Teile der Konfiguration abrufen, indem Sie den Parameter des config Moduls filter einschließen. Der filter Wert des Parameters ist eine Zeichenfolge, die den Teilstrukturfilter enthält, der die zurückzugebenden Konfigurationsanweisungen auswählt. Der Teilbaumfilter gibt die Konfigurationsdaten zurück, die den Selektionskriterien entsprechen. Wenn Sie mehrere Hierarchien anfordern, muss der Wert von filter alle Ebenen der Konfigurationshierarchie darstellen, beginnend mit dem Stamm (dargestellt durch das <configuration> Element) bis hin zu jedem anzuzeigenden Element.

Mit dem folgenden Playbook wird die Konfiguration auf der [edit interfaces] Hierarchieebene und [edit protocols] in der Datenbank für die committierte Konfiguration für jedes Gerät abgerufen und ausgegeben:

Das folgende Playbook ruft die Konfiguration für die ge-1/0/1-Schnittstelle ab und gibt sie aus:

Mit dem folgenden Playbook wird die Konfiguration, für die auf der [edit system services] Hierarchieebene ein Commit ausgeführt wurde, abgerufen und ausgegeben:

Wenn Sie das juniper.device.config Modul zum Abrufen der Konfiguration verwenden, ruft das Modul den Junos-XML-Protokollvorgang <get-configuration> auf, der Konfigurationsdaten in verschiedenen Formaten zurückgeben kann. Standardmäßig gibt das Modul Konfigurationsdaten als formatierten Text zurück. Das Textformat verwendet Zeilenumbrüche, Tabulatoren und andere Leerzeichen, geschweifte Klammern und eckige Klammern, um die hierarchischen Beziehungen zwischen den Anweisungen anzugeben.

Um das Format anzugeben, in dem die Konfigurationsdaten zurückgegeben werden sollen, legen Sie den format Parameter des config Moduls auf das gewünschte Format fest. Zu den akzeptablen Werten gehören:

• 'json'– JavaScript-Objektnotation (JSON)

• 'set'– Junos OS-Befehle set

• 'text'– Formatierter Text (Standard)

• 'xml'– Junos-XML-Elemente

In der Playbookausgabe enthalten die config Schlüssel und config_lines die Konfiguration im angeforderten Format. Wenn Sie das Junos XML- oder JSON-Format anfordern, enthält der config_parsed Schlüssel die entsprechende Konfiguration im JSON-Format.

Mit dem folgenden Playbook wird die vollständige, für jedes Gerät in der Bestandslistengruppe festgelegte Konfiguration im XML-Format abgerufen:

Sie können standardisierte oder benutzerdefinierte YANG-Module auf Junos-Geräte laden, um Datenmodelle hinzuzufügen, die von Junos OS nicht nativ unterstützt, aber von der Übersetzung unterstützt werden können. Sie konfigurieren nicht-native Datenmodelle in der Kandidatenkonfiguration mit der für diese Modelle definierten Syntax. Wenn Sie die Konfiguration bestätigen, übersetzen die Übersetzungsskripte des Datenmodells diese Daten und bestätigen die entsprechende Junos OS-Konfiguration als vorübergehende Änderung in der Check-out-Konfiguration.

Die Kandidaten- und aktiven Konfigurationen enthalten die Konfigurationsdaten für nicht native YANG-Datenmodelle in der von diesen Modellen definierten Syntax. Sie können das juniper.device.config Modul verwenden, um Konfigurationsdaten für Standard- (IETF, OpenConfig) und benutzerdefinierte YANG-Datenmodelle sowie die native Junos OS-Konfiguration abzurufen. Standardmäßig sind Konfigurationsdaten für YANG-Datenmodelle von Drittanbietern nicht in der Antwort des Moduls enthalten.

Um Konfigurationsdaten abzurufen, die durch ein nicht-natives YANG-Datenmodell definiert sind, zusätzlich zum Abrufen der Junos OS-Konfiguration, führen Sie das Modul mit dem model Parameter aus und schließen Sie den namespace Parameter ggf. ein. Das model Argument nimmt einen der folgenden Werte an:

• custom– Ruft Konfigurationsdaten ab, die durch benutzerdefinierte YANG-Datenmodelle definiert sind. Sie müssen das namespace Argument beim Abrufen von Daten für benutzerdefinierte YANG-Datenmodelle einschließen.

• ietf– Ruft Konfigurationsdaten ab, die durch IETF-YANG-Datenmodelle definiert sind.

• openconfig– Ruft Konfigurationsdaten ab, die durch OpenConfig-YANG-Datenmodelle definiert sind.

• True– Rufen Sie alle Konfigurationsdaten ab, einschließlich der vollständigen Junos OS-Konfiguration und Daten aus beliebigen YANG-Datenmodellen.

Wenn das model Argument oder openconfigangibtietf, verwendet das Modul automatisch den entsprechenden Namespace. Wenn Sie angebenmodel: "custom", dass Daten für ein benutzerdefiniertes YANG-Datenmodell abgerufen werden sollen, müssen Sie auch das namespace Argument mit dem entsprechenden Namespace einschließen.

Wenn Sie das model Argument mit dem Wert custom, ietfoder openconfig und auch das filter Argument einschließen, um eine bestimmte XML-Teilstruktur zurückzugeben, gibt Junos OS nur die übereinstimmende Hierarchie aus dem nicht nativen Datenmodell zurück. Wenn die Junos OS-Konfiguration eine gleichnamige Hierarchie enthält, z. B. "Schnittstellen", ist diese nicht in der Antwort enthalten. Die filter Option wird bei Verwendung von model: "True"nicht unterstützt.

Wenn Sie das config Modul zum Abrufen von nicht systemeigenen Konfigurationsdaten verwenden, können Sie das Format der zurückgegebenen Daten nur angeben, wenn Sie auch den filter Parameter einschließen. Wenn Sie den Parameter weglassen, müssen format: "xml"Sie angebenfilter.

Das folgende Playbook ruft die OpenConfig-Konfigurationshierarchie interfaces aus der Commited-Konfiguration ab. Wenn Sie das filter Argument weglassen, gibt der RPC die vollständigen Junos OS- und OpenConfig-Konfigurationen zurück.

Mit der folgenden Aufgabe wird die l2vpn Konfigurationshierarchie aus der festgeschriebenen Konfiguration für ein benutzerdefiniertes YANG-Datenmodell mit dem angegebenen Namespace abgerufen:

Mit der folgenden Aufgabe werden die vollständige, für Junos OS festgelegte Konfiguration sowie die Konfigurationsdaten für andere YANG-Datenmodelle abgerufen, die dem Gerät hinzugefügt wurden:

Wenn Sie das juniper.device.config Modul zum Abrufen der Konfiguration verwenden, ruft das Modul den Junos XML-Protokollvorgang <get-configuration> auf. Das Modul unterstützt explizite Argumente für viele der <get-configuration> Attribute, z. B. das format Attribut. Das Modul unterstützt auch das Argument, mit dem options Sie zusätzliche <get-configuration> Attribute einschließen können, für die kein entsprechendes Modulargument vorhanden ist. Das options Argument verwendet ein Wörterbuch von Schlüssel-Wert-Paaren aller Attribute, die von der <get-configuration> Operation unterstützt werden.

Eine vollständige Liste der Attribute, die von der Junos XML-Protokolloperation <get-configuration> unterstützt werden, finden Sie unter <get-configuration>.

Das config Modul ruft z. B. Daten aus der Konfiguration vor der Vererbung ab, in der , <apply-groups-except><groups><apply-groups>, und <interface-range> Tags separate Elemente in der Konfigurationsausgabe sind. Zum Abrufen von Daten aus der Konfiguration nach der Vererbung, in der Anweisungen angezeigt werden, die von benutzerdefinierten Gruppen und Bereichen als untergeordnete Elemente der erbenden Anweisungen geerbt wurden, können Sie das options Argument mit inherit: "inherit"einschließen.

Das folgende Playbook ruft die Konfigurationsdaten auf Hierarchieebene aus der Konfiguration ab, für [edit system services] die nach der Vererbung ein Commit ausgeführt wurde. Wenn die Konfiguration in diesem Fall auch Anweisungen enthält, die auf der [edit groups global system services] Hierarchieebene konfiguriert sind, werden diese Anweisungen unter in [edit system services] der Konfiguration nach der Vererbung vererbt und in den abgerufenen Konfigurationsdaten zurückgegeben.

Wenn Sie das juniper.device.config Modul zum Abrufen der Konfiguration verwenden, können Sie die zurückgegebenen Konfigurationsdaten in einer Datei auf dem lokalen Ansible-Steuerungsknoten speichern, indem Sie den Parameter oder dest des Moduls dest_dir einfügen. Die dest_dir Option gibt nur ein Verzeichnis an, und die dest Option kann sowohl einen Pfad als auch einen Dateinamen angeben. Wenn bereits eine Ausgabedatei mit dem Zielnamen vorhanden ist, überschreibt das Modul die Datei.

Um das Verzeichnis auf dem lokalen Ansible-Kontrollknoten anzugeben, in dem die abgerufenen Konfigurationen gespeichert werden, fügen Sie das dest_dir Argument hinzu und definieren Sie den Pfad zum Zielverzeichnis. Die Konfiguration für jedes Gerät wird in einer separaten Datei mit dem Namen hostname.config gespeichert.

Mit dem folgenden Playbook wird die bestätigte Konfiguration von allen Geräten in der Bestandslistengruppe abgerufen. Das Playbook speichert jede Gerätekonfiguration in einer separaten Datei im Verzeichnis configs unter dem Playbook-Verzeichnis auf dem Ansible-Steuerungsknoten.

Um den Pfad und den Dateinamen für die Ausgabedateien anzugeben, schließen Sie das dest Argument ein und definieren Sie den absoluten oder relativen Pfad der Datei. Wenn Sie das dest Argument einschließen, aber das Verzeichnis weglassen, werden die Dateien im Playbook-Verzeichnis gespeichert. Wenn Sie die Konfiguration für mehrere Geräte abrufen, muss das dest Argument eine Variable enthalten, z. B {{ inventory_hostname }} . um den Dateinamen für jedes Gerät zu unterscheiden. Wenn Sie die Dateinamen nicht unterscheiden, überschreibt die Konfigurationsdatei für jedes Gerät die Konfigurationsdatei der anderen Geräte.

Mit dem folgenden Playbook wird die [edit system services] Hierarchie aus der Datenbank mit der festgeschriebenen Konfiguration auf allen Geräten in der Bestandslistengruppe abgerufen. Das Playbook speichert jede Gerätekonfiguration in einer separaten Datei im Playbook-Verzeichnis auf dem Ansible-Steuerungsknoten. Jede Datei wird durch den Hostnamen des Geräts eindeutig identifiziert.

Wenn Sie die Konfigurationsdaten in Dateien speichern und die Konfigurationsdaten in der Antwort des Moduls nicht duplizieren möchten, können Sie sie optional in die Argumentliste des Moduls aufnehmenreturn_output: false. Die Einstellung return_output auf false bewirkt, dass das Modul die Tasten , config_linesund config_parsed und configin seiner Antwort weglässt. Dies kann erforderlich sein, wenn das Gerät eine beträchtliche Menge an Konfigurationsdaten zurückgibt.

Das juniper.device.config Modul ermöglicht es Ihnen, die aktive Konfiguration mit einer zuvor bestätigten Konfiguration oder Rollback-Konfiguration zu vergleichen. Um die aktive Konfiguration mit einer vorherigen Konfiguration zu vergleichen, schließen Sie die folgenden Modulargumente ein:

Wenn Sie das rollback: id Argument einschließen, führt das Modul standardmäßig ein Rollback der Konfiguration durch, führt eine Commit-Prüfung durch und führt einen Commit für die Änderungen durch. Sie müssen das commit: false Argument einschließen, um nur die Konfigurationen zu vergleichen und zu verhindern, dass das Modul geladen wird und die Rollback-Konfiguration festschreibt. Durch das Einfügen des check: false Arguments wird der unnötige Commit-Check-Vorgang verhindert.

Das Modul gibt die diff Schlüssel und diff_lines zurück. Die Schlüssel enthalten die Konfigurationsunterschiede zwischen der aktiven und der vorherigen Konfiguration im Diff - oder Patch-Format.

• diff— Wörterbuch, das einen einzelnen Schlüssel mit dem Namen prepared und seinen Wert enthält, bei dem es sich um eine einzelne mehrzeilige Zeichenfolge handelt, die die Unterschiede enthält.

• diff_lines: Liste der einzelnen Zeichenfolgen, die die Unterschiede enthalten.

Um die Unterschiede in einer Datei auf dem lokalen Ansible-Kontrollknoten zu speichern, fügen Sie das diffs_file Argument hinzu und definieren Sie den absoluten oder relativen Pfad der Ausgabedatei. Wenn Sie das diffs_file Argument einschließen, aber das Verzeichnis weglassen, werden die Dateien im Playbookverzeichnis gespeichert. Wenn Sie die Konfigurationen auf mehreren Geräten vergleichen, muss das diffs_file Argument eine Variable enthalten, z. B {{ inventory_hostname }} . zur Unterscheidung des Dateinamens für jedes Gerät. Wenn Sie die Dateinamen nicht unterscheiden, überschreibt die Ausgabedatei für jedes Gerät die Ausgabedatei der anderen Geräte.

Das folgende Playbook fordert Sie zur Eingabe der Rollback-ID einer Konfiguration auf, für die zuvor ein Commit ausgeführt wurde. Das Playbook vergleicht dann die Commit-Konfiguration mit der angegebenen Rollbackkonfiguration, speichert den Vergleich in einer Datei mit eindeutigem Namen und gibt auch die Antwort auf die Standardausgabe aus.