AWX 25 и Execution Environments: как новая версия упростила онбординг коллекций

AWX 25 вышел незаметно - как обычно, без пресс-конференции, просто появился тег в GitHub и обновилась документация. Мы обновляли его в рамках плановой миграции парка серверов у нескольких заказчиков, и в этот раз изменения в управлении Execution Environments оказались достаточно существенными, чтобы написать отдельный пост.

Что такое Execution Environments и почему они были болью

Если кратко: Execution Environment - это контейнерный образ, в котором Ansible запускает плейбуки. Внутри - интерпретатор Python, ansible-core, коллекции и все зависимости. Идея правильная: изолированная воспроизводимая среда вместо «на каком-то сервере стоит Ansible 2.9 с непонятным набором коллекций».

Проблема была в том, что управлять этими образами в AWX 24 и раньше было неудобно. Нужно было вручную собирать образ через ansible-builder на отдельной машине, пушить в registry, потом привязывать к job template в AWX. Каждое изменение коллекции - пересборка образа, новый тег, обновление в AWX. При парке в несколько десятков разнородных серверов с разными наборами коллекций это превращалось в отдельный пайплайн, который нужно было поддерживать.

Что изменилось в AWX 25

Встроенный EE builder. Теперь AWX умеет собирать Execution Environment прямо из интерфейса - по execution-environment.yml и requirements.yml, без внешних инструментов. Builder запускается как задание внутри AWX, образ попадает в локальный registry или во внешний, который вы настроили. Это не rocket science, но убирает один внешний инструмент из цепочки.

Версионирование коллекций в EE через интерфейс. Раньше версия коллекции жила только в requirements.yml внутри образа - то есть где-то в git. В AWX 25 версии видны прямо в карточке EE в интерфейсе: какие коллекции, какие версии, когда собрано. Мелочь, но при разборе «почему вчера плейбук работал, а сегодня нет» экономит время.

Автоматическая разводка EE по job templates. В предыдущих версиях один шаблон - один EE, и если нужно было запускать разные задачи с разными зависимостями, приходилось дублировать шаблоны или тащить все коллекции в один жирный образ. AWX 25 позволяет привязывать EE на уровне inventory-группы или даже отдельного хоста через переменные. Документация об этом написана не очень внятно, разобрались методом проб.

Что это дало при онбординге новых коллекций

Конкретный кейс: к нам пришёл новый заказчик с несколькими объектами на отечественном оборудовании - Eltex и Zelax на сети, РЕД ОС на серверах. Стандартные коллекции community.network и ansible.posix покрывали часть задач, но под Eltex нужна была вендорская коллекция, а под РЕД ОС - специфичный набор модулей для работы с rpm-пакетами и systemd в их реализации.

Раньше это означало: разобраться с зависимостями, собрать образ руками, потестировать на стенде, потом катить в прод. Недели две с учётом согласований.

В AWX 25 мы сделали это иначе. Создали execution-environment.yml с нужными коллекциями, запустили встроенный builder прямо в AWX на тестовом контуре заказчика, получили образ. Проверили, что коллекция Eltex работает корректно (там были нюансы с версией ansible-core - нужна была 2.16+). Поправили, пересобрали - всё в одном интерфейсе, без перебрасывания файлов между машинами. Первый рабочий EE для новой инфраструктуры получили за несколько часов вместо нескольких дней.

Это не потому что AWX стал магически умнее - просто убрали лишние переключения контекста.

Что потребовало внимания при миграции

Не всё прошло гладко.

Совместимость старых EE. Образы, собранные под AWX 24, теоретически должны работать в AWX 25 без изменений. На практике один из образов упал при запуске - оказалось, в нём был захардкожен путь к ansible-runner старой версии. Пришлось пересобирать. Морали две: документировать содержимое EE и не полагаться на «должно совместиться».

Registry в изолированных сегментах. У одного из заказчиков с КИИ-сегментом AWX не мог пушить собранный образ во внешний registry из-за сетевых ограничений. Решение - поднять локальный Harbor внутри периметра и настроить AWX на него. Это работает, но требует отдельной инфраструктуры. Для таких сценариев AWX 25 ничего принципиально нового не предлагает.

EE builder требует привилегированного режима или rootless podman. На серверах с жёсткими SELinux-политиками пришлось разбираться с контекстами. Не критично, но заняло время и добавило пару строк в memory/lessons.md.

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

AWX 25 - это не революция, а аккуратное развитие того, что уже было. Встроенный builder и версионирование EE убирают часть рутины, которая раньше висела на инженере. Для команды, которая занимается managed-сопровождением разнородного парка, это ощущается как небольшое, но реальное облегчение.

Онбординг нового заказчика с нестандартным оборудованием теперь начинается с EE-сборки в AWX, а не с настройки отдельного пайплайна для ansible-builder. Это хорошо. Посмотрим, насколько стабильно всё это работает через несколько месяцев в production - пока история слишком свежая, чтобы делать выводы о надёжности.