Ansible Automation Platform 2.5: смотрим на Event-Driven Ansible для реакции на инциденты Zabbix

Примерно неделю назад Red Hat выкатила Ansible Automation Platform 2.5. Заголовки пресс-релиза сфокусированы на RHEL AI и интеграции с моделями, но нас в первую очередь интересует другое: серьёзно переработанный Event-Driven Ansible. У нас есть несколько клиентов, где AAP уже стоит в периметре на managed-сопровождении, и вопрос автоматической реакции на алерты Zabbix без будильника для дежурного - давно висящий в воздухе.

Что поменялось в Event-Driven Ansible

EDA появился в AAP ещё в версии 2.4, но там это было что-то вроде технического превью в производственном облачении: работало, но с ограничениями, которые выяснялись только в эксплуатации. В 2.5 Red Hat явно вложилась в стабилизацию.

Три вещи, которые нас интересуют на практике:

• Увеличенный лимит одновременных rulebook-активаций. В 2.4 лимит был относительно небольшим и при нескольких параллельных источниках событий начинал ощущаться. В 2.5 этот потолок подняли - цифры в документации есть, но важнее то, что для нашего типового клиентского развёртывания (несколько десятков хостов, Zabbix, несколько источников событий) лимит теперь не будет узким местом по умолчанию.

• Улучшенная работа с фильтрами событий и условиями в rulebook. Это менее очевидное, но важное изменение. Условия в rulebook стали более гибкими - можно точнее описывать, на какие именно события и в какой комбинации нужно реагировать, без обходных костылей через Jinja2 в местах, где он семантически не уместен.

• Интеграция EDA Controller с Automation Controller через новый API. Раньше EDA и контроллер автоматизации общались, но степень интеграции была ограниченной. Теперь запуск Job Template из EDA в ответ на событие - первоклассный сценарий с нормальной передачей переменных и контекста инцидента.

Как это выглядит в сценарии с Zabbix

Мы в нескольких проектах давно используем связку Zabbix + AAP для автоматизации рутинных задач: перезапуск сервисов, очистка логов, проверка и восстановление репликации. Но до EDA это работало по схеме «Zabbix webhook -> API AAP -> job», которую надо настраивать на стороне Zabbix и которая довольно хрупкая: упал webhook - потерял событие.

EDA меняет архитектуру: вместо push-модели от Zabbix у нас pull-модель, где EDA-worker подписывается на источник событий и сам обрабатывает поток. Источник в данном случае - Zabbix через HTTP listener (ansible.eda.webhook).

Вот простая иллюстрация потока:

flowchart LR
    Z[Zabbix Alert] -->|webhook| EDA[EDA Rulebook Activation]
    EDA -->|condition match| AC[Automation Controller]
    AC -->|Job Template| PB[Ansible Playbook]
    PB -->|remediation| H[Хост/Сервис]
    PB -->|update| Z

Rulebook для типового инцидента выглядит примерно так - сервис упал, Zabbix прислал алерт с конкретным триггером, EDA сопоставил условие и запустил playbook восстановления:

- name: Zabbix service restart
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5001
  rules:
    - name: Restart failed service
      condition: event.payload.trigger_name == "Service is down"
      action:
        run_job_template:
          name: "Restart Service"
          organization: "Default"
          job_args:
            extra_vars:
              target_host: "{{ event.payload.host }}"
              service_name: "{{ event.payload.service }}"

Это не экзотика - это буквально базовый сценарий, который теперь работает без изобретения велосипеда.

Что пока не идеально

Честно: несколько вещей нас насторожили.

Документация EDA всё ещё не догнала функционал. Часть новых возможностей 2.5 описана в changelog, но не в операционных руководствах. Это характерно для Red Hat при выходе мажорной версии - документы подтягиваются с небольшим опозданием. Не критично, но с учётом того что EDA - относительно новый компонент, хотелось бы больше примеров.

RHEL AI как headline-фича - это маркетинг для другой аудитории. Понятно, почему Red Hat делает на это акцент, но для команд, которые эксплуатируют AAP в закрытых периметрах КИИ, интеграция с AI-моделями - это скорее пункт для галочки, чем практическая необходимость прямо сейчас.

Миграция rulebook с 2.4 на 2.5 требует внимания. Мы ещё не прошли этот путь на production-инсталляции - тестировали на стенде. Поверхностно всё ок, но несколько параметров в rulebook-синтаксисе изменились, и если у вас много активаций - нужен аккуратный план.

Что будем делать дальше

На ближайший квартал у нас запланировано развернуть EDA в одном из клиентских периметров в пилотном режиме - именно для сценария автоматического реагирования на Zabbix-инциденты. Выбрали клиента с относительно однородным парком и хорошо задокументированными runbook-ами: это важно, потому что EDA не пишет логику за вас - он только вызывает её автоматически.

Главная задача пилота - проверить, насколько надёжно работает цепочка в условиях реального потока алертов, и понять, где нужны ручные предохранители. Реакция на инцидент без дежурного - это хорошо, но реакция, которая что-то ломает по цепочке без участия человека, - это уже другая история.

По итогам напишем предметнее - с тем, что сработало, что нет, и как выглядит поддержка в закрытом периметре без прямого доступа к Red Hat CDN.