Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

Tabla 1: Módulo de software

Conjunto de contenido

Nombre del módulo

juniper.device colección

software

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_seto remote_package el local_packageargumento. 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.

Tabla 2: Argumentos del módulo para la ubicación del paquete de software

Ubicación del paquete de software

no_copy Parámetro

local_package o pkg_set parámetro

remote_package Parámetro

Nodo de control de Ansible

Omitir o establecer en false

Para dispositivos independientes o entornos de chasis virtual no mixtos:

Establezca local_package en la ruta de archivo, incluido el nombre de archivo, del paquete de software en el nodo de control local. Las rutas de archivo son relativas al directorio del manual.

(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 remote_package incluye un nombre de archivo, debe coincidir con el nombre de archivo especificado en local_package.

Para entornos de chasis virtual mixtos:

Se establece pkg_set en una lista de las rutas de archivo, incluidos los nombres de archivo, de uno o más paquetes de software en el nodo de control local. Las rutas de archivo son relativas al directorio del manual.

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 true

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:

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:

Cuando se ejecuta el software módulo, éste realiza las siguientes operaciones:

  1. Compara la versión de Junos OS especificada en el version argumento, o en el nombre de archivo del paquete de software si se omite el version argumento, con la versión instalada en el dispositivo administrado. Si las versiones instaladas y deseadas son idénticas, el módulo omite los pasos y conjuntos changed de instalación restantes y failed en false.
  2. Si el paquete de software se encuentra en el nodo de control de Ansible y el no_copy parámetro se omite o se establece en false, el módulo realiza las siguientes operaciones:
    • Calcula la suma de comprobación del paquete o paquetes de software local mediante el algoritmo especificado en el checksum_algorithm argumento. Los valores aceptables checksum_algorithm son md5, sha1, y sha256. El valor predeterminado es md5. Como alternativa, puede proporcionar una suma de comprobación en el checksum argumento.

    • Realiza una limpieza de almacenamiento en el dispositivo de destino para crear espacio para el paquete de software, a menos que el cleanfs argumento esté establecido en false.

    • SCP o FTP copia cualquier paquete en el dispositivo de destino, si los archivos con los mismos nombres y sumas de comprobación aún no residen en la ubicación de destino en el dispositivo.

      Cuando el módulo incluye local_package, el paquete se copia en el remote_package directorio o, si remote_package no se especifica, en el directorio /var/tmp . Cuando el módulo incluye pkg_set, los paquetes siempre se copian en el directorio /var/tmp del dispositivo principal Virtual Chassis.

      Nota:

      Si el cleanfs argumento se omite o se establece en true, el módulo copia el paquete de software en el dispositivo, incluso si inicialmente existía en la ubicación de destino, ya que la operación de limpieza de almacenamiento quita el archivo existente. Si cleanfs: false está presente y el archivo ya reside en la ubicación de destino, el módulo omite la operación de copia de archivos.

    • Calcula la suma de comprobación de cada archivo remoto y la compara con la suma de comprobación del archivo local.

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:

  1. Valida la configuración con respecto al nuevo paquete cuando el validate argumento se establece en true.

    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 el validate argumento en true.

  2. Instala el paquete en cada motor de enrutamiento individual, a menos que all_re esté establecido en false.

  3. Reinicia cada motor de enrutamiento actualizado, a menos que el reboot argumento se establezca en false.

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_timeoutargumentos , checksum_timeouty cleanfs_timeout en el número de segundos requerido en la lista de argumentos del módulo. Por ejemplo:

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.

Nota:

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.

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:

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:

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:

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:

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:

  1. Incluya la plantilla para el libro de jugadas y esta obra, que ejecuta los módulos localmente.

  2. 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.

  3. (Opcional) Cree una tarea para comprobar la conectividad de NETCONF.

  4. Cree la tarea para instalar el paquete de Junos OS en el dispositivo y notifique al controlador.

  5. (Opcional) Cree una tarea para imprimir la respuesta del módulo.

  6. 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.

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.

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.

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.

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.