Comment redémarrer CentOS 7 avec Ansible?
Je suis en train de redémarrer le serveur exécutant CentOS 7
sur VirtualBox. J'utilise cette tâche:
- name: Restart server
command: /sbin/reboot
async: 0
poll: 0
ignore_errors: true
Serveur est redémarré, mais j'ai cette erreur:
TASK: [common | Restart server] ***********************************************
fatal: [rolcabox] => SSH Error: Shared connection to 127.0.0.1 closed.
It is sometimes useful to re-run the command using -vvvv, which prints SSH debug output to help diagnose the issue.
FATAL: all hosts have already failed -- aborting
Ce que je fais mal? Comment puis-je résoudre ce problème?
- En fonction de la réponse fournie par Marcin Skarbek, j'ai préparé et publié à Ansible Galaxy rôle que l'utilisation de cette méthode. Le rôle de Redémarrer Et Attendre, vous pouvez trouver ici. Merci pour l'aide, feedbacks sont les bienvenus.
- En raison de Ansible du rythme rapide de développement, les plus anciens les réponses ne sont pas de travail pour moi. Veuillez vous référer à ma réponse.
Vous devez vous connecter pour publier un commentaire.
Vous êtes susceptible de ne rien faire vraiment mal, c'est juste que /sbin/reboot est d'arrêter le serveur si rapidement que le serveur est la démolition de la connexion SSH utilisé par Ansible avant Ansible lui-même pouvez la fermer. Comme un résultat Ansible est signalé une erreur parce qu'il voit la connexion SSH échoue pour une raison potentielle.
Ce que vous voulez faire pour contourner ce problème est de passer de l'utilisation de
/sbin/reboot
à l'aide de/sbin/shutdown
à la place. La commande shutdown vous permet de passer un moment, et lorsqu'il est combiné avec le-r
interrupteur, il va effectuer un reboot plutôt que de s'arrêter. De sorte que vous pourriez vouloir essayer une tâche comme ceci:Cela va retarder le redémarrage du serveur pendant 1 minute, mais ce faisant, il devrait donner Ansible assez de temps pour fermer la connexion SSH lui-même, évitant ainsi les erreurs que vous êtes en train d'arriver.
Failed to parse time specification: +1m
d'erreur, donc j'ai dû remplacer+1m
avec+1
.Après le redémarrage de la tâche, vous devez avoir une
local_action
de la tâche qui attend l'hôte distant pour terminer le redémarrage de l'ordinateur, sinon, la connexion ssh sera résilié et le playbook.J'ai aussi écrit un billet de blog sur la réalisation d'une solution similaire: https://oguya.github.io/linux/2015/02/22/ansible-reboot-servers/
async: 1
. Ansible 2.3 ajoute l'utilewait_for_connection delay=20
Une autre solution:
systemd-run
crée "à la volée" nouveau service qui va commencersystemctl reboot
après 10 sec de retard (--on-active=10
).delay=30
danswait_for
pour ajouter un supplément de 20 sec pour être sûr que l'hôte a effectivement commencé le redémarrage.Aucune des solutions ci-dessus a travaillé de manière fiable pour moi.
La délivrance d'un
/sbin/reboot
accidents de la lecture (de la connexion SSH est fermé avant d'ansible terminé la tâche, il se bloque, même avecignore_errors: true
) et/usr/bin/systemd-run --on-active=2 /usr/bin/systemctl reboot
ne redémarre pas après 2 secondes, mais après un certain temps entre 20 secondes et une minute, de sorte que le retard est parfois pas suffisant et ce n'est pas prévisible.Aussi je ne veux pas attendre pendant quelques minutes tandis qu'un serveur cloud peut redémarrer dans quelques secondes.
Voici donc ma solution:
C'est le
shell: ( sleep 3 && /sbin/reboot & )
ligne qui fait le tour.À l'aide de
( command & )
en script shell exécute un programme en arrière-plan et le détache: la commande réussir immédiatement, mais persiste après le shell est détruit.Ansible obtenir sa réponse immédiatement et le serveur redémarre 3 secondes plus tard.
Ansible se développe rapidement et les plus âgés les réponses n'ont pas de travail pour moi.
J'ai trouvé deux questions:
Il est préférable de lancer:
nohup bash -c "sleep 2s && shutdown -r now" &
Cela permet de lancer un shell avec le
sleep
&&shutdown
, mais n'allons pas attendre la coquille à la fin de la dernière&
. Le sommeil va donner un peu de temps pour l'Ansible tâche à la fin avant de la redémarrer et lanohup
permettra de garantir que bash n'a pas été tué lorsque la tâche se termine.wait_for
module n'est pas fiable en attente pour le service SSH.Il détecte l'ouverture de port, probablement par systemd, mais quand la prochaine tâche est exécutée, SSH n'est pas encore prête.
Si vous utilisez Ansible 2.3+, wait_for_connection fonctionne de manière fiable.
Le meilleur "redémarrage et d'attendre" en mon expérience (je suis en utilisant Ansible 2.4) est la suivante:
J'ai le nohup commande à partir de: https://github.com/keithchambers/microservices-playground/blob/master/playbooks/upgrade-packages.yml
J'ai édité ce message à:
Encore un autre (combinée d'autres réponses) version:
Au temps de redémarrage toutes les connexions ssh sont fermés. C'est pourquoi l'Ansible tâche échoue. Le
ignore_errors: true
oufailed_when: false
ajouts ne sont plus de travail que d'Ansible 1.9.x parce que la manipulation des connexions ssh a changé et une connexion fermée maintenant est une erreur fatale qui ne peuvent pas être pris pendant la lecture.La seule façon que j'ai compris comment faire, c'est d'exécuter un shell local tâche qui puis démarre une nouvelle connexion ssh, qui ensuite peut échouer.
Je suis en utilisant Ansible 2.5.3.
Code ci-dessous fonctionne avec une grande simplicité,
Vous pouvez redémarrer immédiatement, puis insérer un retard si votre machine met du temps à descendre:
Ensuite sondage pour faire le playbook de revenir dès que possible:
Cela rendra le playbook de revenir dès que possible après le redémarrage de l'ordinateur.
Solution suivante fonctionne pour moi parfait:
Sommeil est nécessaire car ansible nécessite quelques seconde pour clore la connexion.
Excellent post sur ce problème qui a été écrit ici:
https://www.jeffgeerling.com/blog/2018/reboot-and-wait-reboot-complete-ansible-playbook
si vous utilisez Ansible version >=2.7, vous pouvez utiliser
reboot
module comme décrit iciLe synopsis de l'
reboot
module lui-même:D'une manière simple, vous pouvez définir une tâche simple comme ceci:
Mais vous pouvez ajouter quelques paramètres comme
test_command
pour tester si votre serveur est prêt à prendre de nouvelles tâchesEspérons que cette aide!