Sempre que o ansible faz alterações no sshd no CentOS7, uma reprodução futura aleatória não pode ser conectada

Este já foi um problema bastante irritante, agora que pensei em finalmente perguntar à comunidade em geral qual seria a solução possível. É ainda mais irritante que pareço ser o único a enfrentar esse problema.

Essencialmente, a qualquer momento no CentOS 7.x, as configurações do sshd ou qualquer parte do sshd são modificadas e o daemon é reiniciado / recarregado em algum "ponto aleatório" nos próximos 3 minutos, as conexões ssh são redefinidas e o servidor é reiniciado. inacessível por alguns segundos via ssh.

Isso é especialmente um problema para o ansible, pois, às vezes, é necessário fazer essas alterações no sshd e também recarregá-lo (por exemplo, nas novas compilações do servidor CentOS 7x). Mas, em futuras reproduções, ele aleatoriamente não pode se conectar ao ssh e explode o restante do manual / reproduções para o host que não conseguiu ser contatado. Isso é especialmente ruim para um padrão de host grande, pois alguns serão concluídos aleatoriamente, mas os outros falharão em vários estágios ao longo do manual após a manipulação do sshd. É importante notar que nada disso ocorre no CentOS 5x, 6x ou mesmo no Solaris.

O melhor que posso fazer para evitar isso é criar uma espera de 90 segundos após qualquer alteração no sshd, e mesmo isso não é totalmente infalível. Faz com que esses manuais demorem mais de 20 minutos para serem executados, se forem invocados de 7 a 8 vezes.

Aqui estão alguns fatos sobre esse ambiente:

Todas as novas instalações são de DVDs oficiais da ISO. Todo servidor é um convidado do hyper-v 2012 Todo servidor que tem esse problema é o CentOS 7.x

Aqui estão alguns resultados reais dos problemas e algumas soluções fraudulentas:

A falha:

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}]}

Exemplo de uma das alterações no 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

O seguinte manipulador:

- name: sshd reload Linux 7x
   systemd:
     state: restarted
     daemon_reload: yes
     name: sshd

Finalmente, meu gueto resolveu tentar explicar esse 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")

Tem que haver uma solução melhor do que a que eu criei, e é difícil acreditar que todos os outros encontram isso e também o suportam. Preciso configurar algo nos servidores CentOS 7.x para evitar isso? Existe algo em ansible que é necessário para lidar com isso, como várias tentativas ssh por peça na primeira falha?

Desde já, obrigado!

Em vez de usar o systemdmódulo, tente o servicemódulo:

- name: Restart secure shell daemon post configuration
  service: 
    name: sshd
    state: restarted

Este parece ser um problema comum. Patch para novas tentativas de Ansible ssh a partir de 2016

Uma solução melhor pode ser esperar o sshd estar pronto para se conectar. Tópico original com esta solução de código ansible:

[Tarefas de criação de VM ...]

  - nome: aguarde a instalação do Kickstart concluir e a VM reiniciar local_action: wait_for host = {{vm_hostname}} port = 22 delay = 30 timeout = 1200 timeout = 1200 state = iniciou

  - nome: Agora configure a VM ...