Если после таски по изменению конфига стоит Ok, отработает ли хендлер

Анализ поведения хендлера после успешной таски в Ansible

Короткий ответ: Нет, хендлер не отработает автоматически, если таска завершилась с состоянием ok (не изменила конфигурацию). Это фундаментальное поведение Ansible, основанное на принципе идемпотентности.

Механизм работы хендлеров в Ansible

Хендлеры в Ansible — это специальные таски, которые запускаются только при изменении состояния других тасок (из changed в ok или failed). Они не выполняются автоматически при каждом запуске плейбука.

Ключевые условия срабатывания хендлера:

• Основная таска должна завершиться со статусом changed
• Хендлер должен быть уведомлён (notify) из этой таски
• Хендлер выполнится один раз в конце плейбука, даже если его уведомили несколько раз

Практический пример

Рассмотрим два сценария:

Сценарий 1: Конфиг не изменился (хендлер НЕ сработает)

# playbook.yml
- name: Update config file
  copy:
    src: config.conf
    dest: /etc/app/config.conf
    owner: root
    group: root
    mode: '0644'
  notify:
    - restart service

- name: restart service
  systemd:
    name: myservice
    state: restarted
  listen: "restart service"

Если файл /etc/app/config.conf уже существует с идентичным содержимым, таска завершится с ok (зелёный вывод), и хендлер не будет вызван.

Сценарий Bi: Конфиг изменился (хендлер сработает)

# Симуляция изменения файла
$ echo "new content" > config.conf
$ ansible-playbook playbook.yml

В этом случае таска будет в статусе changed (жёлтый вывод), и хендлер выполнится в конце плейбука.

Как принудительно запустить хендлер

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

1. Использование флага force_handlers

# force_playbook.yml


- hosts: all
  force_handlers: yes  # Принудительный запуск всех уведомлённых хендлеров
  
  tasks:
    - name: Always notify handler
      command: echo "test"
      changed_when: true  # Всегда считаем таску изменённой
      notify: restart service

2. Явный вызов хендлера через мета-таску

- name: Force handler execution
  meta: flush_handlers  # Немедленный запуск накопленных хендлеров

- name: Explicit handler run
  systemd:
    name: myservice
    state: restarted
  when: handler_force_var | default(false)  # Условный запуск

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

- name: Conditional config update
  template:
    src: config.j2
    dest: /etc/app/config.conf
  notify: restart service
  changed_when:  # Кастомная логика определения изменений
    - config_force_restart | default(false)
    - or
    - "'restart_required' in template_result.stdout"

Лучшие практики работы с хендлерами

• Используйте listen вместо индивидуальных имён — позволяет нескольким таскам уведомлять один хендлер
• Группируйте связанные действия — перезагрузка, перечитывание конфигов и т.д.
• Помните об отложенном выполнении — хендлеры запускаются в конце блока задач, не сразу
• Тестируйте идемпотентность — убедитесь, что повторный запуск плейбука не вызывает лишних действий
• Используйте теги для отладки — тегирование хендлеров помогает в диагностике

- name: debug handler
  debug:
    msg: "Handler triggered!"
  tags: 
    - handlers
    - debug

Альтернативные подходы

Если вам требуется более детальный контроль над выполнением операций:

1. Условные задачи вместо хендлеров
2. Модуль shell/command с проверкой изменений через creates или removes
3. Кастомные факты для отслеживания состояния системы
4. Использование handlers в ролях для лучшей организации кода

Вывод

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