Ansible для сервера на сервере: частые ошибки и решения

MAATRIX

Ansible обещает управлять серверами одной командой, но на практике первый же запуск часто встречает ошибками: то SSH не пускает, то sudo требует пароль, то плейбук падает на Python. Хорошая новость в том, что почти все проблемы Ansible для сервера типовые и решаются точечно. Разберём самые частые из них по порядку — от подключения до неожиданных изменений.

Ошибка: unreachable — Ansible не подключается по SSH

Самая ранняя и частая беда: ansible web -m ping возвращает UNREACHABLE вместо SUCCESS. Ansible работает поверх обычного SSH, поэтому причина всегда в доступе. Проверьте вручную, что с управляющей машины вы вообще заходите на целевой сервер тем же пользователем и ключом:

ssh -i ~/.ssh/id_ed25519 root@203.0.113.10

Если ручной вход не работает — дело не в Ansible, а в ключе или адресе. Разложите открытый ключ на сервер и проверьте права папки .ssh. Если ручной вход работает, а Ansible нет, чаще всего в инвентаре указан не тот пользователь, ключ или порт. Сверьте параметры ansible_user, ansible_ssh_private_key_file и, при нестандартном порте, ansible_port. Ещё одна ловушка — незнакомый host key: при первом подключении SSH ждёт подтверждения, а Ansible молча падает. Один раз зайдите руками, чтобы принять ключ хоста, либо настройте это поведение в конфигурации.

Ошибка: sudo требует пароль и задачи падают

Плейбук с become: yes падает с сообщением про пароль sudo. Ansible повышает права через sudo, и если пользователь на сервере обязан вводить пароль, автоматика упирается в этот запрос. Есть два honest-решения. Первое — передавать пароль sudo при запуске флагом, который запросит его интерактивно:

ansible-playbook -i inventory.ini site.yml --ask-become-pass

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

Ошибка: Python не найден на целевом сервере

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

Решение — указать Ansible правильный путь к интерпретатору или доустановить Python на целевой сервер. Путь задаётся переменной в инвентаре:

[web:vars]
ansible_python_interpreter=/usr/bin/python3

Если Python вовсе не установлен, его ставят «сырым» модулем, который работает без интерпретатора, а дальше плейбук идёт обычным порядком. На современных серверах Ubuntu 24.04 Python 3 обычно уже есть, поэтому чаще проблема именно в неверном пути, а не в отсутствии — и решается одной строкой в инвентаре.

Ошибка: changed при каждом запуске

Вы ждёте от Ansible идемпотентности: второй запуск должен показывать ok, ничего не меняя. Но некоторые задачи упорно показывают changed каждый раз. Это признак того, что задача написана императивно, а не декларативно. Чаще всего виноват модуль запуска команд: он выполняет команду всегда и не знает, изменилось ли что-то.

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

Ошибка: секреты в открытом виде

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

Правильный путь — Ansible Vault. Он шифрует файлы с чувствительными данными, и в репозитории лежит уже зашифрованный вариант, а расшифровка происходит только при запуске по паролю или ключу. Заведите привычку с самого начала держать все секреты в зашифрованных файлах, а не переносить их туда потом, когда что-то уже утекло. Отдельно проверьте, что случайно не закоммитили приватные ключи и пароли до внедрения Vault — историю Git иногда приходится чистить.

Ошибка: плейбук применился не к тем серверам

Неприятный сюрприз — команда затронула не ту группу серверов, что планировалось, например прошлась по продакшену вместо тестового стенда. Причина обычно в неаккуратном инвентаре или в слишком широком указании хостов в плейбуке. Когда в hosts стоит all, плейбук идёт по всем серверам инвентаря разом.

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

ansible-playbook -i inventory.ini site.yml --check --diff

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

Как выстроить надёжный процесс

Большинство перечисленных граблей исчезают, если с самого начала соблюдать несколько привычек. Держите весь код Ansible в Git — тогда любое изменение видно, а откат к рабочей версии делается мгновенно. Проверяйте плейбуки в режиме --check перед применением к боевым серверам. Храните секреты только в Vault. Пишите задачи декларативно, через специализированные модули, чтобы сохранять идемпотентность.

Отдельно облегчает жизнь стабильный управляющий узел. Небольшой VPS, всегда онлайн и с быстрым каналом до ваших серверов, избавляет от привязки к ноутбуку и делает запуск плейбуков предсказуемым. У MAATRIX такой сервер оплачивается из России картой, по СБП или криптой, а чистый IP и root вы получаете сразу. На этой основе Ansible из источника ошибок превращается в спокойный инструмент управления инфраструктурой.

Частые вопросы