Установка AWX
Тема дорожной карты · Ansible
Установка AWX — открытого upstream-проекта Ansible Tower — выполняется с помощью AWX Operator, Kubernetes-оператора, управляющего полным жизненным циклом AWX, включая обновления и изменения конфигурации. Рекомендуемый путь установки: развернуть AWX Operator в кластер Kubernetes или K3s командой kubectl apply -f awx-operator.yaml, затем применить манифест кастомного ресурса AWX, задающего имя деплоя, настройки ingress и ограничения ресурсов. Для установки AWX требуется работающий Kubernetes-кластер, постоянное хранилище (для PostgreSQL) и ingress-контроллер; для одноузловых тестовых сред часто используют K3s или Minikube. После того как оператор согласует кастомный ресурс AWX, веб-интерфейс становится доступен на настроенном имени хоста с паролем администратора по умолчанию, получаемым через kubectl get secret <name>-admin-password -o jsonpath="{.data.password}" | base64 --decode.
Как это работает
Установка AWX (теперь Red Hat Ansible Automation Platform / AAP) и его upstream AWX дают веб-UI + REST API поверх Ansible: scheduled jobs, RBAC, audit log, workflow-цепочки (job A → если success → job B), управление credentials, источники inventory. Гоняет Ansible-плейбуки в контейнерах (execution environments) со своими collections + зависимостями, отделённо от контроллера.
Когда применять
AWX или AAP — когда (а) больше 2-3 инженеров гоняют плейбуки (нужны RBAC + аудит), (б) хотите scheduled / triggered автоматизацию, (в) важна ChatOps / self-service интеграция. Для RF-инфры AWX self-hosted на control-VM — практичный выбор. AAP требует Red Hat-лицензии. Маленькие команды остаются с ansible-playbook из CI-раннеров.
Типичные ошибки
Ловушки Установка AWX: сложность деплоя AWX (Kubernetes-based, нетривиальная установка); путаница execution environment (плейбук падает не из-за кода, а из-за пинов collection в EE); утечка credentials через job output (маскируйте sensitive). Планируйте capacity — AWX любит много ядер + RAM для параллельных job.