Ansible Automation Platform 3.0: EDA без отдельного сервера и модули для ROSA и Astra из коробки

Red Hat Ansible Automation Platform 3.0 вышла. Это первый мажорный релиз за четыре года, и в нём достаточно архитектурных изменений, чтобы не просто прочитать changelog, а потрогать руками до того, как везти в production.

Нас интересуют два момента. Первый - переработанный Event-Driven Ansible: Red Hat убрала необходимость в отдельном EDA-сервере, встроив движок напрямую в Automation Controller. Второй - в поставке наконец появились коллекции с модулями для ROSA Server и Astra Linux. На клиентских периметрах у нас давно стоит именно это железо и эти ОС, и вопрос «почему нет нативных модулей» периодически всплывал при каждом разговоре про автоматизацию.

Что изменилось в архитектуре EDA

В AAP 2.5, о котором мы писали год назад, EDA Controller существовал как отдельный компонент - отдельный процесс, отдельный сервис, отдельный порт. Его надо было устанавливать, настраивать связь с Automation Controller, и при падении одного из них цепочка рвалась без очевидной диагностики.

В 3.0 это переработано. Движок event-driven интегрирован в Automation Controller как нативный компонент: rulebook-активации живут там же, где job templates, переменные передаются через тот же API, audit log единый. Отдельного EDA-процесса нет - есть набор worker-threads внутри контроллера с отдельным пулом и лимитами.

Это меняет несколько практических вещей:

• Установка. Больше не нужен отдельный хост или отдельная VM под EDA Controller. На небольших инсталляциях (а у части наших клиентов это именно так) это существенная экономия - один сервис вместо двух.

• Диагностика. Раньше при проблемах с цепочкой «событие -> rulebook -> job» нужно было смотреть логи двух разных сервисов в разных местах. Теперь всё в одном месте. Звучит как мелочь - на практике это съедало приличный кусок времени при разборе инцидентов.

• Ресурсы. Движок EDA теперь конкурирует за ресурсы с обычными job-ами на том же контроллере. Red Hat рекомендует задавать явные лимиты для EDA-пула. Если этого не сделать на нагруженной инсталляции - теоретически EDA-активации могут мешать плановым job-ам. Мы не словили этого на тесте, но держим в голове для production.

Модули для ROSA и Astra Linux

Это давно ожидаемая история. В upstream Ansible Collections модулей, специфичных для отечественных дистрибутивов, нет - там x86 RHEL/Debian-мир. Всё, что касалось ROSA или Astra, делалось либо через generic-модули (command, shell, package с ручным указанием параметров), либо через самописные коллекции, которые каждая команда писала сама и несла сама.

В AAP 3.0 Red Hat добавила redhat.aap_domestic - набор коллекций, который включает:

• модули для управления пакетами через dnf5 на ROSA Server 2.x (с учётом специфики repolist и signature verification под российские CA);
• интеграцию с Astra Linux Security Module - можно управлять мандатными атрибутами файлов и процессов через плейбук без велосипедов на setfattr;
• шаблоны для инвентаризации хостов с автоматическим определением версии Astra Linux и ROSA Server.

Мы прогнали это на тестовом стенде, где стоят серверы YADRO с ROSA Server 2.0 - ту самую инсталляцию, что тестировали в феврале. Модуль управления пакетами встал без проблем, repolist с корпоративным зеркалом подхватился через стандартный baseurl в vars. С Astra Linux картина немного сложнее: ALD Pro (доменная авторизация) требует отдельного шага инициализации, который в шаблоне коллекции не предусмотрен - там assume, что хост уже в домене. Для нас это не проблема, но нужно иметь в виду при составлении playbook для первоначальной настройки машины с нуля.

Новый UI

Здесь коротко: UI переписан с React на что-то более современное (судя по bundle - PatternFly 6 с обновлённым design system). Субъективно - стало быстрее и навигация стала логичнее. Job History теперь показывает связанные EDA-активации прямо в контексте job, не нужно переключаться между разделами.

Для ежедневной работы - приятное улучшение. Для принятия решения об upgrade - не причина сама по себе.

Что пока вызывает вопросы

Миграция с 2.5. Мы прошли тестовую миграцию на стенде - в целом гладко, кроме rulebook-активаций, которые использовали EDA Controller API напрямую. Эти интеграции нужно переписать под новый унифицированный API. Если rulebook-ов немного - это час работы. Если много - закладывайте время на аудит.

EDA в закрытом периметре. Часть event source плагинов в стандартной поставке тянет зависимости с PyPI. В периметрах без интернета это стандартная история - нужен внутренний mirror. AAP 3.0 не изменил эту механику, просто теперь нужно убедиться, что mirror включает зависимости для встроенного EDA-пула, а не только для job execution. Документация по этому пункту есть, но требует внимательного чтения.

Лимиты одновременных активаций. В 2.5 лимит был на уровне EDA Controller и конфигурировался отдельно. В 3.0 это пул worker-threads, и дефолтный размер пула в нашем тесте оказался меньше того, к чему мы привыкли в 2.5 при нескольких параллельных источниках событий. Это конфигурируемо, но нужно проверить явно при планировании upgrade.

Где это появится у клиентов

На текущий момент тест прошёл на стенде, на production-периметры пока не везём - хотим дать версии неделю-другую на подтверждение стабильности от сообщества и посмотреть на первые reported issues. Плановые upgrade клиентов на managed-сопровождении будем обсуждать в апреле, когда накопится больше информации о поведении встроенного EDA под реальной нагрузкой.

Модули для ROSA и Astra - хорошая новость, которую давно ждали. Насколько они покрывают весь зоопарк конфигураций, которые встречаются у клиентов, - покажет эксплуатация.