У мене виникають незвичайні проблеми з моїм візитним вікном (бродячий).

Все працювало вчора, і моя ігрова книга працювала чудово.

Сьогодні ансібі висить на "зборі фактів"?

Ось детальний висновок:

<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 ping на Vagrant, вона просто раптом застрягла без причин і раніше працювала абсолютно чудово. На відміну від будь-якого іншого випуску, наприклад, ssh чи підключення, він просто назавжди помре без часу.

Одне, що я зробив, щоб вирішити цю проблему, - це очистити ~/.ansibleкаталог, і він просто працює знову. Я не можу дізнатися чому, але це все вирішилося.

Якщо у вас з’явилися зміни, щоб його ще раз спробуйте очистити ~/.ansibleпапку, перш ніж оновити Vagrant.

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

Якщо ви зробите "df" на своїй машині, і нічого не трапиться, ви, можливо, будете в одному випадку.

PS: якщо ви не можете перемацати NFS share / mountpoint, подумайте про використання неправильного "umount -l"

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

Відповідь не може підключитися до хоста призначення

Проблеми з ключем хоста (відомі_хости)

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, як вам було задано, дозволить продовжувати гру. Після цього ви зможете виправити основні проблеми відомих_хостів.

Проблеми з автентифікацією приватних ключів

Якщо використовується автентифікація на основі ключа проти пароля, інші проблеми включають:

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

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

Відповідь не може швидко зібрати факти

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 -m ping <hostname>

Цей тест просто підключається до хоста та виконує достатній код для повернення:

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

Якщо це працює, ви можете значною мірою виключити будь-які проблеми з налаштуванням або підключенням, оскільки це доводить, що ви могли вирішити цільове ім'я хоста, відкрити з'єднання, перевірити автентифікацію та виконати модуль ансибілізації за допомогою віддаленого інтерпретатора python.

Тепер ось (не вичерпний) список речей, які можуть піти не так на початку ігрової книги:

Команда, виконана ansible, чекає інтерактивного введення

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

Сучасні версії ansible вирішують обидва ці випадки витончено і негайно викликають помилку для звичайних випадків використання, тому, якщо ви не робите такі речі, як виклик ssh або sudo самостійно, у вас не повинно виникати подібних проблем. І навіть якби ви це зробили, це було б після факту збору.

Мертве з'єднання 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-клієнт все ще вважає це встановленим. Зазвичай це відбувається, коли ви запускаєте книгу зі свого ноутбука, і ви втрачаєте WiFi-з'єднання (або переходите з WiFi на Ethernet тощо).

Цей останній приклад - жахлива ситуація: ви можете пришпилити до цільової машини за допомогою конфігурації 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>

Це ідеально підходить для виправлення одним ударом, але якщо це трапляється занадто часто, можливо, вам доведеться шукати довгострокові виправлення. Ось кілька покажчиків, які можуть допомогти досягти цієї мети:

• Запустіть ігрові книжки з сервера (способом мережевого з’єднання стабільнішим, ніж у вашого ноутбука)
• Використовуйте конфігурацію 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 використовує FQDN хоста. Якщо ваш хост не /etc/hostsвирішений для DNS і у вас немає відображення в ansible, буде чекати, поки DNS закінчиться.

Додавши ::1 <fqdn>у файл-хост машин, до яких ви підключаєте Ansible, ви отримаєте FQDN негайно, не проходячи через DNS.

Зауважте, що хост повинен шукати хости з /etc/hosts, це за замовчуванням для більшості, якщо не всіх, Linux-систем, але якщо це /etc/nsswitch.confтакож може бути проблемою.

У мене було те саме питання. Немає корисної інформації від запуску ansible у багатослівному режимі.

Перш ніж запустити програму, сервер був переглянуто.

Видалення сервера із відомого списку хостів виправлено це за допомогою команди нижче.

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

Примітка. Вам потрібно видалити і ім’я хоста, і ip адресу

Я не знаю, чи використовуєте ви програму «Судо» - але я був, і він висів на паролі судо.

З документації - ви можете це вбити, а потім також використовувати -K.

Удачі.

Можливо, відбиток вашої цільової системи змінився, наприклад, при перевстановці ОС сервера. Ви повинні видалити записи в known_hosts , анзібль буде НЕ повідомить про те , що ненадійний запис є питання, він просто застрягне саме так , як ви описуєте.

Здається, що ansible не може автентифікуватись ... тому використовуйте -k, щоб дозволити ansible запитувати пароль сервера .... як показано нижче:

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

Невідповідність FQDN та імені хоста також може спричинити відповідальну трансляцію. Я використав FQDN з доменом, який відрізняється від домену імені хоста. Після того, як обидва рівні , відповідальний працює ідеально. Можливо, відповідальний порівнює FQDN та ім'я хоста перед виконанням завдань на віддаленому хості. Сподіваюся, це допомагає!

Я вирішив це питання шляхом повторного скидання бродячої коробки

vagrant destroy
vagrant up

У моєму випадку ansible перестав працювати посеред завдання. Причина полягала в тому, що мій ssh-агент перестав працювати ( ssh-add -lнічого не повертав). Я все перезапустив, і це спрацювало знову. Тому перевірте, чи працює ваш ssh-агент належним чином ( ssh-add -lне повинен застрягати).

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

Я вирішив причину цього питання, дотримуючись порад, чому мій альбом-псевдонім висить у "Збір фактів"? допис у блозі.

Його можна спростити:

1. Встановіть DEFAULT_KEEP_REMOTE_FILES=yesдля збереження команд та включення-vvvv

2. Запустіть програму знову.

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