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.devicecollection 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: 830Cré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: noCré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: 5Cré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: resultCré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-playbookcommande 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.