Aktualisierung 2018
Ab 2.3 wird Ansible jetzt mit dem wait_for_connection ausgeliefert Modul, das genau für diesen Zweck verwendet werden kann.
#
## 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
Das Herunterfahren -r +1 verhindert, dass ein Rückgabecode von 1 zurückgegeben wird und die Aufgabe ansible fehlschlägt. Das Herunterfahren wird als asynchrone Aufgabe ausgeführt, daher müssen wir die wait_for_connection verzögern Aufgabe mindestens 60 Sekunden. 75 gibt uns einen Puffer für diese Schneeflockenfälle.
wait_for_connection - Wartet, bis das entfernte System erreichbar/benutzbar ist
Das zuverlässigste, was ich mit 1.9.4 habe, ist (dies ist aktualisiert, die Originalversion ist unten):
- 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
Beachten Sie den async Möglichkeit. 1.8 und 2.0 können mit 0 leben aber 1.9 will es 1 . Das obige überprüft auch, ob die Maschine tatsächlich neu gestartet wurde. Das ist gut, denn einmal hatte ich einen Tippfehler, bei dem der Neustart fehlschlug und kein Hinweis auf den Fehler.
Das große Problem besteht darin, darauf zu warten, dass die Maschine hochgefahren ist. Diese Version sitzt nur 330 Sekunden lang dort und versucht nie, früher auf den Host zuzugreifen. Einige andere Antworten schlagen vor, Port 22 zu verwenden. Dies ist gut, wenn beides zutrifft:
- Sie haben direkten Zugriff auf die Maschinen
- Ihre Maschine ist sofort zugänglich, nachdem Port 22 geöffnet wurde
Diese sind nicht immer wahr, also habe ich beschlossen, 5 Minuten Rechenzeit zu verschwenden. Ich hoffe, dass das Modul wait_for erweitert werden kann, um den Hoststatus tatsächlich zu überprüfen, um Zeitverschwendung zu vermeiden.
Übrigens ist die Antwort, die vorschlägt, Handler zu verwenden, nett. +1 für Handler von mir (und ich habe die Antwort aktualisiert, um Handler zu verwenden).
Hier ist die Originalversion, aber sie ist nicht so gut und nicht so zuverlässig:
- 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 (veröffentlicht im Oktober 2018)
Verwenden Sie das eingebaute Neustartmodul:
- name: Wait for server to restart
reboot:
reboot_timeout: 3600
Ansible <2.7
Als Aufgabe neu starten
- name: restart server
shell: 'sleep 1 && shutdown -r now "Reboot triggered by Ansible" && sleep 1'
async: 1
poll: 0
become: true
Dadurch wird der Shell-Befehl als asynchrone Aufgabe ausgeführt, sodass Ansible nicht auf das Ende des Befehls wartet. Normalerweise async param gibt die maximale Zeit für die Aufgabe an, aber als poll auf 0 gesetzt ist, wird Ansible niemals abfragen, ob der Befehl beendet ist - es macht diesen Befehl zu einem "fire and forget". Schläft vor und nach shutdown sollen verhindern, dass die SSH-Verbindung während des Neustarts unterbrochen wird, während Ansible noch mit Ihrem Remote-Host verbunden ist.
Warten als Aufgabe
Sie könnten einfach verwenden:
- name: Wait for server to restart
local_action:
module: wait_for
host={{ inventory_hostname }}
port=22
delay=10
become: false
..aber vielleicht bevorzugen Sie {{ ansible_ssh_host }} Variable als Hostname und/oder {{ ansible_ssh_port }} als SSH-Host und -Port, wenn Sie Einträge verwenden wie:
hostname ansible_ssh_host=some.other.name.com ansible_ssh_port=2222
..in Ihrem Inventar (Ansible hosts Datei).
Dadurch wird die Wait_for-Aufgabe auf dem Computer ausgeführt, auf dem Ansible ausgeführt wird. Diese Aufgabe wartet darauf, dass Port 22 auf Ihrem Remote-Host geöffnet wird, und beginnt nach einer Verzögerung von 10 Sekunden.
Neu starten und als Handler warten
Aber ich schlage vor, beide als Handler zu verwenden, nicht als Tasks.
Dafür gibt es zwei Hauptgründe:
-
Wiederverwendung von Code - Sie können einen Handler für viele Aufgaben verwenden. Beispiel: Trigger-Server-Neustart nach Änderung der Zeitzone und nach Änderung des Kernels,
-
nur einmal auslösen - wenn Sie einen Handler für ein paar Aufgaben verwenden und mehr als 1 von ihnen eine Änderung vornehmen => den Handler auslösen, dann wird die Sache, die der Handler tut, nur einmal passieren. Beispiel: Wenn Sie einen httpd-Neustart-Handler an die httpd-Konfigurationsänderung und die Aktualisierung des SSL-Zertifikats angehängt haben, wird httpd im Falle einer Änderung sowohl der Konfiguration als auch des SSL-Zertifikats nur einmal neu gestartet.
Lesen Sie hier mehr über Handler.
Neustart und Warten auf den Neustart als Handler:
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
..und verwenden Sie es in Ihrer Aufgabe in einer Sequenz wie dieser, hier gepaart mit einem Neustart des Server-Handlers:
tasks:
- name: Set hostname
hostname: name=somename
notify:
- Restart server
- Wait for server to restart
Beachten Sie, dass Handler in der Reihenfolge ausgeführt werden, in der sie definiert sind, und nicht in der Reihenfolge, in der sie in notify aufgeführt sind !
Sie sollten die Wait_for-Task so ändern, dass sie als local_action ausgeführt wird, und den Host angeben, auf den Sie warten. Zum Beispiel:
- name: Wait for server to restart
local_action:
module: wait_for
host=192.168.50.4
port=22
delay=1
timeout=300