🛠️ Конфиг изменился, notify был, а handler не выполнился

Это возможно по умолчанию в Ansible.

Сценарий:

task меняет config → notify handler → следующая task падает → host получает failed → handler на этом host не запускается

В итоге:

файл уже новый running service ещё использует старую конфигурацию

Поэтому handler — не гарантия того, что после changed runtime state обязательно обновится. После failed run проверьте: — play recap; — changed task; — был ли notify; — какая task потом failed; — запускался ли handler; — какой config сейчас на disk; — перечитал ли его сервис.

Есть: force_handlкers: true

и CLI:

--force-handlers

Но это не универсально безопасная настройка. Если failure означает, что deployment ещё не готов, forced restart может ухудшить ситуацию. Даже с force handlers unreachable host всё равно может помешать выполнению handler.

Отдельный инструмент: meta: flush_handlers

Он запускает handlers, notified к этому моменту, раньше обычной точки выполнения. Но выбирать его нужно по failure path, а не по принципу «handler должен сработать любой ценой».

Главный вопрос при review: что останется на host, если play остановится после каждого шага?

Сохраните этот сценарий для ревью playbook, который меняет конфигурацию production-сервисов.

🔹🔹🔹🔹

🛠️ Конфиг изменился, notify был, а handler не выполнился
Это возможно по умолчанию в Ansible | Сетка — социальная сеть от hh.ru