Практика Ansible: настроить сервер и не сломать его повторным запуском

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

Как работать с подборкой

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

Ниже — статьи с объяснениями и примерами. Практические эксперименты выполняются в вашем учебном окружении; это не встроенный автоматический экзамен.

1. Попасть на нужный хост с нужными параметрами

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

• Ansible UNREACHABLE: отделяем SSH от ошибки become
• Ansible взял не ту переменную: разбираем inventory, group_vars и host_vars

2. Управлять изменениями и перезапусками

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

• Ansible каждый раз показывает changed: проверяем идемпотентность задачи
• Ansible не перезапустил сервис: когда срабатывает handler
• Ansible template: проверяем конфигурацию до замены рабочего файла

3. Понимать границы проверки

Частичный запуск и check mode полезны, когда вы понимаете, какие шаги они пропускают. Разберите структуру результата цикла и отдельно проверьте, не попадают ли чувствительные данные в вывод.

• Ansible check mode: что реально проверяет dry run и чего он не видит
• Ansible --tags пропускает нужные задачи: include_tasks и import_tasks
• Ansible loop и register: как проверять результат каждой итерации
• Ansible Vault и no_log: где секреты остаются после расшифровки

4. Обновлять несколько машин

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

• Последовательное обновление серверов Ansible: serial и проверка готовности
• delegate_to и run_once в Ansible: где выполняется задача и сколько раз

Соберите результат в одну рабочую процедуру

Итоговый сценарий: поменять параметр сервиса, проверить конфигурацию, применить её по очереди на двух машинах и выполнить playbook ещё раз. Объясните каждый перезапуск и каждый changed. Затем намеренно сломайте шаблон и убедитесь, что ошибку видно до замены рабочей конфигурации.

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

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

Если пока не хватает базы или нужен соседний инструмент, выберите другой маршрут в путеводителе по практике DevOps.