Ansible UNREACHABLE: отделяем SSH от ошибки become

Playbook завершает работу с UNREACHABLE, хотя администратор может войти на сервер вручную. Разница часто в параметрах: Ansible выбрал другой адрес, пользователя, ключ или конфигурацию SSH. Добавлять become сразу рано: повышение прав обычно происходит после установления исходного соединения.

Полезно представить путь задачи как последовательность. Controller выбирает inventory host и transport, устанавливает соединение, подготавливает выполнение модуля, а при необходимости повышает права. Ошибку нужно связать с этапом по тексту сообщения, а не только по красному заголовку.

Убедимся, что выбран нужный объект

Проверьте inventory, limit и текущий конфигурационный файл Ansible. Имя web1 может соответствовать ansible_host с другим адресом, а ansible_user — отличаться от логина в терминале. Также проверьте ansible_port, ansible_connection, путь ключа и параметры bastion. Значения могут приходить из group_vars, host_vars и переменных подключения.

Не публикуйте полный inventory и verbose-лог без просмотра: там встречаются приватные адреса и секретные параметры. Для разбора достаточно выбранных несекретных полей и конкретного текста ошибки. Пароль повышения прав и пароль SSH — разные credentials.

Проверим SSH до запуска модулей

Повторите обычное SSH-подключение с теми же user, port, key и jump host. Permission denied publickey указывает на аутентификацию, connection refused — на endpoint, а timeout — на недоступный или задержанный путь. Предупреждение о смене host key требует проверить идентичность узла, а не безусловно отключить проверку.

После проверки транспорта можно выполнить чтение идентичности через raw, отключив become для этого диагностического вызова:

ansible web1 -i inventory.ini -m ansible.builtin.raw -a 'id' -e ansible_become=false -vv

Команда рассчитана на POSIX-узел и не меняет его состояние. Raw не требует remote Python так, как обычные Python-модули. Если он работает, базовое выполнение через transport доступно. Сравните фактического пользователя с ожидаемым.

Отделим Python от сетевой доступности

ansible web1 -i inventory.ini -m ansible.builtin.ping -e ansible_become=false

Модуль ping проверяет возможность выполнить Ansible-модуль и обычно требует подходящий Python на POSIX-узле. Это не ICMP ping. Успешный raw при неуспешном builtin.ping даёт повод проверить interpreter discovery, ansible_python_interpreter и доступность выбранного интерпретатора.

Ошибка выполнения модуля не всегда маркируется как UNREACHABLE: разные connection plugins и точки отказа дают разные статусы. Ориентируйтесь на сообщение о конкретном действии. Для Windows и сетевых устройств нужны соответствующие transports и модули; этот POSIX-маршрут к ним автоматически не переносится.

Проверим повышение прав отдельно

ansible web1 -i inventory.ini -m ansible.builtin.command -a id -b -K

-b включает become, -K запрашивает его пароль при необходимости. При уже настроенном беспарольном механизме prompt может не требоваться. Сравните результат id с исходным пользователем. Если без become команда выполнялась, а здесь возникает missing sudo password или запрет sudo, транспорт уже не главный подозреваемый.

Проверьте become_method, become_user и права исходной учётной записи. Указание become_user само по себе не обязано включать повышение. Правило sudo, разрешающее одну фиксированную команду, также не всегда подходит способу запуска временных Ansible-модулей. Согласуйте допустимый механизм с политикой доступа, а не расширяйте sudo наугад.

Вернёмся к исходной задаче

После диагностики повторите нужную безопасную задачу с первоначальными inventory и limit. Успешное подключение под администратором не подтверждает доступ технической учётной записи. Исправленный путь должен работать с теми же параметрами, которые использует автоматизация.

Запишите, на какой границе была ошибка: адрес, аутентификация, интерпретатор или become. Такая запись даёт проверяемое объяснение и сокращает следующий разбор. Игнорирование unreachable лишь скрывает, что часть hosts вообще не получила требуемое изменение.

Ещё по теме

• Ansible --tags пропускает нужные задачи: include_tasks и import_tasks
• Ansible Vault и no_log: где секреты остаются после расшифровки

Продолжить изучение

Хотите собрать настройку серверов в повторяемый процесс? Inventory, роли, шаблоны и обновление сервисов входят в программу «Ansible: автоматизация инфраструктуры».