Use o Ansible para instalar software em dispositivos Junos
RESUMO Use os módulos Ansible da Juniper Networks para instalar software em dispositivos Junos.
Use o Ansible para instalar software
A Juniper Networks oferece um módulo Ansible que permite instalar ou atualizar a imagem de software em um dispositivo Junos. A Tabela 1 descreve o módulo.
| Conjunto de conteúdo |
Nome do módulo |
|---|---|
|
|
As seções a seguir discutem como especificar a localização da imagem do software e o processo geral de instalação de software e opções ao usar o módulo Ansible para instalar pacotes de software em dispositivos Junos. Eles também discutem como realizar cenários de atualização mais especializados, como uma atualização de host VM, uma atualização unificada de software em serviço (ISSU unificada) ou uma atualização de software ininterrupta (NSSU) em dispositivos que oferecem suporte a esses recursos.
Como especificar a localização da imagem do software
Quando você usa o juniper.device.software módulo para instalar software em dispositivos Junos, você pode baixar o pacote de software para o nó de controle Ansible, e o módulo, por padrão, copia o pacote para o dispositivo-alvo antes de realizar a instalação. Para ambientes virtual chassis mistos, os pacotes de software devem residir no nó de controle Ansible. Para dispositivos autônomos ou ambientes não mistos do Virtual Chassis, você também pode instruir o módulo a instalar uma imagem de software que já reside no dispositivo Junos alvo ou reside em uma URL que é acessível a partir do dispositivo alvo.
A Tabela 2 descreve os argumentos do módulo que você deve definir dependendo da localização do pacote de software. O módulo deve sempre incluir o, pkg_setou remote_package o local_packageargumento. O no_copy argumento é padrão parafalse, o que instrui o módulo a copiar o pacote de software a partir do local especificado no nó de controle Ansible para o dispositivo alvo.
| Localização de pacotes de software |
|
|
|
|---|---|---|---|
| Nó de controle ansível |
Omitir ou definir |
Para dispositivos autônomos ou ambientes não mistos do Virtual Chassis: Configure |
(Opcional) Caminho de arquivo no dispositivo-alvo ao qual o pacote de software é copiado. O diretório padrão é /var/tmp. Se |
| Para ambientes de Virtual Chassis mistos: Configure |
– |
||
| Localização remota |
– |
– |
URL da perspectiva do dispositivo Junos alvo do qual o pacote de software é instalado. |
| Dispositivo-alvo |
Definir para |
– |
Caminho de arquivo no dispositivo alvo onde o pacote de software já deve residir. O diretório padrão é /var/tmp. |
Se o pacote de software residir no nó de controle Ansible, inclua o argumento apropriado para sua instalação:
-
local_package— Instale software em um dispositivo Junos autônomo ou em membros em um Virtual Chassis não misto. O valor do argumento é uma única string que especifica o caminho absoluto ou relativo para a imagem do software. -
pkg_set— Instale software nos membros em um Virtual Chassis misto. O valor do argumento é uma lista de strings que especificam os caminhos de arquivo absolutos ou relativos das imagens de software, em nenhuma ordem específica, para os vários membros do Virtual Chassis.
Por exemplo:
pkg_set: - 'software/jinstall-qfx-5-13.2X51-D35.3-domestic-signed.tgz' - 'software/jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz'
Por padrão, quando você inclui o ou pkg_set o local_package argumento, o módulo copia quaisquer pacotes de software desde o nó de controle Ansible até o diretório /var/tmp no dispositivo Junos alvo (dispositivo individual ou dispositivo principal Virtual Chassis). Se você quiser copiar a local_package imagem para um diretório diferente, defina o remote_package argumento e especifique o diretório alvo. Se o remote_package argumento incluir um nome de arquivo, os nomes de arquivo e remote_package os local_package argumentos devem ser idênticos, ou o módulo gera um erro.
Se o pacote de software já estiver no dispositivo Junos alvo (dispositivo individual ou dispositivo primário Virtual Chassis), o módulo deve incluir o no_copy: true argumento também o remote_package argumento, que especifica o caminho do arquivo para um pacote de software existente no dispositivo alvo. Se remote_package não especificar um diretório, o padrão é /var/tmp.
Se o pacote de software residir em um local diferente do nó de controle ou dispositivo alvo do Ansible, o módulo deve incluir o remote_package argumento e especificar a localização do pacote de software. O valor é remote_package uma URL da perspectiva do dispositivo Junos alvo. Para obter informações sobre formatos de URL aceitáveis, consulte Formato para especificar nomes de arquivos e URLs nos comandos CLI do Junos OS.
Visão geral do processo de instalação
Usar o Ansible para instalar um pacote de software em um dispositivo Junos, executar o software módulo e fornecer quaisquer argumentos necessários. Por exemplo:
---
- 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
Quando você executa o software módulo, ele executa as seguintes operações:
Uma vez que o pacote de software esteja no dispositivo-alvo, seja baixado inicialmente ou copiado pelo módulo, o módulo então executa as seguintes operações:
Valida a configuração em relação ao novo pacote quando o
validateargumento é definido paratrue.Nota:Por padrão, o
softwaremódulo não valida o pacote ou o pacote de software em relação à configuração existente como um pré-requisito para adicionar o pacote de software. Para garantir que a configuração ativa funcionará com a nova imagem de software, defina ovalidateargumento paratrue.Instala o pacote em cada mecanismo de roteamento individual, a menos que
all_reesteja definido parafalse.Reinicializa cada mecanismo de roteamento atualizado, a menos que o
rebootargumento esteja definido parafalse.
O software módulo permite que você registre o progresso da instalação incluindo o argumento do logfile módulo. Por padrão, apenas mensagens de aviso de nível de gravidade ou superior são registradas. Para registrar mensagens de informações de nível de gravidade ou superior, o que é necessário para registrar mensagens para o processo geral de instalação, executar o manual com a opção -v de linha de comando ou --verbose .
Como especificar valores de tempo limite
O juniper.device.software módulo realiza operações em uma sessão netconf. O tempo padrão de um RPC NETCONF para o tempo de saída é de 30 segundos. Durante o processo de instalação, determinadas operações aumentam o intervalo de tempo limite do RPC da seguinte forma:
-
Copiar e instalar o pacote no dispositivo — 1800 segundos (30 minutos)
-
Computação do checksum — 300 segundos (5 minutos)
-
Realizando uma limpeza de armazenamento — 300 segundos (5 minutos)
Em alguns casos, o processo de instalação, cálculo de checksum ou limpeza de armazenamento podem exceder esses intervalos de tempo. Você pode alterar o valor de tempo limite para essas operações configurando o install_timeout, checksum_timeoute cleanfs_timeout os argumentos para o número necessário de segundos na lista de argumentos do módulo. Por exemplo:
- 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
Como especificar opções de instalação que não tenham um argumento de módulo equivalente
Quando você usa o juniper.device.software módulo para instalar software em um dispositivo, o módulo invoca o RPC apropriado para os argumentos de instalação incluídos. Por exemplo, o módulo invoca o <request-package-add> RPC para instalações padrão do Junos OS, o <request-vmhost-package-add> RPC para atualizações de host VM, o <request-package-in-service-upgrade> RPC para cenários ISSU unificados e assim por diante.
O módulo oferece suporte a argumentos explícitos para muitas das opções de instalação, por exemplo, a opção validate . O módulo também oferece suporte ao kwargs argumento, que permite incluir quaisquer opções adicionais que sejam suportadas pelo RPC, mas que não tenham um argumento de módulo equivalente. O kwargs argumento requer um princípio de pares chave/valor de opções adicionais suportadas.
Para obter a lista atual de opções suportadas pelo módulo, consulte a documentação de referência da API para o módulo. Para obter uma lista de todas as opções disponíveis para um RPC específico, consulte a documentação para o comando equivalente ou pesquise a tag de solicitação do RPC no Junos XML API Explorer.
Você só deve incluir opções de instalação que são suportadas no dispositivo Junos alvo para o RPC determinado.
No manual a seguir, o software módulo instala uma nova imagem de software nos hosts-alvo. O módulo inclui o kwargs argumento com unlink: true. Esse argumento, que remove o pacote de software do diretório após uma atualização bem-sucedida, equivale a incluir a opção <unlink/> no <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
Como realizar um upgrade de host VM
Em dispositivos que têm mecanismos de roteamento com suporte de host VM, o Junos OS funciona como uma máquina virtual (VM) em um host baseado em Linux (host VM). Uma atualização do host VM requer um pacote de instalação do VM Host (junos-vmhost-install-tgzx) e atualiza o sistema operacional host e o Junos OS compatível. No CLI, você realiza a atualização usando o comando de request vmhost software add modo operacional, que corresponde ao <request-vmhost-package-add> RPC.
O juniper.device.software módulo oferece suporte ao vmhost: true argumento para realizar um upgrade de host VM. Quando o argumento está presente, o módulo realiza a instalação usando o <request-vmhost-package-add> RPC.
Os seguintes upgrades e reinicializam o Junos OS e o sistema operacional host nos 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
Como realizar um ISSU unificado ou NSSU
O juniper.device.software módulo oferece suporte à realização de uma atualização unificada de software em serviço (ISSU unificada) ou uma atualização de software ininterrupta (NSSU) em dispositivos que oferecem suporte ao recurso e atendem aos requisitos necessários. Para obter mais informações sobre os recursos unificados de ISSU e NSSU, consulte a documentação de software para o seu produto.
O recurso ISSU unificado permite que você atualize entre duas versões diferentes do Junos OS sem interrupções no plano de controle e com o mínimo de interrupção do tráfego. Para realizar uma atualização unificada de software em serviço, o software módulo deve incluir o issu: true argumento. Por exemplo:
---
- 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
O recurso NSSU permite atualizar o software Junos OS em execução em um switch ou Virtual Chassis com mecanismos de roteamento redundantes com o mínimo de interrupção no tráfego da rede. Para realizar uma atualização de software sem parar, o software módulo deve incluir o nssu: true argumento. Por exemplo:
---
- 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
Como instalar software em um membro virtual do chassi da Série EX
Geralmente, quando você atualiza um Chassi Virtual da Série EX não misto, você acompanha o processo de instalação descrito na visão geral do processo de instalação para atualizar todo o Virtual Chassis. No entanto, pode haver momentos em que você precisa instalar software em switches de membros específicos no Virtual Chassis. A partir da versão 1.0.3 da juniper.device coleção, você pode instalar um pacote de software em switches individuais de membros em um Chassi Virtual da Série EX não misto.
Para instalar software em membros específicos, inclua o member_id argumento e defina uma lista de strings que especificam os IDs dos membros. O sistema instala o pacote de software do dispositivo primário Virtual Chassis nos membros especificados.
A cartilha Ansible a seguir atualiza o software sobre o membro 0 e o membro 1 no Virtual Chassis da Série 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"
Exemplo: use o Ansible para instalar software
Este exemplo usa o juniper.device.software módulo para instalar uma imagem de software em um dispositivo Junos.
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
-
Servidor de gerenciamento de configuração executando Ansible 2.10 ou posterior com a
juniper.devicecoleção instalada -
Dispositivo Junos com NETCONF habilitado e uma conta de usuário configurada com permissões apropriadas
-
Par de chave sSH público/privado configurado para o usuário apropriado no nó de controle Ansible e dispositivo Junos
-
Arquivo de inventário Ansible existente com hosts necessários definidos
Visão geral
Este exemplo apresenta um manual ansible que usa o juniper.device.software módulo para atualizar o Junos OS nos hosts no grupo de inventário especificado. Neste exemplo, a imagem de software reside no nó de controle Ansible, e o módulo copia a imagem para o dispositivo alvo antes de instalá-la. O módulo não define explicitamente um host argumento, de modo que o módulo opera no host padrão, que é {{ inventory_hostname }}.
Este manual inclui a Check NETCONF connectivity tarefa, que usa o ansible.builtin.wait_for módulo para tentar estabelecer uma sessão NETCONF com o dispositivo Junos usando a porta NETCONF padrão 830. Se o nó de controle não estabelecer uma sessão netconf com um dispositivo durante a execução de playbook, ele ignora as tarefas restantes em jogo para esse dispositivo.
A Install Junos OS package tarefa executa o software módulo desde que a verificação da NETCONF tenha sido bem sucedida. O version argumento define a versão desejada do Junos OS, pois seria relatada pelo show version comando no dispositivo Junos. Durante a execução da cartilha, o módulo verifica primeiro se a versão solicitada ainda não está instalada no dispositivo. Se a versão solicitada for diferente da versão instalada atualmente, o módulo instala a versão solicitada.
O local_package argumento define o caminho do pacote de software Junos OS no nó de controle Ansible. Durante a instalação, o módulo realiza uma operação de limpeza de armazenamento no dispositivo alvo, copia a imagem do software para o diretório /var/tmp no dispositivo, verifica o checksum do arquivo, valida o novo software contra a configuração ativa e depois instala o software em cada mecanismo de roteamento no host alvo. Por padrão, o software módulo reinicia cada mecanismo de roteamento após a instalação ser concluída; no entanto, essa tarefa define reboot: true explicitamente para clareza.
A tarefa armazena o resultado do response módulo na variável e notifica um manipulador. Se o usuário não executar a cartilha usando o modo de verificação, o wait_reboot manipulador então tenta estabelecer uma sessão com o dispositivo para verificar se o dispositivo está novamente on-line. A wait_time variável define o tempo em que o nó de controle tenta se reconectar com o dispositivo.
Este exemplo inclui o logfile parâmetro para registrar o progresso da instalação. Isso é importante para fins de depuração caso a instalação não ocorra, bem como para registrar as datas e horários das instalações nos dispositivos. O usuário que executa o manual deve ter permissões para escrever no arquivo de log especificado. Por padrão, apenas mensagens de aviso de nível de gravidade ou superior são registradas. Neste exemplo, o manual é executado com a opção -v de registrar mensagens de informações de nível de gravidade ou superior para monitorar a instalação.
Configuração
Criação do Ansible Playbook
Para criar um manual que usa o juniper.device.software módulo para instalar uma imagem de software em um dispositivo Junos:
-
Inclua a placa de caldeira para o manual e esta peça, que executa os módulos localmente.
--- - name: Install Junos OS hosts: mx1 connection: local gather_facts: no
-
Definir ou importar quaisquer variáveis necessárias, o que, por exemplo, inclui a versão desejada do Junos OS e o caminho para a nova imagem, entre outros.
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) Crie uma tarefa para verificar a conectividade NETCONF.
tasks: - name: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: 5 -
Crie a tarefa de instalar o pacote Junos OS no dispositivo e notificar o manipulador.
- 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) Crie uma tarefa para publicar a resposta do módulo.
- name: Print response ansible.builtin.debug: var: response -
Crie o manipulador que verifica se o dispositivo volta on-line após a reinicialização.
O nome do manipulador deve ser o mesmo mencionado na tarefa de instalação.
handlers: - name: wait_reboot ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: "{{ wait_time }}" when: not response.check_mode
Resultados
No nó de controle Ansible, revise o manual completo. Se o manual não exibir o código pretendido, repita as instruções neste exemplo para corrigir o 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
Execute o playbook
Para executar o manual:
-
Emita o
ansible-playbookcomando no nó de controle e forneça o caminho de manual e quaisquer opções desejadas.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
Verificação
Verifique a instalação
Propósito
Verifique se a instalação do software foi bem sucedida.
Ação
A saída de manual deve indicar quaisquer tarefas falhadas. No entanto, você também pode revisar o conteúdo do arquivo de log definido no manual de jogadas para obter detalhes sobre a instalação. A saída de arquivo de log de amostra é mostrada aqui. Alguma saída foi omitida por brevidade.
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
O conteúdo do arquivo de log indica que a imagem foi copiada com sucesso e instalada em ambos os mecanismos de roteamento no dispositivo alvo.