Всякий раз, когда ansible вносит изменения в sshd в CentOS7, случайная будущая игра не может подключиться

Всякий раз, когда ansible вносит изменения в sshd в CentOS7, случайная будущая игра не может подключиться

Это было достаточно раздражающей проблемой, поэтому я подумал, что наконец-то спрошу сообщество в целом, какое возможное решение может быть. Еще больше раздражает то, что я, похоже, единственный, кто сталкивается с этой проблемой.

По сути, в любой момент в CentOS 7.x, если конфигурации sshd или любая часть sshd изменяются, и демон перезапускается/перезагружается в какой-то «случайный момент» в течение следующих 3 минут, все ssh-соединения сбрасываются, а затем этот сервер становится недоступным через ssh в течение нескольких секунд.

Это особенно проблема для ansible, поскольку иногда ему самому нужно вносить эти изменения в sshd, а также перезагружать его (например, в новых сборках сервера CentOS 7x). Но затем в будущих играх он просто случайно не может подключиться к ssh, и он взрывает остальную часть playbook/plays для того хоста, с которым не удалось связаться. Это особенно плохо для большого шаблона хоста, так как несколько будут случайным образом завершены, но другие дадут сбой на разных этапах playbook после манипуляций с sshd. Следует отметить, что ничего подобного не происходит в CentOS 5x, 6x или даже в Solaris.

Лучшее, что я могу сделать, чтобы избежать этого, — это создать 90-секундное ожидание после любых изменений в sshd, и даже это не полностью надежно. Это заставляет эти плейбуки работать более 20 минут, если они вызываются 7-8 раз.

Вот некоторые факты об этой среде:

Все новые установки с официальных ISO DVD. Каждый сервер — гостевой hyper-v 2012. Каждый сервер, на котором возникла эта проблема, — CentOS 7.x.

Вот некоторые реальные результаты проблем и некоторые банальные решения:

Провал:

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

Пример одного из изменений в 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

Следующий обработчик:

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

Наконец, мой гетто-фикс, который попытается объяснить эту проблему:

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

Должно быть лучшее решение, чем то, что придумал я, и трудно поверить, что все остальные сталкиваются с этим и мирятся с этим. Нужно ли что-то настроить на серверах CentOS 7.x, чтобы предотвратить это? Есть ли что-то в ansible, что нужно для решения этой проблемы, например, несколько попыток ssh на воспроизведение при первой неудаче?

Заранее спасибо!

решение1

Похоже, это распространенная проблема. Патч для повторных попыток Ansible ssh от 2016 года

Лучшим решением может быть ожидание готовности sshd к подключению. Оригинальная темас помощью этого решения на основе кода ansible:

[Задачи создания ВМ...]

  - name: Дождитесь завершения установки Kickstart и перезагрузки виртуальной машины local_action: wait_for host={{ vm_hostname }} port=22 delay=30 timeout=1200 state=started

  - имя: Теперь настройте виртуальную машину...

решение2

Вместо того, чтобы использовать systemdмодуль, попробуйте serviceмодуль:

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

Связанный контент