Ansible AWX 24: React-интерфейс и automation mesh для изолированных площадок КИИ

AWX 24 вышел тихо - без громких анонсов, просто очередной релиз в github-репозитории. Но внутри два изменения, которые нас интересуют: полный переход интерфейса на React и заявленные улучшения в automation mesh. Второе интересует нас гораздо больше первого, потому что именно с mesh мы решаем реальную задачу последние пару месяцев.

Что с новым интерфейсом

Старый Ansible Tower UI на AngularJS тянулся в AWX ещё с тех времён, когда проект только отпочковался от коммерческой платформы. Патчить его было мучением, и это было заметно по скорости выхода фиксов на UI-баги. React-переезд - решение правильное, хотя и запоздалое.

На практике новый интерфейс заметно быстрее отрисовывается, меньше виснет при большом количестве хостов в инвентаре. Навигация стала логичнее - workflow-редактор в частности переписан и теперь не вызывает желания закрыть вкладку. Тёмная тема наконец работает без визуальных артефактов.

При этом функциональных изменений UI почти нет - всё те же экраны, просто быстрее и стабильнее. Это нормально. AWX не конкурент AAP с точки зрения продукта, он решает задачу «запустить Ansible centrally без дополнительных расходов на лицензию».

Automation mesh: зачем он нам нужен

Теперь про то, что интересно по-настоящему. У нескольких клиентов с объектами КИИ есть одна и та же проблема: удалённые площадки физически или нормативно изолированы от центрального сегмента. VPN-туннели либо запрещены политикой безопасности, либо работают нестабильно из-за ведомственных межсетевых экранов, которые никто не торопится настраивать под нужды Ansible.

До automation mesh ответ был один: ставить отдельный AWX на каждой площадке или гонять плейбуки через бастион-хост с кучей костылей. Ни то, ни другое не масштабируется при десятке площадок.

Automation mesh решает это через receptor - сетевой слой с mesh-топологией поверх TCP. Control plane AWX общается с execution nodes через receptor-каналы, которые работают с однонаправленным соединением: execution node сам инициирует соединение наружу к control node, VPN в обратную сторону не нужен.

flowchart LR
    AWX["AWX Control Node\n(центральный ЦОД)"] <-->|receptor TLS| HOP["Hop Node\n(DMZ клиента)"]
    HOP <-->|receptor TLS| EX["Execution Node\n(изолированный сегмент)"]
    EX -->|SSH| HOSTS["Управляемые хосты\nизолированного сегмента"]

Что мы поставили на одном из объектов

Задача: управлять инфраструктурой изолированного сегмента (около 40 серверов) через центральный AWX, без VPN и без выделенного AWX на площадке.

Архитектура получилась трёхузловая. Центральный AWX стоит в ЦОД клиента. Hop node - в DMZ площадки, где есть двусторонняя связность с центром. Execution node - уже в изолированном сегменте, откуда он видит только hop node и управляемые хосты.

Установка execution node - это по сути установка receptor и ansible-runner с минимальной конфигурацией. Сам AWX видит новый узел после регистрации и проверки TLS-сертификата. Никаких агентов на управляемых хостах, всё через SSH - стандартный Ansible.

Несколько наблюдений по итогам установки.

Receptor TLS настраивается вручную, автогенерации нет. AWX 24 улучшил интерфейс управления mesh-узлами, но выпустить сертификаты и корректно прописать пути - ручная работа. Документация есть, но разбросана по нескольким страницам, и порядок действий там не очевидный. Потратили пару часов на первую установку.

Hop node - обязательный элемент при жёстком сегментировании. Execution node в полностью изолированном сегменте не может инициировать соединение напрямую к AWX через все межсетевые экраны. Hop node в DMZ - промежуточная точка, которая видит и тот, и другой сегмент. Добавляет задержку, но несущественную для Ansible-задач.

Задания выполняются на execution node, не на control. Это принципиальный момент безопасности: плейбук с учётными данными не уходит на центральный AWX, он выполняется локально на execution node. С точки зрения СБ клиента - учётки не покидают периметр изолированного сегмента.

Логи и артефакты уходят обратно через receptor. После выполнения задания execution node отправляет stdout и артефакты на control node через тот же receptor-канал. Всё видно в интерфейсе AWX как обычное задание - без разницы, где физически оно выполнялось.

Что осталось неудобным

Мониторинг состояния mesh-узлов в AWX 24 стал лучше, но всё ещё поверхностный. Интерфейс показывает статус «healthy / unhealthy», но диагностика при проблеме - это лезть в логи receptor на каждом узле вручную. Нормальных алертов на деградацию mesh из коробки нет - пришлось добавить внешний мониторинг через Zabbix, который проверяет доступность receptor-порта и API-endpoint AWX для каждого узла.

Обновление AWX при наличии mesh-узлов - отдельный квест. Нужно обновлять control node и execution nodes в согласованном порядке, иначе несовместимость версий receptor может положить весь mesh. В документации об этом написано, но не очень громко. Первое обновление делали по шагам с проверкой после каждого узла.

Общее впечатление

Automation mesh в AWX 24 - это рабочая технология для задачи «управлять изолированными сегментами без VPN». Не идеальная, но работающая. Для объектов КИИ с жёсткими требованиями к сетевой изоляции это первый вменяемый вариант оставаться на единой платформе автоматизации вместо зоопарка локальных решений.

Новый React-интерфейс - приятный бонус, который меняет качество ежедневной работы с управляемой инфраструктурой. Но это не повод переходить на AWX 24 прямо сейчас, если текущая версия стабильна. Mesh - вот повод.