Este ha sido un problema bastante irritante ahora que pensé en finalmente preguntarle a la comunidad en general cuál podría ser una posible solución. Es aún más irritante que parezca que soy el único que experimenta este problema.
Esencialmente, en cualquier momento en CentOS 7.x, las configuraciones de sshd o cualquier parte de sshd se modifican y el demonio se reinicia/recarga en algún "punto aleatorio" en los siguientes 3 minutos, todas las conexiones ssh se reinician y luego ese servidor se reinicia. inalcanzable durante unos segundos a través de ssh.
Esto es especialmente un problema para ansible, ya que a veces necesita hacer estos cambios él mismo en sshd y también recargarlo (por ejemplo, en las nuevas compilaciones del servidor CentOS 7x). Pero luego, en jugadas futuras, simplemente no puede conectarse aleatoriamente a ssh, y explota el resto del libro de jugadas/jugadas para ese host con el que no se pudo contactar. Esto es especialmente malo para un patrón de host grande, ya que algunos se completarán aleatoriamente, pero los demás fallarán en varias etapas del libro de jugadas después de manipular sshd. Es de destacar que nada de eso ocurre en CentOS 5x, 6x o incluso en Solaris.
Lo mejor que puedo hacer para evitar esto es crear una espera de 90 segundos después de cualquier cambio en sshd, e incluso esto no es totalmente infalible. Sin embargo, hace que esos libros de jugadas tarden más de 20 minutos en ejecutarse si se invocan entre 7 y 8 veces.
Aquí hay algunos datos sobre este entorno:
Todas las instalaciones nuevas provienen de DVD ISO oficiales. Cada servidor es un invitado Hyper-V 2012. Cada servidor que tiene este problema es CentOS 7.x.
A continuación se muestran algunos resultados reales de los problemas y algunas soluciones trilladas:
La falla:
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}]}
Ejemplo de uno de los cambios en 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
El siguiente controlador:
- name: sshd reload Linux 7x
systemd:
state: restarted
daemon_reload: yes
name: sshd
Finalmente, mi gueto solucionó el problema para intentar solucionar este problema:
- 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")
Tiene que haber una solución mejor que la que se me ocurrió a mí, y es difícil creer que todos los demás se enfrentan a esto y también lo soportan. ¿Hay algo que deba configurar en los servidores CentOS 7.x para evitar esto? ¿Hay algo en ansible que sea necesario para lidiar con esto, como múltiples intentos de ssh por jugada en el primer error?
¡Gracias de antemano!
Respuesta1
Esto parece ser un problema común. Parche para reintentos ssh de Ansible de 2016
Una mejor solución podría ser esperar a que sshd esté listo para conectarse. hilo originalcon esta solución de código ansible:
[Tareas de creación de VM...]
- nombre: Espere a que se complete la instalación Kickstart y que la VM se reinicie local_action: wait_for host={{ vm_hostname }} port=22 delay=30 timeout=1200 state=started
- nombre: Ahora configure la VM...
Respuesta2
En lugar de utilizar el systemdmódulo, pruebe el servicemódulo:
- name: Restart secure shell daemon post configuration
service:
name: sshd
state: restarted