Utiliser Ansible pour arrêter, redémarrer ou arrêter des équipements Junos
Utilisez les modules Ansible de Juniper Networks pour arrêter, redémarrer ou arrêter les équipements Junos.
Utiliser Ansible pour arrêter, redémarrer ou éteindre des appareils
Juniper Networks fournit un module Ansible qui vous permet d’arrêter, de redémarrer ou d’éteindre un équipement Junos. Le tableau 1 présente les modules disponibles.
Ensemble de contenu |
Nom du module |
---|---|
|
Vous pouvez utiliser le juniper.device.system
module pour demander les opérations suivantes sur les équipements Junos. Par défaut, le module exécute immédiatement l’opération demandée et effectue l’opération sur tous les moteurs de routage dans une configuration à double moteur de routage ou Virtual Chassis.
-
Un arrêt, un redémarrage ou un arrêt immédiat du système
-
Une opération d’arrêt, de redémarrage ou d’arrêt avec un délai facultatif
-
Une opération d’arrêt, de redémarrage ou d’arrêt planifiée à une date et une heure précises
Le system
module requiert un argument, action
, qui définit l’action effectuée par le module. Le Tableau 2 définit la valeur de paramètre action
requise pour arrêter, redémarrer ou arrêter un périphérique et fournit une brève description de chaque action ainsi que la commande CLI correspondante. Pour plus d’informations sur l’action, reportez-vous à la section Utiliser Ansible pour restaurer les paramètres de configuration d’usine par défaut d’un équipement Junos."zeroize"
Valeur du |
Description |
Commande CLI équivalente |
---|---|---|
|
Arrêtez le logiciel Junos OS sans problème, mais maintenez l’alimentation du système |
|
|
Redémarrez le logiciel Junos OS |
|
|
Arrêtez correctement le logiciel Junos OS et mettez les moteurs de routage hors tension |
|
Le playbook Ansible suivant utilise le system
module with action: "reboot"
pour redémarrer immédiatement tous les moteurs de routage sur les hôtes du groupe d’inventaire spécifié.
--- - name: Reboot Junos devices hosts: dc1 connection: local gather_facts: no tasks: - name: Reboot all REs on the device juniper.device.system: action: "reboot"
Comment effectuer un arrêt, un redémarrage ou un arrêt avec un délai ou à une heure spécifiée
Vous pouvez retarder l’interruption, le redémarrage ou l’arrêt de l’opération d’un nombre de minutes spécifié. Pour ajouter un délai, définissez le paramètre facultatif in_min
sur le nombre de minutes que le système doit attendre avant d’exécuter l’opération. La tâche suivante demande un redémarrage de tous les moteurs de routage dans les 30 minutes :
--- - name: Reboot Junos devices hosts: dc1 connection: local gather_facts: no tasks: - name: Reboot all REs in 30 minutes juniper.device.system: action: "reboot" in_min: 30
Vous pouvez également planifier l’opération d’arrêt, de redémarrage ou d’arrêt à une heure précise. Pour planifier une heure, incluez le at
paramètre, qui prend une chaîne qui peut être spécifiée de l’une des manières suivantes :
-
now
: lancez immédiatement l’arrêt, le redémarrage ou l’arrêt du logiciel. -
+minutes
: nombre de minutes à partir de ce moment où l’action demandée est lancée. -
yymmddhhmm
: heure absolue à laquelle lancer l’action demandée, spécifiée comme année, mois, jour, heure et minute. -
hh:mm
: heure absolue du jour en cours à laquelle lancer l’action demandée, spécifiée dans un délai de 24 heures.
La tâche suivante planifie l’arrêt du système de tous les moteurs de routage à 22 h 30 le jour en cours :
tasks: - name: Shut down all REs at 22:30 on the current day juniper.device.system: action: "shutdown" at: "22:30"
Comment spécifier le moteur de routage cible
Par défaut, le system
module effectue l’opération demandée sur tous les moteurs de routage d’une configuration à double moteur de routage ou Virtual Chassis. Vous pouvez également demander au module d’effectuer l’opération uniquement sur le moteur de routage auquel l’application est connectée ou d’effectuer l’opération sur tous les moteurs de routage à l’exception de celui auquel l’application est connectée.
Pour spécifier les moteurs de routage, utilisez les all_re
paramètres and other_re
. Le Tableau 3 récapitule les all_re
valeurs et other_re
requises pour exécuter l’opération demandée sur des moteurs de routage spécifiques.
Moteurs de routage concernés |
|
|
---|---|---|
Tous les moteurs de routage (par défaut) |
Omettre ou définir sur |
– |
Seul le moteur de routage connecté |
Se mettre à |
– |
Tous les moteurs de routage, à l’exception du moteur de routage auquel l’application est connectée |
– |
Se mettre à |
Pour indiquer explicitement que l’opération doit être effectuée sur tous les moteurs de routage d’une configuration à double moteur de routage ou Virtual Chassis, incluez l’argument all_re: true
, qui est l’argument par défaut.
--- - name: Reboot Junos devices hosts: dc1 connection: local gather_facts: no tasks: - name: Reboot all Routing Engines juniper.device.system: action: "reboot" all_re: true
Pour effectuer l’action demandée uniquement sur le moteur de routage auquel l’application est connectée, incluez l’argument all_re: false
.
tasks: - name: Reboot only the connected Routing Engine juniper.device.system: action: "reboot" all_re: false
Pour effectuer l’action demandée sur tous les moteurs de routage du système, à l’exception du moteur de routage auquel l’application est connectée, incluez l’argument other_re: true
.
tasks: - name: Shut down all other Routing Engines juniper.device.system: action: "shutdown" other_re: true
Comment redémarrer ou arrêter un hôte de machine virtuelle
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 machines virtuelles). Le system
module prend en charge l’argument vmhost
, qui vous permet de redémarrer ou d’arrêter un hôte de machine virtuelle.
Lorsque vous incluez les action: "reboot"
arguments et vmhost: true
, le système redémarre le système d’exploitation hôte et les Junos OS compatibles sur tous les moteurs de routage en exécutant le <request-vmhost-reboot>
RPC, qui correspond à la request vmhost reboot
commande du mode opérationnel.
De même, lorsque vous incluez les action: "shutdown"
arguments et vmhost: true
, le système arrête le système d’exploitation hôte et le système d’exploitation Junos OS compatible sur tous les moteurs de routage en exécutant le <request-vmhost-poweroff>
RPC, qui correspond à la request vmhost power-off
commande du mode opérationnel.
Le playbook suivant effectue un redémarrage de l’hôte de machine virtuelle, qui redémarre à la fois le système d’exploitation hôte et le système d’exploitation Junos OS invité.
--- - name: Reboot VM Hosts hosts: vm_hosts connection: local gather_facts: no tasks: - name: Reboot VM host juniper.device.system: action: "reboot" vmhost: true all_re: false
Exemple : Utiliser Ansible pour redémarrer des équipements Junos
Le juniper.device.system
module vous permet d’arrêter, de redémarrer ou d’arrêter un équipement Junos. Cet exemple utilise le system
module pour redémarrer un équipement Junos.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
-
Serveur de gestion de la configuration exécutant Ansible 2.17 ou version ultérieure avec la
juniper.device
collection installée -
Équipement Junos sur lequel NETCONF est activé et compte d’utilisateur configuré avec les autorisations appropriées
-
Paire de clés publique/privée SSH configurée pour l’utilisateur approprié sur le nœud de contrôle Ansible et l’équipement Junos
-
Fichier d’inventaire Ansible existant avec les hôtes requis définis
Aperçu
Cet exemple présente un playbook Ansible qui utilise le juniper.device.system
module pour redémarrer un équipement Junos. La valeur de l’argument du action
module définit l’opération à exécuter sur l’hôte.
Lorsque vous appelez le module à partir d’un playbook, nous vous recommandons d’utiliser une invite interactive pour confirmer que l’utilisateur a bien l’intention de redémarrer les périphériques spécifiés. Si un utilisateur exécute involontairement le playbook et qu’aucune vérification n’est effectuée, cela peut avoir des répercussions négatives sur tous les réseaux qui ont besoin des appareils concernés. Par mesure de précaution, ce playbook utilise une invite interactive pour vérifier que l'utilisateur a l'intention de redémarrer les périphériques et exige que l'utilisateur tape manuellement 'yes' sur la ligne de commande pour exécuter le module. En cas d’échec de la Confirmation check
tâche, le nœud de contrôle Ansible ignore les autres tâches en lecture pour cet appareil.
Ce playbook inclut la Check NETCONF connectivity
tâche qui utilise le ansible.builtin.wait_for
module pour tenter d’établir une session NETCONF avec le périphérique Junos à l’aide du port NETCONF 830 par défaut. Si le nœud de contrôle ne parvient pas à établir une session NETCONF avec le périphérique pendant l’exécution du playbook, il ignore les tâches restantes dans le jeu pour ce périphérique.
La tâche qui redémarre l’appareil exécute le system
module à condition que les vérifications de confirmation et NETCONF aient réussi. L’argument action
est défini sur la valeur "reboot"
, qui indique que le logiciel doit être redémarré. L’argument in_min: 2
indique au module d’attendre le nombre de minutes spécifié avant d’exécuter la commande reboot. Les utilisateurs ont ainsi le temps de se déconnecter du système.
La tâche stocke le résultat du module dans la result
variable et notifie deux gestionnaires. Le pause_for_reboot
gestionnaire attend un certain temps après le lancement de l’opération de redémarrage pour éviter qu’il wait_reboot
ne détecte à tort que le périphérique est en ligne avant que le redémarrage n’ait lieu. Le wait_reboot
gestionnaire tente ensuite d’établir une session avec l’appareil pour vérifier que l’appareil se reconnecte après le redémarrage. La wait_time_after_reboot
variable définit la durée pendant laquelle le noeud de contrôle tente de se reconnecter à l’équipement.
Configuration
Créer et exécuter le playbook Ansible
Procédure étape par étape
Pour créer un playbook qui utilise le system
module pour redémarrer un équipement Junos :
Incluez le passe-partout pour le playbook et ce play, qui exécute les modules localement.
--- - name: Reboot Junos devices hosts: dc1 connection: local gather_facts: no
Définissez ou importez les variables nécessaires.
vars: wait_time_after_reboot: 300 netconf_port: 830
Créez une invite interactive pour empêcher les utilisateurs d’exécuter accidentellement le module sans en comprendre au préalable les implications.
vars_prompt: - name: "reboot_confirmation" prompt: "This playbook reboots devices. Enter 'yes' to continue" private: no
Créez la tâche qui confirme l’intention de l’utilisateur.
tasks: - name: Confirmation check fail: msg="Playbook run confirmation failed" when: reboot_confirmation != "yes"
(Facultatif) Créez une tâche pour vérifier la connectivité NETCONF.
- name: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: 5
Créez la tâche pour redémarrer l’appareil après un nombre spécifié de minutes, puis informez les gestionnaires.
- name: Reboot all Routing Engines on the Junos device juniper.device.system: action: "reboot" in_min: 2 all_re: true register: result notify: - pause_for_reboot - wait_reboot
(Facultatif) Créez une tâche pour imprimer la réponse.
- name: Print response ansible.builtin.debug: var: result
Créez le gestionnaire qui s’interrompt après le redémarrage et le gestionnaire qui vérifie que l’appareil se reconnecte après le redémarrage.
Les noms des gestionnaires doivent être les mêmes que ceux référencés dans la tâche de redémarrage.
handlers: - name: pause_for_reboot pause: seconds: 180 when: result.reboot - name: wait_reboot ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: "{{ wait_time_after_reboot }}" when: result.reboot
Résultats
Sur le nœud de contrôle Ansible, passez en revue le playbook terminé. Si le playbook n’affiche pas le code voulu, répétez les instructions de cet exemple pour corriger le playbook.
--- - name: Reboot Junos devices hosts: dc1 connection: local gather_facts: no vars: wait_time_after_reboot: 300 netconf_port: 830 vars_prompt: - name: "reboot_confirmation" prompt: "This playbook reboots devices. Enter 'yes' to continue" private: no tasks: - name: Confirmation check fail: msg="Playbook run confirmation failed" when: reboot_confirmation != "yes" - name: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: 5 - name: Reboot all Routing Engines on the Junos device juniper.device.system: action: "reboot" in_min: 2 all_re: true register: result notify: - pause_for_reboot - wait_reboot - name: Print response ansible.builtin.debug: var: result handlers: - name: pause_for_reboot pause: seconds: 180 when: result.reboot - name: wait_reboot ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: "{{ wait_time_after_reboot }}" when: result.reboot
Exécuter le playbook
Procédure
Procédure étape par étape
Pour exécuter le playbook :
-
Émettez la
ansible-playbook
commande sur le nœud de contrôle et indiquez le chemin d’accès au playbook ainsi que les options souhaitées.user@ansible-cn:~/ansible$ ansible-playbook ansible-pb-junos-reboot.yaml This playbook reboots devices. Enter 'yes' to continue: yes PLAY [Reboot Junos devices] ************************************************** TASK [Confirmation check] **************************************************** skipping: [dc1a.example.net] TASK [Check NETCONF connectivity] ******************************************** ok: [dc1a.example.net] TASK [Reboot all Routing Engines on the Junos device] ************* changed: [dc1a.example.net] TASK [Print response] ******************************************************** ok: [dc1a.example.net] => { "result": { "action": "reboot", "all_re": true, "changed": true, "failed": false, "media": false, "msg": "reboot successfully initiated. Response got Shutdown at Fri Dec 11 17:36:50 2020. [pid 11595]", "other_re": false, "reboot": true, "vmhost": false } } RUNNING HANDLER [pause_for_reboot] ******************************************* Pausing for 180 seconds (ctrl+C then 'C' = continue early, ctrl+C then 'A' = abort) ok: [dc1a.example.net] RUNNING HANDLER [wait_reboot] ************************************************ ok: [dc1a.example.net] PLAY RECAP ******************************************************************* dc1a.example.net : ok=5 changed=1 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
Vérification
Vérifier le redémarrage
But
Vérifiez que le périphérique Junos a bien redémarré.
Action
Lorsque vous exécutez le playbook, examinez le résultat de la wait_reboot
tâche pour chaque appareil.
RUNNING HANDLER [wait_reboot] ************************************************* ok: [dc1a.example.net]
Signification
Le wait_reboot
résultat indique si le nœud de contrôle a bien établi une session avec le périphérique après son redémarrage. Si le résultat indique la réussite, cela signifie que l’appareil est en ligne.
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
juniper.device
la version 1.0.3 de la collection, le module prend en charge l’arrêt
system
d’un hôte de machine virtuelle.