AWX — открытая версия контроллера автоматизации Red Hat Ansible Automation Platform. Это веб-интерфейс и API поверх Ansible: проекты хранят плейбуки из Git, инвентари описывают хосты, учётные данные лежат в зашифрованном виде, а задания запускаются по расписанию, вручную или по цепочке. AWX не заменяет Ansible, а добавляет к нему управление доступом, журнал запусков и изоляцию окружений. Ниже — установка на Kubernetes, первый проект, шаблон задания и диагностика.

Что даёт AWX и чего он не делает

AWX выполняет плейбуки в execution environment — контейнерах с Ansible и нужными коллекциями. Это решает главную боль ручных запусков: на сервере не нужно держать зависимости, а результат каждого запуска сохраняется с кодом возврата и выводом. При этом AWX не является системой мониторинга и не хранит состояние хостов: он лишь запускает задачи и показывает, что произошло.

  • Роли и команды с разграничением прав на проекты и шаблоны.
  • Хранилище секретов: пароли и ключи не попадают в плейбуки.
  • Расписания и workflow из нескольких шаблонов подряд.
  • Журнал запусков с пошаговым выводом и поиском по нему.

Важное ограничение: установка через docker-compose больше не поддерживается, нужен Kubernetes. Для домашнего стенда достаточно k3s на одной машине.

Подготовка кластера

Оператору нужен рабочий кластер и kubectl. На чистой машине проще всего поставить k3s: он занимает один бинарник и не требует отдельного etcd.

curl -sfL https://get.k3s.io | sh -
sudo k3s kubectl get nodes
mkdir -p ~/awx && cd ~/awx

Для k3s удобно скопировать конфиг в домашний каталог, чтобы не писать sudo перед каждой командой. Если кластер уже есть, шаг пропускают. Перед установкой стоит проверить, что в кластере есть StorageClass по умолчанию: без него поды базы данных останутся в состоянии Pending.

Установка оператора

Оператор ставится через Kustomize. В файле указывают конкретный тег релиза, а не ветку devel: иначе версия может измениться между применениями и поведение стенда перестанет быть воспроизводимым.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - github.com/ansible/awx-operator/config/default?ref=2.7.2
images:
  - name: quay.io/ansible/awx-operator
    newTag: 2.7.2
namespace: awx

После kubectl apply -k . в пространстве имён awx появляется контроллер. Готовность проверяют по поду с двумя контейнерами: менеджер и kube-rbac-proxy. Если под висит в ImagePullBackOff, причина обычно в недоступности реестра или опечатке в теге.

Создание инстанса AWX

Сам AWX описывается ресурсом AWX. В спецификации задают тип сервиса и, при необходимости, размеры томов. Для доступа снаружи на домашнем стенде удобен NodePort.

apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx-demo
spec:
  service_type: nodeport
  postgres_storage_class: local-path

Оператор создаст базу PostgreSQL, веб-под, под задач и сервис. Пароль администратора генерируется автоматически и лежит в секрете с суффиксом -admin-password. Его извлекают одной командой и сразу меняют через интерфейс.

kubectl get secret awx-demo-admin-password -o jsonpath='{.data.password}' | base64 -d
kubectl get svc awx-demo-service -o wide
kubectl logs -f deploy/awx-operator-controller-manager -c awx-manager

Первый проект и шаблон задания

Дальше работа идёт в интерфейсе: создают организацию, проект с адресом Git-репозитория, инвентарь и учётные данные. Учётные данные типа Machine содержат ключ SSH и становятся доступны шаблону без раскрытия в плейбуке. Шаблон задания связывает проект, плейбук, инвентарь и окружение.

Для автоматизации удобен CLI awx из пакета awxkit. Он работает через REST API и токен, который создаётся в профиле пользователя.

pip install awxkit
awx login --conf.host https://awx.example.com --conf.token $AWX_TOKEN
awx projects list
awx job_templates launch 7 --monitor

Токен лучше хранить в переменной окружения или в менеджере секретов, а не в истории команд. Для CI тот же API вызывается через curl с заголовком Authorization: Bearer.

Повторяющиеся запуски оформляют расписанием: оно привязано к шаблону и часовому поясу, а не к машине оператора. Для последовательности задач, где важен результат предыдущего шага, строят workflow из нескольких узлов. Это удобнее цепочки в одном плейбуке, потому что каждый шаг виден в журнале отдельно и может выполняться на своём инвентаре.

Execution Environment

Плейбуки с коллекциями и Python-библиотеками требуют собственного образа. Его собирают через ansible-builder по файлу определения, где перечислены зависимости, и публикуют в доступном реестре.

ansible-builder build --file execution-environment.yml --tag registry.example.com/ee/web:1.0
docker push registry.example.com/ee/web:1.0

Тег образа фиксируют, а не используют latest: иначе очередная сборка незаметно поменяет состав коллекций и поведение заданий. В AWX образ указывают в шаблоне задания. Если коллекция не найдена, задание падает ещё до первого шага — это самый частый сбой после переноса плейбука из ручного запуска. Проверить состав образа можно локально командой ansible-galaxy collection list внутри контейнера.

Диагностика

Основные источники информации — поды, события и журналы контейнеров и самого оператора. Под задач показывает вывод запуска, веб-под отвечает за интерфейс и API, а оператор — за согласование ресурсов.

kubectl -n awx get pods
kubectl -n awx describe pod awx-demo-task-xxxxx
kubectl -n awx logs deploy/awx-demo-task --tail=100
kubectl -n awx exec deploy/awx-demo-web -- awx-manage list_instances

Перед обновлением оператора и AWX делают резервную копию ресурсом AWXBackup: он сохраняет базу и секреты согласованно, в отличие от копирования одного тома. Восстановление выполняется ресурсом AWXRestore в новое пространство имён, поэтому стенд для проверки копии не мешает рабочему.

Если задания зависают в ожидании, смотрят awx-manage list_instances и состояние очереди. Если интерфейс отвечает ошибкой 502, проверяют готовность веб-пода и ресурсы узла. Если под задач не запускается, смотрят события пространства имён и выставленные лимиты ресурсов на поды.

Итог

AWX превращает набор плейбуков в управляемый сервис с ролями, расписаниями и журналом. Ставится он оператором на Kubernetes, работает через execution environment и не требует docker-compose. Начинать стоит с одного проекта и одного шаблона, затем добавить резервное копирование и только после этого открывать доступ команде.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте