Utilisation du juniper.device.system module Ansible pour arrêter, redémarrer ou éteindre les équipements Junos
Utilisez le juniper.device.system module Ansible pour arrêter, redémarrer ou arrêter les équipements exécutant Junos OS ou Junos OS Evolved.
Utiliser Ansible pour arrêter, redémarrer ou éteindre des appareils
Juniper Networks fournit un module Ansible que vous pouvez utiliser pour arrêter, redémarrer ou arrêter les équipements exécutant Junos OS ou les équipements exécutant Junos OS Evolved. Le Tableau 1 présente les modules disponibles.
|
Collecte |
Ensemble de modules |
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 optionnel
-
Une opération d’arrêt, de redémarrage ou d’arrêt planifiée à une date et une heure spécifiques
Le system module nécessite un argument, action, qui définit l’action à effectuer. Le Tableau 2 définit les action valeurs des paramètres et fournit une brève description de chaque action ainsi que la commande CLI correspondante. Pour plus d’informations sur l’action "zeroize" , consultez Utilisation du module Ansible juniper.device.system pour restaurer un périphérique Junos à son état d’usine par défaut.
|
|
Descriptif |
Commande CLI équivalente |
|---|---|---|
|
|
Arrêtez gracieusement le logiciel Junos OS ou le logiciel Junos OS Evolved, tout en maintenant l’alimentation du système |
|
|
|
Redémarrez le logiciel Junos OS ou le logiciel Junos OS Evolved |
|
|
|
Arrêtez en douceur le logiciel Junos OS ou le logiciel Junos OS Evolved et éteignez les moteurs de routage |
|
Le playbook Ansible suivant utilise le juniper.device.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
Procédure d’arrêt, de redémarrage ou d’arrêt avec un délai ou à une heure spécifiée
Vous pouvez retarder l’opération d’arrêt, de redémarrage ou d’arrêt d’un nombre spécifié de minutes. 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 en 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 spécifique. Pour planifier une heure, incluez le at paramètre, qui prend une chaîne pouvant être spécifiée de l’une des manières suivantes :
-
now: lancer immédiatement l’arrêt, le redémarrage ou l’arrêt du logiciel. -
+minutes: nombre de minutes à partir du moment où l’action demandée est lancée. -
yymmddhhmm: heure absolue à laquelle lancer l’action demandée, spécifiée en année, mois, jour, heure et minute. -
hh:mm: heure absolue du jour en cours pour lancer l’action demandée, spécifiée en 24 heures.
La tâche suivante planifie l’arrêt système de tous les moteurs de routage à 22h30 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"
Spécification du moteur de routage cible
Par défaut, le juniper.device.system module effectue l’opération demandée sur tous les moteurs de routage dans 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 sauf celui auquel l’application est connectée.
Pour spécifier les moteurs de routage, utilisez les all_re paramètres et 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é |
Défini sur |
– |
|
Tous les moteurs de routage à l’exception du moteur de routage auquel l’application est connectée |
– |
Défini sur |
Pour indiquer explicitement que l’opération doit être effectuée sur tous les moteurs de routage dans une configuration à double moteur de routage ou Virtual Chassis, incluez l’argument all_re: true 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 prenant en charge l’hôte de machine virtuelle, Junos OS s’exécute en tant que machine virtuelle sur un hôte Linux (hôte de machine virtuelle). Le juniper.device.system module prend en charge l’argument vmhost , ce qui vous permet de redémarrer ou d’arrêter un hôte de machine virtuelle.
Lorsque vous incluez les action: reboot arguments and vmhost: true , le système redémarre le système d’exploitation hôte et Junos OS compatible 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 and vmhost: true , le système arrête le système d’exploitation hôte et le système d’exploitation compatible Junos OS sur tous les moteurs de routage en exécutant le <request-vmhost-poweroff> RPC, qui correspond à la commande du request vmhost power-off mode opérationnel.
Le playbook suivant redémarre l’hôte de la 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 : Utilisation d’Ansible pour redémarrer des appareils Junos
Le juniper.device.system module vous permet d’arrêter, de redémarrer ou d’éteindre 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.devicecollection installée -
Équipement Junos sur lequel NETCONF est activé et un compte 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
Vue d’ensemble
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 module définit l’opération à exécuter sur l’hôte action .
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 appareils spécifiés. Si un utilisateur exécute le guide par inadvertance sans aucune vérification, 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 appareils. L’invite nécessite que l’utilisateur tape manuellement 'yes' sur la ligne de commande pour exécuter le module. Si la Confirmation check tâche échoue, le nœud de contrôle Ansible ignore les autres tâches en cours de lecture pour cet appareil.
Ce guide comprend la Check NETCONF connectivity tâche qui utilise le ansible.builtin.wait_for module pour essayer d’établir une session NETCONF avec l’équipement 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 l’appareil pendant l’exécution du playbook, il ignore les tâches restantes dans le jeu pour cet appareil.
La tâche de redémarrage exécute le juniper.device.system module à condition que la confirmation et les vérifications NETCONF aient réussi. L’argument action est défini sur reboot, ce qui indique que le logiciel doit être redémarré. L’argument in_min: 2 demande au module d’attendre le nombre de minutes spécifié avant d’exécuter la commande reboot. Cela donne le temps aux utilisateurs 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 empêcher le wait_reboot gestionnaire de détecter à tort que l’appareil 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 ractive après le redémarrage. La wait_time_after_reboot variable définit la durée pendant laquelle le nœud de contrôle tente de se reconnecter à l’appareil.
La configuration
Créer et exécuter le playbook Ansible
Procédure étape par étape
Pour créer un playbook qui utilise le juniper.device.system module pour redémarrer un équipement Junos :
-
Incluez le passe-partout du playbook et de ce jeu, qui exécute les modules localement.
--- - name: Reboot Junos devices hosts: dc1 connection: local gather_facts: no
-
Définissez ou importez toutes 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 d’abord 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 notifiez 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 ractive 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 prévu, 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 guide stratégique
Procédure
Procédure étape par étape
Pour exécuter le playbook :
-
Exécutez la
ansible-playbookcommande sur le nœud de contrôle et fournissez le chemin du playbook et toutes 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érifiez le redémarrage
Objet
Vérifiez que le périphérique Junos a bien redémarré.
Mesures à prendre
Lorsque vous exécutez le playbook, examinez la sortie de la wait_reboot tâche pour chaque périphérique.
RUNNING HANDLER [wait_reboot] ************************************************* ok: [dc1a.example.net]
Signification
Le wait_reboot résultat indique si le nœud de contrôle a réussi à établir une session avec l’appareil après son redémarrage. Si le résultat indique un succès, 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 À partir de la version de collecte 1.0.3, le module prend en charge l’arrêt system d’un hôte de machine virtuelle.