Коротко о главном

Ansible позволяет описывать состояние серверов в YAML и применять его повторно. Не нужен агент: достаточно SSH и Python на целевой машине. Это снижает порог входа, но требует дисциплины в организации инвентаря и ролей.

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

Ansible редко ломается сам по себе. Чаще проблема в неверной конфигурации, устаревшей версии или команде, скопированной без понимания. Разберём типичные сбои и способы их исправления.

Почему это происходит

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

Типичные ошибки

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

1. UNREACHABLE

Проверьте SSH-ключи, адрес, пользователя и файрвол. Запустите ssh вручную с теми же параметрами.

2. Модуль не найден

Проверьте коллекцию и версию Ansible. Установите нужную коллекцию через ansible-galaxy.

3. Плейбук меняет всё при каждом запуске

Ищите shell/command без changed_when и задачи, не описывающие целевое состояние.

Как настроить правильно

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

Установка

В Debian, Ubuntu и Linux Mint используется пакетный менеджер APT:

sudo apt install ansible

В Fedora и RHEL-совместимых системах пакет ставится через DNF:

sudo dnf install ansible

В Arch Linux и производных пакет доступен в официальных репозиториях:

sudo pacman -S ansible

1. Создайте инвентарь

Начните с простого INI-файла. Группы помогают применять разные роли к веб-серверам и базам.

[web]
web1 ansible_host=203.0.113.10

[db]
db1 ansible_host=203.0.113.20

2. Проверьте подключение

Модуль ping проверяет SSH и Python, а не ICMP.

ansible all -i inventory.ini -m ping

3. Напишите первый плейбук

Плейбук описывает задачи декларативно. Указывайте state: present и не используйте shell без необходимости.

- hosts: web
  become: true
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

4. Запустите с проверкой

Сначала —check, затем обычный запуск. Для отладки используйте -vvv, но не оставляйте высокий уровень в логах.

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

Рабочий конфиг

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

[defaults]
inventory = ./inventory.ini
host_key_checking = True

Практические советы

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

Совет 1. Идемпотентность важнее скорости первого запуска.

Идемпотентность важнее скорости первого запуска.

Совет 2. Не храните SSH-пароли в инвентаре.

Не храните SSH-пароли в инвентаре.

Совет 3. Используйте отдельного пользователя для автоматизации.

Используйте отдельного пользователя для автоматизации.

Совет 4. Проверяйте плейбуки на тестовом стенде.

Проверяйте плейбуки на тестовом стенде.

Профилактика

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

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

Чек-лист

  • Версия пакета и конфигурация зафиксированы и доступны для сравнения.
  • Есть автоматическая проверка синтаксиса перед перезапуском службы.
  • Журналы ротуются, а диск не заполняется ими за неделю.
  • Изменения проходят через тестовый стенд, а не сразу на рабочий сервер.

Итог

Большинство ошибок с Ansible лечится не переустановкой, а проверкой конфигурации, логов и прав доступа. Действуйте по одному изменению за раз — и причина быстро найдётся.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте