У меня возникли странные проблемы с моей коробкой (бродяга).

Все работало вчера, и моя пьеса работала нормально.

Сегодня ансибл висит на "сборе фактов"?

Вот подробный вывод:

<5.xxx.xxx.xxx> ESTABLISH CONNECTION FOR USER: deploy
<5.xxx.xxx.xxx> REMOTE_MODULE setup
<5.xxx.xxx.xxx> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-
o', 'ControlPersist=60s', '-o', 'ControlPath=/home/vagrant/.ansible/cp/ansible-s
sh-%h-%p-%r', '-o', 'Port=2221', '-o', 'KbdInteractiveAuthentication=no', '-o',
'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o
', 'PasswordAuthentication=no', '-o', 'User=deploy', '-o', 'ConnectTimeout=10',
'5.xxx.xxx.xxx', "/bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1411372677
.18-251130781588968 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1411372677.18-2
51130781588968 && echo $HOME/.ansible/tmp/ansible-tmp-1411372677.18-251130781588
968'"]

У меня была похожая проблема с пингом Ansible на Vagrant, он просто внезапно завис без причины и ранее работал абсолютно нормально. В отличие от любой другой проблемы, такой как ssh или проблема с соединением, она просто умирает без перерыва.

Одна вещь, которую я сделал, чтобы решить эту проблему, это очистить ~/.ansibleкаталог, и он снова работает. Я не могу выяснить почему, но это действительно решено.

Если вам нужно внести изменения, попробуйте очистить ~/.ansibleпапку перед обновлением Vagrant.

Для меня модуль установочного модуля застрял на мертвой монтировке NFS.

Если вы делаете «df» на своей машине и ничего не происходит, вы можете быть в том же случае.

PS: если вы не можете размонтировать общий ресурс / точку монтирования NFS, попробуйте использовать неверный «umount -l»

Ansible может зависать таким образом по ряду причин, обычно из-за проблемы с подключением или из-за зависания модуля установки. Вот как можно сузить проблему, чтобы вы могли ее решить.

Ansible не может подключиться к хосту назначения

Проблемы с ключом хоста (known_hosts)

1) В более старых версиях Ansible (2.1 или более ранних) Ansible не всегда будет сообщать вам, не существует ли ключ хоста для адресата в источнике или имеется несоответствие.

Решение: попробуйте открыть соединение SSH с теми же параметрами для этого места назначения. Вы можете найти ошибки SSH, которые вам нужно устранить, и тогда команда сработает.

2) Иногда Ansible отображает сообщение о соединении SSH в разгар других состояний, в результате чего Ansible «зависает» при выполнении этой задачи:

Warning: the ECDSA host key for 'myhost' differs from the key for the IP address '10.10.1.10'
Offending key for IP in /etc/ssh/ssh_known_hosts:246
Matching host key in /etc/ssh/ssh_known_hosts:477
Are you sure you want to continue connecting (yes/no)?

В этом случае, просто набрав «да» для столько вопросов SSH, сколько вам было задано, можно продолжить игру. После этого вы можете исправить проблемы root

Проблемы с аутентификацией закрытого ключа

При использовании аутентификации на основе ключей и пароля, другие проблемы включают в себя:

• Закрытый ключ может быть неправильно настроен в пункте назначения
• Закрытый ключ может иметь неправильные разрешения локально (должен быть доступен для чтения только пользователю, выполняющему задание Ansible)

Решение: попробуйте запустить ansible -m ping <destination> -kпроблемный хост - если это не сработает, попробуйте решения проблем с ключами хоста выше.

Ansible не может быстро собрать факты

setupМодуль (при запуске автоматически в начале в ansible-playbookперспективе, или при запуске вручную ansible -m setup <host>) может часто зависать при сборе аппаратных фактов (например , если получать информацию о диске из хостов с высоким I / O, плохая запись монтируемым и т.д.).

Решение: попробуйте запустить ansible -m setup -a gather_subset=!all <destination>. Если это работает, вам следует рассмотреть возможность установки этой строки в вашем ansible.cfg:

gather_subset=!hardware

У меня была похожая проблема с Ansible, висящим в Gathering Facts. Я свел свой сценарий к приглашению без заданий и ролей, и он все еще зависал.

Я нашел 12 зависших процессов в моем списке процессов, которые накопились за день.

/usr/bin/python /tmp/ansible_Jfv4PA/ansible_module_setup.py
/usr/bin/python /tmp/ansible_M2T10L/ansible_module_setup.py

Как только я убил их, он снова начал работать.

Есть много причин, по которым ansible может зависнуть при сборе фактов, но прежде чем идти дальше, вот первый тест, который вы должны выполнить в любой такой ситуации:

ansible -m ping <hostname>

Этот тест просто подключается к хосту и выполняет достаточно кода для возврата:

<hostname> | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

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

Теперь, вот (не исчерпывающий) список вещей, которые могут пойти не так в начале книги игр:

Команда, выполняемая ansible, ожидает интерактивного ввода

Я могу вспомнить, что это происходило в более старых версиях ANSI, где команда ожидала интерактивного ввода, который никогда не поступит, такого как пароль sudo (если вы забыли -Kпереключатель), или принятие нового отпечатка хоста ssh (для новой цели). хост).

Современные версии ansible корректно обрабатывают оба этих случая и немедленно вызывают ошибку для обычных случаев использования, поэтому, если вы сами не делаете такие вещи, как вызов ssh или sudo, у вас не должно быть проблем такого рода. И даже если бы вы это сделали, это было бы после сбора фактов.

Dead ssh master соединение

В журнале отладки, приведенном здесь, есть несколько очень интересных опций, переданных клиенту ssh:

• ControlMaster=auto
• ControlPersist=60s
• ControlPath=/home/vagrant/.ansible/cp/ansible-ssh-%h-%p-%r

Эти параметры описаны в man ssh_config .

По умолчанию ansible постарается проявить смекалку в отношении использования ssh-соединения. Для данного хоста вместо создания нового соединения для каждой задачи в пьесе он откроет его один раз и оставит открытым для всей пьесы (и даже для всех книг).

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

На практике каждое ssh-соединение будет проверять наличие сокета в ~/.ansible/cp/some-host-specific-path. Первое соединение не может найти его, поэтому оно подключается нормально, а затем создает его. Каждое последующее соединение будет просто использовать этот сокет, чтобы пройти через уже установленное соединение.

Даже если установленное соединение, наконец, перестает работать и закрывается после того, как не использовалось достаточно долго, сокет тоже закрывается, и мы возвращаемся к исходной точке.

Все идет нормально.

Иногда, однако, соединение на самом деле умирает, но клиент ssh по-прежнему считает его установленным. Обычно это происходит, когда вы запускаете playbook со своего ноутбука и теряете соединение WiFi (или переключаетесь с WiFi на Ethernet и т. Д.)

Последний пример - ужасная ситуация: вы можете использовать ssh на целевой машине с конфигурацией ssh ​​по умолчанию, но пока ваше предыдущее соединение все еще считается активным, ansible даже не будет пытаться установить новое.

На данный момент мы просто хотим избавиться от этого старого сокета, и самый простой способ сделать это - удалить его:

# Delete all the current sockets (may disrupt currently running playbooks)
rm -r ~/.ansible/cp
# Delete only the affected socket (requires to know which one it is)
rm ~/.ansible/cp/<replace-by-your-socket>

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

• Запуск Playbooks с сервера (с более стабильным подключением к сети, чем у вашего ноутбука)
• Используйте конфигурацию ANSIBLE или непосредственно конфигурацию клиента ssh, чтобы отключить общий доступ к соединению
• Используйте те же ресурсы, но для точной настройки тайм-аутов, чтобы сбой основного соединения фактически превышал время ожидания

Обратите внимание, что на момент написания этой статьи несколько вариантов изменилось (например, мой последний прогон дал мне ControlPath=/home/toadjaune/.ansible/cp/871b533295), но общая идея остается в силе.

На самом деле сбор фактов занимает слишком много времени

В начале каждой игры ansible собирает много информации о целевой системе и помещает ее в факты . Это переменные, которые вы можете затем использовать в своей книге игр, и они обычно очень удобны, но иногда получение этой информации может быть очень долгим (плохие точки монтирования, диски с высокой скоростью ввода-вывода, высокой нагрузкой…)

Это , как говорится, не строго нужны факты , чтобы запустить сборник пьес, и почти наверняка не все из них, так что давайте попробуем отключить то , что нам не нужно. Несколько вариантов для этого:

• Полностью отключить модуль настройки
• Измените конфигурацию модуля настройки, чтобы включить только определенные его части.
  • Через аргументы командной строки
  • Через ANSIBLE файлы конфигурации

В целях отладки действительно удобно вызывать модуль установки непосредственно из командной строки:

ansible -m setup <hostname>

Эта последняя команда должна зависнуть так же, как ваша книга воспроизведения, и, в конечном итоге, время ожидания (или успех). Теперь давайте снова запустим модуль, отключив все, что можем:

ansible -m setup -a gather_subset='!all' <hostname>

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

Если, однако, он работает хорошо (и быстро), то посмотрите документацию к модулю . У вас есть два варианта:

• Ограничьте сбор фактов подмножеством, исключая то, что вам не нужно (см. Возможные значения для gather_subset)
• gather_timeout может также помочь вам решить вашу проблему, предоставив больше времени (хотя это будет исправление ошибки тайм-аута, а не зависание)

Другие вопросы

Очевидно, что другие вещи могут пойти не так, как надо. Несколько указателей, помогающих отладке:

• Используйте максимально допустимый уровень детализации ( -vvvv), так как он покажет вам каждую выполненную команду
• Используйте pingи setupмодули непосредственно из командной строки, как описано выше
• Попробуйте ssh вручную, если ansible -m pingне работает

Дмитрий на что-то идет!

Ansible использует полное доменное имя хоста. Если ваш хост не разрешен в DNS, и у вас нет сопоставления в /etc/hostsansible, будет ждать истечения времени ожидания DNS.

При добавлении ::1 <fqdn>в файл хоста подключаемых компьютеров Ansible сразу же получит полное доменное имя, не обращаясь к DNS.

Обратите внимание, что хост должен искать хосты с него /etc/hosts, это значение по умолчанию для большинства, если не для всех, систем linux, но если ваше редактирование /etc/nsswitch.confтакже может быть проблемой.

Я была такая же проблема. Не получил полезной информации от запуска ansible в подробном режиме.

Сервер был повторно подготовлен перед запуском playbook.

Удаление сервера из списка известных хостов исправило это с помощью приведенной ниже команды.

$ ssh-keygen -f "~/.ssh/known_hosts" -R <hostname>
$ ssh-keygen -f "~/.ssh/known_hosts" -R <ip_address>

Примечание. Необходимо удалить имя хоста и IP-адрес.

Я не знаю, используете ли вы sudo playbook - но я был, и он завис на пароле sudo.

Из документации - вы можете убить это, а затем использовать -K.

Удачи.

Возможно, отпечаток вашей целевой системы изменился, например, при переустановке ОС сервера. Вы должны удалить записи в known_hosts , ansible не будет уведомлять о том, что проблема не является доверенной, она просто застревает именно так, как вы ее описали.

Кажется, что ansible не может аутентифицироваться ... поэтому используйте -k, чтобы ansible запросил пароль сервера ...., как показано ниже:

ansible-playbook  -K -i hosts playbook.yml -vvvv

Несоответствие FQDN и имени хоста также может привести к зависанию. Я использовал полное доменное имя с доменом, отличным от имени домена. После того, как оба равны , ansible работает отлично. Возможно, ANSIBL сравнивает FQDN и имя хоста перед выполнением задач на удаленном хосте. Надеюсь, это поможет!

Я решил эту проблему, сбросив бродячий ящик

vagrant destroy
vagrant up

В моем случае ansible перестал работать в середине задачи. Причина в том, что мой ssh-agent перестал работать ( ssh-add -lничего не возвращал). Я перезапустил все, и это снова заработало. Поэтому проверьте, правильно ли работает ваш ssh-агент ( ssh-add -lне должен застрять).

Удаление в ~/.ansibleодиночку не сделало это для меня. Поэтому, чтобы проверить, что находится в этом каталоге, я просто выполнил команду ctrl-z (переведите процесс в спящий режим) и проверил, а затем продолжил процесс ansible через fg. Я ничего не удалил в этом случае. но после этого просто продолжил. Так что я только что попробовал ctrl-z-> fgодин, и это тоже сработало. Похоже на танец дождя, но если кто-то застрял, пожалуйста, попробуйте это.

Я устранил причину этой проблемы, следуя совету Почему моя книга-игра висит в «Сбор фактов»? Сообщение блога.

Это может быть упрощено до:

1. Установите, DEFAULT_KEEP_REMOTE_FILES=yesчтобы сохранить команды и включить-vvvv

2. Запустите playbook снова.

3. Когда воспроизведение застревает, скопируйте последнюю напечатанную команду оболочки (часть после /bin/sh -c)

4. Войдите на сервер через ssh.

5. Используйте straceдля воспроизведения последнего шага игры. Команда шага копируется из -vvvвывода. Например:strace -f /bin/sh -c "echo BECOME-SUCCESS-ltxvshvezrnmumzdprccoiekhjheuwxt; /usr/bin/python /home/user/.ansible/tmp/ansible-tmp-1527099315.31-224479822965785/setup.py"

6. Проверьте, на каком вызове «натянутый» шаг застрял и исправьте его :)

В моем случае это был недоступный сетевой диск ...

Пароль Судо является проблемой. Удостоверьтесь, что (1) вы можете выдать 'sudo что - нибудь ' на недавно открытом терминале (где пароль не кэшируется), не предоставив (2), чтобы куколка не отменила ваши предыдущие ручные изменения "sudoers".