Определение обработчиков и шаблонов перезапуска

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

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

Имя обработчика — это строка, на которую другие задачи ссылаются в notify. Считайте его стабильной точной меткой, которую Вы будете использовать повторно.

Классический обработчик перезапуска использует модуль service со значением состояния restarted. Он останавливает и запускает службу одним шагом.

Предпочитайте состояние reloaded, если служба его поддерживает. При перезагрузке конфигурация перечитывается без разрыва соединений, в отличие от полного перезапуска.

Модуль systemd даёт более точный контроль на узлах с systemd, включая daemon_reload после изменения файла службы.

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

Когда в очередь поставлено несколько обработчиков, они выполняются в порядке, в котором определены, а не в порядке уведомления. Планируйте эту последовательность.

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

В роли обработчики размещаются в handlers/main.yml. Задачи роли уведомляют их по имени, точно так же, как в обычном плейбуке.

Используйте имена в форме действий, например Перезапустить nginx или Перезагрузить sshd. Понятные имена делают вывод читаемым, а строки notify — очевидными.

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

Теперь Вы умеете определять обработчики в разделе handlers, выбирать между перезапуском и перезагрузкой и полагаться на выполнение в порядке определения. 🎯