Utiliser le module Ansible pour installer des juniper.device.software Logiciels sur les équipements Junos
Vous pouvez utiliser le module Ansible pour installer des juniper.device.software logiciels sur des équipements exécutant Junos OS ou des équipements exécutant Junos OS Evolved.
Utiliser Ansible pour installer des Logiciels
Juniper Networks fournit des modules Ansible qui vous permettent d’installer une image logicielle sur des équipements Junos. Le Tableau 1 présente les modules. Si vous utilisez déjà un ensemble donné de modules de la juniper.device collection, utilisez le module pour cet ensemble.
|
Collecte |
Ensemble de modules |
Nom du module |
|---|---|---|
|
|
||
|
|
Les sections suivantes expliquent comment utiliser le juniper.device.software module pour installer un package logiciel sur un équipement Junos. Les sections décrivent comment spécifier l’emplacement de l’image logicielle ainsi que le processus et les options générales d’installation du logiciel. Les sections expliquent également comment effectuer des scénarios de mise à niveau plus spécialisés, tels qu’une mise à niveau d’hôte de machine virtuelle, une mise à niveau logicielle unifiée en service (ISSU unifiée) ou une mise à niveau logicielle ininterrompue (NSSU) sur des appareils prenant en charge ces fonctionnalités.
Spécification de l’emplacement de l’image du Logiciels
Lorsque vous utilisez le module pour installer un juniper.device.software logiciel sur des équipements Junos, vous pouvez télécharger le package logiciel sur le nœud de contrôle Ansible. Le module, par défaut, copie le package sur l’appareil 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 périphériques 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 à une URL accessible depuis le périphérique cible.
Le Tableau 2 présente 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 . L’argument no_copy par défaut est false, ce qui indique au module de copier le package logiciel de l’emplacement spécifié sur le nœud de contrôle Ansible vers l’équipement cible.
|
Logiciels emplacement du colis |
|
|
|
|---|---|---|---|
|
Nœud de contrôle Ansible |
Omettre ou définir sur |
Pour les appareils autonomes ou les environnements Virtual Chassis non mixtes : Défini |
(Facultatif) Chemin d’accès au fichier sur l’appareil cible sur lequel le progiciel est copié. Le répertoire par défaut est /var/tmp. Si |
|
Pour les environnements Virtual Chassis mixtes : Défini |
– |
||
|
Emplacement distant |
– |
– |
URL du point de vue de l’équipement Junos cible à partir duquel le package logiciel est installé. |
|
Appareil cible |
Défini sur |
– |
Chemin d’accès au fichier sur l’appareil cible où le progiciel doit déjà résider. Le répertoire par défaut est /var/tmp. |
Si le package logiciel réside sur le nœud de contrôle Ansible, incluez l’argument approprié à votre installation :
-
local_package: installe le logiciel sur un équipement Junos autonome ou sur des 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: installe 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 de fichiers absolus ou relatifs 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 (périphérique individuel ou périphérique principal 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 package logiciel 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 en plus de l’argument remote_package . L’argument remote_package spécifie le chemin d’accès à un package logiciel existant sur l’appareil cible. Si remote_package ne spécifie pas de répertoire, la valeur par défaut est /var/tmp.
Si le progiciel réside à 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 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.
Présentation du processus d’installation
Utiliser Ansible pour installer un package logiciel sur un équipement Junos, exécuter le juniper.device.software module et fournir 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 juniper.device.software module, il effectue les opérations suivantes :
Une fois que le progiciel est sur l’appareil cible, qu’il y soit 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, sauf si l’argument
validateest défini surfalse.Remarque : À partir dejuniper.devicela version 2.0.4, levalidateparamètre par défaut esttrue. Dans les versions antérieures, la valeur par défaut estfalse. -
Installe le package sur chaque moteur de routage individuel, sauf si
all_rela valeur est .false -
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 enregistrés. Pour consigner les messages de niveau de gravité INFO ou supérieur, ce qui est nécessaire pour consigner les messages pour le processus d’installation général, exécutez le playbook avec l’option -v de ligne de commande ou --verbose .
Spécification de valeurs de délai d’attente
Le juniper.device.software module effectue des opérations sur une session NETCONF. Le délai d’expiration par défaut d’un RPC NETCONF est de 30 secondes. Pendant le 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 : 1800 secondes (30 minutes)
-
Calcul de la somme de contrôle : 300 secondes (5 minutes)
-
Nettoyage de l’entrepôt : 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. Vous pouvez modifier la valeur du délai d’expiration de ces opérations en définissant les install_timeoutarguments , checksum_timeoutet 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 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 invoque 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 VM, 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 soutient également l’argument kwargs . L’argument vous permet d’inclure toutes les options supplémentaires prises en charge par le RPC. L’argument kwargs prend 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 pour le 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 de Junos.
Vous ne devez inclure que les options d’installation prises en charge par l’équipement 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 . unlink: true Cet argument, qui supprime le package logiciel 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
Mise à niveau d’un hôte de machine virtuelle
Sur les équipements dotés de moteurs de routage prenant en charge l’hôte de machine virtuelle, Junos OS s’exécute en tant que machine virtuelle sur un hôte Linux (hôte de machine virtuelle). Une mise à niveau de l’hôte de machine virtuelle nécessite un package d’installation de l’hôte de la machine virtuelle (junos-vmhost-install-x.tgz) et met à niveau le système d’exploitation hôte et les Junos OS compatibles. Dans la CLI, vous effectuez la mise à niveau à l’aide de la request vmhost software add commande mode opérationnel, qui correspond au <request-vmhost-package-add> RPC.
Le juniper.device.software module prend en charge l’argument en faveur de la mise à niveau d’un vmhost: true hôte de 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 le système d’exploitation Junos OS et le système d’exploitation hôte sur les équipements 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 effectuer un ISSU ou un NSSU unifié
Le juniper.device.software module prend en charge l’exécution d’un ISSU unifié ou d’un NSSU sur les appareils qui prennent en charge la fonctionnalité et répondent aux exigences nécessaires. Pour plus d’informations sur les fonctionnalités unifiées d’ISSU et de NSSU, consultez la documentation logicielle de votre produit.
La fonctionnalité ISSU unifiée 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 un ISSU unifié, 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 fonctionnalité NSSU vous permet de mettre à niveau le logiciel Junos OS exécuté sur un commutateur ou un Virtual Chassis avec des moteurs de routage redondants avec une interruption minimale du trafic réseau. Pour effectuer un NSSU, 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
Installation de Logiciels sur un membre du Virtual Chassis EX Series
En règle générale, lorsque vous mettez à niveau un Virtual Chassis EX Series non mixte, vous suivez 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 deviez installer un logiciel sur des commutateurs membres spécifiques dans le Virtual Chassis. Le juniper.device.software module vous permet d’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 des membres. Le système installe le progiciel du périphérique principal Virtual Chassis sur les membres spécifiés.
Le playbook Ansible suivant met à niveau le logiciel sur le membre 0 et le membre 1 dans EX Series 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"
Exemple : Utiliser Ansible pour installer des Logiciels
Cet exemple utilise le module pour installer une image logicielle juniper.device.software sur un équipement exécutant Junos OS.
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 un compte 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
Vue d’ensemble
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 réside sur le nœud de contrôle Ansible et le module copie l’image sur l’appareil 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 guide comprend la Check NETCONF connectivity tâche qui utilise le ansible.builtin.wait_for module pour essayer d’établir une session NETCONF avec l’équipement 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 en cours de lecture pour ce périphérique.
La Install Junos OS package tâche exécute le juniper.device.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 l’équipement 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 du package logiciel Junos OS sur le nœud de contrôle Ansible. Lors de l’installation, le module :
-
Effectue une opération de nettoyage du stockage sur l’équipement cible
-
Copie l’image du logiciel dans le répertoire /var/tmp de l’appareil
-
Vérifie la somme de contrôle du fichier
-
Validation du nouveau logiciel par rapport à la configuration active
-
Installe le logiciel sur chaque moteur de routage sur l’hôte cible
Par défaut, le juniper.device.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 vous n’exécutez pas le playbook en utilisant le mode check, le gestionnaire tente alors d’établir wait_reboot 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 nœud de contrôle tente de se reconnecter à l’appareil.
Cet exemple inclut le logfile paramètre permettant d’enregistrer la progression de l’installation. Ce journal est important à des fins de débogage en cas d’échec de l’installation, ainsi que pour la journalisation des dates et heures d’installation sur les appareils. L’utilisateur exécutant 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 enregistrés. L’exemple exécute le playbook avec la -v possibilité d’enregistrer les messages de niveau de gravité INFO ou supérieur pour surveiller l’installation.
La 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 du playbook et de ce jeu, 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, qui incluent pour cet 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 pour installer le package Junos OS sur l’équipement et en informer 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 ractive 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 prévu, 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 guide stratégique
Pour exécuter le playbook :
-
Exécutez la
ansible-playbookcommande sur le nœud de contrôle et fournissez le chemin du playbook et toutes les options requises.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érifiez l’installation
Objet
Vérifiez que l’installation du logiciel a réussi.
Mesures à prendre
La sortie du playbook doit indiquer toutes les tâches ayant é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 de fichier journal est présenté 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 le playbook a copié et installé l’image sur les deux moteurs de routage de l’équipement cible.
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
juniper.device la version 2.0.4, le validate paramètre par défaut est true. Dans les versions antérieures, la valeur par défaut est false.