Для многих технических специалистов AWX на протяжении многих лет был синонимом «бесплатного Ansible Tower» — надёжным и функциональным решением для управления Ansible-автоматизацией. Это был стандарт де-факто для тех, кто хотел получить удобство (практически) "коробочного" решения и функциональность корпоративного уровня, не вкладываясь в лицензии коммерческого решения.
Однако 2 июля 2024 года вышел релиз AWX версии 24.6.1, который стал последним на данный момент выпуском проекта. С тех пор прошло более полутора лет, а новых релизов так и не появилось. В репозитории проекта на GitHub висит предупреждение: «Releases of this project are now paused during a large scale refactoring». Для сообщества, активно использующего или планирующего использовать AWX как основной инструмент централизованного управления Ansible-автоматизацией, эта ситуация вызывает закономерные вопросы: Что происходит с проектом? Есть ли у него будущее?
Для конечного пользователя не совсем очевидно, но AWX не умирает, а кардинально трансформируется. В данной статье мы разберем текущую ситуацию вокруг AWX, опираясь на официальные анонсы, технические дискуссии разработчиков и статусы ключевых проектов. Проанализируем архитектурные изменения проекта. Разберемся, почему эти изменения были неизбежны, что именно было «вырезано» из проекта и что всё это значит для вас — инженеров ИТ инфраструктуры и архитекторов автоматизации, которые используют AWX в своей работе и проектах.
Наследие прошлого: архитектурный динозавр
Чтобы понять масштаб и логику текущих изменений, необходимо заглянуть в историю, а для этого полезно будет ознакомиться с одной из наших прошлых публикаций. Если кр��тко, то проект AWX был открыт компанией Red Hat в 2017 году и с тех пор активно развивается сообществом. Red Hat остался верен своей модели разработки и следует практике upstream-first, когда изменения сначала вносятся в исходный, открытый проект, а затем на его основе создаются стабильные, коммерческие enterprise‑продукты с предсказуемыми жизненными циклами и поддержкой. В случае с AWX - это upstream коммерческого решения Ansible Automation Platform, в состав которой входят и другие компоненты.
В 2024 году команда Red Hat, активно участвующая в развитии проекта AWX, опубликовала сообщение в блоге, которое стало первой в последующей серии сообщений на форуме Ansible, анонсирующих кардинальные изменения в архитектуре AWX. Как отмечает Мэттью Джонс, главный архитектор Ansible Automation в Red Hat, архитектурные основы AWX были заложены более 10 лет назад, в 2013 году. В то время это был передовой продукт, но IT-индустрия не стоит на месте.
Проблемы текущей архитектуры: почему монолит должен умереть
Команда, работающая над проектом, выделяет следующие проблемы:
Технический долг: Исторически AWX развивался как монолитное Django-приложение, в котором все компоненты тесно связаны между собой. Решения, принятые 10 лет назад, сегодня увеличивали нагрузку на инженеров, замедляли разработку и блокировали инновации. Любое изменение в одной части монолита могло сломать что-то в другой.
Дублирование кода: В экосистеме Ansible есть еще несколько открытых проектов (AWX, Event-Driven Ansible, Ansible Galaxy), которые Red Hat об��единяет в коммерческой платформе Ansible Automation Platform. Многие функции приходится реализовывать отдельно в каждом проекте. Это приводит к дублированию усилий и увеличению технического долга.
Сложность входа для контрибьюторов: Огромная кодовая база затрудняла участие сообщества.
Инженерные команды Red Hat поняли, что не могут позволить себе поддерживать upstream-проекты в текущем состоянии при одновременном расширении функциональных возможностей коммерческой платформы автоматизации за счет этих проектов.
Рефакторинг: разделяй и оптимизируй
В результате было принято решение перейти к «pluggable, service-oriented architecture» — модульной сервис-ориентированной архитектуре. При этом сам по себе переход был невозможен без рефакторинга: существующая кодовая база была слишком, как упоминалось ранее, "монолитной", без четко выделенных функциональных границ. Поэтому основная идея — разбить большое приложение на более мелкие самостоятельные сервисы, каждый из которых развивать в рамках отдельного репозитория. Цели:
Гибкость: проще вносить изменения и расширять функциональность.
Удобство сопровождения (maintainability): разделение на репозитории уменьшало кодовую базу.
Переиспользование кода: между различными проектами экосистемы Ansible через общие библиотеки (сервисы).
Активное участие сообщества: снижение барьера и больше возможностей для вклада в развитие экосистемы Ansible.
План реализации включал несколько ключевых этапов. Первый этап стартовал во второй половине 2024 года и далее предлагаю перейти к конкретике рефакторинга и рассмотреть какие компоненты были выделены из монолитного AWX в отдельные проекты.
Новый фронтенд: не только лишь визуальный сахар
Одним из первых изменений стал переход на новый UI фреймворк. 22 августа 2024 старый UI полностью удален из основного репозитория AWX через merge PR #15414. Интерфейс на AngularJS заменяется новым, унифицированным UI-фреймворком на базе Patternfly из репозитория ansible/ansible-ui. Почему он вдруг стал «унифицированным»? Потому что теперь предназначен для нескольких ключевых проектов экосистемы:
AWX
EDA (Event-Driven Ansible)
HUB (Ansible Galaxy Hub)
Единый UI соответствует поставленным целям, например переиспользование кода, и дополнительно обеспечивает единый визуальный пользовательский опыт при работе с компонентами, которые в итоге являются upstream'ами Ansible Automation Platform. Стоит обратить внимание, что изменение UI в основную ветку проекта внесено уже после последнего доступного релиза AWX 24.6.1.
А что с плагинами: еще одна деталь конструктора
Многие плагины источников инвентаря (например, ec2, azure_rm, vmware, terraform) и плагины учётных данных (например, aws, github_token, openstack) перемещаются в новый, выделенный репозиторий плагинов. Логика изменений проста: если вам нужно было протестировать, например, плагин для работы с VMware, раньше требовалось поднимать полноценный экземпляр AWX. Теперь плагин можно тестировать изолированно, а кодовая база AWX уменьшается, что значительно упрощает разработку в рамках отдельных проектов и снижает порог входа для контрибьюторов.
Публикация на форуме, анонсирующая изменения UI и плагинов, доступна по ссылке.
RBAC и аутентификация: прощай enterprise
Одно из самых ключевых изменений, которое затрагивает большинство корпоративных пользователей, стало удаление из проекта AWX механизмов внешней аутентификации. Это касается LDAP, OAuth2, SSO (включая Azure, GitHub, Google, OIDC и SAML), RADIUS и TACACS+. Вместе с ними "отъезжает" и функциональность управления доступом на основе ролей (RBAC).
Теперь в ядре AWX по умолчанию остаётся только базовая аутентификация по локальному логину и паролю. Технически это не "удаление фич" - вся логика аутентификации и авторизации переезжает в отдельный, общий компонент/библиотеку в репозиторий ansible/django-ansible-base (далее DAB). Идея состоит в том, чтобы создать общий слой аутентификации, который будет использоваться не только в AWX, но и в других проектах, таких как Event-Driven Ansible и Private Automation Hub (galaxy_ng). Опять же, это соответствует цели рефакторинга - устранению дублирования кода и упрощению кодовой базы AWX.
Публикация с анонсом на форуме по ссылке.
AWX Operator и Helm: запутанная история
AWX Operator - это Kubernetes-оп��ратор для развертывания и управления жизненным циклом AWX в кластерах Kubernetes. Оператор всегда находился в отдельном от AWX репозитории ansible/awx-operator. Интересно, что изначально оператор в 2019 году разработал Jeff Geerling, достаточно легендарная личность в мире Ansible, а затем проект был передан сообществу для дальнейшей поддержки и развития. В 2022 году в проект AWX Operator был добавлен код Helm-чарта, а сам оператор был опубликован Red Hat на OperatorHub.
Спустя два года, в августе 2024, в рамках процессов, затрагиваемых в этой статье, Red Hat удалила оператор из OperatorHub (при этом образы на Quay.io остаются). В то же время Helm-чарт отделяется в новый репозиторий ansible-community/awx-operator-helm.
Судя по анализу коммитов обоих репозиториев можно сказать, что активность продолжается. Ранее релизы AWX Operator всегда шли в "комплекте" с ключевыми релизами AWX. Последний "совместный" релиз вышел 2 июля 2024 года, версия AWX Operator 2.19.1 и AWX 24.6.1. После этого релизы есть только у Helm-чарта, все последние версии которого (3.0.0, 3.1.0, 3.2.0) используют тот же оператор и развертывают ту же версию AWX.
Helm Chart Tag | Chart Version | AWX Operator | AWX (по умолчанию) |
|---|---|---|---|
awx-operator-3.2.0 | 3.2.0 | 2.19.1 | 24.6.1 |
awx-operator-3.1.0 | 3.1.0 | 2.19.1 | 24.6.1 |
awx-operator-3.0.0 | 3.0.0 | 2.19.1 | 24.6.1 |
А по этой ссылке публикация с анонсом изменений.
Когда ждать новых релизов AWX: предсказание на коммитах
В посте «Streamlining AWX Releases» сообщается о переходе на CalVer (Calendar Versioning) и паузе в релизах до завершения основных архитектурных изменений. Подобное предупреждение есть и в самом репозитории проекта. AWX 24.6.1 на момент публикации статьи уже 1,5 года является последним релизом и, видимо, так и останется на период, пока команда внедряет эти фундаментальные изменения. Активность репозитория показывает, что работа продолжается, проект развивается, новые фичи добавляются, ошибки и уязвимости устраняются. Несложная проверка количества коммитов:
aanpleev@~/.../src/awx$ cat ../activity_check.sh printf "Коммитов в сентябре 2025: %3d\n" "$(git log --since=2025-09-01 --before=2025-10-01 --oneline | wc -l)" printf "Коммитов в октябре 2025: %3d\n" "$(git log --since=2025-10-01 --before=2025-11-01 --oneline | wc -l)" printf "Коммитов в ноябре 2025: %3d\n" "$(git log --since=2025-11-01 --before=2025-12-01 --oneline | wc -l)" printf "Коммитов в декабре 2025: %3d\n" "$(git log --since=2025-12-01 --before=2026-01-01 --oneline | wc -l)" printf "Коммитов в январе 2026: %3d\n" "$(git log --since=2026-01-01 --oneline | wc -l)" echo "-------------------------------" printf "Коммитов после 2 июля 2024: %3d\n" "$(git log --since=2024-06-03 --oneline | wc -l)" aanpleev@~/.../src/awx$ ../activity_check.sh Коммитов в сентябре 2025: 70 Коммитов в октябре 2025: 15 Коммитов в ноябре 2025: 12 Коммитов в декабре 2025: 12 Коммитов в январе 2026: 14 ------------------------------- Коммитов после 2 июля 2024: 746 aanpleev@~/.../src/awx$ git remote -v origin https://github.com/ansible/awx.git (fetch) origin https://github.com/ansible/awx.git (push)
Но длительная пауза, отсутствие четкого понимания релизных циклов создает неопределенность, в условиях которой организации, планирующие внедрение или использующие AWX, вынуждены принимать решения.
Стоит ли в 2026 году надеяться на долгожданный релиз с новой архитектурой?
Критический анализ изменений: конструктор без инструкций и лабиринт зависимостей
Суммируя все изменения, можно сформулировать основной вывод: AWX перестал быть коробочным решением. Он превращается в ядро, или фреймворк, вокруг которого предполагается самостоятельная сборка недостающих компонентов. С технической точки зрения это имеет большое значение для коммерческого Ansible Automation Platform, который включает несколько компонентов, и использование единого слоя аутен��ификации и унифицированный UI для всех компонентов - правильная архитектура. Однако для пользователей upstream-проекта AWX это решение создает серьезные проблемы:
Увеличение числа зависимостей. Вынос функциональностей в отдельные библиотеки увеличивает число зависимостей проекта. Теперь вместо одного проекта AWX пользователь должен работать с несколькими (awx, DAB, UI, awx-operator).
Больше интеграции и их сложности. Поскольку AWX больше не готовое решение «из коробки» и для большей части сообщества это фактически означает деградацию функциональности. В анонсе на форуме Ansible об этом сказано совершенно прозрачно: "Community projects built from AWX source will need to maintain their own integration if they require authentication functionality." Другими словами, если планируете использовать внешние аутентификации или тонко настраивать права доступа, вам придётся самостоятельно интегрировать AWX с DAB и поддерживать эту интеграцию.
На практике, в российских реалиях это означает, что AWX в «чистом» виде перестаёт быть готовым бесплатным решением для корпоративной среды. Использовать его в инфраструктуре, где требуется централизованное управление доступом, теперь практически невозможно без серьёзных доработок. По нашему опыту и на момент написания статьи (январь 2026 года) в публичном доступе отсутствует прямой документация о том, как интегрировать DAB с собранным из исходников AWX.Особенности импортозамещения. Внешние аутентификации через LDAP (Active Directory/ALDPro/FreeIPA) или SAML/OIDC (Keycloak) в российских корпоративных средах являются практически стандартными вариантами. В контексте санкций и импортозамещения AWX был привлекательным вариантом именно потому, что предоставлял полнофункциональное решение без лицензионных ограничений. Теперь же нужно вкладывать дополнительные ресурсы в интеграцию, возможно даже в виде отдельной команды разработки, либо искать альтернативы.
Есть ли будущее: upstream для умелых
Так что же, мертв ли проект AWX?
AWX в том виде, в котором его многие знали последние 7–8 лет, фактически прекратился летом 2024 года. Проект трансформируется и становится менее "коробочным" и более модульным: UI, аутентификация и управление привилегиями выделены в независимые проекты, а ядро освобождается от дублированных функций для упрощения и скорости развития.
В процессе изучения материалов для подготовки статьи сложилось ощущение, что направление развития AWX усиливает его роль в качестве upstream для компонента Ansible Automation Platform от Red Hat, а не готового для использования решения. Это наблюдение подтвердилось выходом очередного анонса на форуме. Но при этом исходники и лицензии AWX остаются открытыми. Если не вдаваться в детали, ситуация отдаленно напоминает то, что произошло с RHEL в 2023 году, когда сообществу оставили исходники только в рамках upstream проекта CentOS Stream, а стабильные сборки и релизы только в виде коммерческого продукта RHEL.
Эти изменения являются логичными и правильными как для экосистемы Ansible, так и для Ansible Automation Platform. Однако для сообщества, и особенно для корпоративных пользователей в России, это серьезный вызов из-за значительно возросшего порога входа при использовании AWX в серьёзных проектах.
Подходит ли вам AWX? Да, если:
Вы готовы использовать AWX 24.6.1 (от 2 июля 2024 года) - на текущий момент это последний доступный релиз с функциональностью SSO/LDAP и RBAC, с готовыми сборками и документацией от сообщества. Но учитывайте неустраненные уязвимости и ошибки. От вас потребуется огромная работа по анализу рисков и применение дополнительных мер по их снижению. Также могут быть сложности с масштабированием и обновлением с выходом (если они все-таки выйдут) новых релизов.
В организации есть сильная команда разработчиков и DevOps и вы готовы инвестировать время и ресурсы в сборку кастомного решения из AWX(devel) c интеграцией с DAB, UI и плагинами.
Когда стоит рассмотреть коммерческие решения на базе AWX:
Если вам нужна стабильная, поддерживаемая платформа с работающими «из коробки» SSO, RBAC и другими enterprise-функциями.
Если у вашей команды нет ресурсов или экспертизы на «сборку» и поддержку конструктора из разрозненных компонентов.
Заключение на сладкое
На российском рынке в качестве альтернативы AWX можно рассмотреть коммерческий продукт Astra Automation (на февраль 2026 доступна версия 2.0). Ранее мы уже публиковали краткий обзор состава платформы на Хабре. Платформа объединяет в едином веб-интерфейсе несколько ключевых компонентов экосистемы Ansible:
актуальную devel-ветку AWX (Automation Controller для автоматизации процессов)
проект Event-Driven Ansible (Event-Driven Automation для обработки событий)
galaxy-совместимый портал (Automation Hub для работы с контент автоматизации)
Astra Automation поддерживает различные модели развертывания ("классический" и в Kubernetes), полноценный LDAP/SSO/RBAC и ориентирована именно на корпоративные требования (включая импортозамещение). Добавлю к преимуществам джентльменский набор коммерческого продукта: предсказуемый жизненный цикл релизов, понятная дорожная карта, документация, материалы для обучения и техническая поддержка.
При этом, работая с платформой, вы полностью остаётесь в экосистеме Ansible: galaxy-портал, playbook'и, коллекции, среды исполнения, а так же накопленный опыт и знания AWX используются на 100%. Подходит ли Astra Automation именно вашей команде - это вопрос открытый, который мы готовы обсуждать с вами в любом формате: демо, пилоты, технические обсуждения, расчеты и пр. Делитесь в комментариях своим мнением и мыслями.
Ожидайте следующих публикаций и спасибо, что дочитали до конца!
