Ansible Tips : Reboot & Continue

Quand on pilote des serveurs avec Ansible, il arrive souvent d'avoir besoin de faire un redémarrage avant de continuer les opérations, ne serait-ce que pour changer de kernel. C'est une question récurrente, autant en formation que dans les équipes que je fréquente. Voici donc un petit aide-mémoire pour vous expliquer comment redémarrer et attendre le retour d'une ou plusieurs machines avant de continuer le flow des tâches Ansible.

Mise en situation

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 :

  • l'attribut 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.
  • l'attribut poll vient avec async et donne la durée en secondes entre 2 vérifications de fin de tâches par Ansible.

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.

Conclusion

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.