Я использую сервер Ansible AWX 1.0.7.2, использующий Ansible 2.6.2 в Ubuntu 18.04.1 LTS.
Я пытаюсь создать сборник воспроизведения Ansible (используемый в AWX), который выполняет следующие действия:
Моя рабочая тетрадь работает на большинстве хостов. Однако в двух из моих экземпляров AMI создаются, но после этого хосты отображаются как недоступные, а игры после них не работают.
Я использую эту книгу:
---
- hosts: all
remote_user: "{{ remote_user }}"
tasks:
- name: Create an AMI for backup
ec2_ami:
instance_id: "{{ instance_id }}"
name: "{{ inventory_hostname }}-{{ ansible_date_time.iso8601_basic_short }}"
tags:
Name: "{{ inventory_hostname }}-{{ ansible_date_time.iso8601_basic_short }}"
register: result
- name: Pause for 120 seconds to allow instance to become reachable again
pause: seconds=120
- include_tasks: update-RedHat.yml
when: (ansible_os_family == 'RedHat' and result.changed|default(false)|bool == true)
- include_tasks: update-Debian.yml
when: (ansible_os_family == 'Debian' and result.changed == true)
И результат, на котором сценарий не работает:
fatal: [testserver.mydomain.com]: UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n 7 Dec 2017\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug1: /etc/ssh/ssh_config line 19: Applying options for *\r\ndebug1: auto-mux: Trying existing master\r\ndebug2: fd 3 setting O_NONBLOCK\r\ndebug2: mux_client_hello_exchange: master version 4\r\ndebug3: mux_client_forwards: request forwardings: 0 local, 0 remote\r\ndebug3: mux_client_request_session: entering\r\ndebug3: mux_client_request_alive: entering\r\ndebug3: mux_client_request_alive: done pid = 3353\r\ndebug3: mux_client_request_session: session request sent\r\ndebug1: mux_client_request_session: master session id: 2\r\ndebug3: mux_client_read_packet: read header failed: Broken pipe\r\ndebug2: Control master terminated unexpectedly\r\nShared connection to testserver.mydomain.com closed.\r\n",
"unreachable": true
}
В обоих случаях, если экземпляры, которые не работают, имеют большие (256 ГБ) подключенные тома и становятся доступными в течение 30-60 секунд при создании образа, и я предполагаю, что это проблема. Однако несколько методов вставки задержки, похоже, не помогают - кажется, что ansible проверяет подключение немедленно, независимо от того, что я делаю.
Вы можете увидеть паузу после создания изображения. Это работает на других хостах, но на отказавших он не заходит так далеко, поскольку уже отображается как недостижимый, прежде чем доходит до этого.
Я попробовал это после этапа создания изображения:
- name: wait for host to come back up
wait_for: host = {{ inventory_hostname }} port=22 delay=60 timeout=180 state=started
Но получил тот же сбой и сообщение.
Кажется, ошибка находится в задаче ec2_ami
, поэтому я также попытался вставить wait
:
---
- hosts: all
remote_user: "{{ remote_user }}"
wait: yes
tasks:
- name: Create an AMI for backup
ec2_ami:
instance_id: "{{ instance_id }}"
name: "{{ inventory_hostname }}-{{ ansible_date_time.iso8601_basic_short }}"
tags:
Name: "{{ inventory_hostname }}-{{ ansible_date_time.iso8601_basic_short }}"
register: result
Но это тоже не имело значения, экземпляр по-прежнему отображается как недоступный.
Есть ли способ обойти это?
Но я не думаю, что дело заходит так далеко - игра create AMI демонстрирует провал, хотя на самом деле она создает AMI. Во всяком случае, я пробовал с этим на 300 и той же проблеме.
Пробовать использовать более длинный
timeout
? По умолчанию в модулеwait_for
установлено значение 300 с, но вы снизили его до 180 с, что уже не работало сpause
. Поставь на миллион и иди обедать. Посмотри, сколько времени это займет.