Este tem sido um problema tão irritante agora que pensei em finalmente perguntar à comunidade em geral qual poderia ser uma solução possível. É ainda mais irritante que eu pareça ser o único com esse problema.
Essencialmente, a qualquer momento no CentOS 7.x, configurações sshd ou qualquer parte do sshd são modificadas, e o daemon é reiniciado/recarregado em algum "ponto aleatório" nos próximos 3 minutos, todas as conexões ssh são redefinidas e então esse servidor é inacessível por alguns segundos via ssh.
Isso é especialmente um problema para o ansible, pois às vezes ele precisa fazer essas alterações no sshd e também recarregá-lo (por exemplo, em novas compilações de servidor CentOS 7x). Mas então, em jogadas futuras, ele aleatoriamente não consegue se conectar ao ssh, e ele explode o resto do manual/jogos para aquele host que não foi 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. É digno de nota 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. Isso 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 este ambiente:
Todas as novas instalações são de DVDs ISO oficiais. Todo servidor é um convidado do Hyper-V 2012. Todo servidor que apresenta esse problema é o CentOS 7.x
Aqui estão alguns resultados reais dos problemas e algumas soluções banais:
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, minha correção do gueto para 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 aquela que eu encontrei, e é difícil acreditar que todo mundo encontra isso e também tolera isso. Há algo que preciso configurar nos servidores CentOS 7.x para evitar isso? Existe algo no ansible necessário para lidar com isso, como várias tentativas de ssh por jogo na primeira falha?
Desde já, obrigado!
Responder1
Este parece ser um problema comum. Patch para tentativas ssh do Ansible de 2016
Uma solução melhor pode ser esperar que o sshd esteja pronto para se conectar. Tópico originalcom esta solução de código ansible:
[Tarefas de criação de VM...]
- nome: Aguarde a conclusão da instalação do Kickstart e a reinicialização da VM local_action: wait_for host={{ vm_hostname }} port=22 delay=30 timeout=1200 state=started
- nome: Agora configure a VM...
Responder2
Em vez de usar o systemdmódulo, experimente o servicemódulo:
- name: Restart secure shell daemon post configuration
service:
name: sshd
state: restarted