Dieses Problem ist mittlerweile so ärgerlich, dass ich endlich die Community fragen wollte, was eine mögliche Lösung sein könnte. Noch ärgerlicher ist, dass ich anscheinend der Einzige bin, der dieses Problem hat.
Im Wesentlichen werden jedes Mal, wenn in CentOS 7.x die SSHD-Konfigurationen oder ein beliebiger Teil von SSHD geändert wird und der Daemon an einem „zufälligen Punkt“ innerhalb der nächsten 3 Minuten neu gestartet/neu geladen wird, alle SSH-Verbindungen zurückgesetzt und der Server ist dann für einige Sekunden per SSH nicht erreichbar.
Dies ist insbesondere für Ansible ein Problem, da es diese Änderungen manchmal selbst an SSHD vornehmen und es auch neu laden muss (beispielsweise in neuen CentOS 7x-Server-Builds). In zukünftigen Spielen kann es dann jedoch zufällig keine Verbindung zu SSH herstellen und es sprengt den Rest des Playbooks/der Plays für den Host, der nicht kontaktiert werden konnte. Dies ist insbesondere für ein großes Host-Muster schlecht, da einige zufällig abgeschlossen werden, die anderen jedoch in verschiedenen Phasen des Playbooks fehlschlagen, nachdem SSHD manipuliert wurde. Es ist bemerkenswert, dass nichts dergleichen in CentOS 5x, 6x oder sogar unter Solaris vorkommt.
Das Beste, was ich tun kann, um dies zu vermeiden, ist, nach jeder Änderung an sshd eine Wartezeit von 90 Sekunden einzuführen, und selbst das ist nicht absolut narrensicher. Wenn diese Playbooks 7-8 Mal aufgerufen werden, dauert die Ausführung jedoch mehr als 20 Minuten.
Hier einige Fakten zu dieser Umgebung:
Alle Neuinstallationen erfolgen von offiziellen ISO-DVDs. Jeder Server ist ein Hyper-V 2012-Gast. Jeder Server, der dieses Problem hat, ist CentOS 7.x.
Hier sind einige tatsächliche Ausgaben der Probleme und einige abgedroschene Lösungen:
Der Fehlschlag:
fatal: [voltron]: UNREACHABLE! => {"changed": false, "msg": "All items completed", "results": [{"_ansible_item_result": true, "item": ["rsync", "iotop", "bind-utils", "sysstat.x86_64", "lsof"], "msg": "Failed to connect to the host via ssh: Shared connection to voltron closed.\r\n", "unreachable": true}]}
Beispiel für eine der Änderungen an sshd:
- name: Configure sshd to disallow root logins for security purposes on CentOS and Redhat 7x servers.
lineinfile:
backup: yes
dest: /etc/ssh/sshd_config
regexp: '^(#PermitRootLogin)'
line: "PermitRootLogin no"
state: present
when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")
notify: sshd reload Linux 7x
Der folgende Handler:
- name: sshd reload Linux 7x
systemd:
state: restarted
daemon_reload: yes
name: sshd
Zum Schluss noch mein Ghetto-Fix, um dieses Problem zu lösen:
- name: Wait a bit on CentOS/Redhat 7x servers to ensure changes don't mess up ssh and screw up further plays.
pause:
seconds: 90
when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")
Es muss eine bessere Lösung geben als die, die ich mir ausgedacht habe, und es ist schwer zu glauben, dass alle anderen das auch erleben und sich damit abfinden. Muss ich in CentOS 7.x-Servern etwas konfigurieren, um dies zu verhindern? Gibt es etwas in Ansible, das erforderlich ist, um damit umzugehen, z. B. mehrere SSH-Versuche pro Spiel beim ersten Fehler?
Dank im Voraus!
Antwort1
Dies scheint ein häufiges Problem zu sein. Patch für Ansible SSH-Wiederholungen ab 2016
Eine bessere Lösung könnte darin bestehen, zu warten, bis SSHD zur Verbindung bereit ist. Ursprünglicher Threadmit dieser Ansible-Code-Lösung:
[Aufgaben zur VM-Erstellung...]
- Name: Warten Sie, bis die Kickstart-Installation abgeschlossen ist und die VM neu gestartet wurde. local_action: wait_for host={{ vm_hostname }} port=22 delay=30 timeout=1200 state=started
- Name: Konfigurieren Sie jetzt die VM …
Antwort2
Versuchen Sie anstelle des systemdModuls das servicefolgende Modul:
- name: Restart secure shell daemon post configuration
service:
name: sshd
state: restarted