Переход с AWX 19 на Ansible Automation Platform 2.0: automation mesh в сегментированных сетях

Red Hat выпустил Ansible Automation Platform 2.0 - и это не просто версия с новыми фичами, а фактически другой продукт с переработанной архитектурой. Главное изменение: монолитный AWX уходит на второй план, ему на замену приходит automation mesh - распределённая сетка execution-узлов с маршрутизацией задач между ними.

Для нас это событие совпало с работой над задачей, которая давно болела: у одного крупного клиента автоматизация на AWX 19 упиралась именно в сетевую связность. Появление AAP 2.0 дало повод разобраться с migration path вживую.

Почему AWX 19 не справлялся

Инфраструктура клиента разбита на несколько сегментов с жёсткой фильтрацией: prod-сеть, DMZ, технологическая сеть АСУ, плюс пара удалённых площадок. AWX в этой картине стоит в одном сегменте и пытается SSH-ить во все остальные. Часть маршрутов разрешена через jump-хосты, часть - вообще не разрешена напрямую.

Решение было кустарное: один AWX, несколько inventory с разными ansible_ssh_common_args, кое-где ProxyJump в SSH-конфиге. Это работало, но с постоянными оговорками - job запускается только с нужного runner-а, переменные среды надо не забыть переопределить, и никакой нормальной видимости что где выполняется.

Что такое automation mesh

В AAP 2.0 архитектура выполнения задач стала трёхуровневой. Есть control plane (automation controller, бывший AWX), есть execution plane - набор узлов разного типа:

• Hop-узлы - маршрутизируют трафик, сами ничего не выполняют. Ставятся в точках перехода между сегментами.
• Execution-узлы - непосредственно запускают job'ы. Стоят в целевом сегменте, наружу им выходить не надо.
• Hybrid-узлы - и маршрутизируют, и выполняют. Подходит для небольших площадок.

Связь между узлами - WireGuard поверх TCP/443. Это важно: не SSH, не какой-то проприетарный протокол, а нормальный VPN-туннель с взаимной аутентификацией. Firewall на TCP/443 обычно открыт, а даже если нет - это стандартный запрос к сетевикам, не экзотика.

[automation controller]
       |
  (WireGuard/443)
       |
  [hop-node DMZ]
       |
  (WireGuard/443)
       |
  [execution-node prod]
  [execution-node tech-network]

Для клиента с его сегментацией эта схема ложится аккуратно: hop-узел в DMZ, execution-узлы в каждом целевом сегменте. Каждый execution-узел SSH-ит только в свой сегмент. Controller вообще не знает про детали топологии - он просто отправляет job на нужный execution-узел через mesh.

Migration path с AWX 19

Прямой upgrade AWX -> AAP не существует. AWX - upstream-проект, AAP - коммерческий downstream с enterprise-контрактом. Это разные продукты, хотя и на одной кодовой базе.

Практический path выглядит так:

Первое - инвентаризация того что есть. Выгружаем из AWX: все inventory, credentials (типы и привязки, не сами значения), templates, workflows, schedules. Для этого есть awx CLI и AWX API - берём JSON-дампы всего. У клиента накопилось несколько десятков job templates и три workflow - не катастрофа, но вручную переносить неприятно.

Второе - подготовка execution environment. AAP 2.0 выполняет задачи внутри контейнеров (execution environments). Это замена старой схеме с виртуальными окружениями Python на control node. EE собираются через ansible-builder - берётся базовый образ, добавляются нужные коллекции и Python-зависимости. Для клиентских playbooks пришлось собрать два EE: один для общих задач, один для задач с vendor-специфичными коллекциями (СУБД, сетевые железки).

Третье - разворачиваем mesh-узлы. Инсталлятор AAP 2.0 (setup.sh с inventory-файлом) умеет деплоить всю топологию за один прогон. В inventory описываем: какой хост что за роль - [automationcontroller], [execution_nodes], [hop_nodes]. Указываем peers для каждого узла. Инсталлятор сам настраивает WireGuard и регистрирует узлы в controller.

Четвёртое - импорт конфигурации. Credentials, inventory, templates пересоздаём через API или terraform-провайдер ansible/tower (он поддерживает AAP-ресурсы). Workflows переносим руками - там логика, которую надо проверить глазами в любом случае.

Что не очевидно при переходе

Credential типа Machine из AWX работает и в AAP, но vault credentials теперь устроены иначе - Vault-интеграция переработана. Если в AWX были кастомные credential types, их определения нужно перенести явно, они не мигрируют автоматически.

Execution environments требуют container registry - где-то надо хранить образы. На площадке клиента решили через Harbor, который уже стоял для других нужд. Это дополнительная зависимость в production-потоке, которой раньше не было.

Планировщик задач (schedules) переносится через API, но временные зоны надо проверить - AWX и AAP по-разному обрабатывают локальные TZ в старых записях.

Где сейчас

Automation mesh запущен в тестовом режиме параллельно с живым AWX. Job'ы выполняются через execution-узлы в целевых сегментах, hop-узел в DMZ работает. Связность между сегментами через WireGuard оказалась предсказуемо надёжнее, чем прыжки по jump-хостам через SSH.

AWX 19 продолжает крутить production-задачи - переключение будет плановым, не в один день. Параллельный период полезен ещё и тем, что позволяет сравнить результаты выполнения одних и тех же playbooks в разных средах.

Клиентам на сопровождении с похожей сегментированной инфраструктурой стоит смотреть на AAP 2.0 как на решение именно сетевой проблемы - не как на «новый AWX», а как на инструмент с другой моделью связности.