Verwenden von Ansible zum Konfigurieren von Junos-Geräten

Mit dem juniper.device.config Modul können Sie die folgenden Vorgänge auf Junos-Geräten ausführen:

• Konfigurationsdaten laden

• Bestätigen der Konfiguration

• Zurücksetzen der Konfiguration

• Laden der Wiederherstellungskonfiguration

Um die Konfiguration zu ändern, muss die Argumentliste des Moduls entweder den load Parameter zum Laden neuer Konfigurationsdaten oder den Parameter zum Zurücksetzen auf die Wiederherstellungskonfiguration oder eine rollback zuvor festgeschriebene Konfiguration enthalten. 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.

Standardmäßig nimmt das Modul mithilfe von config mode Änderungen an der Kandidatenkonfigurationsdatenbank configure exclusive 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 kurzlebigen Konfigurationsdatenbank 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 – Der Ladevorgang bestimmt, wie die Konfigurationsdaten in die ausgewählte Konfigurationsdatenbank geladen werden. Die Funktion unterstützt viele der Ladevorgänge, die auch in der Junos OS 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-Kontrollknoten, einer Jinja2-Vorlage oder einer URL, die vom Client-Gerät aus erreichbar ist, laden, indem Sie den linesParameter , srctemplateoder url einschließen. Weitere Informationen zum Angeben der Quelle der Konfigurationsdaten finden Sie in den folgenden Abschnitten:

  • Laden von Konfigurationsdaten als Zeichenfolgen

  • Laden von Konfigurationsdaten aus einer lokalen oder Remote-Datei

  • Laden von Konfigurationsdaten mithilfe einer Jinja2-Vorlage

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

• So laden Sie die Rescue-Konfiguration

• 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 überträgt das config Modul die Änderungen an die Konfiguration. Informationen zum Ändern dieses Verhaltens oder zum Bereitstellen zusätzlicher Commit-Optionen finden Sie unter Ausführen eines Commit-Commits für die Konfiguration.

Wenn das config Modul die load Argumente or rollback zum Ändern der Konfiguration enthält, gibt das Modul standardmäßig automatisch die Konfigurationsänderungen im Diff - oder Patch-Format in der Antwort des Moduls zurück. Die Differenzen werden in den diff diff_lines Variablen und zurückgegeben. Um zu verhindern, dass das Modul die Differenzen berechnet und zurückgibt, legen Sie das diff Modulargument auf falsefest.

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 Moduls config_mode ein. Zu den unterstützten Konfigurationsmodi gehören:

• batch

• dynamic

• ephemeral

• exclusive

• private

Standardmäßig nimmt das Modul mithilfe configure exclusive von juniper.device.config mode Änderungen an der Kandidatenkonfigurationsdatenbank vor. Der exklusive Konfigurationsmodus sperrt die globale Kandidatenkonfiguration (auch als freigegebene Konfigurationsdatenbank bezeichnet), solange das Modul die angeforderten Änderungen an der Konfiguration vornehmen muss. Durch das Sperren der Datenbank wird verhindert, dass andere Benutzer Änderungen an der Datenbank vornehmen oder einen Commit für die Datenbank ausführen, bis die Sperre aufgehoben wird.

In den folgenden Beispielen wird gezeigt, 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 Ladevorgänge, die auch in der Junos OS CLI unterstützt werden. Sie geben den Ladevorgang an, indem Sie den load Parameter in die Argumentliste des Moduls aufnehmen und auf den Wert des entsprechenden Ladevorgangs festlegen. Tabelle 2 fasst die Parametereinstellungen zusammen, die für jeden Typ von Ladevorgang erforderlich sind.

Tabelle 2: Parameter zum Angeben des Lastvorgangs

Ladevorgang	load-Argument	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.
load patch	load: "patch"	Laden Sie Konfigurationsdaten aus einer Patch-Datei.
load replace	load "replace"	Führen Sie die geladene Konfiguration mit der vorhandenen Konfiguration zusammen, aber ersetzen Sie Anweisungen in der vorhandenen Konfiguration durch diejenigen, die das replace: Tag in der geladenen Konfiguration angeben. Wenn in der vorhandenen Konfiguration keine Anweisung vorhanden ist, wird die Anweisung in der geladenen Konfiguration hinzugefügt.
load set	load: "set"	Laden Sie Konfigurationsdaten, die im set Format vorliegen. Die Konfigurationsdaten werden zeilenweise geladen und können Konfigurationsmodusbefehle wie set, deleteund deactivateenthalten.
load update	load: "update"	Vergleichen Sie die gesamte geladene Konfiguration mit der vorhandenen Konfiguration. Jedes Konfigurationselement, das sich in der geladenen Konfiguration unterscheidet, ersetzt das entsprechende Element in der vorhandenen Konfiguration. Während des Commit-Vorgangs wird die neue Konfiguration nur von Systemprozessen analysiert, die von geänderten Konfigurationselementen betroffen sind.

Das juniper.device.config Modul ermöglicht es Ihnen, Junos-Geräte in 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, einer Datei oder einer Jinja2-Vorlage bereitstellen, werden Text, Junos-XML-Elemente, Junos OS-Befehle set und JSON unterstützt.

Das 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, indem Sie der Datei entweder die entsprechende Erweiterung hinzufügen oder das format Argument einschließen.

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 einschließen, überschreibt es sowohl das Format für die automatische Erkennung von Zeichenfolgen als auch das Format, das durch eine Dateierweiterung angegeben wird.

Tabelle 3: Festlegen des Formats für Konfigurationsdaten

Konfigurationsdatenformat	Dateiendung	format-Parameter
CLI-Konfigurationsanweisungen (Text)	.Conf	"text"
JavaScript-Objektnotation (JSON)	.json	"json"
set Junos OS-Befehle	.Garnitur	"set"
Junos XML-Elemente	.XML	"xml"

Anmerkung:

Wenn Sie das load Argument des Moduls auf 'override' oder 'update'setzen, 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, fügen Sie das entsprechende load Argument und das lines Argument ein. Das lines Argument akzeptiert 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 einschließen, wird das automatisch erkannte Format überschrieben.

Im folgenden Playbook werden zwei Op-Skripts konfiguriert und ausgeführt. In diesem Fall hat das load Argument den Wert 'set', da die Konfigurationsdaten in lines das Junos OS-Anweisungsformat set verwenden.

Im folgenden Playbook werden die gleichen Anweisungen mithilfe von lines with-Konfigurationsdaten im Textformat konfiguriert. In diesem Fall wird verwendet. load: "merge"

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

• URL, die vom Client-Gerä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 Laden von Konfigurationsdaten mithilfe einer Jinja2-Vorlage.

Sie können das Format der Konfigurationsdaten angeben, indem Sie den format Parameter entweder explizit in die Argumentliste des Moduls aufnehmen oder der Konfigurationsdatendatei die entsprechende Erweiterung hinzufügen. Wenn Sie den format Parameter angeben, wird das durch die Dateierweiterung angegebene Format überschrieben. 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.

Anmerkung:

Sie müssen keine Konfigurationsdaten, die als ASCII-Text, Junos OS-Befehle set oder JSON formatiert <configuration-text>sind, in , oder Tags wie erforderlich einschließen, <configuration-set>wenn <configuration-json> Sie das Gerät direkt in einer NETCONF-Sitzung konfigurieren.

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

Tabelle 4: Angeben des Speicherorts der Konfigurationsdatei

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

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

Um Konfigurationsdaten aus einer Datei auf dem Junos-Gerät oder von einer FTP- oder HTTP-URL zu laden, verwenden Sie den url Parameter und geben Sie den Pfad der Datei an, die die zu ladenden Konfigurationsdaten enthält. 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 eingehängten Dateisystem, entweder auf der lokalen Flash-Festplatte oder auf der Festplatte.

  • ein:filename oder a:path/filename—Datei auf dem lokalen Laufwerk. Der Standardpfad ist / (das Verzeichnis auf Stammebene). Der Wechseldatenträger kann im MS-DOS- oder UNIX-Format (UFS) vorliegen.

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

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

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

Das juniper.device.config Modul ermöglicht es Ihnen, Konfigurationsdaten aus einer Jinja2-Vorlagendatei auf dem Ansible-Steuerungsknoten 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, z. B. ASCII-Text, Junos-XML-Elemente, Junos OS-Befehle set und JSON. Das Ansible-Modul verwendet die Jinja2-Vorlage und ein bereitgestelltes Variablenwörterbuch, um die Konfigurationsdaten zu rendern.

Um Konfigurationsdaten mithilfe einer Jinja2-Vorlage zu laden und zu bestätigen, fügen Sie die template Parameter und vars in 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 angeben, 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 Jinja2-Vorlage zu verwenden, setzen Sie das template Argument auf den Pfad der Vorlagendatei und definieren Sie die Variablen, die für die Vorlage im vars Wörterbuch erforderlich sind. Im folgenden Playbook werden die Jinja2-Vorlage und die darin vars definierten Variablen verwendet, um die Konfigurationsdaten zu rendern und sie auf den Zielhost zu laden und zu committen. Der format Parameter gibt das Format der Konfigurationsdaten in der Vorlagendatei an.

Das Modul generiert die folgenden Konfigurationsdaten, die in die Kandidatenkonfiguration auf dem Gerät geladen und übergeben werden:

Mit einer Wiederherstellungskonfiguration können Sie eine bekannte funktionierende Konfiguration oder eine Konfiguration mit einem bekannten Status definieren, die Sie jederzeit wiederherstellen können. Sie verwenden die Wiederherstellungskonfiguration, 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 Wiederherstellungskonfiguration erstellen, speichert das Gerät die zuletzt bestätigte Konfiguration als Wiederherstellungskonfiguration.

Mit dem juniper.device.config Modul können Sie zu einer vorhandenen Wiederherstellungskonfiguration auf Junos-Geräten zurückkehren. Um die Wiederherstellungskonfiguration auf einem Gerät zu laden und zu bestätigen, schließen Sie das Argument des Moduls rollback: "rescue" ein. Zum Beispiel:

Junos-Geräte speichern je nach Plattform eine Kopie der zuletzt bestätigten Konfiguration und bis zu 49 vorherige Konfigurationen. Sie können zu jeder der gespeicherten Konfigurationen zurückkehren. Dies ist nützlich, wenn Konfigurationsänderungen zu unerwünschten Ergebnissen führen und Sie zu einer bekannten funktionierenden Konfiguration zurückkehren möchten. Das Zurücksetzen der Konfiguration ähnelt dem Prozess zum Vornehmen von Konfigurationsänderungen auf dem Gerät, aber anstatt Konfigurationsdaten zu laden, führen Sie ein Rollback durch, bei dem die gesamte Kandidatenkonfiguration durch eine zuvor festgelegte Konfiguration ersetzt wird.

Mit dem juniper.device.config Modul können Sie auf Junos-Geräten auf eine zuvor festgelegte Konfiguration zurücksetzen. Um die Konfiguration zurückzusetzen und einen Commit auszuführen, fügen Sie das rollback Argument des 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 (maximal 49).

Das folgende Playbook fordert zur Eingabe der Rollback-ID der wiederherzustellenden Konfiguration auf, führt ein Rollback der Konfiguration durch, führt einen Commit für die Konfiguration aus und gibt dann die Konfigurationsänderungen in der Standardausgabe aus:

Wenn Sie das juniper.device.config Modul verwenden, um die Konfiguration mit dem load Argument oder rollback zu ändern, führt das Modul standardmäßig automatisch eine Commit-Prüfung durch und führt einen Commit für die Änderungen durch. Um zu verhindern, dass das Modul eine Commit-Prüfung durchführt oder die Änderungen festschreibt, legen Sie das check Argument or commit auf falsefest.

Sie können den Commit-Vorgang auch mit vielen der Optionen anpassen, die auch in der Junos OS CLI verfügbar sind. In Tabelle 5 sind die Modulargumente aufgeführt, 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 Commit-Vorgang in der Systemprotokolldatei und im Commit-Verlauf 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	Übernehmen Sie die Konfigurationsänderungen, auch wenn es keine Unterschiede zwischen der Kandidatenkonfiguration und der bestätigten Konfiguration gibt.	false
commit_force_sync: boolean	Synchronisieren Sie die Konfiguration, und bestätigen Sie sie auf allen Routing-Modulen, auch wenn offene Konfigurationssitzungen oder nicht festgeschriebene Konfigurationsänderungen auf der anderen Routing-Engine vorhanden sind.	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 der Commit nicht innerhalb der angegebenen Zeit bestätigt wird, führen Sie ein Rollback auf die zuvor bestätigte Konfiguration durch. Entweder die commit: true Option oder die check: true Option muss verwendet werden, um den Commit zu bestätigen.	–
timeout: seconds	Warten Sie auf den Abschluss des Vorgangs, indem Sie den angegebenen Wert als Timeout verwenden.	30 Sekunden

Kommentar bestätigen

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

Commit-Prüfung

Standardmäßig führt das 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 dem Commit-Vorgang gewartet werden soll. Schließen Sie dieses Argument ein, wenn Sie dem Gerät ausreichend Zeit einräumen müssen, um den Commit-Überprüfungsvorgang abzuschließen und die Konfigurationssperre aufzuheben, bevor Sie den Commit-Vorgang initiieren. Wenn Sie das check_commit_wait Argument weglassen, kann es bestimmte Umstände geben, unter denen ein Gerät den Commit-Vorgang initiiert, bevor der Commit-Check-Vorgang seine Sperre für die Konfiguration aufhebt, was zu einem fehlgeschlagenen CommitError Commit-Vorgang führt.

Commit für leere Änderungen

Wenn es keine Unterschiede zwischen der Kandidatenkonfiguration und der festgeschriebenen Konfiguration gibt, führt das Modul standardmäßig keinen Commit für die Änderungen aus. Um einen Commitvorgang zu erzwingen, auch wenn keine Unterschiede vorhanden sind, schließen Sie das commit_empty_changes: true Argument ein.

Commit-Synchronisierung

Wenn das Gerät über zwei Routing-Module verfügt, können Sie die Konfiguration auf beiden Routing-Modulen synchronisieren und bestätigen, indem Sie das commit_sync: true Argument einschließen. Verwenden Sie das commit_force_sync: true Argument, um zu erzwingen, dass der commit synchronize Vorgang auch dann erfolgreich ausgeführt wird, wenn offene Konfigurationssitzungen oder nicht festgeschriebene Konfigurationsänderungen auf der anderen Routing-Engine vorhanden sind. Wenn Sie die commit_force_sync: true Option einschließen, beendet das Gerät alle Konfigurationssitzungen auf der anderen Routing-Engine, bevor es synchronisiert und die Konfiguration festschreibt.

Bestätigen

Wenn Sie festlegen möchten, dass ein Commitvorgang innerhalb eines bestimmten Zeitraums nach dem ersten Commit bestätigt wird, fügen Sie das confirmed: minutes Argument ein. Wenn der Commit nicht innerhalb des angegebenen Zeitlimits bestätigt wird, wird für die Konfiguration automatisch ein Rollback auf die zuvor festgelegte Konfiguration ausgeführt. 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 verhindert nicht den Verwaltungszugriff auf das Gerät. 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 nach Ablauf der Rollback-Frist. Um den Commit-Vorgang zu bestätigen, rufen Sie das 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überprüfung und dem Commitvorgang und erfordert, dass der Commitvorgang 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 führen Sie möglicherweise Validierungsaufgaben nach dem ersten Commit aus und führen die Commitbestätigung nur aus, wenn die Aufgaben bestimmte Validierungskriterien erfüllen.

Mit dem juniper.device.config Modul können Sie die Konfiguration auf Junos-Geräten ändern und 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 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 nimmt einen booleschen Wert, eine Zeichenfolge oder eine Liste von Zeichenfolgen an.

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

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

Um das Modul anzuweisen, bestimmte Warnungen zu ignorieren, legen Sie das ignore_warning Argument auf eine Zeichenfolge oder eine Liste von Zeichenfolgen fest, 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.