Utiliser Junos PyEZ pour installer des logiciels sur des équipements Junos

Lorsque vous utilisez Junos PyEZ pour installer des logiciels sur des équipements Junos, vous pouvez télécharger l’image logicielle sur le serveur de gestion de la configuration et la install() méthode, par défaut, la copie sur l’équipement cible avant d’effectuer l’installation. Vous pouvez également demander à la install() méthode d’installer une image qui réside déjà sur l’appareil cible ou qui réside à une URL accessible à partir de l’équipement cible.

Le Tableau 1 décrit les paramètres de install() méthode que vous devez définir en fonction de l’emplacement du progiciel. Vous devez toujours inclure le package paramètre ou pkg_set dans l’appel de méthode install() .

Tableau 1 : paramètres de la méthode install() pour l’emplacement du paquet logiciel

Emplacement du progiciel	no_copy Paramètre	package ou pkg_set Paramètre	remote_path Paramètre
Serveur de gestion de la configuration	Omettre ou définir sur False	Chemin d’accès au fichier, y compris le nom de fichier du ou des packages logiciels sur le serveur local exécutant Junos PyEZ.	(Facultatif) Chemin d’accès au répertoire de l’équipement cible vers lequel le ou les packages seront copiés. La valeur par défaut est /var/tmp.
Équipement cible	Se mettre à True	Nom de fichier du ou des progiciels.	(Facultatif) Chemin d’accès au répertoire de l’équipement cible où le ou les packages doivent déjà résider. La valeur par défaut est /var/tmp.
URL	–	URL du point de vue de l’équipement Junos cible à partir duquel le progiciel est installé.	–

L’argument package est utilisé pour installer des logiciels sur un seul équipement Junos ou sur des membres d’un Virtual Chassis non mixte. L’argument package est une chaîne qui spécifie une seule image logicielle. Par exemple:

L’argument pkg_set est utilisé pour installer des logiciels sur les membres d’un Virtual Chassis mixte. Il contient une liste ou un tuple de chaînes qui spécifient les images logicielles nécessaires, sans ordre particulier, pour les différents membres de Virtual Chassis. Par exemple:

Pour les packages résidant sur le serveur local exécutant Junos PyEZ, lorsque vous omettez l’argument no_copy ou que vous le définissez sur False, le serveur copie le package logiciel spécifié sur le périphérique. L’inclusion de l’argument package oblige le serveur à copier le package sur l’équipement cible (périphérique individuel ou routeur principal ou commutateur dans un Virtual Chassis non mixte), et l’inclusion de l’argument pkg_set entraîne la copie de tous les packages de la liste sur le routeur principal ou le commutateur dans un Virtual Chassis mixte. Par défaut, les images logicielles sont placées dans le répertoire /var/tmp , sauf si l’argument remote_path spécifie un répertoire différent.

Si vous définissez l’argument no_copy sur True, les packages logiciels nécessaires doivent déjà exister sur la machine cible ou la machine principale Virtual Chassis avant le début de l’installation. Les paquets doivent résider soit dans le répertoire spécifié par l’argument remote_path , soit, s’il remote_path est omis, dans le répertoire /var/tmp par défaut.

Junos PyEZ prend également en charge l’installation d’images logicielles à partir d’une URL. Dans ce cas, la package valeur ou pkg_set doit être une URL du point de vue de l’équipement Junos cible. Le package est copié et installé à partir de l’URL spécifiée, et les no-copy arguments et remote_path sont ignorés. Pour plus d’informations sur la spécification du format de l’URL, reportez-vous à la section Format de spécification des noms de fichiers et des URL dans les commandes CLI de Junos OS.

Pour installer une image logicielle sur un équipement Junos, une application Junos PyEZ se connecte au périphérique individuel ou au périphérique principal d’un Virtual Chassis, crée une instance de l’utilitaire SW et appelle la install() méthode avec les arguments obligatoires ou facultatifs. Par exemple:

Pour la liste actuelle des paramètres de install() la méthode, consultez install().

Si le package logiciel se trouve sur le serveur de gestion de la configuration et que le no_copy paramètre est omis ou défini sur False, la install() méthode effectue les opérations suivantes avant d’installer le logiciel :

• Calcule la somme de contrôle du ou des progiciels locaux à l’aide de l’algorithme spécifié dans l’argument checksum_algorithm , si la somme de contrôle n’est pas déjà fournie par l’argument checksum . Les valeurs acceptables checksum_algorithm sont "md5", "sha1", et "sha256". La valeur par défaut est "md5".

• Effectue un nettoyage du stockage sur l’équipement cible afin de libérer de l’espace pour le progiciel, sauf si cleanfs la valeur est .False

• SCP ou FTP copie le paquet dans le remote_path répertoire ou, s’il remote_path n’est pas spécifié, dans le répertoire /var/tmp , si un fichier portant le même nom et la même somme de contrôle ne réside pas déjà à l’emplacement cible sur le périphérique.

• Calcule la somme de contrôle du fichier distant et la compare à la valeur du fichier local.

Une fois que le progiciel est sur l’équipement cible, qu’il y ait été téléchargé initialement, copié à partir du serveur de gestion de la configuration par la install() méthode ou copié à partir d’une URL par l’équipement cible, la install() méthode effectue les opérations suivantes :

• Valide la configuration par rapport au nouveau package si le validate paramètre est défini sur True

• Installe le package sur tous les moteurs de routage, sauf s’il all_re est défini sur False

Note:

À partir de la version 2.1.5, Junos PyEZ met à niveau par défaut tous les moteurs de routage sur les équipements individuels et les membres d’un Virtual Chassis. Dans les versions antérieures, ou si all_re=False, Junos PyEZ met uniquement à niveau le moteur de routage auquel il est connecté.

À partir de la version 2.5.0 de Junos PyEZ, la install() méthode renvoie un tuple contenant l’état de l’installation et une chaîne de message. Dans les versions antérieures, la méthode renvoie uniquement l’état de l’installation. L’état est True si l’installation est réussie et False non. La chaîne de message fournit des informations supplémentaires sur la réussite ou l’échec de l’installation et peut inclure des messages d’information ou des messages d’erreur générés par Junos PyEZ ou l’équipement. Par exemple:

La install() méthode ne redémarre pas automatiquement l’appareil. Pour redémarrer ou arrêter l’appareil une fois l’installation terminée, appelez la reboot() méthode ou shutdown() respectivement.

La vidéo suivante présente une courte session Python qui illustre comment utiliser Junos PyEZ pour installer Junos OS.

Junos PyEZ effectue des opérations sur une session NETCONF. Le délai d’expiration par défaut d’un RPC NETCONF est de 30 secondes. Au cours du processus d’installation, Junos PyEZ augmente l’intervalle entre le délai d’expiration RPC à 1800 secondes (30 minutes) lors de la copie et de l’installation du package sur l’équipement et à 300 secondes (5 minutes) lors du calcul de la somme de contrôle. Dans certains cas, le processus d’installation ou le calcul de la somme de contrôle peut dépasser ces intervalles de temps.

Pour augmenter la valeur du délai d’expiration pour le processus d’installation et le calcul de la somme de contrôle, incluez respectivement les timeout paramètres et checksum_timeout dans l’appel à la install() méthode et définissez-les sur les valeurs appropriées. Par exemple:

Le processus d’installation de Junos PyEZ vous permet d’afficher ou de consigner la progression de l’installation en incluant l’argument progress dans l’appel de install() méthode. L’argument est défini sur une fonction de rappel, qui doit avoir un prototype de fonction défini qui inclut les arguments de chaîne d’instance Device et de rapport. Vous pouvez également le configurer progress=True pour les sw.progress() rapports de base.

L’exemple suivant imprime la progression de l’installation à l’aide de la myprogress fonction.

La sortie de progression est dans le format défini par l’utilisateur.

Sur les équipements dotés de moteurs de routage avec prise en charge d’hôtes de machines virtuelles, Junos OS s’exécute en tant que machine virtuelle (VM) sur un hôte basé sur Linux (hôte de machine virtuelle). Une mise à niveau d’hôte de machine virtuelle nécessite un package d’installation d’hôte de machine virtuelle (junos-vmhost-install-x.tgz) et met à niveau le système d’exploitation hôte et les Junos OS compatibles. La mise à niveau est effectuée à l’aide de la request vmhost software add commande mode opérationnel, qui correspond au <request-vmhost-package-add> RPC.

À partir de la version 2.1.6 de Junos PyEZ, la sw.install() méthode prend en charge l’argument permettant d’effectuer une mise à niveau d’hôte vmhost=True de machine virtuelle. Lorsque l’argument vmhost=True est présent, la sw.install() méthode effectue l’installation à l’aide du <request-vmhost-package-add> RPC au lieu du <request-package-add> RPC.

L’exemple suivant met à niveau et redémarre Junos OS et le système d’exploitation hôte sur un seul périphérique du moteur de routage :

Pour redémarrer uniquement le logiciel Junos OS, appelez la sw.reboot() méthode sans l’argument vmhost .

Junos PyEZ permet d’effectuer une mise à niveau logicielle en service unifié (ISSU unifiée) ou une mise à niveau logicielle ininterrompue (NSSU) sur les équipements qui prennent en charge cette fonctionnalité et répondent aux exigences requises. Le Tableau 2 présente la version de Junos PyEZ dans laquelle les fonctionnalités unifiées ISSU et NSSU sont prises en charge pour la première fois. Pour plus d’informations sur l’ISSU unifié et le NSSU, reportez-vous à la documentation logicielle de votre produit.

Tableau 2 : prise en charge de Junos PyEZ Unified ISSU et NSSU

Lancement de Junos PyEZ	Prise en charge des fonctionnalités
2.1.0	Prise en charge d’ISSU et NSSU unifiés sur les équipements Junos à double moteur de routage.
2.1.6	Prise en charge d’ISSU unifié lors d’une mise à niveau d’hôte de machine virtuelle pour les équipements avec prise en charge d’hôte de machine virtuelle qui utilisent la request vmhost software in-service-upgrade commande pour effectuer une mise à niveau logicielle unifiée en service du système d’exploitation hôte et de Junos OS.

La fonctionnalité ISSU unifié vous permet de passer d’une version de Junos OS à une autre sans perturbation du plan de contrôle et avec une perturbation minimale du trafic. Pour effectuer une mise à niveau logicielle unifiée en service sur les appareils qui prennent en charge cette fonctionnalité, incluez l’argument issu=True dans la install() méthode.

Dans l’exemple suivant, la méthode met à niveau install() Junos OS sur les deux moteurs de routage et redémarre le nouveau moteur de routage principal (anciennement l’ancien moteur de routage de secours) dans le cadre du processus d’installation. Si l’installation réussit, la reboot() méthode redémarre alors le moteur de routage connecté, qui est le nouveau moteur de routage de secours (anciennement l’ancien moteur de routage principal).

Pour effectuer une mise à niveau logicielle unifiée en service sur un moteur de routage avec prise en charge de l’hôte de machine virtuelle qui répond aux exigences nécessaires et prend en charge l’ISSU unifié, incluez les vmhost=True arguments et issu=True dans la install() méthode. L’équipement effectue une mise à niveau d’un système d’exploitation hôte et d’une version de Junos OS vers la version demandée à l’aide du <request-vmhost-package-in-service-upgrade> RPC.

La fonctionnalité NSSU vous permet de mettre à niveau le logiciel Junos OS exécuté sur un commutateur ou Virtual Chassis avec des moteurs de routage redondants avec une perturbation minimale du trafic réseau. Pour effectuer une mise à niveau logicielle ininterrompue sur les appareils qui prennent en charge cette fonctionnalité, incluez l’argument nssu=True dans la install() méthode. Par exemple:

En règle générale, lorsque vous mettez à niveau un EX Series Virtual Chassis non mixte, vous devez suivre le processus d’installation décrit dans Présentation du processus d’installation pour mettre à niveau l’ensemble du Virtual Chassis. Toutefois, il peut arriver que vous ayez besoin d’installer un logiciel sur des commutateurs membres spécifiques dans un Virtual Chassis. À partir de la version 2.6.8 de Junos PyEZ, vous pouvez installer un package logiciel sur des commutateurs membres individuels dans un EX Series Virtual Chassis à l’aide de l’argument member_id . L’argument member_id est une liste de chaînes spécifiant les ID de membre sur lesquels installer le logiciel.

Par exemple, l’application Junos PyEZ suivante met à niveau le logiciel sur les membres 0 et 1 dans le EX Series Virtual Chassis :