Verwenden von Ansible zum Installieren von Software auf Junos-Geräten
Verwenden Sie die Ansible-Module von Juniper Networks, um Software auf Junos-Geräten zu installieren.
Verwenden von Ansible zum Installieren von Software
Juniper Networks stellt ein Ansible-Modul bereit, mit dem Sie das Software-Image auf einem Junos-Gerät installieren oder aktualisieren können. Tabelle 1 gibt einen Überblick über das Modul.
| Inhaltsgruppe |
Modulname |
|---|---|
|
|
In den folgenden Abschnitten wird erläutert, wie Sie den Speicherort des Software-Images sowie den allgemeinen Softwareinstallationsprozess und die Optionen angeben, wenn das Ansible-Modul zur Installation von Softwarepaketen auf Junos-Geräten verwendet wird. Außerdem wird erläutert, wie speziellere Upgradeszenarien wie ein VM-Hostupgrade, ein einheitliches In-Service-Softwareupgrade (Unified ISSU) oder ein Nonstop-Softwareupgrade (NSSU) auf Geräten durchgeführt werden können, die diese Funktionen unterstützen.
Angeben des Speicherorts des Software-Images
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, und das Modul kopiert das Paket standardmäßig auf das Zielgerät, bevor es die Installation durchführt. Bei gemischten Virtual Chassis-Umgebungen müssen sich die Softwarepakete auf dem Ansible-Steuerungsknoten befinden. Für eigenständige Geräte oder nicht gemischte Virtual Chassis-Umgebungen können Sie das Modul auch anweisen, ein Software-Image zu installieren, das sich bereits auf dem Junos-Zielgerät oder unter einer URL befindet, die vom Zielgerät aus erreichbar ist.
In Tabelle 2 sind die Modulargumente 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. Der no_copy Standardwert ist der Wert von false, wodurch das Modul angewiesen wird, das Softwarepaket von der angegebenen Position auf dem Ansible-Steuerungsknoten auf das Zielgerät zu kopieren.
| Speicherort des Softwarepakets |
|
|
|
|---|---|---|---|
| Ansible-Steuerungsknoten |
Weglassen oder auf |
Für eigenständige Geräte oder nicht gemischte Virtual Chassis-Umgebungen: Wird auf den Dateipfad, einschließlich des Dateinamens, des Softwarepakets auf dem lokalen Steuerungsknoten gesetzt |
(Optional) Dateipfad auf dem Zielgerät, auf das das Softwarepaket kopiert wird. Das Standardverzeichnis ist /var/tmp. Wenn |
| Für gemischte Virtual Chassis-Umgebungen: Legt diese Option auf eine Liste der Dateipfade, einschließlich der Dateinamen, eines oder mehrerer Softwarepakete auf dem lokalen Steuerungsknoten fest |
– |
||
| Remote-Standort |
– |
– |
URL aus der Perspektive des Junos-Zielgeräts, von dem aus das Softwarepaket installiert wird. |
| Zielgerät |
Legen Sie diese Einstellung fest 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 hinzu:
-
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 Komponenten in einem gemischten Virtual Chassis. Der Argumentwert ist eine Liste von Zeichenfolgen, die die absoluten oder relativen Dateipfade der Softwareimages für die verschiedenen Virtual Chassis-Member in beliebiger Reihenfolge 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 einschließen, kopiert das Modul standardmäßig alle Softwarepakete vom Ansible-Steuerungsknoten in das Verzeichnis /var/tmp auf dem Junos-Zielgerä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 remote_package Argumente und identisch sein, da das Modul sonst einen Fehler generiert.
Wenn sich das Softwarepaket bereits auf dem Junos-Zielgerät (Einzelgerät oder primäres Virtual Chassis-Gerät) befindet, muss das Modul neben dem Argument auch das no_copy: true Argument enthalten, das remote_package den Dateipfad zu einem vorhandenen Softwarepaket auf dem Zielgerät angibt. Wenn remote_package kein Verzeichnis angegeben wird, ist der Standardwert /var/tmp.
Wenn sich das Softwarepaket an einem anderen Ort als dem Ansible-Steuerungsknoten 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. Hinweise zu zulässigen URL-Formaten finden Sie unter Format zum Angeben von Dateinamen und URLs in Junos OS-CLI-Befehlen.
Übersicht über den Installationsprozess
Um Ansible zum Installieren eines Softwarepakets auf einem Junos-Gerät zu verwenden, führen Sie das software Modul aus und geben Sie alle 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 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 ursprünglich dorthin heruntergeladen oder vom Modul kopiert wurde, führt das Modul die folgenden Vorgänge aus:
Überprüft die Konfiguration anhand des neuen Pakets, wenn das
validateArgument auf festgelegt ist.trueAnmerkung:Standardmäßig validiert das
softwareModul das Softwarepaket oder -paket nicht anhand der vorhandenen Konfiguration als Voraussetzung für das Hinzufügen des Softwarepakets. Um sicherzustellen, dass die aktive Konfiguration mit dem neuen Software-Image funktioniert, legen Sie dasvalidateArgument auftrue.Installiert das Paket auf jeder einzelnen Routing-Engine, es sei denn
all_re, es ist auffalsefestgelegt.Startet jedes aktualisierte Routing-Modul neu, es sei denn, das
rebootArgument ist auffalsefestgelegt.
Das software Modul ermöglicht es Ihnen, den Fortschritt der Installation zu protokollieren, indem Sie das logfile Argument module einschließen. Standardmäßig werden nur Meldungen des Schweregrads WARNUNG oder höher protokolliert. Um Meldungen des Schweregrads INFO oder höher zu protokollieren, der für die Protokollierung von Meldungen für den allgemeinen Installationsprozess erforderlich ist, führen Sie das Playbook mit der -v Befehlszeilenoption oder --verbose aus.
Angeben von Timeout-Werten
Das juniper.device.software Modul führt Vorgänge über eine NETCONF-Sitzung aus. Die Standardzeit für eine Zeitüberschreitung bei einem NETCONF-RPC beträgt 30 Sekunden. Während des Installationsvorgangs wird das RPC-Timeoutintervall durch bestimmte Vorgänge wie folgt erhöht:
-
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 kann der Installationsprozess, die Prüfsummenberechnung oder die Speicherbereinigung diese Zeitintervalle überschreiten. Sie können den Timeoutwert für diese Vorgänge ändern, checksum_timeoutindem Sie die install_timeoutArgumente , und cleanfs_timeout auf die erforderliche Anzahl von Sekunden in der Argumentliste des Moduls 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
Angeben von Installationsoptionen, die nicht über ein entsprechendes Modulargument verfügen
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 z. B. den <request-package-add> RPC für Standardinstallationen von Junos OS, den <request-vmhost-package-add> RPC für VM-Host-Upgrades, den <request-package-in-service-upgrade> RPC für Szenarien mit einheitlicher ISSU usw. auf.
Das Modul unterstützt explizite Argumente für viele der Installationsoptionen, z. B. die validate Option. Das Modul unterstützt auch das Argument, mit dem kwargs Sie zusätzliche Optionen einschließen können, die vom RPC unterstützt werden, aber kein entsprechendes Modulargument haben. Das kwargs Argument verwendet ein Wörterbuch von Schlüssel-Wert-Paaren mit zusätzlichen unterstützten Optionen.
Die aktuelle Liste der Optionen, die vom Modul unterstützt werden, 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 zum entsprechenden Befehl, oder suchen Sie im Junos XML API Explorer nach dem Anforderungs-Tag des RPC.
Sie sollten nur Installationsoptionen einschließen, die auf dem Junos-Zielgerät für den jeweiligen RPC unterstützt werden.
Im folgenden Playbook installiert das software Modul ein neues Softwareimage 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, die über Routing-Engines mit VM-Host-Unterstützung verfügen, läuft Junos OS als virtuelle Maschine (VM) über einen Linux-basierten Host (VM-Host). Für ein VM-Host-Upgrade ist ein VM-Host-Installationspaket (junos-vmhost-install-x.tgz) erforderlich, und es werden das Hostbetriebssystem und das kompatible Junos OS aktualisiert. In der CLI führen Sie das Upgrade mit dem request vmhost software add Befehl operational mode 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.
Mit dem folgenden Playbook werden Junos OS und das Hostbetriebssystem auf den angegebenen Geräten aktualisiert und neu gestartet:
---
- 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
Wie führe ich eine einheitliche ISSU oder NSSU durch
Das juniper.device.software Modul unterstützt die Durchführung eines einheitlichen In-Service-Software-Upgrades (Unified ISSU) oder eines Nonstop-Software-Upgrades (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 einheitliche ISSU-Funktion ermöglicht Ihnen ein Upgrade zwischen zwei verschiedenen Junos OS-Versionen ohne Unterbrechung der Control Plane und mit minimaler Unterbrechung des Datenverkehrs. Um ein einheitliches In-Service-Softwareupgrade 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 ein Nonstop-Softwareupgrade durchzufü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 unter Übersicht über den Installationsprozess beschriebenen Installationsprozess, um das gesamte Virtual Chassis zu aktualisieren. Es kann jedoch vorkommen, dass Sie Software auf bestimmten Mitglieds-Switches im Virtual Chassis installieren müssen. Ab Version 1.0.3 der juniper.device Sammlung können Sie ein Softwarepaket auf einzelnen Mitglieds-Switches in einem nicht gemischten Virtual Chassis der EX-Serie 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 Membern.
Mit dem folgenden Ansible-Playbook wird die Software auf Member 0 und Member 1 im EX-Serie Virtual Chassis aktualisiert:
---
- 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 Software-Image auf einem Junos-Gerät zu installieren.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
-
Configuration Management Server mit Ansible 2.17 oder höher und auf dem die
juniper.deviceSammlung installiert ist -
Junos-Gerät mit aktiviertem NETCONF und einem Benutzerkonto mit entsprechenden Berechtigungen
-
Öffentliches/privates SSH-Schlüsselpaar, das für den entsprechenden Benutzer auf dem Ansible-Kontrollknoten und dem Junos-Gerät konfiguriert ist
-
Vorhandene Ansible-Bestandsdatei mit definierten erforderlichen Hosts
Überblick
In diesem Beispiel wird ein Ansible-Playbook dargestellt, das das Modul zum Aktualisieren von juniper.device.software Junos OS auf den Hosts in der angegebenen Bestandslistengruppe verwendet. In diesem Beispiel befindet sich das Software-Image auf dem Ansible-Steuerungsknoten, und das Modul kopiert das Image vor der Installation auf das Zielgerät. Da das Modul nicht explizit ein host Argument definiert, arbeitet es auf dem Standardhost, der .{{ inventory_hostname }}
Dieses Playbook enthält die Check NETCONF connectivity Aufgabe, die das ansible.builtin.wait_for Modul nutzt, um zu versuchen, eine NETCONF-Sitzung mit dem Junos-Gerät über den Standard-NETCONF-Port 830 einzurichten. Wenn der Steuerungsknoten während der Ausführung des Playbooks keine NETCONF-Sitzung mit einem Gerät einrichten kann, überspringt er die verbleibenden Aufgaben in der Wiedergabe für dieses Gerät.
Der Install Junos OS package Task führt das 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 Playbookausfü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-Steuerknoten. Während der Installation führt das Modul 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 und installiert dann die Software auf jeder Routing-Engine auf dem Zielhost. Standardmäßig startet das software Modul jede Routing-Engine nach Abschluss der Installation neu. Diese Aufgabe dient jedoch explizit reboot: true der Klarheit.
Die Aufgabe speichert das Modulergebnis in der response Variablen und benachrichtigt einen Handler. Wenn der Benutzer das Playbook nicht im Überprüfungsmodus ausführt, versucht der wait_reboot Handler, 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, in der der Steuerungsknoten versucht, sich erneut mit dem Gerät zu verbinden.
Dieses Beispiel enthält den logfile Parameter zum Protokollieren des Installationsfortschritts. Dies ist wichtig für das Debugging, falls die Installation fehlschlägt, sowie für die Protokollierung von Datum und Uhrzeit von Installationen auf den Geräten. Der Benutzer, der das Playbook ausführt, muss über Berechtigungen zum Schreiben in die angegebene Protokolldatei verfügen. Standardmäßig werden nur Meldungen des Schweregrads WARNUNG oder höher protokolliert. In diesem Beispiel wird das Playbook mit der Option ausgeführt, Meldungen -v des Schweregrads 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 Stück 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, in diesem Beispiel unter anderem die gewünschte Junos OS-Version und den Pfad zum neuen Image.
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, um die NETCONF-Konnektivität zu überprüfen.
tasks: - name: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: 5 -
Erstellen Sie den Task, um das Junos OS-Paket auf dem Gerät zu installieren, und benachrichtigen Sie den Handler.
- 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 Modulantwort 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 geschaltet wird.
Der Handlername sollte mit dem Namen identisch sein, auf den in der Installationsaufgabe verwiesen wird.
handlers: - name: wait_reboot ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: "{{ wait_time }}" when: not response.check_mode
Befund
Überprüfen Sie auf dem Ansible-Steuerungsknoten das fertige Playbook. Wenn das Playbook den beabsichtigten Code nicht 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 ein, und geben Sie den Playbookpfad und alle gewünschten 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
Vergewissern Sie sich, dass die Softwareinstallation erfolgreich war.
Aktion
Die Playbookausgabe sollte alle fehlgeschlagenen Aufgaben anzeigen. Sie können jedoch auch den Inhalt der im Playbook definierten Protokolldatei auf Details zur Installation überprüfen. Hier sehen Sie eine Beispielausgabe für eine Protokolldatei. 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 Image erfolgreich kopiert und auf beiden Routing-Modulen auf dem Zielgerät installiert wurde.