Mise à jour 2018
Depuis la version 2.3, Ansible est désormais livré avec le wait_for_connection module, qui peut être utilisé exactement dans ce but.
#
## Reboot
#
- name: (reboot) Reboot triggered
command: /sbin/shutdown -r +1 "Ansible-triggered Reboot"
async: 0
poll: 0
- name: (reboot) Wait for server to restart
wait_for_connection:
delay: 75
Le shutdown -r +1 empêche un code de retour de 1 d'être renvoyé et de faire échouer la tâche. L'arrêt est exécuté comme une tâche asynchrone, nous devons donc retarder le wait_for_connection tâche au moins 60 secondes. 75 nous donne un tampon pour ces cas de flocons de neige.
wait_for_connection - Attend jusqu'à ce que le système distant soit accessible/utilisable
Le plus fiable que j'ai avec 1.9.4 est (c'est mis à jour, la version originale est en bas):
- name: Example ansible play that requires reboot
sudo: yes
gather_facts: no
hosts:
- myhosts
tasks:
- name: example task that requires reboot
yum: name=* state=latest
notify: reboot sequence
handlers:
- name: reboot sequence
changed_when: "true"
debug: msg='trigger machine reboot sequence'
notify:
- get current time
- reboot system
- waiting for server to come back
- verify a reboot was actually initiated
- name: get current time
command: /bin/date +%s
register: before_reboot
sudo: false
- name: reboot system
shell: sleep 2 && shutdown -r now "Ansible package updates triggered"
async: 1
poll: 0
ignore_errors: true
- name: waiting for server to come back
local_action: wait_for host={{ inventory_hostname }} state=started delay=30 timeout=220
sudo: false
- name: verify a reboot was actually initiated
# machine should have started after it has been rebooted
shell: (( `date +%s` - `awk -F . '{print $1}' /proc/uptime` > {{ before_reboot.stdout }} ))
sudo: false
Notez le async option. 1.8 et 2.0 peuvent vivre avec 0 mais la 1.9 le veut 1 . Ce qui précède vérifie également si la machine a effectivement été redémarrée. C'est bien parce qu'une fois j'ai eu une faute de frappe qui a échoué au redémarrage et aucune indication de l'échec.
Le gros problème est d'attendre que la machine soit en place. Cette version reste là pendant 330 secondes et n'essaie jamais d'accéder à l'hôte plus tôt. Certaines autres réponses suggèrent d'utiliser le port 22. C'est bien si les deux sont vrais :
- vous avez un accès direct aux machines
- votre machine est accessible immédiatement après l'ouverture du port 22
Ce n'est pas toujours vrai, j'ai donc décidé de perdre 5 minutes de temps de calcul. J'espère pouvoir étendre le module wait_for pour vérifier l'état de l'hôte afin d'éviter de perdre du temps.
btw la réponse suggérant d'utiliser des gestionnaires est agréable. +1 pour les gestionnaires de ma part (et j'ai mis à jour la réponse pour utiliser les gestionnaires).
Voici la version originale mais elle n'est pas si bonne et pas si fiable :
- name: Reboot
sudo: yes
gather_facts: no
hosts:
- OSEv3:children
tasks:
- name: get current uptime
shell: cat /proc/uptime | awk -F . '{print $1}'
register: uptime
sudo: false
- name: reboot system
shell: sleep 2 && shutdown -r now "Ansible package updates triggered"
async: 1
poll: 0
ignore_errors: true
- name: waiting for server to come back
local_action: wait_for host={{ inventory_hostname }} state=started delay=30 timeout=300
sudo: false
- name: verify a reboot was actually initiated
# uptime after reboot should be smaller than before reboot
shell: (( `cat /proc/uptime | awk -F . '{print $1}'` < {{ uptime.stdout }} ))
sudo: false
Ansible >= 2.7 (publié en octobre 2018)
Utilisez le module de redémarrage intégré :
- name: Wait for server to restart
reboot:
reboot_timeout: 3600
Ansible <2.7
Redémarrer en tant que tâche
- name: restart server
shell: 'sleep 1 && shutdown -r now "Reboot triggered by Ansible" && sleep 1'
async: 1
poll: 0
become: true
Cela exécute la commande shell en tant que tâche asynchrone, donc Ansible n'attendra pas la fin de la commande. Généralement async param donne le temps maximum pour la tâche mais comme poll est défini sur 0, Ansible n'interrogera jamais si la commande est terminée - cela fera de cette commande un "lancer et oublier". Dort avant et après shutdown sont destinés à empêcher la rupture de la connexion SSH lors du redémarrage alors qu'Ansible est toujours connecté à votre hôte distant.
Attendre en tant que tâche
Vous pouvez simplement utiliser :
- name: Wait for server to restart
local_action:
module: wait_for
host={{ inventory_hostname }}
port=22
delay=10
become: false
..mais vous préférerez peut-être utiliser {{ ansible_ssh_host }} variable comme nom d'hôte et/ou {{ ansible_ssh_port }} comme hôte et port SSH si vous utilisez des entrées telles que :
hostname ansible_ssh_host=some.other.name.com ansible_ssh_port=2222
..dans votre inventaire (Ansible hosts fichier).
Cela exécutera la tâche wait_for sur la machine exécutant Ansible. Cette tâche attendra que le port 22 soit ouvert sur votre hôte distant, commençant après un délai de 10 secondes.
Redémarrer et attendre en tant que gestionnaires
Mais je suggère d'utiliser les deux comme gestionnaires, pas comme tâches.
Il y a 2 raisons principales de le faire :
-
réutilisation du code - vous pouvez utiliser un gestionnaire pour de nombreuses tâches. Exemple : déclencher le redémarrage du serveur après avoir changé le fuseau horaire et après avoir changé le noyau,
-
déclencher une seule fois - si vous utilisez un gestionnaire pour quelques tâches, et que plus d'une d'entre elles apportera des modifications => déclencher le gestionnaire, alors ce que le gestionnaire fera ne se produira qu'une seule fois. Exemple : si vous avez un gestionnaire de redémarrage httpd attaché au changement de configuration httpd et à la mise à jour du certificat SSL, alors dans le cas où les changements de configuration et de certificat SSL, httpd ne sera redémarré qu'une seule fois.
En savoir plus sur les gestionnaires ici.
Redémarrage et attente du redémarrage en tant que gestionnaires :
handlers:
- name: Restart server
command: 'sleep 1 && shutdown -r now "Reboot triggered by Ansible" && sleep 1'
async: 1
poll: 0
ignore_errors: true
become: true
- name: Wait for server to restart
local_action:
module: wait_for
host={{ inventory_hostname }}
port=22
delay=10
become: false
..et l'utiliser dans votre tâche dans une séquence, comme celle-ci, associée ici au redémarrage du gestionnaire de serveur :
tasks:
- name: Set hostname
hostname: name=somename
notify:
- Restart server
- Wait for server to restart
Notez que les gestionnaires sont exécutés dans l'ordre dans lequel ils sont définis, et non dans l'ordre dans lequel ils sont répertoriés dans notify !
Vous devez modifier la tâche wait_for pour qu'elle s'exécute en tant que local_action et spécifier l'hôte que vous attendez. Par exemple :
- name: Wait for server to restart
local_action:
module: wait_for
host=192.168.50.4
port=22
delay=1
timeout=300