AAP 2.1 и automation mesh: execution nodes без SSH через firewall

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

Что такое automation mesh и почему это важно

В классическом AWX (и в AAP 1.x) схема простая: есть центральный контроллер, есть managed nodes, и AWX подключается к ним по SSH напрямую или через jump-хост. При одной площадке это работает нормально. Когда площадок несколько - ЦОД компании, облако, удалённый офис, DMZ - начинаются вопросы: кто проброшен через firewall, у кого белый IP, у кого нет, как управлять этим зоопарком ключей и исключений в правилах фильтрации.

Automation mesh решает это иначе. Между контроллером и execution nodes устанавливается постоянный TLS-туннель (Receptor/TCP) - execution node сам инициирует соединение наружу. Никакого входящего SSH. Никаких дыр в firewall на сторону площадки. Сеть - это ребро в графе, и топология этого графа настраивается явно.

Структура получается примерно такая:

[Controller + Hub]
        |
    (mesh / WireGuard TLS)
        |
[Hop node - DMZ или граница сети]
        |
    (mesh)
        |
[Execution node - целевая площадка]

Execution node на удалённой площадке не нужен публичный IP. Нужен только исходящий доступ к hop node или напрямую к контроллеру. Это принципиально меняет требования к сетевой архитектуре.

Как мы это проверяли

У одного из клиентов сейчас три площадки: основной ЦОД, небольшой удалённый объект и тестовый стенд в облаке. Раньше автоматизация на удалённом объекте работала через jump-хост с отдельным ключом, прописанным вручную в AWX. Это работало, но каждый раз при смене ключа или изменении сети - отдельный квест с правилами firewall и согласованиями с сетевой командой.

После развёртывания AAP 2.1 с mesh-топологией мы вынесли hop node в DMZ. Execution nodes на обеих площадках подключились к нему сами - без изменений firewall на стороне площадок. Controller видит их как healthy, задачи раскидываются на нужный execution node по метке площадки в inventory.

Настройка в /etc/receptor/receptor.conf на execution node выглядит прямолинейно:

- node:
    id: execution-node-site2

- tls-client:
    name: tlsclient
    cert: /etc/receptor/tls/receptor.crt
    key: /etc/receptor/tls/receptor.key

- tcp-peer:
    address: hop.example.internal:27199
    tls: tlsclient

- work-command:
    worktype: ansible-runner
    command: ansible-runner
    params: worker
    allowruntimeparams: true

Receptor - это и есть transport layer mesh. Он умеет работать в режиме peer-to-peer и строить граф произвольной топологии. В AAP 2.1 он встроен и настраивается через installer.

Event-Driven Ansible preview

AAP 2.1 также везёт preview Event-Driven Ansible - механизм реакции на события через rulebooks. Это ещё очень ранняя история: в preview нет полноценного production-ready статуса, документация местами сырая, и запускать это в prod прямо сейчас мы бы не стали. Но направление понятное - плейбук как реакция на событие из внешней системы (Kafka, webhook, alertmanager), без внешнего триггера типа cron или кнопки в UI.

Смотрим, тестируем в лабе. В production - пока рано.

Что это меняет в контексте импортозамещения

Отдельный момент, актуальный именно сейчас. После ухода западных вендоров и перетряски инфраструктуры у нескольких клиентов инфраструктура стала ещё более фрагментированной: часть сервисов едет в отечественные облака, часть остаётся в своём ЦОД, часть - на резервных площадках, которые раньше почти не использовались. Автоматизировать всё это из единого контроллера раньше означало либо открывать SSH везде, либо городить jump-хосты.

Mesh это не полностью решает - нужен hop node в достижимой зоне, нужен receptor на каждом execution node, нужно разобраться с PKI. Но требование «открытый порт из центра на каждую площадку» снимается. Это заметно упрощает переговоры с сетевой командой.

Что с лицензией

AAP - платный продукт Red Hat. Это не AWX. Стоимость считается по управляемым нодам, лицензия годовая. В нынешней ситуации с Red Hat в России (с марта продажи остановлены) - покупка через прямой канал недоступна. Часть клиентов работает по ранее приобретённым подпискам, часть смотрит на AWX как open-source альтернативу - там mesh нет, но базовая функциональность сохраняется.

Мы сопровождаем оба варианта в рамках managed-инфраструктуры. Если mesh-топология нужна прямо сейчас, а AAP недоступен - смотрим на Receptor отдельно: он open-source и технически может работать с AWX, хотя это нестандартная конфигурация и потребует ручной работы.

Коротко

• Automation mesh - главная фича AAP 2.1. Execution nodes сами инициируют соединение, SSH через firewall больше не нужен.
• Hop nodes позволяют строить многоуровневые топологии для сложных сетевых сегментов.
• Event-Driven Ansible - пока preview, не для prod.
• Лицензионный вопрос актуален: для тех, кто не может купить AAP, смотрим на AWX + Receptor как компромисс.

Mesh - это то, что в AWX всегда решалось костылями. Хорошо, что Red Hat наконец сделал это частью платформы, а не отдельным квестом для DevOps.