Aller au contenu
Infrastructure as Code medium

Module reboot Ansible : redémarrer et attendre la reconnexion

8 min de lecture

Logo Ansible

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.
  • 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.
  • 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.
- 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 /.

- 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.

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.

- 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.

- 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.

- 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).

SymptômeCauseFix
reboot_timeout atteint avant reconnexionVM lente à booterAugmenter reboot_timeout, réduire connect_timeout
Erreurs SSH "Connection refused" pendant le rebootPas de post_reboot_delayAjouter 20-30s pour laisser le réseau remonter
Reboot lancé alors que pas nécessairereboot: direct au lieu de handlerUtiliser notify: + handler
Sur Windows, échec mystérieuxWinRM met du temps à redémarrerconnect_timeout: 30 minimum
  • 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).

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn