Utiliser Ansible pour installer des logiciels sur les équipements Junos
Utilisez les modules Ansible de Juniper Networks pour installer des logiciels sur les équipements Junos.
Utiliser Ansible pour installer des logiciels
Juniper Networks fournit un module Ansible qui vous permet d’installer ou de mettre à niveau l’image logicielle sur un équipement Junos. Le tableau 1 présente le module.
| Ensemble de contenu |
Nom du module |
|---|---|
|
|
Les sections suivantes expliquent comment spécifier l’emplacement de l’image logicielle ainsi que le processus et les options généraux d’installation du logiciel lors de l’utilisation du module Ansible pour installer des packages logiciels sur des équipements Junos. Ils expliquent également comment effectuer des scénarios de mise à niveau plus spécialisés, tels qu’une mise à niveau de l’hôte d’une machine virtuelle, une mise à niveau logicielle en service unifié (ISSU unifiée) ou une mise à niveau logicielle ininterrompue (NSSU) sur les appareils qui prennent en charge ces fonctionnalités.
Comment spécifier l’emplacement de l’image logicielle
Lorsque vous utilisez le juniper.device.software module pour installer des logiciels sur des équipements Junos, vous pouvez télécharger le package logiciel sur le nœud de contrôle Ansible, et le module, par défaut, copie le package sur l’équipement cible avant d’effectuer l’installation. Pour les environnements Virtual Chassis mixtes, les packages logiciels doivent résider sur le nœud de contrôle Ansible. Pour les équipements autonomes ou les environnements Virtual Chassis non mixtes, vous pouvez également demander au module d’installer une image logicielle qui réside déjà sur le périphérique Junos cible ou qui réside à une URL accessible à partir de l’équipement cible.
Le Tableau 2 décrit les arguments de module que vous devez définir en fonction de l’emplacement du progiciel. Le module doit toujours inclure l’argument local_package, pkg_setou remote_package . La no_copy valeur par défaut est false, qui indique au module de copier le progiciel à partir de l’emplacement spécifié sur le nœud de contrôle Ansible vers l’équipement cible.
| Emplacement du progiciel |
|
|
|
|---|---|---|---|
| nœud de contrôle Ansible |
Omettre ou définir sur |
Pour les équipements autonomes ou les environnements Virtual Chassis non mixtes : Défini |
(Facultatif) Chemin d’accès au fichier sur l’équipement cible sur lequel le progiciel est copié. Le répertoire par défaut est /var/tmp. S’il |
| Pour les environnements Virtual Chassis mixtes : Défini |
– |
||
| Emplacement distant |
– |
– |
URL du point de vue de l’équipement Junos cible à partir duquel le progiciel est installé. |
| Équipement cible |
Se mettre à |
– |
Chemin d’accès au fichier sur l’équipement cible sur lequel le progiciel doit déjà résider. Le répertoire par défaut est /var/tmp. |
Si le progiciel se trouve sur le nœud de contrôle Ansible, incluez l’argument approprié pour votre installation :
-
local_package: permet d’installer le logiciel sur un équipement Junos autonome ou sur les membres d’un Virtual Chassis non mixte. La valeur de l’argument est une chaîne unique spécifiant le chemin absolu ou relatif vers l’image logicielle. -
pkg_set: permet d’installer le logiciel sur les membres d’un Virtual Chassis mixte. La valeur de l’argument est une liste de chaînes qui spécifient les chemins d’accès absolus ou relatifs aux fichiers des images logicielles, sans ordre particulier, pour les différents membres de Virtual Chassis.
Par exemple:
pkg_set: - 'software/jinstall-qfx-5-13.2X51-D35.3-domestic-signed.tgz' - 'software/jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz'
Par défaut, lorsque vous incluez l’argument local_package or pkg_set , le module copie tous les packages logiciels du nœud de contrôle Ansible vers le répertoire /var/tmp du périphérique Junos cible (équipement individuel ou équipement principal de Virtual Chassis). Si vous souhaitez copier l’image local_package dans un autre répertoire, définissez l’argument remote_package et spécifiez le répertoire cible. Si l’argument remote_package inclut un nom de fichier, les noms de fichiers des local_package arguments et remote_package doivent être identiques, sinon le module génère une erreur.
Si le progiciel réside déjà sur l’équipement Junos cible (équipement individuel ou équipement principal Virtual Chassis), le module doit inclure l’argument no_copy: true ainsi que l’argument remote_package , qui spécifie le chemin d’accès à un progiciel existant sur l’équipement cible. S’il remote_package ne spécifie pas de répertoire, la valeur par défaut est /var/tmp.
Si le progiciel se trouve à un emplacement autre que le nœud de contrôle Ansible ou l’équipement cible, le module doit inclure l’argument remote_package et spécifier l’emplacement du progiciel. La valeur de remote_package est une URL du point de vue de l’équipement Junos cible. Pour plus d’informations sur les formats d’URL acceptables, reportez-vous à la section Format de spécification des noms de fichiers et des URL dans les commandes CLI de Junos OS.
Vue d’ensemble du processus d’installation
Pour utiliser Ansible afin d’installer un progiciel sur un équipement Junos, exécutez le software module et fournissez les arguments nécessaires. Par exemple:
---
- 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
Lorsque vous exécutez le software module, il effectue les opérations suivantes :
Une fois que le progiciel est sur l’équipement cible, qu’il y ait été téléchargé initialement ou copié par le module, le module effectue alors les opérations suivantes :
Valide la configuration par rapport au nouveau package lorsque l’argument
validateest défini surtrue.Note:Par défaut, le
softwaremodule ne valide pas le progiciel ou le bundle par rapport à la configuration existante comme condition préalable à l’ajout du progiciel. Pour vous assurer que la configuration active fonctionnera avec la nouvelle image logicielle, définissez l’argumentvalidatesurtrue.Installe le package sur chaque moteur de routage, sauf s’il
all_reest défini surfalse.Redémarre chaque moteur de routage mis à niveau, sauf si l’argument
rebootest défini surfalse.
Le software module vous permet d’enregistrer la progression de l’installation en incluant l’argument logfile module. Par défaut, seuls les messages de niveau de gravité AVERTISSEMENT ou supérieur sont consignés. Pour consigner les messages de niveau de gravité INFO ou supérieur, qui est nécessaire pour consigner les messages du processus d’installation général, exécutez le playbook à l’aide de l’option -v de ligne de commande ou --verbose .
Comment spécifier des valeurs de délai d’expiration
Le juniper.device.software module effectue des opérations sur une session NETCONF. Par défaut, le délai d’expiration d’un RPC NETCONF est de 30 secondes. Au cours du processus d’installation, certaines opérations augmentent l’intervalle de délai d’expiration RPC comme suit :
-
Copie et installation du package sur l’appareil : 1 800 secondes (30 minutes)
-
Calcul de la somme de contrôle : 300 secondes (5 minutes)
-
Nettoyage du stockage : 300 secondes (5 minutes)
Dans certains cas, le processus d’installation, le calcul de la somme de contrôle ou le nettoyage du stockage peuvent dépasser ces intervalles de temps. Vous pouvez modifier la valeur du délai d’expiration de ces opérations en définissant les install_timeoutarguments , checksum_timeout, et cleanfs_timeout sur le nombre de secondes requis dans la liste des arguments du module. Par exemple:
- 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
Comment spécifier des options d’installation qui n’ont pas d’argument de module équivalent
Lorsque vous utilisez le juniper.device.software module pour installer un logiciel sur un périphérique, le module appelle le RPC approprié pour les arguments d’installation inclus. Par exemple, le module appelle le RPC pour les <request-package-add> installations standard de Junos OS, le RPC pour les <request-vmhost-package-add> mises à niveau d’hôtes de machines virtuelles, le RPC pour les <request-package-in-service-upgrade> scénarios ISSU unifiés, etc.
Le module prend en charge des arguments explicites pour de nombreuses options d’installation, par exemple, l’option validate . Le module prend également en charge l’argument kwargs , ce qui vous permet d’inclure toutes les options supplémentaires prises en charge par le RPC mais qui n’ont pas d’argument de module équivalent. L’argument kwargs utilise un dictionnaire de paires clé/valeur d’options supplémentaires prises en charge.
Pour obtenir la liste actuelle des options prises en charge par le module, consultez la documentation de référence de l’API du module. Pour obtenir la liste de toutes les options disponibles pour un RPC spécifique, reportez-vous à la documentation de la commande équivalente ou recherchez la balise request du RPC dans l’explorateur d’API XML Junos.
Vous ne devez inclure que les options d’installation prises en charge sur le périphérique Junos cible pour le RPC donné.
Dans le playbook suivant, le software module installe une nouvelle image logicielle sur les hôtes cibles. Le module inclut l’argument kwargs avec unlink: true. Cet argument, qui supprime le progiciel du répertoire après une mise à niveau réussie, équivaut à inclure l’option <unlink/> dans le <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
Procédure de mise à niveau d’un hôte de machine virtuelle
Sur les équipements dotés de moteurs de routage avec prise en charge d’hôtes de machines virtuelles, Junos OS s’exécute en tant que machine virtuelle (VM) sur un hôte basé sur Linux (hôte de machines virtuelles). Une mise à niveau de l’hôte d’une machine virtuelle nécessite un package d’installation de l’hôte de machine virtuelle (junos-vmhost-install-x.tgz) et met à niveau le système d’exploitation hôte et les Junos OS compatibles. Dans l’interface de ligne de commande, vous effectuez la mise à niveau à l’aide de la request vmhost software add commande du mode opérationnel, qui correspond au <request-vmhost-package-add> RPC.
Le juniper.device.software module prend en charge l’argument permettant d’effectuer une mise à niveau de l’hôte d’une vmhost: true machine virtuelle. Lorsque l’argument est présent, le module effectue l’installation à l’aide du <request-vmhost-package-add> RPC.
Le playbook suivant met à niveau et redémarre Junos OS et le système d’exploitation hôte sur les périphériques spécifiés :
---
- 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
Comment réaliser un ISSU unifié ou une NSSU
Le juniper.device.software module prend en charge l’exécution d’une mise à niveau logicielle en service unifiée (ISSU unifiée) ou d’une mise à niveau logicielle ininterrompue (NSSU) sur les équipements qui prennent en charge la fonctionnalité et répondent aux exigences nécessaires. Pour plus d’informations sur les fonctionnalités unifiées ISSU et NSSU, reportez-vous à la documentation logicielle de votre produit.
La fonction ISSU unifié vous permet d’effectuer une mise à niveau entre deux versions différentes de Junos OS sans interruption sur le plan de contrôle et avec une interruption minimale du trafic. Pour effectuer une mise à niveau logicielle unifiée en service, le software module doit inclure l’argument issu: true . Par exemple:
---
- 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
La fonction NSSU vous permet de mettre à niveau le logiciel Junos OS s’exécutant sur un commutateur ou Virtual Chassis avec des moteurs de routage redondants avec une interruption minimale du trafic réseau. Pour effectuer une mise à jour logicielle ininterrompue, le software module doit inclure l’argument nssu: true . Par exemple:
---
- 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
Comment installer un logiciel sur un membre EX Series Virtual Chassis
En règle générale, lorsque vous mettez à niveau un Virtual Chassis EX Series non mixte, vous devez suivre le processus d’installation décrit dans Présentation du processus d’installation pour mettre à niveau l’ensemble du Virtual Chassis. Toutefois, il peut arriver que vous ayez besoin d’installer le logiciel sur des commutateurs membres spécifiques dans Virtual Chassis. À partir de la version 1.0.3 de la juniper.device collection, vous pouvez installer un package logiciel sur des commutateurs membres individuels dans un Virtual Chassis EX Series non mixte.
Pour installer un logiciel sur des membres spécifiques, incluez l’argument member_id et définissez une liste de chaînes qui spécifient les ID de membre. Le système installe le package logiciel à partir de l’équipement principal de Virtual Chassis sur les membres spécifiés.
Le guide Ansible suivant met à niveau le logiciel sur les membres 0 et 1 du Virtual Chassis EX Series :
---
- 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"
Exemple : Utiliser Ansible pour installer des logiciels
Cet exemple utilise le module pour installer une image logicielle juniper.device.software sur un équipement Junos.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
-
Serveur de gestion de la configuration exécutant Ansible 2.17 ou version ultérieure avec la
juniper.devicecollection installée -
Équipement Junos sur lequel NETCONF est activé et compte d’utilisateur configuré avec les autorisations appropriées
-
Paire de clés publique/privée SSH configurée pour l’utilisateur approprié sur le nœud de contrôle Ansible et l’équipement Junos
-
Fichier d’inventaire Ansible existant avec les hôtes requis définis
Aperçu
Cet exemple présente un playbook Ansible qui utilise le juniper.device.software module pour mettre à niveau Junos OS sur les hôtes du groupe d’inventaire spécifié. Dans cet exemple, l’image logicielle se trouve sur le nœud de contrôle Ansible et le module copie l’image sur l’équipement cible avant de l’installer. Le module ne définit pas explicitement d’argument host , il fonctionne donc sur l’hôte par défaut, qui est {{ inventory_hostname }}.
Ce playbook inclut la Check NETCONF connectivity tâche qui utilise le ansible.builtin.wait_for module pour tenter d’établir une session NETCONF avec le périphérique Junos à l’aide du port NETCONF 830 par défaut. Si le nœud de contrôle ne parvient pas à établir une session NETCONF avec un périphérique pendant l’exécution du playbook, il ignore les tâches restantes dans la lecture pour ce périphérique.
La Install Junos OS package tâche exécute le software module à condition que la vérification NETCONF ait réussi. L’argument version définit la version de Junos OS souhaitée telle qu’elle serait signalée par la show version commande sur le périphérique Junos. Lors de l’exécution du playbook, le module vérifie d’abord que la version demandée n’est pas déjà installée sur l’appareil. Si la version demandée est différente de la version actuellement installée, le module installe la version demandée.
L’argument local_package définit le chemin d’accès du progiciel Junos OS sur le nœud de contrôle Ansible. Au cours de l’installation, le module effectue une opération de nettoyage du stockage sur l’équipement cible, copie l’image logicielle dans le répertoire /var/tmp de l’appareil, vérifie la somme de contrôle du fichier, valide le nouveau logiciel par rapport à la configuration active, puis installe le logiciel sur chaque moteur de routage sur l’hôte cible. Par défaut, le software module redémarre chaque moteur de routage une fois l’installation terminée ; toutefois, cette tâche est explicitement définie reboot: true pour plus de clarté.
La tâche stocke le résultat du module dans la response variable et notifie un gestionnaire. Si l’utilisateur n’exécute pas le playbook à l’aide du mode de vérification, le wait_reboot gestionnaire tente alors d’établir une session avec l’appareil pour vérifier que l’appareil est de nouveau en ligne. La wait_time variable définit la durée pendant laquelle le noeud de contrôle tente de se reconnecter à l’équipement.
Cet exemple inclut le logfile paramètre permettant d’enregistrer la progression de l’installation. Ceci est important à des fins de débogage en cas d’échec de l’installation, ainsi que pour enregistrer les dates et heures d’installation sur les appareils. L’utilisateur qui exécute le playbook doit disposer des autorisations nécessaires pour écrire dans le fichier journal spécifié. Par défaut, seuls les messages de niveau de gravité AVERTISSEMENT ou supérieur sont consignés. Dans cet exemple, le playbook est exécuté avec la possibilité de consigner les -v messages de niveau de gravité INFO ou supérieur pour surveiller l’installation.
Configuration
Création du playbook Ansible
Pour créer un playbook qui utilise le module pour installer une image logicielle juniper.device.software sur un équipement Junos :
-
Incluez le passe-partout pour le playbook et ce play, qui exécute les modules localement.
--- - name: Install Junos OS hosts: mx1 connection: local gather_facts: no
-
Définissez ou importez toutes les variables nécessaires, ce qui inclut par exemple la version de Junos OS souhaitée et le chemin d’accès à la nouvelle image, entre autres.
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 -
(Facultatif) Créez une tâche pour vérifier la connectivité NETCONF.
tasks: - name: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: 5 -
Créez la tâche d’installation du package Junos OS sur le périphérique et informez le gestionnaire.
- 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 -
(Facultatif) Créez une tâche pour imprimer la réponse du module.
- name: Print response ansible.builtin.debug: var: response -
Créez le gestionnaire qui vérifie que l’appareil se reconnecte après le redémarrage.
Le nom du gestionnaire doit être le même que celui référencé dans la tâche d’installation.
handlers: - name: wait_reboot ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: "{{ wait_time }}" when: not response.check_mode
Résultats
Sur le nœud de contrôle Ansible, passez en revue le playbook terminé. Si le playbook n’affiche pas le code voulu, répétez les instructions de cet exemple pour corriger le playbook.
---
- 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
Exécuter le playbook
Pour exécuter le playbook :
-
Émettez la
ansible-playbookcommande sur le nœud de contrôle et indiquez le chemin d’accès au playbook ainsi que les options souhaitées.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
Vérification
Vérifier l’installation
But
Vérifiez que l’installation du logiciel a réussi.
Action
La sortie du playbook doit indiquer les tâches qui ont échoué. Toutefois, vous pouvez également consulter le contenu du fichier journal défini dans le playbook pour plus de détails sur l’installation. Un exemple de sortie du fichier journal est affiché ici. Certains résultats ont été omis par souci de concision.
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'
Signification
Le contenu du fichier journal indique que l’image a été copiée et installée avec succès sur les deux moteurs de routage de l’équipement cible.