Verwenden des juniper.device.config Ansible-Moduls zur Verwaltung der Junos OS-Konfiguration

Das juniper.device.config Modul ermöglicht es Ihnen, die folgenden Operationen auf Junos-Geräten durchzuführen:

• Konfigurationsdaten laden

• Bestätigen der Konfiguration

• Rollback der Konfiguration

• Laden der Rettungskonfiguration

Der grundlegende Prozess zum Vornehmen von Konfigurationsänderungen besteht darin, die Konfiguration zu sperren, die Konfigurationsänderungen zu laden, die Konfiguration zu bestätigen, um sie zu aktivieren, und dann die Konfiguration zu entsperren. Das Benutzerkonto, das zum Vornehmen von Konfigurationsänderungen verwendet wird, muss über Berechtigungen zum Ändern der relevanten Teile der Konfiguration auf jedem Gerät verfügen. Um die Konfiguration zu ändern, muss die Argumentliste des Moduls einen der folgenden Parameter enthalten:

• load– Laden Sie neue Konfigurationsdaten.

• rollback– Kehrt zur Rettungskonfiguration oder einer zuvor festgeschriebenen Konfiguration zurück.

Standardmäßig nimmt das juniper.device.config Modul Änderungen an der Kandidatenkonfigurationsdatenbank mithilfe des configure exclusive Modus vor, wodurch die globale Kandidatenkonfiguration automatisch gesperrt und entsperrt wird. Sie können auch einen anderen Konfigurationsmodus angeben. Sie können z. B. Änderungen an einer privaten Kopie der Kandidatenkonfiguration oder an der Datenbank für kurzlebige Konfigurationen vornehmen. Weitere Informationen zum Angeben des Konfigurationsmodus finden Sie unter Angeben des Konfigurationsmodus.

Beim Laden neuer Konfigurationsdaten können Sie neben dem Konfigurationsmodus auch den Ladevorgang sowie die Quelle und das Format der Änderungen angeben.

• Ladevorgang (Load Operation) – Der Ladevorgang bestimmt, wie die Konfigurationsdaten in die ausgewählte Konfigurationsdatenbank geladen werden. Sie können aus vielen der gleichen Ladevorgänge auswählen, die in der Junos OS CLI CLI verfügbar sind. Weitere Informationen finden Sie unter Angeben der Ladeaktion.

• Format: Sie können Junos-Geräte in einem der unterstützten Standardformate konfigurieren. Sie können Konfigurationsdaten oder Jinja2-Vorlagen als Text, Junos XML-Elemente, Junos OS-Befehle set oder JSON bereitstellen. Informationen zum Angeben des Formats der Konfigurationsdaten finden Sie unter Angeben des Formats der zu ladenden Konfigurationsdaten.

• Konfigurationsdatenquelle: Sie können Konfigurationsdaten aus einer Liste von Zeichenfolgen, einer Datei auf dem lokalen Ansible-Steuerungsknoten, einer Jinja2-Vorlage oder einer vom Clientgerät aus erreichbaren URL laden. Weitere Informationen zum Angeben der Quelle der Konfigurationsdaten finden Sie in den folgenden Abschnitten:

  • Laden von Konfigurationsdaten als Zeichenfolgen

  • So laden Sie Konfigurationsdaten aus einer lokalen oder Remote-Datei

  • So laden Sie Konfigurationsdaten mit einer Jinja2-Vorlage

Das juniper.device.config Modul ermöglicht es Ihnen auch, die Rettungskonfiguration zu laden und zu bestätigen oder die Konfiguration auf eine zuvor festgeschriebene Konfiguration zurückzusetzen. Um die Rettungskonfiguration oder eine zuvor festgeschriebene Konfiguration zu laden, müssen Sie das rollback Argument Modul einschließen. Weitere Informationen finden Sie in den folgenden Abschnitten:

• So laden Sie die Rettungskonfiguration

• Zurücksetzen der Konfiguration

Nachdem Sie die Konfiguration geändert haben, müssen Sie die Konfiguration bestätigen, um sie zur aktiven Konfiguration auf dem Gerät zu machen. Standardmäßig übernimmt das juniper.device.config Modul die Änderungen an der Konfiguration. Informationen zum Ändern dieses Verhaltens oder zum Bereitstellen zusätzlicher Commit-Optionen finden Sie unter Bestätigen der Konfiguration.

Wenn das juniper.device.config Modul die load Argumente or rollback enthält, gibt die Antwort des Moduls standardmäßig automatisch die Konfigurationsänderungen im Diff - oder Patch-Format zurück. Das Modul gibt die Unterschiede in den diff Feldern und diff_lines zurück. Um zu verhindern, dass das Modul die Differenzen berechnet und zurückgibt, setzen Sie das diff Argument Modul auf false.

Sie können den Konfigurationsmodus angeben, der beim Ändern der Gerätekonfiguration verwendet werden soll. Um den Konfigurationsmodus in Ihrer Aufgabe anzugeben, fügen Sie den Parameter des config_mode Moduls ein. Zu den unterstützten Konfigurationsmodi gehören:

• batch

• dynamic

• ephemeral

• exclusive

• private

Standardmäßig nimmt das juniper.device.config Modul Änderungen an der Kandidatenkonfigurationsdatenbank mithilfe des configure exclusive Modus vor. Der exklusive Modus "Exklusiv konfigurieren" sperrt die globale Kandidatenkonfiguration (auch als freigegebene Konfigurationsdatenbank bezeichnet) so lange, wie das Modul benötigt, um die angeforderten Konfigurationsänderungen vorzunehmen. Durch das Sperren der Datenbank wird verhindert, dass andere Benutzer gleichzeitig Änderungen an der Datenbank vornehmen oder festschreiben.

Die folgenden Beispiele zeigen, wie eine private Kopie der Kandidatenkonfiguration und die kurzlebige Datenbank konfiguriert werden.

• Beispiel: config_mode: "private"
• Konfigurieren der flüchtigen Datenbank

Das juniper.device.config Modul unterstützt das Laden von Konfigurationsänderungen mit vielen der gleichen Ladevorgänge, die in der Junos OS CLI CLI unterstützt werden. Sie geben die Ladeoperation an, indem Sie das load Argument des Moduls auf den Wert der entsprechenden Ladeoperation setzen. Tabelle 2 fasst die Argumentwerte für die verschiedenen Ladevorgänge zusammen.

Tabelle 2: Parameter für die Angabe der Ladeoperation

Vorgang laden	load Argumentation	Beschreibung
load merge	load: merge	Führen Sie die geladene Konfiguration mit der vorhandenen Konfiguration zusammen.
load override	load: override	Ersetzen Sie die gesamte Konfiguration durch die geladene Konfiguration. Alle Systemprozesse analysieren die Konfiguration.
load patch	load: patch	Konfigurationsdaten aus einer Patch-Datei laden.
load replace	load: replace	Führen Sie die geladene Konfiguration mit der vorhandenen Konfiguration zusammen, ersetzen Sie jedoch Anweisungen in der vorhandenen Konfiguration durch Anweisungen in der geladenen Konfiguration, die das replace: Tag angeben. Wenn sich die Anweisung nicht in der vorhandenen Konfiguration befindet, wird die Anweisung in der geladenen Konfiguration hinzugefügt.
load set	load: set	Laden Sie Konfigurationsdaten im set Format. Die Konfigurationsdaten werden Zeile für Zeile geladen und können Konfigurationsmodusbefehle wie set, deleteund deactivateenthalten.
load update	load: update	Laden Sie eine vollständige Konfiguration und vergleichen Sie sie mit der vorhandenen Konfiguration. Ersetzen Sie nur die Teile der Kandidatenkonfiguration, die sich geändert haben. Während des Commitvorgangs analysieren nur betroffene Systemprozesse die neue Konfiguration.

Das juniper.device.config Modul ermöglicht es Ihnen, Junos-Geräte mit einem der unterstützten Standardformate zu konfigurieren. Sie können Konfigurationsdaten als Zeichenfolgen oder Dateien bereitstellen. Dateien können entweder Konfigurationsdaten oder Jinja2-Vorlagen enthalten. Wenn Sie Konfigurationsdaten in einer Zeichenfolge, Datei oder Jinja2-Vorlage bereitstellen, werden Text, Junos XML-Elemente, Junos OS-Befehle set und JSON unterstützt.

Das juniper.device.config Modul versucht, das Format der Konfigurationsdaten, die Sie als Zeichenfolgen innerhalb des lines Arguments angeben, automatisch zu erkennen. Sie können jedoch das Format für Zeichenfolgen explizit angeben, indem Sie das format Argument einschließen. Wenn Sie Konfigurationsdaten in einer Datei oder Jinja2-Vorlage bereitstellen, müssen Sie das Format der Daten angeben. Fügen Sie der Datei die entsprechende Erweiterung hinzu oder fügen Sie das format Argument ein.

Tabelle 3 fasst die unterstützten Formate für die Konfigurationsdaten und den entsprechenden Wert für die Dateierweiterung und format den Parameter zusammen. Wenn Sie das format Argument angeben, überschreibt es sowohl das Format für die automatische Erkennung von Zeichenfolgen als auch das Format, das durch eine Dateierweiterung angegeben wird.

Tabelle 3: Angeben des Formats für Konfigurationsdaten

Datenformat für die Konfiguration	Dateiendung	format Parameter
CLI-Konfigurationsanweisungen (Text)	.conf	text
JavaScript-Objektnotation (JSON)	.json	json
set Junos OS Befehle	.set	set
Junos XML-Elemente	.xml	xml

Hinweis:

Wenn Sie das load Argument des Moduls auf override oder updatesetzen, können Sie das Junos OS-Befehlsformat set nicht verwenden.

Das juniper.device.config Modul ermöglicht es Ihnen, Konfigurationsdaten aus einer Liste von Zeichenfolgen zu laden. Um Konfigurationsdaten als Zeichenfolgen zu laden, schließen Sie das entsprechende load Argument und das lines Argument ein. Das lines Argument verwendet eine Liste von Zeichenfolgen, die die zu ladenden Konfigurationsdaten enthalten.

Das Modul versucht, das Format der lines Konfigurationsdaten automatisch zu erkennen. Sie können das Format jedoch explizit angeben, indem Sie das format Argument einschließen. Informationen zum Angeben des Formats finden Sie unter Angeben des Formats der zu ladenden Konfigurationsdaten. Wenn Sie das format Argument angeben, wird das automatisch erkannte Format überschrieben.

Im folgenden Playbook werden zwei Op-Skripte konfiguriert und committet. In diesem Fall hat das load Argument den Wert, 'set' weil die Konfigurationsdaten in lines das Junos OS-Anweisungsformat set verwenden.

Im folgenden Playbook werden die gleichen Anweisungen mit lines Konfigurationsdaten im Textformat konfiguriert. In diesem Fall verwendet load: "merge"das Beispiel .

Das juniper.device.config Modul ermöglicht es Ihnen, Konfigurationsdaten aus einer Datei zu laden. Die Datei kann sich an einem der folgenden Speicherorte befinden:

• Ansible-Steuerungsknoten

• Client-Gerät

• FTP- oder HTTP-URL, die vom Clientgerät aus erreichbar ist

Wenn Sie Konfigurationsdaten aus einer Datei laden, müssen Sie den Speicherort der Datei und das Format der Konfigurationsdaten in der Datei angeben. Zu den unterstützten Konfigurationsdatenformaten gehören Text, Junos XML-Elemente, Junos OS-Befehle set und JSON. Informationen zum Laden von Dateien, die Jinja2-Vorlagen enthalten, finden Sie unter So laden Sie Konfigurationsdaten mithilfe einer Jinja2-Vorlage.

Um das Format anzugeben, fügen Sie den Parameter des format Moduls ein oder fügen Sie der Konfigurationsdatendatei die entsprechende Erweiterung hinzu. Wenn Sie den format Parameter angeben, überschreibt er das durch die Dateierweiterung angegebene Format. Informationen zum Angeben des Formats finden Sie unter Angeben des Formats der zu ladenden Konfigurationsdaten. Wenn die Konfigurationsdaten das Junos-XML-Format verwenden, müssen Sie die Daten in das Tag der obersten Ebene <configuration> einschließen.

Hinweis:

Sie müssen keine Konfigurationsdaten einschließen, die als Text, Junos OS-Befehle set oder JSON in <configuration-text>formatiert sind, <configuration-set>oder <configuration-json> Tags, wie es bei der Konfiguration des Geräts direkt in einer NETCONF-Sitzung erforderlich ist.

In Tabelle 4 sind die Modulparameter aufgeführt, die Sie einschließen können, um den Speicherort der Datei anzugeben.

Tabelle 4: Festlegen des Speicherorts der Konfigurationsdatei

Modul-Parameter	Beschreibung
src	Absoluter oder relativer Pfad zu einer Datei auf dem Ansible-Steuerungsknoten. Das Standardverzeichnis ist das Playbook-Verzeichnis.
url	Absoluter oder relativer Pfad zu einer Datei auf dem Client-Gerät. Das Standardverzeichnis auf dem Clientgerät ist das aktuelle Arbeitsverzeichnis, das standardmäßig das Home-Verzeichnis des Benutzers ist. FTP-URL HTTP-URL

Um Konfigurationsdaten aus einer lokalen Datei auf dem Ansible-Steuerungsknoten zu laden, setzen Sie das src Argument auf den absoluten oder relativen Pfad der Datei, die die Konfigurationsdaten enthält. Zum Beispiel:

Verwenden Sie den url Parameter, um Konfigurationsdaten aus einer Datei auf dem Junos-Gerät oder von einer FTP- oder HTTP-URL zu laden. Geben Sie den Pfad oder die URL der zu ladenden Datei an. Zum Beispiel:

Der Wert für url kann ein absoluter oder relativer lokaler Dateipfad, ein FTP-Speicherort oder eine HTTP-URL sein.

• Der Dateipfad für eine lokale Datei auf dem Zielgerät hat eine der folgenden Formen:

  • /path/filename—Datei auf einem gemounteten Dateisystem, entweder auf der lokalen Flash-Disk oder auf der Festplatte.

  • ein:filename oder a:path/filename—Datei auf dem lokalen Laufwerk. Der Standardpfad ist / (das Verzeichnis auf Stammebene). Die Wechselmedien können im MS-DOS- oder UNIX-Format (UFS) vorliegen.

• Der Dateipfad für eine Datei auf einem FTP-Server hat das folgende Format:

• Der Dateipfad für eine Datei auf einem HTTP-Server hat das folgende Format:

In jedem Fall ist der Standardwert für die path Variable das Home-Verzeichnis für den Benutzer. Um einen absoluten Pfad anzugeben, beginnt die Anwendung den Pfad mit den Zeichen %2F; z. B. ftp://username:password@hostname/%2Fpath/filename.

Das juniper.device.config Modul ermöglicht es Ihnen, Konfigurationsdaten aus einer Jinja2-Vorlagendatei auf dem Ansible-Steuerknoten zu rendern und die Konfiguration auf ein Junos-Gerät zu laden und zu bestätigen. Jinja ist eine Vorlagen-Engine für Python, mit der Sie Dokumente aus vordefinierten Vorlagen generieren können. Die Vorlagen, bei denen es sich um Textdateien in der gewünschten Sprache handelt, bieten Flexibilität durch die Verwendung von Ausdrücken und Variablen. Sie können Junos OS-Konfigurationsdaten mithilfe von Jinja2-Vorlagen in einem der unterstützten Konfigurationsformate erstellen, einschließlich ASCII-Text, Junos XML-Elementen, Junos OS-Befehlen set und JSON. Das Ansible-Modul verwendet die Jinja2-Vorlage und ein bereitgestelltes Wörterbuch von Variablen, um die Konfigurationsdaten zu rendern.

Um Konfigurationsdaten mit einer Jinja2-Vorlage zu laden und zu committen, fügen Sie die Parameter und vars in template die Argumentliste des Moduls ein.

• template– Pfad der Jinja2-Vorlagendatei

• vars– Wörterbuch der Schlüssel und Werte, die zum Rendern der Jinja2-Vorlage erforderlich sind

Sie müssen den format Parameter auch dann einschließen, wenn die Dateierweiterung der Vorlage das Format der Daten nicht angibt. Informationen zum Angeben des Formats finden Sie unter Angeben des Formats der zu ladenden Konfigurationsdaten.

Die Datei interfaces-mpls.j2 enthält beispielsweise die folgende Jinja2-Vorlage:

Um das juniper.device.config Modul zum Laden der Vorlage Jinja2 zu verwenden, setzen Sie das template Argument auf den Pfad der Vorlagendatei. Definieren Sie die Variablen, die von der Vorlage im vars Wörterbuch benötigt werden.

Im folgenden Playbook werden die Jinja2-Vorlage und das vars Wörterbuch verwendet, um die Konfigurationsdaten zu rendern. Der format Parameter gibt das Format der Konfigurationsdaten in der Vorlagendatei an. Das Playbook lädt die Konfiguration und führt sie auf den Zielhost aus.

Das Modul generiert die folgenden Konfigurationsdaten. Das Modul lädt die Daten in die Kandidatenkonfiguration auf dem Gerät und führt sie aus.

Mit einer Rettungskonfiguration können Sie eine bekannte Arbeitskonfiguration oder eine Konfiguration mit bekanntem Status definieren, die Sie jederzeit wiederherstellen können. Sie verwenden die Rettungskonfiguration, wenn Sie zu einer bekannten Konfiguration zurückkehren müssen, oder als letzten Ausweg, wenn die Gerätekonfiguration und die Sicherungskonfigurationsdateien irreparabel beschädigt sind. Wenn Sie eine Rettungskonfiguration erstellen, speichert das Gerät die zuletzt festgeschriebene Konfiguration als Rettungskonfiguration.

Das juniper.device.config Modul ermöglicht es Ihnen, zu einer bestehenden Rettungskonfiguration auf Junos-Geräten zurückzukehren. Um die Rettungskonfiguration auf ein Gerät zu laden und zu bestätigen, schließen Sie das Argument des rollback: rescue Moduls ein. Zum Beispiel:

Junos-Geräte speichern je nach Plattform eine Kopie der zuletzt übertragenen Konfiguration und bis zu 49 vorherige Konfigurationen. Sie können zu jeder der gespeicherten Konfigurationen zurückkehren. Diese Funktion ist nützlich, wenn Konfigurationsänderungen unerwünschte Ergebnisse verursachen und Sie zu einer bekannten funktionierenden Konfiguration zurückkehren möchten. Das Zurücksetzen der Konfiguration ähnelt dem Vorgang zum Vornehmen von Konfigurationsänderungen auf dem Gerät. Anstatt jedoch Konfigurationsdaten zu laden, führen Sie ein Rollback durch, bei dem die gesamte Kandidatenkonfiguration durch eine zuvor festgeschriebene Konfiguration ersetzt wird.

Mit dem juniper.device.config Modul können Sie auf Junos-Geräten zu einer zuvor festgeschriebenen Konfiguration zurückkehren. Um die Konfiguration zurückzusetzen und zu bestätigen, schließen Sie das Argument des rollback Moduls ein und geben Sie die ID der Rollback-Konfiguration an. Gültige ID-Werte sind 0 (Null, für die zuletzt festgeschriebene Konfiguration) bis eins weniger als die Anzahl der gespeicherten vorherigen Konfigurationen (Maximum ist 49).

Im folgenden Playbook werden Sie zunächst zur Eingabe der Rollback-ID der wiederherzustellenden Konfiguration aufgefordert. Die erste Aufgabe setzt die Konfiguration auf die angeforderte Version zurück und führt einen Commit aus. Die zweite Aufgabe gibt die Konfigurationsunterschiede in der Standardausgabe aus.

Wenn Sie das juniper.device.config Modul zum Ändern der Konfiguration verwenden, führt das Modul standardmäßig automatisch eine Commit-Prüfung durch und führt die Änderungen aus. Um zu verhindern, dass das Modul eine Commit-Prüfung durchführt oder die Änderungen festschreibt, setzen Sie das check Argument or commit auf false.

Sie können den Commit-Vorgang auch mit vielen der gleichen Optionen anpassen, die in der Junos OS CLI-CLI verfügbar sind. Tabelle 5 beschreibt die Modul-Argumente, mit denen Sie verschiedene Commit-Optionen angeben können.

Tabelle 5: Commit-Optionen

Modul-Argument	Beschreibung	Standardwert für load und rollback Operationen
check: boolean	Führen Sie eine Commit-Prüfung durch oder bestätigen Sie einen zuvor bestätigten Commit-Vorgang.	true
check_commit_wait: seconds	Warten Sie die angegebene Anzahl von Sekunden zwischen der Commit-Prüfung und dem Commit-Vorgang.	–
comment: "string"	Protokollieren Sie einen Kommentar für diesen Commitvorgang in der Systemprotokolldatei und im Commitverlauf des Geräts.	–
commit: boolean	Bestätigen Sie die Konfigurationsänderungen oder bestätigen Sie einen zuvor bestätigten Commit-Vorgang.	true
commit_empty_changes: boolean	Bestätigen Sie die Konfiguration, auch wenn die Kandidatenkonfiguration keine Änderungen enthält.	false
commit_force_sync: boolean	Synchronisieren und bestätigen Sie die Konfiguration auf allen Routing-Engines, auch wenn die andere Routing-Engine über offene Konfigurationssitzungen oder nicht festgelegte Konfigurationsänderungen verfügt.	false
commit_sync: boolean	Synchronisieren und bestätigen Sie die Konfiguration auf allen Routing-Engines.	false
confirmed: minutes	Erfordern, dass ein Commitvorgang innerhalb eines bestimmten Zeitraums nach dem ersten Commit bestätigt wird. Wenn Sie den Commit nicht innerhalb der angegebenen Zeit bestätigen, führen Sie ein Rollback auf die zuvor festgeschriebene Konfiguration durch. Bestätigen Sie den Commit entweder mit der commit: true Option oder der check: true Option.	–
timeout: seconds	Warten Sie auf den Abschluss des Vorgangs mit dem angegebenen Wert als Zeitüberschreitung.	30 Sekunden

Kommentar bestätigen

Wenn Sie die Konfiguration bestätigen, können Sie einen kurzen Kommentar einfügen, um den Zweck der festgeschriebenen Änderungen zu beschreiben. Um einen Kommentar zu protokollieren, der die Änderungen beschreibt, schließen Sie das comment: "comment string" Argument in die Nachrichtenzeichenfolge ein.

Commit-Prüfung

Standardmäßig führt das juniper.device.config Modul sowohl eine Commit-Prüfung als auch eine Commit-Operation aus. Das check_commit_wait Argument definiert die Anzahl der Sekunden, die zwischen der Commit-Prüfung und den Commit-Operationen gewartet werden soll. Fügen Sie dieses Argument ein, wenn Sie dem Gerät genügend Zeit geben müssen, um den Commit-Überprüfungsvorgang abzuschließen und die Konfigurationssperre aufzuheben, bevor der Commit-Vorgang initiiert wird. Wenn das Gerät den Commit-Vorgang initiiert, bevor der Commit-Prüfvorgang seine Sperre für die Konfiguration aufhebt, schlägt der Commit-Vorgang fehl und das Modul gibt eine .CommitError

Leere Änderungen bestätigen

Wenn die Kandidatenkonfiguration und die festgeschriebene Konfiguration keine Unterschiede aufweisen, übernimmt das Modul die Änderungen standardmäßig nicht. Um einen Commitvorgang zu erzwingen, auch wenn keine Unterschiede vorhanden sind, schließen Sie das commit_empty_changes: true Argument ein.

Commit Synchronisieren

Wenn das Gerät über zwei Routing-Engines verfügt, können Sie die Konfiguration auf beiden Routing-Engines synchronisieren und bestätigen, indem Sie das commit_sync: true Argument einfügen. Um zu erzwingen, dass der commit synchronize Vorgang auch dann erfolgreich ist, wenn die andere Routing-Engine über offene Konfigurationssitzungen oder nicht festgeschriebene Konfigurationsänderungen verfügt, verwenden Sie das commit_force_sync: true Argument. Wenn Sie diese commit_force_sync: true Option angeben, beendet das Gerät alle Konfigurationssitzungen auf der anderen Routing-Engine, bevor die Konfiguration synchronisiert und festgeschrieben wird.

Commit Bestätigen

Um zu verlangen, dass ein Commitvorgang innerhalb eines bestimmten Zeitraums nach dem ersten Commit bestätigt werden muss, schließen Sie das confirmed: minutes Argument ein. Wenn Sie den Commit nicht innerhalb des angegebenen Zeitlimits bestätigen, wird die Konfiguration automatisch auf die zuvor festgeschriebene Konfiguration zurückgesetzt. Der zulässige Bereich liegt zwischen 1 und 65.535 Minuten. Der bestätigte Commit-Vorgang ist nützlich, um zu überprüfen, ob eine Konfigurationsänderung ordnungsgemäß funktioniert und den Verwaltungszugriff auf das Gerät nicht verhindert. Wenn die Änderung den Zugriff verhindert oder andere Fehler verursacht, ermöglicht das automatische Rollback auf die vorherige Konfiguration den Zugriff auf das Gerät, nachdem der Rollback-Stichtag abgelaufen ist. Um den Commit-Vorgang zu bestätigen, rufen Sie das juniper.device.config Modul mit dem check: true Argument or commit: true auf.

Im folgenden Playbook ändert die erste Aufgabe die Konfiguration, wartet 10 Sekunden zwischen der Commit-Prüfung und dem Commit-Vorgang und erfordert, dass der Commit-Vorgang innerhalb von 5 Minuten bestätigt wird. Außerdem wird ein Kommentar für den Commit protokolliert. Die zweite Aufgabe gibt einen commit check Vorgang aus, um den Commit zu bestätigen. In einem realen Szenario können Sie Validierungsaufgaben nach dem ersten Commit ausführen und die Commitbestätigung nur ausführen, wenn die Aufgaben bestimmte Validierungskriterien erfüllen.

Das juniper.device.config Modul ermöglicht es Ihnen, die Konfiguration auf Junos-Geräten zu ändern und zu bestätigen. In einigen Fällen kann die RPC-Antwort Elemente mit dem Schweregrad Warnung oder höher enthalten <rpc-error> , die dazu führen, dass das Modul eine RpcError Ausnahme auslöst. Eine RpcError Ausnahme kann dazu führen, dass der Lade- oder Commitvorgang fehlschlägt.

In bestimmten Fällen kann es notwendig oder wünschenswert sein, die Ausnahmen zu unterdrücken, die RpcError als Reaktion auf Warnungen für Lade- und Commitvorgänge ausgelöst werden. Sie können das juniper.device.config Modul anweisen, Ausnahmen zu unterdrücken RpcError , die für Warnungen ausgelöst werden, indem Sie den ignore_warning Parameter in die Argumentliste des Moduls aufnehmen. Das ignore_warning Argument akzeptiert einen booleschen Wert, eine Zeichenfolge oder eine Liste von Zeichenfolgen.

Um das Modul anzuweisen, alle Warnungen für Lade- und Commit-Operationen zu ignorieren, die vom Modul ausgeführt werden, fügen Sie das ignore_warning: true Argument ein. Im folgenden Beispiel werden alle Warnungen für Lade- und Commitvorgänge ignoriert.

Wenn Sie einschließen ignore_warning: true und alle <rpc-error> Elemente einen Schweregrad von Warnung haben, ignoriert die Anwendung alle Warnungen und löst keine RpcError Ausnahme aus. Alle <rpc-error> Elemente mit höheren Schweregraden lösen jedoch weiterhin Ausnahmen aus.

Um das Modul anzuweisen, bestimmte Warnungen zu ignorieren, setzen Sie das ignore_warning Argument auf eine Zeichenkette oder eine Liste von Zeichenfolgen, die die zu ignorierenden Warnungen enthalten. Im folgenden Beispiel werden zwei spezifische Warnungen ignoriert:

Das Modul unterdrückt RpcError Ausnahmen, wenn alle <rpc-error> Elemente den Schweregrad Warnung aufweisen und jede Warnung in der Antwort mit einer oder mehreren der angegebenen Zeichenfolgen übereinstimmt.