Usar o juniper.device.software módulo Ansible para instalar software em dispositivos Junos
Você pode usar o módulo Ansible para instalar software em dispositivos que executam o Junos OS ou dispositivos que executam o juniper.device.software Junos OS Evolved.
Use o Ansible para instalar software
A Juniper Networks oferece módulos Ansible que permitem instalar uma imagem de software em dispositivos Junos. A Tabela 1 descreve os módulos. Se você já estiver usando um determinado conjunto de módulos da juniper.device coleção, use o módulo para esse conjunto.
|
Coleção de Emoji |
Conjunto de módulos |
Nome do módulo |
|---|---|---|
|
|
||
|
|
As seções a seguir discutem como usar o juniper.device.software módulo para instalar um pacote de software em um dispositivo Junos. As seções descrevem como especificar o local da imagem de software e o processo e as opções gerais de instalação do software. As seções também discutem como executar cenários de atualização mais especializados, como uma atualização de host de VM, uma atualização unificada de software em serviço (ISSU unificado) ou uma atualização de software ininterrupta (NSSU) em dispositivos que oferecem suporte a esses recursos.
Como especificar o local da imagem de software
Ao usar o módulo para instalar software juniper.device.software em dispositivos Junos, você pode baixar o pacote de software para o nó de controle do Ansible. O módulo, por padrão, copia o pacote para o dispositivo de destino antes de executar a instalação. Para ambientes Virtual Chassis mistos, os pacotes de software devem residir no nó de controle do Ansible. Para dispositivos autônomos ou ambientes de Virtual Chassis não mistos, você também pode instruir o módulo a instalar uma imagem de software que já resida no dispositivo Junos de destino ou resida em uma URL que possa ser acessada a partir do dispositivo de destino.
A Tabela 2 descreve os argumentos do módulo que você deve definir dependendo do local do pacote de software. O módulo deve sempre incluir o local_packageargumento , pkg_set, ou remote_package . O no_copy argumento é padronizado para false, que instrui o módulo a copiar o pacote de software do local especificado no nó de controle do Ansible para o dispositivo de destino.
|
Localização do pacote de software |
|
|
|
|---|---|---|---|
|
Nó de controle do Ansible |
Omitir ou definir como |
Para dispositivos autônomos ou ambientes de Virtual Chassis não mistos: Defina |
(Opcional) Caminho do arquivo no dispositivo de destino para o qual o pacote de software é copiado. O diretório padrão é /var/tmp. Se |
|
Para ambientes Virtual Chassis mistos: Defina |
– |
||
|
Localização remota |
– |
– |
URL da perspectiva do dispositivo Junos de destino a partir do qual o pacote de software está instalado. |
|
Dispositivo de destino |
Defina como |
– |
Caminho do arquivo no dispositivo de destino 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 do Ansible, inclua o argumento apropriado para sua instalação:
-
local_package— Instale o software em um dispositivo Junos autônomo ou em membros em um Virtual Chassis não misto. O valor do argumento é uma única cadeia de caracteres que especifica o caminho absoluto ou relativo para a imagem de software. -
pkg_set— Instale o 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 local_package argumento or pkg_set , o módulo copia todos os pacotes de software do nó de controle do Ansible para o diretório /var/tmp no dispositivo Junos de destino (dispositivo individual ou dispositivo principal do 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 de destino. Se o remote_package argumento incluir um nome de arquivo, os local_package nomes de arquivo dos argumentos e remote_package deverão ser idênticos ou o módulo gerará um erro.
Se o pacote de software já reside no dispositivo Junos de destino (dispositivo individual ou dispositivo principal do Virtual Chassis), o módulo deve incluir o no_copy: true argumento e o remote_package argumento. O remote_package argumento especifica o caminho do arquivo para um pacote de software existente no dispositivo de destino. Se remote_package não especificar um diretório, o padrão será /var/tmp.
Se o pacote de software residir em um local diferente do nó de controle do Ansible ou do dispositivo de destino, o módulo deverá incluir o remote_package argumento e especificar o local do pacote de software. O valor de remote_package é um URL da perspectiva do dispositivo Junos de destino. Para obter informações sobre formatos de URL aceitáveis, consulte Formato para especificar nomes de arquivos e URLs em 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 juniper.device.software módulo e fornecer os 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 juniper.device.software módulo, ele executa as seguintes operações:
Uma vez que o pacote de software está no dispositivo de destino, seja baixado inicialmente ou copiado pelo módulo, o módulo executa as seguintes operações:
-
Valida a configuração em relação ao novo pacote, a menos que o
validateargumento seja definido comofalse.Observação: A partir dajuniper.deviceversão 2.0.4, ovalidateparâmetro padrão étrue. Em versões anteriores, o padrão éfalse. -
Instala o pacote em cada Mecanismo de Roteamento individual, a menos que
all_reesteja definido comofalse. -
Reinicializa cada Mecanismo de Roteamento atualizado, a menos que o
rebootargumento seja definido comofalse.
O software módulo permite que você registre o progresso da instalação incluindo o argumento do logfile módulo. Por padrão, somente as mensagens de nível de gravidade WARNING ou superior são registradas. Para registrar mensagens de nível de gravidade INFO ou superior, que é necessário para registrar mensagens para o processo de instalação geral, execute o guia estratégico com a -v opção de linha de comando ou --verbose .
Como especificar valores de tempo limite
O juniper.device.software módulo executa operações em uma sessão NETCONF. O tempo padrão para um RPC NETCONF atingir o tempo limite é de 30 segundos. Durante o processo de instalação, determinadas operações aumentam o intervalo de tempo limite do RPC da seguinte maneira:
-
Copiar e instalar o pacote no dispositivo — 1800 segundos (30 minutos)
-
Cálculo da soma de verificação — 300 segundos (5 minutos)
-
Executando uma limpeza de armazenamento — 300 segundos (5 minutos)
Em alguns casos, o processo de instalação, o cálculo da soma de verificação ou a limpeza do armazenamento podem exceder esses intervalos de tempo. Você pode alterar o valor de tempo limite para essas operações definindo os install_timeoutargumentos , checksum_timeoute cleanfs_timeout como 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 têm um argumento de módulo equivalente
Quando você usa o módulo para instalar software juniper.device.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 de VM, o <request-package-in-service-upgrade> RPC para cenários de ISSU unificado e assim por diante.
O módulo suporta argumentos explícitos para muitas das opções de instalação, por exemplo, a validate opção. O módulo também suporta o kwargs argumento. O argumento permite que você inclua quaisquer opções adicionais compatíveis com o RPC. O kwargs argumento usa um dicionário de pares de chave/valor de opções adicionais com suporte.
Para obter a lista atual de opções compatíveis com o 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 do 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 o dispositivo Junos de destino suporta para o RPC fornecido.
No manual a seguir, o software módulo instala uma nova imagem de software nos hosts de destino. 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, é equivalente a incluir a <unlink/> <request-package-add> opção no 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 executar uma atualização de host de VM
Em dispositivos que têm mecanismos de roteamento com suporte a host de VM, o Junos OS é executado como uma máquina virtual (VM) em um host baseado em Linux (host de VM). Uma atualização do host da VM requer um pacote de instalação do host da VM (junos-vmhost-install-x.tgz) e atualiza o sistema operacional do host e o Junos OS compatível. Na CLI, você executa o upgrade usando o request vmhost software add comando de modo operacional, que corresponde ao <request-vmhost-package-add> RPC.
O juniper.device.software módulo dá suporte vmhost: true ao argumento para executar uma atualização de host de VM. Quando o argumento está presente, o módulo executa a instalação usando o <request-vmhost-package-add> RPC.
O seguinte playbook atualiza e reinicializa o Junos OS e o host OS 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 executar um ISSU ou NSSU unificado
O juniper.device.software módulo suporta a execução de um ISSU unificado ou um NSSU em dispositivos que suportam o recurso e atendem aos requisitos necessários. Para obter mais informações sobre os recursos unificados ISSU e NSSU, consulte a documentação de software do seu produto.
O recurso ISSU unificado permite que você atualize entre duas versões diferentes do Junos OS sem interrupção no plano de controle e com o mínimo de interrupção do tráfego. Para executar um ISSU unificado, 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 que você atualize 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 de rede. Para executar um NSSU, 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 o software em um membro do Virtual Chassis da Série EX
Geralmente, quando você atualiza um Virtual Chassis da Série EX não misto, você segue 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ê precise instalar software em switches de membros específicos no Virtual Chassis. O juniper.device.software módulo permite que você instale um pacote de software em switches de membros individuais em um Virtual Chassis da Série EX não misto.
Para instalar software em membros específicos, inclua o member_id argumento e defina uma lista de cadeias de caracteres que especificam as IDs de membro. O sistema instala o pacote de software do dispositivo principal do Virtual Chassis nos membros especificados.
O seguinte playbook do Ansible atualiza o software no membro 0 e no 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: usar o Ansible para instalar software
Este exemplo usa o módulo para instalar uma imagem de software em um dispositivo que executa o juniper.device.software Junos OS.
Requerimentos
Este exemplo usa os seguintes componentes de hardware e software:
-
Servidor de gerenciamento de configuração executando o Ansible 2.17 ou posterior com a
juniper.devicecoleção instalada -
Dispositivo Junos com NETCONF habilitado e uma conta de usuário configurada com as permissões apropriadas
-
Par de chaves SSH público/privado configurado para o usuário apropriado no nó de controle do Ansible e no dispositivo Junos
-
Arquivo de inventário existente do Ansible com hosts necessários definidos
Visão geral
Este exemplo apresenta um playbook do Ansible que usa o módulo para atualizar o juniper.device.software Junos OS nos hosts no grupo de inventário especificado. Neste exemplo, a imagem de software reside no nó de controle do Ansible e o módulo copia a imagem para o dispositivo de destino antes de instalá-la. O módulo não define explicitamente um host argumento, portanto, o módulo opera no host padrão, que é {{ inventory_hostname }}.
Este playbook inclui a Check NETCONF connectivity tarefa, que utiliza 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 conseguir estabelecer uma sessão NETCONF com um dispositivo durante a execução do manual, ele ignorará as tarefas restantes na reprodução para esse dispositivo.
A Install Junos OS package tarefa executa o juniper.device.software módulo desde que a verificação NETCONF tenha sido bem-sucedida. O version argumento define a versão desejada do Junos OS como seria relatada show version pelo comando no dispositivo Junos. Durante a execução do playbook, o módulo primeiro verifica se a versão solicitada ainda não está instalada no dispositivo. Se a versão solicitada for diferente da versão atualmente instalada, o módulo instala a versão solicitada.
O local_package argumento define o caminho do pacote de software do Junos OS no nó de controle do Ansible. Durante a instalação, o módulo:
-
Executa uma operação de limpeza de armazenamento no dispositivo de destino
-
Copia a imagem do software para o diretório /var/tmp no dispositivo
-
Verifica a soma de verificação do arquivo
-
Valida o novo software em relação à configuração ativa
-
Instala o software em cada Mecanismo de Roteamento no host de destino
Por padrão, o juniper.device.software módulo reinicializa cada Mecanismo de Roteamento após a conclusão da instalação; no entanto, essa tarefa é reboot: true definida explicitamente para maior clareza.
A tarefa armazena o resultado do response módulo na variável e notifica um manipulador. Se você não executar o guia estratégico usando o modo de verificação, o wait_reboot manipulador tentará estabelecer uma sessão com o dispositivo para verificar se o dispositivo está online novamente. A wait_time variável define o período de tempo que o nó de controle tenta se reconectar ao dispositivo.
Este exemplo inclui o logfile parâmetro para registrar o progresso da instalação. Esse log é importante para fins de depuração caso a instalação falhe, bem como para registrar as datas e horas das instalações nos dispositivos. O usuário que executa o guia estratégico deve ter permissões para gravar no arquivo de log especificado. Por padrão, somente as mensagens de nível de gravidade WARNING ou superior são registradas. O exemplo executa o guia estratégico com a -v opção de registrar mensagens de nível de gravidade INFO ou superior para monitorar a instalação.
Configuração
Criando o playbook do Ansible
Para criar um playbook que usa o juniper.device.software módulo para instalar uma imagem de software em um dispositivo Junos:
-
Inclua o clichê do manual e desta jogada, que executa os módulos localmente.
--- - name: Install Junos OS hosts: mx1 connection: local gather_facts: no
-
Defina ou importe quaisquer variáveis necessárias, que para este exemplo, incluem a versão desejada do Junos OS e o caminho para a nova imagem, entre outras.
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 para instalar o pacote do 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 imprimir a resposta do módulo.
- name: Print response ansible.builtin.debug: var: response -
Crie o manipulador que verifica se o dispositivo volta a ficar online após a reinicialização.
O nome do manipulador deve ser o mesmo referenciado 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 do Ansible, examine o manual concluído. Se o guia estratégico 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 manual
Para executar o manual:
-
Emita o
ansible-playbookcomando no nó de controle e forneça o caminho do guia estratégico e todas as opções necessárias.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
Finalidade
Verifique se a instalação do software foi bem-sucedida.
Ação
A saída do guia estratégico deve indicar todas as tarefas com falha. No entanto, você também pode revisar o conteúdo do arquivo de log definido no guia estratégico para obter detalhes sobre a instalação. A saída do arquivo de log de exemplo é mostrada aqui. Algumas saídas foram omitidas por questões de 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 o playbook copiou e instalou com êxito a imagem em ambos os mecanismos de roteamento no dispositivo de destino.
Tabela de histórico de alterações
A compatibilidade com recursos é determinada pela plataforma e versão utilizada. Use o Explorador de recursos para determinar se um recurso é compatível com sua plataforma.
juniper.device versão 2.0.4, o validate parâmetro padrão é true. Em versões anteriores, o padrão é false.