Verwenden von Salt zum Konfigurieren von Geräten mit Junos OS

Sie können die Kandidatenkonfiguration sperren, bevor Sie sie ändern, um zu verhindern, dass andere Benutzer oder Anwendungen sie aktualisieren, bis die Sperre aufgehoben wird. Dies entspricht dem configure exclusive Befehl in der CLI. Es wird empfohlen, die Konfiguration vor dem Vornehmen von Änderungen zu sperren, insbesondere auf Geräten, auf denen mehrere Benutzer berechtigt sind, die Konfiguration zu ändern, da ein Commitvorgang für alle Änderungen in der Kandidatenkonfiguration gilt, nicht nur für diejenigen, die vom Benutzer oder der Anwendung vorgenommen werden, die den Commit anfordert.

Die junos.install_config Funktion nimmt mithilfe von mode Änderungen an der Kandidatenkonfigurationsdatenbank configure exclusive vor, wodurch die Konfigurationsdatenbank automatisch gesperrt, die Änderungen geladen und festgeschrieben und die Datenbank entsperrt wird. Wenn Sie jedoch die Lade- und Commitvorgänge separat ausführen müssen, z. B. mithilfe der junos.load junos.commit and-Funktionen, können Sie die Datenbank explizit sperren und entsperren, indem Sie die junos.lock Funktionen and junos.unlock execution oder state verwenden.

Um die Konfigurationsdatenbank explizit zu sperren, bevor Sie sie ändern, verwenden Sie die junos.lock Funktion. Zum Beispiel:

Um die Datenbank zu entsperren und nicht festgeschriebene Änderungen zu verwerfen, verwenden Sie die junos.unlock Funktion. Zum Beispiel:

Wenn die Konfigurationsdatenbank geändert wurde oder wenn ein anderer Benutzer bereits über eine exklusive Sperre verfügt, gibt die junos.lock Funktion eine LockError Meldung zurück, wie in den folgenden Beispielen gezeigt:

Die junos.install_config Funktion ermöglicht es Ihnen, Änderungen in verschiedenen Konfigurationsmodi vorzunehmen. Standardmäßig nimmt die Funktion mithilfe von mode Änderungen an der Kandidatenkonfigurationsdatenbank vor configure exclusive . Der configure exclusive Modus sperrt die globale Kandidatenkonfiguration (auch als freigegebene Konfigurationsdatenbank bezeichnet), solange die Funktion 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.

Um einen anderen Modus anzugeben, setzen Sie den mode Parameter auf den gewünschten Modus. Zu den unterstützten Modi gehören batch, dynamic, exclusiveephemeral, und private. Informationen zu den verschiedenen Modi finden Sie im CLI-Benutzerhandbuch.

Mit dem folgenden Befehl werden z. B. mithilfe von mode Änderungen an der Konfiguration configure private vorgenommen, wodurch eine private Kopie der Kandidatenkonfiguration geöffnet wird:

Auf ähnliche Weise können Sie das Argument in eine Salt-Statusdatei aufnehmen.

Sie können die junos.install_config Funktion auch verwenden, um die kurzlebige Konfigurationsdatenbank auf Geräten zu aktualisieren, die diese Datenbank unterstützen. Die flüchtige Datenbank ist eine alternative Konfigurationsdatenbank, die eine schnelle programmatische Schnittstelle zum Ausführen von Konfigurationsaktualisierungen auf Geräten mit Junos OS bereitstellt. Sie benötigen Salt Version 3001 und Junos PyEZ Version 2.1.3 oder höher, um diese Funktion nutzen zu können

Anmerkung:

Bei der kurzlebigen Konfigurationsdatenbank handelt es sich um eine erweiterte Funktion, die bei falscher Verwendung schwerwiegende negative Auswirkungen auf den Betrieb des Geräts haben kann. Weitere Informationen finden Sie unter Grundlegendes zur flüchtigen Konfigurationsdatenbank.

Um die Standardinstanz der kurzlebigen Konfigurationsdatenbank zu konfigurieren, legen Sie das mode Argument auf ephemeral. Zum Beispiel:

Um eine benutzerdefinierte Instanz der kurzlebigen Konfigurationsdatenbank zu konfigurieren, legen Sie das mode Argument auf ephemeralund das Argument auf den Namen der Instanz fest ephemeral_instance .

Sie können die junos.load junos.install_config und-Funktionen verwenden, um Konfigurationsänderungen mit einem load merge, load overrideload replace, oder load update Vorgang zu laden. Sie geben den gewünschten Ladevorgang an, indem Sie die entsprechenden Argumente für diese Funktion einschließen oder weglassen. Wenn Sie keinen Ladevorgang angeben, ist load replaceder Standardwert . Tabelle 2 fasst die Argumente zusammen, die für jeden Typ von Ladevorgang erforderlich sind.

Tabelle 2: Parameter zum Angeben des Lastvorgangs

Ladevorgang	Argument der Funktion	Beschreibung
load merge	merge=True	Führen Sie die geladene Konfiguration mit der vorhandenen Konfiguration zusammen.
load override	overwrite=True	Ersetzen Sie die gesamte Konfiguration durch die geladene Konfiguration.
load replace (Standard)	–	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 update	update=True	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.

Mit dem folgenden Befehl wird die gesamte Konfiguration auf dem Zielgerät durch die angegebene Konfiguration ersetzt und ein Commit ausgeführt. Das RPC-Timeout wird erhöht, um genügend Zeit zum Laden und Bestätigen der vollständigen Konfiguration zu bieten.

Die entsprechende Statusdatei lautet:

junos.install_config Mit den junos.load und-Funktionen können Sie Geräte, auf denen Junos OS ausgeführt wird, in einem der unterstützten Standardformate konfigurieren. Sie können Konfigurationsdaten aus einer Datei laden, die eine teilweise oder vollständige Konfiguration oder eine Jinja2-Vorlage enthält. Die Daten können als Text, Junos XML-Elemente, Junos OS-Befehle set oder JSON bereitgestellt werden.

Sie müssen das Format der Konfigurationsdaten angeben, indem Sie entweder der Konfigurationsdatei die entsprechende Erweiterung hinzufügen oder das format Argument explizit in den Funktionsaufruf aufnehmen. 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, wird das durch die Dateierweiterung angegebene Format überschrieben.

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:

Geräte, auf denen Junos OS ausgeführt wird, unterstützen das Laden von Konfigurationsdaten im JSON-Format ab Junos OS Version 16.1R1.

junos.install_config Mit den junos.load und-Funktionen können Sie Konfigurationsdaten aus einer Datei laden, die eine teilweise oder vollständige Konfiguration oder eine Jinja2-Vorlage enthält. Die Datei kann sich auf dem Salt-Master oder dem Proxy-Minion-Server befinden. Die Funktionen müssen die salt:// Notation verwenden, um einen Pfad auf dem Salt-Master anzugeben, und sie müssen einen absoluten Pfad verwenden, um einen Pfad auf dem Proxy-Minion-Server anzugeben. Wenn die Datei keine der akzeptierten Dateierweiterungen verwendet, um das Format der Konfigurationsdaten anzugeben, muss der Funktionsaufruf auch das format Argument zum Angeben des Datenformats enthalten.

In Tabelle 4 werden die Konfigurationsdatenquellen beschrieben, die Sie verwenden können, und es werden die Ausführungs- und Zustandsfunktionsargumente aufgeführt, die zum Angeben des Speicherorts der Datei erforderlich sind. Die Ausführungsfunktionen können den Pfad als Positionsargument oder mithilfe des Schlüsselworts path angeben.

Tabelle 4: Konfigurationsdatenquellen

Konfigurationsdatenquelle	Beschreibung	Ort	Ausführungsfunktionsargument	State-Funktionsargument
Konfigurationsdatendatei	Datei mit Konfigurationsdaten im ASCII-Format, Junos-XML-Elementen, Junos OS-Befehlen set oder JSON.	Salt-Master – salt:// Notation verwenden Proxy-Minion-Server: Verwenden Sie einen absoluten Pfad	path	name
Jinja2-Vorlagendatei	Datei mit einer Jinja2-Vorlage, die als ASCII-Text, Junos-XML-Elemente, Junos OS-Befehle set oder JSON formatiert ist. Fügen Sie den template_vars Parameter in den Funktionsaufruf ein, um ein Wörterbuch mit allen erforderlichen Jinja2-Vorlagenvariablen bereitzustellen, die noch nicht im Salt-System definiert sind, z. B. als Säulen- oder Korndaten.	Salt-Master – verwenden Sie salt:// Notation Proxy-Minion-Server: Verwenden Sie einen absoluten Pfad	path	name

Die folgende Datei enthält beispielsweise Junos OS-Befehle set , mit denen zwei Op-Skripte konfiguriert werden. Die Dateierweiterung gibt das Format für die Konfigurationsdaten an.

Der folgende Salt-Befehl verwendet die junos.install_config Ausführungsfunktion, um die Konfiguration auf dem Zielgerät zu laden und zu bestätigen. Der Pfad wird als Positionsargument angegeben.

Die entsprechende Statusdatei lautet:

Die junos.install_config Funktion führt automatisch einen Unterschied zwischen der Kandidatenkonfiguration und der angeforderten Konfiguration durch. Die Funktion wendet die Konfiguration nur an, wenn es Änderungen gibt. Wenn Sie versuchen, dieselbe Konfiguration ein zweites Mal anzuwenden, gibt die junos.install_config Funktion eine Meldung zurück, dass die Konfiguration bereits angewendet wurde, und lädt sie nicht erneut und führt keinen erneuten Commit aus, wie im folgenden Beispiel gezeigt:

junos.install_config Die junos.load Ausführungs- und Statusfunktionen unterstützen die Verwendung von Jinja2-Vorlagen für Junos OS-Konfigurationsdaten. 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. Die Funktionen verwenden die Jinja2-Vorlage und ein bereitgestelltes Variablenwörterbuch, um die Konfigurationsdaten zu rendern.

Jinja2-Vorlagen bieten eine leistungsstarke Methode zum Generieren von Konfigurationsdaten, insbesondere für ähnliche Konfigurationsbereichen. Anstatt z. B. manuell dieselben Konfigurationsanweisungen für jede Schnittstelle auf einem Gerät hinzuzufügen, können Sie eine Vorlage erstellen, die eine Liste von Schnittstellen durchläuft und die erforderlichen Konfigurationsanweisungen für jede Schnittstelle erstellt. In Jinja werden Blöcke durch '{%' und '%}' getrennt und Variablen werden in '{{' und '}}' eingeschlossen.

Um eine Jinja2-Vorlage zu laden, müssen Sie die folgenden Parameter in den junos.load Funktionsaufruf or junos.install_config einfügen:

• Vorlagenpfad: Geben Sie den Pfad zu einer Vorlagendatei auf dem Salt-Master- oder Proxy-Minion-Server an, wie unter Laden von Konfigurationsdaten beschrieben.

• Vorlagenformat: Legen Sie das format Argument fest, um das Format der Konfigurationsdaten anzugeben, wenn die Vorlagendatei keine der akzeptierten Dateierweiterungen verwendet, um das Format anzugeben. Informationen zum Angeben des Formats finden Sie unter Angeben des Formats der zu ladenden Konfigurationsdaten.

• Vorlagenvariablen: Die Vorlage kann auf interne Salt-Variablen verweisen, wie sie in Säulen- oder Korndaten definiert sind. Alle Variablen, die noch nicht im Salt-System definiert sind, müssen im template_vars Argument angegeben werden. Der template_vars Wert ist ein Wörterbuch von Schlüsseln und Werten, die zum Rendern der Jinja2-Vorlage erforderlich sind.

  Anmerkung:

  Wenn Ihre Vorlage nur interne Salt-Variablen wie Säulendaten, Korndaten und Funktionen enthält, muss die junos.install_config Funktion möglicherweise definiert template_vars: True werden, um die Vorlage zu rendern.

Die folgende Jinja2-Beispielvorlage generiert Konfigurationsdaten, die MPLS auf der logischen Einheit 0 für jede Schnittstelle in einer bestimmten Liste aktivieren, und konfiguriert die Schnittstelle auch unter den Protokollen MPLS und RSVP.

Der folgende Befehl verwendet die Jinja2-Vorlage und die darin template_vars definierten Variablen, um die Konfigurationsdaten zu rendern, die dann auf dem Zielhost geladen und festgeschrieben werden:

Die folgende Statusdatei lädt dieselbe Konfiguration. Die Konfigurationsunterschiede werden in der diffs_file Datei auf dem Proxy-Minion-Server gespeichert.

Wenn Sie den Zustand anwenden, rendert Salt die Konfiguration und lädt die Konfiguration und führt einen Commit für die Konfiguration auf dem Gerät aus.

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

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. Die junos.install_configFunktionen , junos.rollbackund junos.set_hostname und laden die angeforderten Konfigurationsänderungen und führen dann automatisch eine Commit-Prüfung und einen Commit-Vorgang aus. Sie können die Funktionen junos.commit_check individual und junos.commit auch verwenden, um eine Commit-Prüfung und einen Commit-Vorgang durchzuführen, z. B. nachdem Sie die junos.load Funktion zum Aktualisieren der Konfiguration verwendet haben.

Die Junos OS CLI bietet Optionen für den Commit-Vorgang, wie z. B. das Hinzufügen eines Commit-Kommentars oder die Synchronisierung der Konfiguration auf mehreren Routing-Engines. Einige dieser Optionen werden von den Junos-Ausführungs- und Statusmodulfunktionen unterstützt. Tabelle 5 gibt einen Überblick über die verfügbaren Commit-Optionen und die Funktionen, die sie unterstützen. Unterstützte Argumente sind sowohl für die Ausführungsfunktion als auch für die Zustandsfunktion gültig.

Tabelle 5: Argumente für Commit-Optionen

Argument der Funktion	Beschreibung	Funktionen, die das Argument unterstützen	Entspricht dem CLI-Befehl
comment=comment	Protokollieren Sie einen Kommentar für diesen Commit-Vorgang in der Systemprotokolldatei und im Commit-Verlauf des Geräts.	junos.commit junos.install_config junos.rollback junos.set_hostname	commit comment "comment"
confirm=(True | minutes)	Erfordern, dass ein Commitvorgang innerhalb eines bestimmten Zeitraums nach dem ersten Commit bestätigt wird. Andernfalls führen Sie ein Rollback auf die zuvor festgelegte Konfiguration durch. Legen Sie das Argument auf True fest, um die Standardzeit von 10 Minuten zu verwenden.	junos.commit junos.install_config junos.rollback junos.set_hostname	commit confirmed <minutes>
detail=True	Gibt detaillierte Informationen über den Commit-Prozess zurück.	junos.commit	commit | display detail
dev_timeout=seconds	Warten Sie auf den Abschluss des Vorgangs, indem Sie den angegebenen Wert als Timeout verwenden.	junos.commit junos.install_config junos.rollback junos.set_hostname	–
force_sync=True	Synchronisieren Sie die Konfiguration, und bestätigen Sie sie auf beiden Routing-Modulen, auch wenn offene Konfigurationssitzungen oder nicht festgeschriebene Konfigurationsänderungen auf der anderen Routing-Engine vorhanden sind.	junos.commit	commit synchronize force
sync=True	Synchronisieren Sie die Konfiguration, und bestätigen Sie sie auf beiden Routing-Engines.	junos.commit	commit synchronize

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, fügen Sie das comment Argument und eine Meldungszeichenfolge ein. Zum Beispiel:

Ähnlich verhält es sich in einer Statusdatei:

Der Commit-Kommentar ist in der Systemprotokollmeldung für den Commit enthalten und wird in der Commit-Historie protokolliert.

Commit bestätigt

Wenn Sie die Kandidatenkonfiguration bestätigen, können Sie eine explizite Bestätigung anfordern, damit die Bestätigung dauerhaft wird. Wenn der Commit nicht innerhalb des angegebenen Zeitraums bestätigt wird, wird das Gerät automatisch geladen und führt einen Rollback zur zuvor bestätigten Konfiguration durch. 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, stellt das automatische Rollback auf die vorherige Konfiguration den Zugriff auf das Gerät nach Ablauf der Rollback-Frist wieder her.

Wenn Sie festlegen möchten, dass ein Commitvorgang innerhalb eines bestimmten Zeitraums nach dem ersten Commit bestätigt wird, fügen Sie das confirm=minutes Argument ein. Der zulässige Bereich liegt zwischen 1 und 65.535 Minuten. Sie können auch angeben confirm=True , dass die Standardzeit von 10 Minuten verwendet werden soll.

Für den folgenden Befehl muss der Commit innerhalb von 15 Minuten bestätigt werden:

Um den Commitvorgang zu bestätigen, rufen Sie entweder die junos.commit or-Funktion junos.commit_check auf.

Commit-Details

Wenn Sie die junos.commit Funktion verwenden, um einen Commit für die Konfiguration auszuführen, können Sie die Details des gesamten Commitvorgangs überprüfen, indem Sie das detail=True Argument einschließen. Wenn Sie dieses Argument einschließen, gibt die Funktion detaillierte Informationen über den Commit-Prozess zurück.

Commit-Synchronisierung

Wenn Sie die junos.commit Funktion verwenden, um die Konfiguration zu bestätigen, können Sie die Konfiguration auf beiden Routing-Modulen in einem System mit dualer Routing-Engine synchronisieren und bestätigen, indem Sie das sync=True Argument einschließen. Zum Beispiel:

Wenn Sie das sync=True Argument einschließen, kopiert das Gerät die Kandidatenkonfiguration, die in der lokalen Routing-Engine gespeichert ist, in die andere Routing-Engine, überprüft die syntaktische Korrektheit des Kandidaten und überträgt sie auf beiden Routing-Engines. Verwenden Sie das 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. Das Einfügen dieses Arguments bewirkt, dass das Gerät alle Konfigurationssitzungen auf der anderen Routing-Engine beendet, bevor die Synchronisierung und der Commit für die Konfiguration ausgeführt wird.

Commit-Timeout

Die Standardzeit für ein RPC beträgt 30 Sekunden. Große Konfigurationsänderungen können diesen Wert überschreiten, was zu einer Zeitüberschreitung des Vorgangs führt, bevor die Konfiguration hochgeladen und übergeben werden kann. Um Konfigurationsänderungen zu berücksichtigen, die möglicherweise eine Commitzeit erfordern, die länger als das Standardtimeoutintervall ist, schließen Sie das dev_timeout=seconds Argument ein, und legen Sie das Timeoutintervall auf einen geeigneten Wert fest. Zum Beispiel:

Geräte, auf denen Junos OS ausgeführt wird, 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 der salt.modules.junos.rollback Ausführungsfunktion und der salt.states.junos.rollback Statusfunktion können Sie die Konfiguration auf einem Gerät, auf dem Junos OS ausgeführt wird, auf eine zuvor festgelegte Konfiguration zurücksetzen. Um die Konfiguration zurückzusetzen und einen Commit auszuführen, führen Sie die Funktion aus, und legen Sie das id Argument auf die ID der gewünschten Rollbackkonfiguration fest. 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). Wenn Sie das Schlüsselwort weglassen, wird es id standardmäßig auf 0 gesetzt.

Mit dem folgenden Befehl wird die Konfiguration z. B. auf die zuvor festgeschriebene Konfiguration zurückgesetzt und ein Commit ausgeführt:

Um die Konfiguration zurückzusetzen und die Konfigurationsunterschiede in einer Datei für spätere Referenzen zu protokollieren, fügen Sie das diffs_file Argument ein, und legen Sie es auf den Pfad der Datei auf dem Proxyminionserver fest, in den die Unterschiede geschrieben werden.

Die Unterschiede werden in der angegebenen Datei auf dem Proxy-Minion-Server gespeichert.