Module reboot Ansible : redémarrer et attendre la reconnexion

ansible.builtin.reboot: redémarre proprement un managed node et attend qu'il soit de nouveau accessible avant de poursuivre le playbook. C'est le module à utiliser pour les upgrades kernel, les changements de config persistants (selinux disabled, fstab critique), ou les opérations de maintenance planifiée.

Le module gère trois choses automatiquement :

1. Lancer le shutdown -r (ou équivalent) sur la machine.
2. Attendre que la machine soit injoignable (le reboot a vraiment commencé).
3. Tester la reconnexion avec une commande (whoami par défaut) jusqu'à reboot_timeout.

Ce que vous allez apprendre

• Redémarrer un managed node et attendre la reconnexion proprement.
• Personnaliser la commande de test (test_command:).
• Ajuster les délais pré/post-reboot (pre_reboot_delay, post_reboot_delay).
• Gérer un timeout long (kernel update, machine lente).
• Conditionner un reboot via when: ou un handler.

Prérequis

• become: true (un user normal ne peut pas reboot).
• Le module bloque le play jusqu'à reconnexion, prévoir une fenêtre de maintenance côté CI/CD.

Reboot simple avec attente

- name: Redemarrer le serveur et attendre la reconnexion
  ansible.builtin.reboot:
    reboot_timeout: 600
    test_command: whoami

Comportement :

• Ansible lance shutdown -r now (selon la distrib).
• Attend que la machine soit injoignable (= reboot lancé).
• Tente une reconnexion SSH jusqu'à reboot_timeout secondes (600s = 10 min).
• À chaque tentative, lance test_command: whoami pour valider.

test_command: whoami est un défaut pertinent, il valide à la fois SSH et le filesystem /.

Délais pré/post-reboot

Les deux délais encadrent le redémarrage et répondent à des besoins opposés. Celui d'avant laisse la machine se fermer proprement, journaux écrits et services arrêtés. Celui d'après retarde la première tentative de connexion, le temps que le réseau remonte, ce qui évite une salve de refus sur les machines virtuelles lentes à initialiser.

- name: Reboot avec delais
  ansible.builtin.reboot:
    pre_reboot_delay: 5     # Attendre 5s avant le shutdown
    post_reboot_delay: 20   # Attendre 20s avant la 1re tentative SSH
    reboot_timeout: 300

Cas d'usage :

• pre_reboot_delay : laisser le temps aux logs de flusher, aux services de fermer proprement (typiquement 5-10s).
• post_reboot_delay : pour les VMs qui mettent du temps à initialiser le réseau (cloud, hyperviseurs lents). Évite les erreurs SSH prématurées au redémarrage.

Reboot conditionnel via handler

Pattern fréquent : reboot uniquement si un kernel a été mis à jour.

- name: Mise a jour kernel
  ansible.builtin.dnf:
    name: kernel
    state: latest
  notify: Reboot needed

handlers:
  - name: Reboot needed
    ansible.builtin.reboot:
      reboot_timeout: 900
      msg: "Reboot après mise à jour kernel par Ansible"

notify: déclenche le handler seulement si la tâche a changed. Pas de kernel update → pas de reboot. Idempotent.

msg: affiche un message aux utilisateurs connectés via wall avant le reboot.

Reboot sur condition explicite (when:)

- name: Detecter si un reboot est necessaire
  ansible.builtin.command: needs-restarting -r
  register: needs_restart
  changed_when: false
  failed_when: false

- name: Reboot si needs-restarting le demande (rc=1)
  ansible.builtin.reboot:
    reboot_timeout: 600
  when: needs_restart.rc == 1

needs-restarting -r (paquet dnf-utils sur RHEL) retourne rc=1 si un reboot est requis, rc=0 sinon. Combinaison classique pour automatiser la détection.

Timeout long pour kernel update

- name: Reboot apres upgrade complet
  ansible.builtin.reboot:
    reboot_timeout: 1800   # 30 minutes
    pre_reboot_delay: 30   # Laisser systemd faire son cleanup
    post_reboot_delay: 60  # VMs cloud parfois lentes
    test_command: "systemctl is-system-running"

test_command: systemctl is-system-running est plus strict que whoami, il vérifie que systemd a fini son init (running ou degraded), pas seulement que SSH répond.

Quand utiliser un long timeout : kernel updates massifs, migration filesystem, fsck au boot, hyperviseurs cloud lents.

Reboot sur Windows

- name: Reboot Windows
  ansible.builtin.reboot:
    reboot_timeout: 900
    connect_timeout: 10

Le module fonctionne aussi avec Windows via WinRM ou OpenSSH. Les délais doivent généralement être plus longs (Windows boot ~2-5 min vs Linux ~30s).

Pièges courants

Trois de ces quatre lignes se règlent en ajustant un délai, et la difficulté est de savoir lequel : le délai total borne l'attente, celui d'après le redémarrage retarde la première tentative, celui de connexion limite chaque essai. La quatrième n'est pas un réglage mais une méthode, redémarrer par handler plutôt que systématiquement.

Symptôme	Cause	Fix
reboot_timeout atteint avant reconnexion	VM lente à booter	Augmenter reboot_timeout, réduire connect_timeout
Erreurs SSH "Connection refused" pendant le reboot	Pas de post_reboot_delay	Ajouter 20-30s pour laisser le réseau remonter
Reboot lancé alors que pas nécessaire	reboot: direct au lieu de handler	Utiliser notify: + handler
Sur Windows, échec mystérieux	WinRM met du temps à redémarrer	connect_timeout: 30 minimum

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• reboot_timeout = durée max d'attente totale (défaut 600s).
• test_command = commande de validation après reconnexion (défaut whoami).
• pre_reboot_delay / post_reboot_delay = marges avant/après le reboot.
• Pattern handler = reboot uniquement si nécessaire (notify: + handler).
• needs-restarting -r (dnf-utils) détecte si un reboot est requis sur RHEL.
• Sur Windows, prévoir des délais plus longs (~3-5 min).

Pour aller plus loin

• Modules wait_for et pause : attendre un port ou un fichier plutôt que de deviner le temps que met la machine à revenir.
• Module service_facts : vérifier que les services attendus sont bien repartis après le redémarrage.
• debug, setup, add_host, group_by : les outils transversaux, dont la reconnexion SSH et la recollecte de facts après un reboot.

×

📖 Voir la documentation →