Ilekroć ansible wprowadza zmiany w sshd w CentOS7, losowa gra w przyszłości nie może się połączyć

Był to wystarczająco irytujący problem, kiedy pomyślałem, że w końcu zapytam całą społeczność, jakie jest możliwe rozwiązanie. Jeszcze bardziej irytujące jest to, że wydaje mi się, że tylko ja mam ten problem.

Zasadniczo, w dowolnym momencie w CentOS 7.x, konfiguracje sshd lub dowolna część sshd zostanie zmodyfikowana, a demon zostanie zrestartowany / ponownie załadowany w jakimś „losowym punkcie” w ciągu najbliższych 3 minut, połączenia ssh resetują się, a następnie ten serwer jest nieosiągalny przez kilka sekund przez ssh.

Jest to szczególnie problem dla ansible, ponieważ musi on czasami dokonywać tych zmian w sshd, a także przeładowywać go (na przykład w nowych wersjach serwera CentOS 7x). Ale potem w przyszłości gra po prostu losowo nie może połączyć się z ssh, i wysadza resztę podręcznika / gier dla tego hosta, z którym nie udało się skontaktować. Jest to szczególnie złe w przypadku dużych wzorców hostów, ponieważ niektóre z nich zostaną losowo ukończone, ale inne zawiodą na różnych etapach w podręczniku po manipulacji sshd. Należy zauważyć, że nic takiego nie występuje w CentOS 5x, 6x, a nawet w Solarisie.

Najlepszym sposobem, aby tego uniknąć, jest utworzenie 90-sekundowego oczekiwania po jakichkolwiek zmianach w sshd, a nawet to nie jest całkowicie niezawodne. Sprawia, że ​​uruchomienie tych podręczników zajmuje ponad 20 minut, jeśli zostanie wywołane 7-8 razy.

Oto kilka faktów na temat tego środowiska:

Wszystkie nowe instalacje pochodzą z oficjalnych płyt DVD ISO. Każdy serwer jest gościem hyper-v 2012 Każdy serwer, na którym występuje ten problem, to CentOS 7.x

Oto niektóre rzeczywiste skutki problemów i niektóre zhackowane rozwiązania:

Awaria:

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

Przykład jednej ze zmian w 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

Następujący moduł obsługi:

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

Wreszcie moja poprawka do getta próbuje rozwiązać ten problem:

- 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")

Musi być lepsze rozwiązanie niż to, co wymyśliłem, i trudno uwierzyć, że wszyscy inni się z tym spotykają i też to znoszą. Czy jest coś, co muszę skonfigurować na serwerach CentOS 7.x, aby temu zapobiec? Czy jest coś, co jest potrzebne, aby sobie z tym poradzić, takie jak wielokrotne próby ssh na grę przy pierwszej awarii?

Z góry dziękuję!

Zamiast używać systemdmodułu, wypróbuj servicemoduł:

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

To wydaje się być powszechnym problemem. Poprawka do ponownych prób Ansible ssh z 2016 roku

Lepszym rozwiązaniem może być poczekanie, aż sshd będzie gotowy do połączenia. Oryginalny wątek z tym rozwiązaniem kodu ansible:

[Zadania tworzenia maszyn wirtualnych ...]

  - name: Poczekaj na zakończenie instalacji Kickstart i maszynę wirtualną do ponownego uruchomienia lokalnego działanie: wait_for host = {{vm_hostname}} port = 22 opóźnienie = 30 limit czasu = 1200 stan = rozpoczęty

  - nazwa: Teraz skonfiguruj maszynę wirtualną ...