AWX вместо Ansible Tower: разворачиваем open-source UI для централизованной автоматизации

Ansible Tower - хороший продукт, но у него есть одна особенность которая портит настроение: лицензия. На инфраструктуре крупного клиента с парой сотен хостов это превращается в разговор с procurement-отделом на несколько месяцев. AWX 1.0 вышел в сентябре прошлого года как open-source upstream-версия Tower, без ограничений по числу нод и без лицензионных платежей. Мы взяли его под один из наших managed-проектов и разобрались что там реально работает, а где придётся смириться.

Зачем вообще Tower-образная надстройка

До AWX у клиента было примерно то, что бывает когда Ansible используют «как получилось»: роли живут в нескольких репозиториях с разной структурой, запускают playbooks с ноутбуков через ansible-playbook, кто именно что запустил - восстанавливается только через Slack-переписку. При десяти серверах это ещё терпимо. При двухстах - уже нет.

Нам нужны были три вещи. Первое - аудит-лог: кто, когда, какой playbook, с какими переменными, что получилось. Второе - RBAC: команда разработки может деплоить своё приложение, но не может трогать сетевую конфигурацию или базы данных - это отдельные зоны ответственности. Третье - расписание: ночные задачи по обслуживанию серверов сейчас запускаются через cron с control-ноды, и это хрупко - если нода недоступна, задача молча не выполнится.

Tower закрывает всё три из коробки. AWX - тот же Tower, только без поддержки Red Hat и без платежей за лицензию.

Разворачиваем AWX

AWX распространяется как набор Docker-контейнеров под оркестрацию либо через docker-compose, либо через OpenShift/Kubernetes. Мы выбрали docker-compose как самый прямолинейный вариант - кластер Kubernetes у клиента есть, но тащить туда AWX на первом этапе показалось избыточным.

Установка через официальный installer/ - это Ansible-playbook, который сам разворачивает стек. Звучит рекурсивно, и так оно и есть:

git clone https://github.com/ansible/awx.git
cd awx/installer
# Правим inventory: postgres_data_dir, secret_key, admin-пароль
ansible-playbook -i inventory install.yml

После прогона поднимается пять контейнеров: awx_web, awx_task, awx_rabbitmq, awx_memcached и Postgres. Первый запуск базы занимает несколько минут - AWX применяет миграции и создаёт начальные объекты. Потом на порту 80 появляется веб-интерфейс.

Первая неочевидность: AWX не хранит данные о хостах - он работает с динамическими инвентарями. Для нашего случая это означало подключить inventory-скрипт который забирает список хостов из нашей CMDB. Статический инвентарий тоже поддерживается, но это уже шаг назад.

Credentials, Projects, Job Templates

Три основных сущности с которыми работаешь каждый день.

Credentials - хранилище для SSH-ключей, паролей от vault, токенов. AWX шифрует их, и самое важное: при запуске задачи учётные данные подставляются в контейнер, но никогда не отображаются в UI и не попадают в лог. Разработчик может запустить деплой с production-ключом, который у него никогда не был в руках. Это одна из причин почему Tower-архитектура в enterprise не просто красивая идея.

Projects - репозитории с playbooks. AWX синхронизирует их по расписанию или вручную. Можно указать конкретную ветку или тег - это позволяет запускать staging-деплой из develop, а production - только из тегированных релизов. Мы строим workflow через Git уже несколько месяцев, и AWX сюда встраивается без трений.

Job Templates - это и есть основная единица запуска. Здесь связываются: inventory, credentials, playbook, extra variables. К шаблону можно прикрутить survey - форму с параметрами, которую пользователь заполняет перед запуском. Например: выбрать окружение (staging/production), версию пакета, ветку. Без кодирования, просто через UI.

RBAC: кто что может трогать

Модель прав в AWX иерархическая: Organizations -> Teams -> Users. На каждый объект (inventory, credential, job template) можно выдать: use, execute, admin.

Для нашего случая это выглядело так:

• разработчики попадают в команду Developers - у них есть execute на шаблоны деплоя их сервисов, но нет доступа к credentials для production-баз данных;
• сетевые инженеры - отдельная команда с доступом к шаблонам конфигурации сети и к соответствующим credential-объектам;
• DevOps-команда имеет admin-права на всё в рамках organization.

На практике настройка RBAC заняла больше времени чем сама установка AWX - не потому что инструмент сложный, а потому что пришлось договориться внутри клиента кто к чему должен иметь доступ. Инструмент только фиксирует решения, принять их должны люди.

Scheduled Jobs и уведомления

Scheduled Jobs - это cron поверх Job Templates. Синтаксис стандартный, результат запуска виден в истории с полным логом. Если задача упала - AWX может отправить нотификацию: email, Slack, PagerDuty, webhook. Настраивается на уровне шаблона.

Это закрыло нашу третью проблему: ночные задачи по обслуживанию переехали с control-ноды в AWX, и теперь видно не только что они запустились, но и что именно выполнилось, сколько времени заняло, и были ли changed/failed хосты.

Что стоит иметь в виду

AWX - это upstream, и он движется быстро. Версия 1.0 вышла в сентябре, сейчас уже 1.0.6, и между ними были заметные изменения в API и поведении scheduler. Red Hat явно использует AWX как площадку для обкатки изменений перед переносом в коммерческий Tower. Это значит что API может меняться, и если у вас написаны скрипты которые дёргают AWX по API - надо следить за changelog.

Upgrade AWX - это пересоздание контейнеров с новым образом и миграция базы. Процедура описана в документации, у нас прошла без проблем, но бэкап базы перед этим обязателен.

Высокая доступность в AWX не предусмотрена в docker-compose-установке - это single point of failure. Для нашего клиента это принято как компромисс: AWX не лежит в critical path приложений, он управляет автоматизацией, и час недоступности UI не означает падения продакшна. Если такой компромисс неприемлем - нужно смотреть в сторону OpenShift-деплоя или платного Tower с поддержкой HA-конфигурации.

Ansible-плейбуки на сетевом оборудовании клиент тоже перенёс в AWX - теперь инженер запускает конфигурацию коммутаторов через UI с survey вместо прямого вызова playbook. Это оказалось неожиданно удобным: меньше шансов передать не те переменные или случайно запустить не на том инвентаре.

В целом: AWX делает именно то для чего предназначен, установка не требует магии, и для клиента с парой сотен хостов это рабочая альтернатива платному Tower. Минус - нет коммерческой поддержки и документация местами отстаёт от кода. Плюс - ноль рублей за лицензию.