Le playbook ci-dessous impacte un groupe de machines que j'ai arbitrairement nommé pending-reboot. A moins d'être vraiment "très très sûr" de ce que vous faites, je vous conseille de cantonner vos playbooks "dangereux" à des groupes de hosts que vous ne remplirez qu'au moment de l'opération à réaliser et laisser vides le reste du temps.
Il ne serait pas bien vu de lancer un malencontreux reboot sur le groupe all juste parce qu'on a oublié de rajouter une option --limit $SUBGROUP au lancement de notre playbook...
Voici donc le playbook le plus minimaliste auquel je suis parvenu :
---
- hosts: pending-reboot
become: yes
tasks:
- name: Attempting reboot
shell: reboot
async: 1200
poll: 0
- name: Waiting for resurection
wait_for_connection:
delay: 60
timeout: 300
- name: Is it still you Bob?
setup:
Pour bien comprendre la mécanique, sachez que :
async est positionnable sur n'importe quelle tâche et indique à Ansible de la lancer en asynchrone. La valeur de async donne la durée maximale d'exécution en secondes.La tâche Attempting reboot lance donc une simple commande shell, mais avec un async suffisament long pour qu'Ansible ne se préoccupe pas de couper le sous-processus, et un poll à 0 ce qui indique de ne jamais venir vérifier si le processus s'est bien terminé.
Enfin, la tâche Waiting for resurection va attendre 60 secondes avant de tenter de se connecter à nouveau à nos machines. Cela laisse largement le temps à sshd de s'éteindre et évite qu'Ansible ne valide la connexion comme active alors même que la machine va s'éteindre. Il y aura une tentative de connexion toutes les delay secondes jusqu'au timeout.
Une fois que la connexion est revenue, le flow de tâches continue normalement.
En jouant sur les valeurs des attributs et où vous placez ces 2 tâches, je suis sûr que vous arriverez à tirer le meilleur parti de ces modestes lignes.
Have fun. Hack in peace.