Verwenden Sie das juniper.device.software Ansible-Modul, um Software auf Junos-Geräten zu installieren
Sie können das juniper.device.software Ansible-Modul verwenden, um Software auf Geräten mit Junos OS oder Geräten mit Junos OS Evolved zu installieren.
Ansible zur Installation von Software verwenden
Juniper Networks stellt Ansible-Module bereit, mit denen Sie ein Software-Image auf Junos-Geräten installieren können. Tabelle 1 skizziert die Module. Wenn Sie bereits einen bestimmten Satz von Modulen aus der juniper.device Sammlung verwenden, verwenden Sie das Modul für diesen Satz.
|
Kollektion |
Modul-Set |
Modulname |
|---|---|---|
|
|
||
|
|
In den folgenden Abschnitten wird erläutert, wie Sie das juniper.device.software Modul verwenden, um ein Softwarepaket auf einem Junos-Gerät zu installieren. In den Abschnitten wird erläutert, wie Sie den Speicherort des Softwareimages sowie den allgemeinen Softwareinstallationsprozess und die Optionen angeben. In den Abschnitten wird auch erläutert, wie speziellere Upgradeszenarien wie ein VM-Host-Upgrade, ein einheitliches In-Service-Software-Upgrade (Unified ISSU) oder ein Nonstop-Software-Upgrade (NSSU) auf Geräten durchgeführt werden, die diese Features unterstützen.
So legen Sie den Speicherort des Software-Images fest
Wenn Sie das juniper.device.software Modul verwenden, um Software auf Junos-Geräten zu installieren, können Sie das Softwarepaket auf den Ansible-Steuerungsknoten herunterladen. Das Modul kopiert das Paket standardmäßig auf das Zielgerät, bevor die Installation durchgeführt wird. Bei gemischten Virtual Chassis-Umgebungen müssen sich die Softwarepakete auf dem Ansible-Steuerungsknoten befinden. Bei Standalone-Geräten oder nicht gemischten Virtual Chassis-Umgebungen können Sie das Modul auch anweisen, ein Software-Image zu installieren, das sich bereits auf dem Junos-Zielgerät befindet oder sich unter einer URL befindet, die vom Zielgerät aus erreichbar ist.
In Tabelle 2 sind die Modul-Argumente aufgeführt, die Sie je nach Speicherort des Softwarepakets festlegen müssen. Das Modul muss immer entweder das local_packageArgument , pkg_setoder remote_package enthalten. Das no_copy Argument ist standardmäßig auf false, wodurch das Modul angewiesen wird, das Softwarepaket von der angegebenen Position auf dem Ansible-Steuerknoten auf das Zielgerät zu kopieren.
|
Speicherort des Software-Pakets |
|
|
|
|---|---|---|---|
|
Ansible-Steuerungsknoten |
Auslassen oder auf |
Für eigenständige Geräte oder nicht gemischte Virtual Chassis-Umgebungen: Legen Sie diese Option auf den Dateipfad einschließlich des Dateinamens des Softwarepakets auf dem lokalen Steuerungsknoten fest |
(Optional) Dateipfad auf dem Zielgerät, auf das das Softwarepaket kopiert wird. Das Standardverzeichnis ist /var/tmp. Wenn ein |
|
Für gemischte Virtual Chassis-Umgebungen: Legen Sie diese Option auf eine Liste der Dateipfade, einschließlich der Dateinamen, eines oder mehrerer Softwarepakete auf dem lokalen Steuerungsknoten fest |
– |
||
|
Remote-Standort |
– |
– |
URL aus Sicht des Junos-Zielgeräts, von dem das Softwarepaket installiert wird. |
|
Zielgerät |
Legen Sie Wert auf |
– |
Dateipfad auf dem Zielgerät, auf dem sich das Softwarepaket bereits befinden muss. Das Standardverzeichnis ist /var/tmp. |
Wenn sich das Softwarepaket auf dem Ansible-Steuerungsknoten befindet, fügen Sie das für Ihre Installation geeignete Argument ein:
-
local_package– Installieren Sie Software auf einem eigenständigen Junos-Gerät oder auf Mitgliedern in einem nicht gemischten Virtual Chassis. Der Argumentwert ist eine einzelne Zeichenfolge, die den absoluten oder relativen Pfad zum Software-Image angibt. -
pkg_set– Installieren Sie Software auf den Mitgliedern in einem gemischten Virtual Chassis. Der Argumentwert ist eine Liste von Zeichenfolgen, die die absoluten oder relativen Dateipfade der Software-Images in keiner bestimmten Reihenfolge für die verschiedenen Virtual Chassis-Mitglieder angeben.Zum Beispiel:
pkg_set: - 'software/jinstall-qfx-5-13.2X51-D35.3-domestic-signed.tgz' - 'software/jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz'
Wenn Sie das local_package Argument or pkg_set einfügen, kopiert das Modul standardmäßig alle Softwarepakete vom Ansible-Steuerknoten in das Verzeichnis /var/tmp auf dem Ziel-Junos-Gerät (Einzelgerät oder primäres Virtual Chassis-Gerät). Wenn Sie das local_package Image in ein anderes Verzeichnis kopieren möchten, definieren Sie das remote_package Argument und geben Sie das Zielverzeichnis an. Wenn das remote_package Argument einen Dateinamen enthält, müssen die Dateinamen der local_package Argumente und remote_package identisch sein, oder das Modul generiert einen Fehler.
Wenn sich das Softwarepaket bereits auf dem Ziel-Junos-Gerät (Einzelgerät oder primäres Virtual Chassis-Gerät) befindet, muss das Modul neben dem Argument auch das no_copy: true remote_package Argument enthalten. Das remote_package Argument gibt den Dateipfad zu einem vorhandenen Softwarepaket auf dem Zielgerät an. Wenn remote_package kein Verzeichnis angegeben wird, ist der Standardwert /var/tmp.
Wenn sich das Softwarepaket an einem anderen Speicherort als dem Ansible-Steuerknoten oder dem Zielgerät befindet, muss das Modul das remote_package Argument enthalten und den Speicherort des Softwarepakets angeben. Der Wert von remote_package ist eine URL aus der Perspektive des Junos-Zielgeräts. Informationen zu akzeptablen URL-Formaten finden Sie unter Format zum Angeben von Dateinamen und URLs in Junos OS CLI-Befehlen.
Übersicht über den Installationsprozess
Um Ansible zu verwenden, um ein Softwarepaket auf einem Junos-Gerät zu installieren, führen Sie das Modul aus und geben Sie alle juniper.device.software erforderlichen Argumente an. Zum Beispiel:
---
- name: Perform a Junos OS software upgrade
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Upgrade Junos OS
juniper.device.software:
local_package: "software/jinstall-ppc-17.3R1.10-signed.tgz"
no_copy: false
validate: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
Wenn Sie das juniper.device.software Modul ausführen, führt es die folgenden Vorgänge aus:
Sobald sich das Softwarepaket auf dem Zielgerät befindet, unabhängig davon, ob es zunächst dorthin heruntergeladen oder vom Modul kopiert wurde, führt das Modul die folgenden Vorgänge aus:
-
Überprüft die Konfiguration anhand des neuen Pakets, es sei denn, das
validateArgument ist auffalsegesetzt.Hinweis:juniper.deviceAb Version 2.0.4 ist dervalidateParameter standardmäßig auftrue. In früheren Versionen istfalseder Standardwert . -
Installiert das Paket auf jeder einzelnen Routing-Engine, sofern
all_rees nicht auffalsefestgelegt ist. -
Startet jede aktualisierte Routing-Engine neu, es sei denn, das
rebootArgument ist auffalsegesetzt.
Das software Modul ermöglicht es Ihnen, den Fortschritt der Installation zu protokollieren, indem Sie das logfile Modul-Argument einschließen. Standardmäßig werden nur Meldungen mit dem Schweregrad WARNUNG oder höher protokolliert. Um Meldungen mit dem Schweregrad INFO oder höher zu protokollieren, die zum Protokollieren von Meldungen für den allgemeinen Installationsprozess erforderlich sind, führen Sie das Playbook mit der -v Befehlszeilenoption oder --verbose aus.
Festlegen von Timeoutwerten
Das juniper.device.software Modul führt Operationen über eine NETCONF-Sitzung aus. Die Standardzeit für ein NETCONF-RPC für das Timeout beträgt 30 Sekunden. Während des Installationsvorgangs erhöhen bestimmte Vorgänge das RPC-Timeoutintervall wie folgt:
-
Kopieren und Installieren des Pakets auf dem Gerät – 1800 Sekunden (30 Minuten)
-
Berechnung der Prüfsumme – 300 Sekunden (5 Minuten)
-
Durchführen einer Speicherbereinigung – 300 Sekunden (5 Minuten)
In einigen Fällen können der Installationsprozess, die Prüfsummenberechnung oder die Speicherbereinigung diese Zeitintervalle überschreiten. Sie können den Timeoutwert für diese Vorgänge ändern, indem Sie die install_timeoutArgumente , checksum_timeoutund cleanfs_timeout und in der Argumentliste des Moduls auf die erforderliche Anzahl von Sekunden festlegen. Zum Beispiel:
- name: Upgrade Junos OS
juniper.device.software:
local_package: "software/jinstall-ppc-17.3R1.10-signed.tgz"
validate: true
install_timeout: 2000
checksum_timeout: 420
cleanfs_timeout: 600
So geben Sie Installationsoptionen an, für die kein entsprechendes Modulargument vorhanden ist
Wenn Sie das juniper.device.software Modul verwenden, um Software auf einem Gerät zu installieren, ruft das Modul den entsprechenden RPC für die enthaltenen Installationsargumente auf. Das Modul ruft beispielsweise den <request-package-add> RPC für standardmäßige Junos OS-Installationen, den <request-vmhost-package-add> RPC für VM-Hostupgrades, den <request-package-in-service-upgrade> RPC für einheitliche ISSU-Szenarien usw. auf.
Das Modul unterstützt explizite Argumente für viele der Installationsoptionen, z. B. die validate Option. Das Modul unterstützt das kwargs Argument ebenfalls. Mit dem Argument können Sie alle zusätzlichen Optionen einschließen, die der RPC unterstützt. Das kwargs Argument verwendet ein Wörterbuch mit Schlüssel/Wert-Paaren zusätzlicher unterstützter Optionen.
Die aktuelle Liste der vom Modul unterstützten Optionen finden Sie in der API-Referenzdokumentation für das Modul. Eine Liste aller verfügbaren Optionen für einen bestimmten RPC finden Sie in der Dokumentation des entsprechenden Befehls oder suchen Sie im Junos XML API Explorer nach dem Anforderungs-Tag des RPC.
Sie sollten nur Installationsoptionen einschließen, die das Junos-Zielgerät für den jeweiligen RPC unterstützt.
Im folgenden Playbook installiert das software Modul ein neues Software-Image auf den Zielhosts. Das Modul enthält das kwargs Argument mit unlink: true. Dieses Argument, das das Softwarepaket nach einem erfolgreichen Upgrade aus dem Verzeichnis entfernt, entspricht dem Einschließen der <unlink/> Option in den <request-package-add> RPC.
---
- name: Perform a Junos OS software upgrade
hosts: router1
connection: local
gather_facts: no
tasks:
- name: Upgrade Junos OS
juniper.device.software:
local_package: "software/jinstall-ppc-17.3R1.10-signed.tgz"
kwargs:
unlink: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
So führen Sie ein VM-Host-Upgrade durch
Auf Geräten mit Routing-Engines mit VM-Host-Unterstützung kann Junos OS als virtuelle Maschine (VM) über einen Linux-basierten Host (VM-Host) ausgeführt werden. Ein VM-Host-Upgrade erfordert ein VM-Host-Installationspaket (junos-vmhost-install-x.tgz) und aktualisiert das Host-Betriebssystem und das kompatible Junos OS. In der CLI führen Sie das Upgrade mit dem request vmhost software add Befehl "Betriebsmodus" durch, der dem <request-vmhost-package-add> RPC entspricht.
Das juniper.device.software Modul unterstützt das Argument für die vmhost: true Durchführung eines VM-Hostupgrades. Wenn das Argument vorhanden ist, führt das Modul die Installation mithilfe des <request-vmhost-package-add> RPC durch.
Das folgende Playbook aktualisiert das Junos OS und Host-Betriebssystem auf den angegebenen Geräten und startet es neu:
---
- name: Upgrade VM Hosts
hosts: vm_hosts
connection: local
gather_facts: no
tasks:
- name: Perform a VM host upgrade
juniper.device.software:
local_package: "junos-vmhost-install-qfx-x86-64-18.1R1.9.tgz"
vmhost: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
So führen Sie eine einheitliche ISSU oder NSSU durch
Das juniper.device.software Modul unterstützt die Durchführung einer vereinheitlichten ISSU oder einer NSSU auf Geräten, die die Funktion unterstützen und die erforderlichen Anforderungen erfüllen. Weitere Informationen zu den vereinheitlichten ISSU- und NSSU-Funktionen finden Sie in der Softwaredokumentation für Ihr Produkt.
Die vereinheitlichte ISSU-Funktion ermöglicht Ihnen Upgrades zwischen zwei verschiedenen Junos OS-Versionen ohne Unterbrechung auf der Steuerungsebene und mit minimaler Unterbrechung des Datenverkehrs. Um eine vereinheitlichte ISSU durchzuführen, muss das software Modul das issu: true Argument enthalten. Zum Beispiel:
---
- name: Perform a Junos OS software upgrade
hosts: mx1
connection: local
gather_facts: no
tasks:
- name: Perform a unified ISSU
juniper.device.software:
local_package: "junos-install-mx-x86-64-17.2R1.13.tgz"
issu: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
Mit der NSSU-Funktion können Sie die Junos OS-Software, die auf einem Switch oder Virtual Chassis ausgeführt wird, mit redundanten Routing-Engines mit minimaler Unterbrechung des Netzwerkverkehrs aktualisieren. Um eine NSSU auszuführen, muss das software Modul das nssu: true Argument enthalten. Zum Beispiel:
---
- name: Perform a Junos OS software upgrade
hosts: ex1
connection: local
gather_facts: no
tasks:
- name: Perform an NSSU
juniper.device.software:
local_package: "jinstall-ex-4300-17.3R1.10-signed.tgz"
nssu: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
So installieren Sie Software auf einem Virtual Chassis-Mitglied der EX-Serie
Wenn Sie ein nicht gemischtes Virtual Chassis der EX-Serie aktualisieren, befolgen Sie im Allgemeinen den in der Übersicht über den Installationsprozess beschriebenen Installationsprozess, um das gesamte Virtual Chassis zu aktualisieren. Es kann jedoch vorkommen, dass Sie Software auf bestimmten Komponenten-Switches im Virtual Chassis installieren müssen. Das juniper.device.software Modul ermöglicht es Ihnen, ein Softwarepaket auf einzelnen Switches in einem nicht gemischten Virtual Chassis der EX-Serie zu installieren.
Um Software auf bestimmten Membern zu installieren, schließen Sie das member_id Argument ein, und definieren Sie eine Liste von Zeichenfolgen, die die Member-IDs angeben. Das System installiert das Softwarepaket vom primären Virtual Chassis-Gerät auf den angegebenen Mitgliedern.
Das folgende Ansible-Playbook aktualisiert die Software auf Member 0 und Member 1 im EX-Serie Virtual Chassis:
---
- name: Upgrade specific EX VC members
hosts: ex_vc
connection: local
gather_facts: no
vars:
OS_version: "23.2R1.13"
OS_package: "junos-install-ex-x86-64-23.2R1.13.tgz"
pkg_dir: "software"
log_dir: /var/log/
tasks:
- name: Check NETCONF connectivity
ansible.builtin.wait_for:
host: "{{ inventory_hostname }}"
port: 830
timeout: 5
- name: Install package on EX VC members
juniper.device.software:
version: "{{ OS_version }}"
local_package: "{{ pkg_dir }}/{{ OS_package }}"
member_id: ["0","1"]
logfile: "{{ log_dir }}/software.log"
Beispiel: Verwenden von Ansible zum Installieren von Software
In diesem Beispiel wird das juniper.device.software Modul verwendet, um ein Softwareimage auf einem Gerät zu installieren, auf dem Junos OS ausgeführt wird.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
-
Konfigurationsmanagement-Server mit Ansible 2.17 oder höher mit installierter
juniper.deviceSammlung -
Junos-Gerät mit aktiviertem NETCONF und einem Benutzerkonto mit entsprechenden Berechtigungen
-
Öffentliches/privates SSH-Schlüsselpaar, konfiguriert für den entsprechenden Benutzer auf dem Ansible-Steuerknoten und dem Junos-Gerät
-
Vorhandene Ansible-Inventardatei mit definierten erforderlichen Hosts
Überblick
In diesem Beispiel wird ein Ansible-Playbook vorgestellt, das das juniper.device.software Modul verwendet, um Junos OS auf den Hosts in der angegebenen Bestandslistengruppe zu aktualisieren. In diesem Beispiel befindet sich das Software-Image auf dem Ansible-Steuerknoten, und das Modul kopiert das Image auf das Zielgerät, bevor es installiert wird. Das Modul definiert nicht explizit ein host Argument, daher arbeitet das Modul auf dem Standardhost, der {{ inventory_hostname }}.
Dieses Playbook enthält die Check NETCONF connectivity Aufgabe, die das ansible.builtin.wait_for Modul verwendet, um zu versuchen, eine NETCONF-Sitzung mit dem Junos-Gerät über den Standard-NETCONF-Port 830 aufzubauen. Wenn der Steuerungsknoten während der Playbook-Ausführung keine NETCONF-Sitzung mit einem Gerät einrichten kann, überspringt er die verbleibenden Aufgaben in der Wiedergabe für dieses Gerät.
Die Install Junos OS package Aufgabe führt das juniper.device.software Modul aus, sofern die NETCONF-Prüfung erfolgreich war. Das version Argument definiert die gewünschte Junos OS-Version, wie sie vom show version Befehl auf dem Junos-Gerät gemeldet wird. Während der Playbook-Ausführung prüft das Modul zunächst, ob die angeforderte Version nicht bereits auf dem Gerät installiert ist. Wenn sich die angeforderte Version von der aktuell installierten Version unterscheidet, installiert das Modul die angeforderte Version.
Das local_package Argument definiert den Pfad des Junos OS-Softwarepakets auf dem Ansible-Steuerungsknoten. Während der Installation wird das Modul:
-
Führt eine Speicherbereinigung auf dem Zielgerät durch.
-
Kopiert das Software-Image in das Verzeichnis /var/tmp auf dem Gerät
-
Überprüft die Prüfsumme der Datei
-
Überprüft die neue Software anhand der aktiven Konfiguration
-
Installiert die Software auf jeder Routing-Engine auf dem Zielhost
Standardmäßig startet das juniper.device.software Modul jede Routing-Engine neu, nachdem die Installation abgeschlossen ist.reboot: true
Die Aufgabe speichert das Ergebnis des Moduls in der response Variablen und benachrichtigt einen Handler. Wenn Sie das Playbook nicht im Prüfmodus ausführen, versucht der wait_reboot Handler dann, eine Sitzung mit dem Gerät einzurichten, um zu überprüfen, ob das Gerät wieder online ist. Die wait_time Variable definiert die Zeitspanne, die der Steuerknoten versucht, sich wieder mit dem Gerät zu verbinden.
Dieses Beispiel enthält den logfile Parameter zum Protokollieren des Fortschritts der Installation. Dieses Protokoll ist wichtig für das Debuggen im Falle eines Installationsfehlers sowie für die Protokollierung von Datum und Uhrzeit der Installationen auf den Geräten. Der Benutzer, der das Playbook ausführt, muss über Schreibberechtigungen in die angegebene Protokolldatei verfügen. Standardmäßig werden nur Meldungen mit dem Schweregrad WARNUNG oder höher protokolliert. Im Beispiel wird das Playbook mit der -v Option ausgeführt, Meldungen mit dem Schweregrad INFO oder höher zu protokollieren, um die Installation zu überwachen.
Konfiguration
Erstellen des Ansible Playbooks
So erstellen Sie ein Playbook, das das juniper.device.software Modul verwendet, um ein Software-Image auf einem Junos-Gerät zu installieren:
-
Fügen Sie die Textbausteine für das Playbook und dieses Spiel hinzu, das die Module lokal ausführt.
--- - name: Install Junos OS hosts: mx1 connection: local gather_facts: no
-
Definieren oder importieren Sie alle erforderlichen Variablen, die in diesem Beispiel unter anderem die gewünschte Junos OS-Version und den Pfad zum neuen Image enthalten.
vars: OS_version: "23.4R1.9" OS_package: "junos-install-mx-x86-64-23.4R1.9.tgz" pkg_dir: "software" log_dir: "{{ playbook_dir }}" netconf_port: 830 wait_time: 3600 -
(Optional) Erstellen Sie eine Aufgabe zum Überprüfen der NETCONF-Konnektivität.
tasks: - name: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: 5 -
Erstellen Sie die Aufgabe, um das Junos OS-Paket auf dem Gerät zu installieren und den Handler zu benachrichtigen.
- name: Install Junos OS package juniper.device.software: version: "{{ OS_version }}" local_package: "{{ pkg_dir }}/{{ OS_package }}" reboot: true validate: true logfile: "{{ log_dir }}/software.log" register: response notify: - wait_reboot -
(Optional) Erstellen Sie eine Aufgabe, um die Antwort des Moduls zu drucken.
- name: Print response ansible.builtin.debug: var: response -
Erstellen Sie den Handler, der überprüft, ob das Gerät nach dem Neustart wieder online ist.
Der Handlername sollte mit dem in der Installationsaufgabe angegebenen identisch sein.
handlers: - name: wait_reboot ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: "{{ wait_time }}" when: not response.check_mode
Ergebnisse
Überprüfen Sie auf dem Ansible-Steuerungsknoten das fertige Playbook. Wenn das Playbook nicht den beabsichtigten Code anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um das Playbook zu korrigieren.
---
- name: Install Junos OS
hosts: mx1
connection: local
gather_facts: no
vars:
OS_version: "23.4R1.9"
OS_package: "junos-install-mx-x86-64-23.4R1.9.tgz"
pkg_dir: "software"
log_dir: "{{ playbook_dir }}"
netconf_port: 830
wait_time: 3600
tasks:
- name: Check NETCONF connectivity
ansible.builtin.wait_for:
host: "{{ inventory_hostname }}"
port: "{{ netconf_port }}"
timeout: 5
- name: Install Junos OS package
juniper.device.software:
version: "{{ OS_version }}"
local_package: "{{ pkg_dir }}/{{ OS_package }}"
reboot: true
validate: true
logfile: "{{ log_dir }}/software.log"
register: response
notify:
- wait_reboot
- name: Print response
ansible.builtin.debug:
var: response
handlers:
- name: wait_reboot
ansible.builtin.wait_for:
host: "{{ inventory_hostname }}"
port: "{{ netconf_port }}"
timeout: "{{ wait_time }}"
when: not response.check_mode
Ausführen des Playbooks
So führen Sie das Playbook aus:
-
Geben Sie den
ansible-playbookBefehl auf dem Steuerungsknoten ab und geben Sie den Playbook-Pfad und alle erforderlichen Optionen an.user@ansible-cn:~/ansible$ ansible-playbook -v ansible-pb-junos-install-os.yaml Using /etc/ansible/ansible.cfg as config file PLAY [Install Junos OS] **************************************************** TASK [Check NETCONF connectivity] ****************************************** ok: [mx1a.example.com] => {"changed": false, "elapsed": 0, "match_groupdict": {}, "match_groups": [], "path": null, "port": 830, "search_regex": null, "state": "started"} TASK [Install Junos OS package] ******************************************** changed: [mx1a.example.com] => {"changed": true, "check_mode": false, "msg": "Package /home/user/ansible/software/junos-install-mx-x86-64-23.4R1.9.tgz successfully installed. Response from device is: \nVerified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256\n [...output truncated...] NOTICE: 'pending' set will be activated at next reboot... Reboot successfully initiated. Reboot message: Shutdown NOW! [pid 79385]"} TASK [Print response] ****************************************************** ok: [mx1a.example.com] => { "response": { "changed": true, "check_mode": false, "failed": false, "msg": "Package /home/user/ansible/software/junos-install-mx-x86-64-23.4R1.9.tgz successfully installed. Response from device is: \nVerified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256\nVerified auto-snapshot signed by PackageProductionECP256_2023 method ECDSA256+SHA256\n [...output truncated...] NOTICE: 'pending' set will be activated at next reboot... Reboot successfully initiated. Reboot message: Shutdown NOW! [pid 79385]" } } RUNNING HANDLER [wait_reboot] ********************************************** ok: [mx1a.example.com] => {"changed": false, "elapsed": 250, "match_groupdict": {}, "match_groups": [], "path": null, "port": 830, "search_regex": null, "state": "started"} PLAY RECAP ***************************************************************** mx1a.example.com : ok=4 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Verifizierung
Überprüfen Sie die Installation
Zweck
Überprüfen Sie, ob die Softwareinstallation erfolgreich war.
Aktion
Die Playbook-Ausgabe sollte alle fehlgeschlagenen Aufgaben anzeigen. Sie können jedoch auch den Inhalt der im Playbook definierten Protokolldatei überprüfen, um Details zur Installation zu erhalten. Die Beispielausgabe der Protokolldatei wird hier angezeigt. Einige Ausgaben wurden der Kürze halber weggelassen.
2024-08-23 22:20:49,455 - ncclient.transport.ssh - INFO - Connected (version 2.0, client OpenSSH_7.9) 2024-08-23 22:20:52,950 - ncclient.transport.ssh - INFO - Authentication (publickey) successful! ... 2024-08-23 22:21:00,770 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] computing checksum on local package: /home/user/ansible/software/junos-install-mx-x86-64-23.4R1.9.tgz 2024-08-23 22:21:08,070 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] cleaning filesystem ... ... 2024-08-23 22:21:08,329 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] before copy, computing checksum on remote package: /var/tmp/junos-install-mx-x86-64-23.4R1.9.tgz ... 2024-08-23 22:21:08,491 - paramiko.transport - INFO - Connected (version 2.0, client OpenSSH_7.9) 2024-08-23 22:21:08,958 - paramiko.transport - INFO - Authentication (publickey) successful! 2024-08-23 22:21:16,846 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 363528192 / 3635202890 (10%) 2024-08-23 22:21:24,405 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 727056384 / 3635202890 (20%) 2024-08-23 22:21:31,966 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 1090568192 / 3635202890 (30%) 2024-08-23 22:21:39,652 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 1454096384 / 3635202890 (40%) 2024-08-23 22:21:47,631 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 1817608192 / 3635202890 (50%) 2024-08-23 22:21:55,343 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 2181136384 / 3635202890 (60%) 2024-08-23 22:22:02,878 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 2544648192 / 3635202890 (70%) 2024-08-23 22:22:11,395 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 2908176384 / 3635202890 (80%) 2024-08-23 22:22:19,949 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 3271688192 / 3635202890 (90%) 2024-08-23 22:22:27,522 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 3635202890 / 3635202890 (100%) 2024-08-23 22:22:27,533 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] after copy, computing checksum on remote package: /var/tmp/junos-install-mx-x86-64-23.4R1.9.tgz ... 2024-08-23 22:22:44,891 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] checksum check passed. 2024-08-23 22:22:44,892 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] validating software against current config, please be patient ... ... 2024-08-23 22:27:52,538 - ncclient.transport.ssh - INFO - [host mx1a.example.com session-id 27526] Received message from host 2024-08-23 22:27:52,542 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] software validate package-result: 0 Output: Verified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256 Adding junos-mx-x86-64-23.4R1.9 ... ... Validating against /config/juniper.conf.gz mgd: commit complete Validation succeeded 2024-08-23 22:27:52,542 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] installing software on RE0 ... please be patient ... ... 2024-08-23 22:30:57,510 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] software pkgadd package-result: 0 Output: Verified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256 ... NOTICE: 'pending' set will be activated at next reboot... 2024-08-23 22:30:57,510 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] installing software on RE1 ... please be patient ... ... 2024-08-23 22:34:30,228 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] software pkgadd package-result: 0 Output: Pushing /var/tmp/junos-install-mx-x86-64-23.4R1.9.tgz to re1:/var/tmp/junos-install-mx-x86-64-23.4R1.9.tgz Verified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256 ... NOTICE: 'pending' set will be activated at next reboot... ... 2024-08-23 22:34:30,732 - ncclient.operations.rpc - INFO - [host mx1a.example.com session-id 27526] Requesting 'CloseSession'
Bedeutung
Der Inhalt der Protokolldatei gibt an, dass das Playbook das Image erfolgreich kopiert und auf beiden Routing-Engines auf dem Zielgerät installiert hat.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.
juniper.device Ab Version 2.0.4 ist der validate Parameter standardmäßig auf true. In früheren Versionen ist falseder Standardwert .