Usar Ansible para instalar software en dispositivos Junos
Utilice los módulos de Ansible de Juniper Networks para instalar software en dispositivos Junos.
Usar Ansible para instalar software
Juniper Networks proporciona un módulo de Ansible que le permite instalar o actualizar la imagen de software en un dispositivo Junos. La Tabla 1 describe el módulo.
Conjunto de contenido |
Nombre del módulo |
---|---|
|
En las siguientes secciones se explica cómo especificar la ubicación de la imagen de software y el proceso y las opciones generales de instalación de software cuando se utiliza el módulo Ansible para instalar paquetes de software en dispositivos Junos. También explican cómo realizar escenarios de actualización más especializados, como una actualización de host de máquina virtual, una actualización de software en servicio unificada (ISSU unificada) o una actualización de software sin interrupciones (NSSU) en dispositivos que admiten estas características.
Cómo especificar la ubicación de la imagen de software
Cuando utilice el juniper.device.software
módulo para instalar software en dispositivos Junos, puede descargar el paquete de software en el nodo de control de Ansible y el módulo, de forma predeterminada, copia el paquete en el dispositivo de destino antes de realizar la instalación. Para entornos de chasis virtual mixtos, los paquetes de software deben residir en el nodo de control de Ansible. En el caso de dispositivos independientes o entornos de chasis virtual no mixtos, también puede indicar al módulo que instale una imagen de software que ya resida en el dispositivo Junos de destino o que resida en una URL accesible desde el dispositivo de destino.
En la tabla 2 se describen los argumentos del módulo que debe establecer en función de la ubicación del paquete de software. El módulo siempre debe incluir el , pkg_set
o remote_package
el local_package
argumento. El no_copy
argumento predeterminado es false
, que indica al módulo que copie el paquete de software desde la ubicación especificada en el nodo de control de Ansible al dispositivo de destino.
Ubicación del paquete de software |
|
|
|
---|---|---|---|
Nodo de control de Ansible |
Omitir o establecer en |
Para dispositivos independientes o entornos de chasis virtual no mixtos: Establezca |
(Opcional) Ruta del archivo en el dispositivo de destino en el que se copia el paquete de software. El directorio predeterminado es /var/tmp. Si |
Para entornos de chasis virtual mixtos: Se establece |
– |
||
Ubicación remota |
– |
– |
URL desde la perspectiva del dispositivo Junos de destino desde el que está instalado el paquete de software. |
Dispositivo de destino |
Establecer en |
– |
Ruta del archivo en el dispositivo de destino donde ya debe residir el paquete de software. El directorio predeterminado es /var/tmp. |
Si el paquete de software reside en el nodo de control de Ansible, incluya el argumento adecuado para su instalación:
-
local_package
: instale el software en un dispositivo Junos independiente o en miembros en un Virtual Chassis no mixto. El valor del argumento es una sola cadena que especifica la ruta absoluta o relativa a la imagen de software. -
pkg_set
: Instalar software en los miembros en un Virtual Chassis mixto. El valor del argumento es una lista de cadenas que especifican las rutas de archivo absolutas o relativas de las imágenes de software, sin ningún orden en particular, para los distintos miembros de Virtual Chassis.
Por ejemplo:
pkg_set: - 'software/jinstall-qfx-5-13.2X51-D35.3-domestic-signed.tgz' - 'software/jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz'
De forma predeterminada, cuando se incluye el local_package
argumento o pkg_set
, el módulo copia los paquetes de software del nodo de control de Ansible al directorio /var/tmp del dispositivo Junos de destino (dispositivo individual o dispositivo principal de Virtual Chassis). Si desea copiar la local_package
imagen en un directorio diferente, defina el remote_package
argumento y especifique el directorio de destino. Si el remote_package
argumento incluye un nombre de archivo, los nombres de archivo de los local_package
argumentos y remote_package
deben ser idénticos o el módulo genera un error.
Si el paquete de software ya reside en el dispositivo Junos de destino (dispositivo individual o dispositivo principal de Virtual Chassis), el módulo debe incluir el no_copy: true
argumento y el remote_package
argumento, que especifica la ruta del archivo a un paquete de software existente en el dispositivo de destino. Si remote_package
no especifica un directorio, el valor predeterminado es /var/tmp.
Si el paquete de software reside en una ubicación distinta del nodo de control de Ansible o del dispositivo de destino, el módulo debe incluir el remote_package
argumento y especificar la ubicación del paquete de software. El valor de remote_package
es una URL desde la perspectiva del dispositivo Junos de destino. Para obtener información acerca de los formatos de URL aceptables, consulte Formato para especificar nombres de archivo y URL en los comandos de la CLI de Junos OS.
Descripción general del proceso de instalación
Para usar Ansible para instalar un paquete de software en un dispositivo Junos, ejecute el software
módulo y proporcione los argumentos necesarios. Por ejemplo:
--- - 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
Cuando se ejecuta el software
módulo, éste realiza las siguientes operaciones:
Una vez que el paquete de software está en el dispositivo de destino, ya sea descargado allí inicialmente o copiado por el módulo, el módulo realiza las siguientes operaciones:
Valida la configuración con respecto al nuevo paquete cuando el
validate
argumento se establece entrue
.Nota:De forma predeterminada, el
software
módulo no valida el paquete o paquete de software con la configuración existente como requisito previo para agregar el paquete de software. Para asegurarse de que la configuración activa funcionará con la nueva imagen de software, establezca elvalidate
argumento entrue
.Instala el paquete en cada motor de enrutamiento individual, a menos que
all_re
esté establecido enfalse
.Reinicia cada motor de enrutamiento actualizado, a menos que el
reboot
argumento se establezca enfalse
.
El software
módulo permite registrar el progreso de la instalación mediante la inclusión del argumento del logfile
módulo. De forma predeterminada, solo se registran los mensajes de nivel de gravedad WARNING o superior. Para registrar mensajes de nivel de gravedad INFO o superior, que es necesario para registrar mensajes para el proceso de instalación general, ejecute el manual con la -v
opción de línea de comandos o --verbose
.
Cómo especificar valores de tiempo de espera
El juniper.device.software
módulo realiza operaciones a través de una sesión de NETCONF. El tiempo predeterminado para que se agote el tiempo de espera de una RPC de NETCONF es de 30 segundos. Durante el proceso de instalación, algunas operaciones aumentan el intervalo de tiempo de espera de RPC de la siguiente manera:
-
Copiar e instalar el paquete en el dispositivo: 1800 segundos (30 minutos)
-
Cálculo de la suma de comprobación: 300 segundos (5 minutos)
-
Realizar una limpieza de almacenamiento: 300 segundos (5 minutos)
En algunos casos, el proceso de instalación, el cálculo de la suma de comprobación o la limpieza del almacenamiento pueden superar estos intervalos de tiempo. Puede cambiar el valor de tiempo de espera para estas operaciones estableciendo los install_timeout
argumentos , checksum_timeout
y cleanfs_timeout
en el número de segundos requerido en la lista de argumentos del módulo. Por ejemplo:
- 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
Cómo especificar opciones de instalación que no tienen un argumento de módulo equivalente
Cuando se utiliza el juniper.device.software
módulo para instalar software en un dispositivo, el módulo invoca la RPC adecuada para los argumentos de instalación incluidos. Por ejemplo, el módulo invoca la <request-package-add>
RPC para instalaciones estándar de Junos OS, la <request-vmhost-package-add>
RPC para actualizaciones de host de máquina virtual, la <request-package-in-service-upgrade>
RPC para escenarios ISSU unificados, etc.
El módulo admite argumentos explícitos para muchas de las opciones de instalación, por ejemplo, la validate
opción. El módulo también admite el kwargs
argumento, lo que permite incluir cualquier opción adicional admitida por RPC pero que no tenga un argumento de módulo equivalente. El kwargs
argumento toma un diccionario de pares clave/valor de opciones adicionales admitidas.
Para obtener la lista actual de opciones admitidas por el módulo, consulte la documentación de referencia de API para el módulo. Para obtener una lista de todas las opciones disponibles para un RPC específico, consulte la documentación del comando equivalente o busque la etiqueta de solicitud del RPC en el Explorador de API XML de Junos.
Solo debe incluir opciones de instalación compatibles con el dispositivo Junos de destino para el RPC dado.
En el siguiente manual, el software
módulo instala una nueva imagen de software en los hosts de destino. El módulo incluye el kwargs
argumento con unlink: true
. Este argumento, que quita el paquete de software del directorio después de una actualización correcta, equivale a incluir la <unlink/>
opción en el <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
Cómo realizar una actualización de host de máquina virtual
En los dispositivos que tienen motores de enrutamiento compatibles con host de máquina virtual, Junos OS se ejecuta como una máquina virtual (VM) a través de un host basado en Linux (host VM). Una actualización de host de máquina virtual requiere un paquete de instalación de host de máquina virtual (junos-vmhost-install-x.tgz) y actualiza el sistema operativo del host y Junos OS compatible. En la CLI, la actualización se realiza mediante el comando de request vmhost software add
modo operativo, que corresponde al <request-vmhost-package-add>
RPC.
El juniper.device.software
módulo admite el argumento para realizar una actualización de vmhost: true
host de máquina virtual. Cuando el argumento está presente, el módulo realiza la instalación utilizando el <request-vmhost-package-add>
RPC.
El siguiente manual actualiza y reinicia Junos OS y el sistema operativo host en los dispositivos especificados:
--- - 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
Cómo realizar una ISSU o NSSU unificada
El juniper.device.software
módulo admite la realización de una actualización de software unificada en servicio (ISSU unificada) o una actualización de software sin interrupciones (NSSU) en dispositivos que admiten la función y cumplen con los requisitos necesarios. Para obtener más información acerca de las funciones unificadas de ISSU y NSSU, consulte la documentación del software del producto.
La función ISSU unificada le permite actualizar entre dos versiones diferentes de Junos OS sin interrupciones en el plano de control y con una interrupción mínima del tráfico. Para llevar a cabo una actualización de software unificada en servicio, el software
módulo debe incluir el issu: true
argumento. Por ejemplo:
--- - 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 función NSSU le permite actualizar el software Junos OS que se ejecuta en un conmutador o en un chasis virtual con motores de enrutamiento redundantes con una interrupción mínima del tráfico de red. Para realizar una actualización de software sin interrupciones, el software
módulo debe incluir el nssu: true
argumento. Por ejemplo:
--- - 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
Cómo instalar software en un miembro de chasis virtual de la serie EX
Generalmente, cuando se actualiza un Virtual Chassis no mixto de la serie EX, se sigue el proceso de instalación descrito en Descripción general del proceso de instalación para actualizar todo el Virtual Chassis. Sin embargo, puede haber ocasiones en las que necesite instalar software en conmutadores miembro específicos del chasis virtual. A partir de la versión 1.0.3 de la juniper.device
colección, puede instalar un paquete de software en conmutadores miembro individuales en un chasis virtual no mixto de la serie EX.
Para instalar software en miembros específicos, incluya el member_id
argumento y defina una lista de cadenas que especifiquen los ID de miembro. El sistema instala el paquete de software desde el dispositivo principal Virtual Chassis en los miembros especificados.
El siguiente manual de estrategias de Ansible actualiza el software del miembro 0 y del miembro 1 del chasis virtual de la serie EX:
--- - 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"
Ejemplo: Usar Ansible para instalar software
En este ejemplo se utiliza el módulo para instalar una imagen de juniper.device.software
software en un dispositivo Junos.
Requisitos
En este ejemplo se utilizan los siguientes componentes de hardware y software:
-
Servidor de administración de configuración que ejecuta Ansible 2.18 o posterior con la
juniper.device
colección instalada -
Dispositivo Junos con NETCONF habilitado y una cuenta de usuario configurada con los permisos adecuados
-
Par de claves pública y privada SSH configurado para el usuario adecuado en el nodo de control de Ansible y en el dispositivo Junos
-
Archivo de inventario de Ansible existente con los hosts necesarios definidos
Visión general
En este ejemplo se presenta un manual de Ansible que utiliza el juniper.device.software
módulo para actualizar Junos OS en los hosts del grupo de inventario especificado. En este ejemplo, la imagen del software reside en el nodo de control de Ansible y el módulo copia la imagen en el dispositivo de destino antes de instalarlo. El módulo no define explícitamente un host
argumento, por lo que el módulo opera en el host predeterminado, que es {{ inventory_hostname }}
.
Este manual incluye la Check NETCONF connectivity
tarea, que utiliza el ansible.builtin.wait_for
módulo para intentar establecer una sesión NETCONF con el dispositivo Junos utilizando el puerto NETCONF predeterminado 830. Si el nodo de control no puede establecer una sesión de NETCONF con un dispositivo durante la ejecución del manual, omite las tareas restantes en la reproducción para ese dispositivo.
La Install Junos OS package
tarea ejecuta el software
módulo siempre que la comprobación de NETCONF se haya realizado correctamente. El version
argumento define la versión de Junos OS deseada tal como la informaría el show version
comando en el dispositivo Junos. Durante la ejecución del manual, el módulo primero comprueba que la versión solicitada no esté ya instalada en el dispositivo. Si la versión solicitada es diferente de la versión instalada actualmente, el módulo instala la versión solicitada.
El local_package
argumento define la ruta del paquete de software de Junos OS en el nodo de control de Ansible. Durante la instalación, el módulo realiza una operación de limpieza de almacenamiento en el dispositivo de destino, copia la imagen de software en el directorio /var/tmp del dispositivo, verifica la suma de comprobación del archivo, valida el nuevo software con respecto a la configuración activa y, a continuación, instala el software en cada motor de enrutamiento en el host de destino. De forma predeterminada, el software
módulo reinicia cada motor de enrutamiento una vez completada la instalación; sin embargo, esta tarea se establece reboot: true
explícitamente para mayor claridad.
La tarea almacena el resultado del módulo en la response
variable y notifica a un controlador. Si el usuario no ejecuta el manual mediante el modo de verificación, el wait_reboot
controlador intenta establecer una sesión con el dispositivo para comprobar que el dispositivo está de nuevo en línea. La wait_time
variable define el período de tiempo que el nodo de control intenta volver a conectarse con el dispositivo.
En este ejemplo se incluye el logfile
parámetro para registrar el progreso de la instalación. Esto es importante para fines de depuración en caso de que la instalación falle, así como para registrar las fechas y horas de las instalaciones en los dispositivos. El usuario que ejecuta el manual debe tener permisos para escribir en el archivo de registro especificado. De forma predeterminada, solo se registran los mensajes de nivel de gravedad WARNING o superior. En este ejemplo, el playbook se ejecuta con la -v
opción de registrar mensajes de nivel de gravedad INFO o superior para supervisar la instalación.
Configuración
Creación del manual de estrategias de Ansible
Para crear un manual que utilice el módulo para instalar una imagen de juniper.device.software
software en un dispositivo Junos:
-
Incluya la plantilla para el libro de jugadas y esta obra, que ejecuta los módulos localmente.
--- - name: Install Junos OS hosts: mx1 connection: local gather_facts: no
-
Defina o importe las variables necesarias, que para este ejemplo incluyen la versión deseada de Junos OS y la ruta a la nueva imagen, entre otros.
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
-
(Opcional) Cree una tarea para comprobar la conectividad de NETCONF.
tasks: - name: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: 5
-
Cree la tarea para instalar el paquete de Junos OS en el dispositivo y notifique al controlador.
- 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
-
(Opcional) Cree una tarea para imprimir la respuesta del módulo.
- name: Print response ansible.builtin.debug: var: response
-
Cree el controlador que compruebe que el dispositivo vuelve a estar en línea después de reiniciar.
El nombre del controlador debe ser el mismo al que se hace referencia en la tarea de instalación.
handlers: - name: wait_reboot ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: "{{ wait_time }}" when: not response.check_mode
Resultados
En el nodo de control Ansible, revise el manual completado. Si el manual no muestra el código deseado, repita las instrucciones de este ejemplo para corregir el manual.
--- - 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
Ejecute el libro de estrategias
Para ejecutar el manual:
-
Ejecute el
ansible-playbook
comando en el nodo de control y proporcione la ruta del manual y las opciones deseadas.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
Verificación
Verificar la instalación
Propósito
Compruebe que la instalación del software se ha realizado correctamente.
Acción
La salida del manual de estrategias debe indicar cualquier tarea fallida. Sin embargo, también puede revisar el contenido del archivo de registro definido en el manual para obtener detalles sobre la instalación. Aquí se muestra la salida del archivo de registro de muestra. Algunos resultados se han omitido por brevedad.
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'
Significado
El contenido del archivo de registro indica que la imagen se copió e instaló correctamente en ambos motores de enrutamiento del dispositivo de destino.