Ansible Tower 2.4 у клиента с командой из 15 администраторов: журнал, роли, порядок

Есть задача, которая выглядит просто, пока команда маленькая: запустить Ansible-плейбук. ansible-playbook site.yml - и готово. Но когда администраторов пятнадцать и все они в разной степени знают Ansible, эта команда превращается в источник боли. Кто запускал? Когда? С каким инвентарём? Что именно менялось в пятницу вечером перед тем как всё упало?

Именно с таким клиентом мы сейчас разбираемся.

Исходная ситуация

На проекте - смешанная инфраструктура: несколько сотен серверов, Linux и Windows, разные окружения. Ansible использовали уже год - плейбуки в Git, роли, всё как положено. Но запуск - у каждого со своей машины, каждый клонировал репозиторий, обновлял как умел. В результате у одного администратора репозиторий недельной давности, у другого - свежий, у третьего - с локальными правками «на пробу».

Когда число администраторов перевалило за десяток, это стало настоящей проблемой. История изменений есть в Git, но «кто именно запустил плейбук и с какими переменными» - уже нет. Если что-то пошло не так, расследование начиналось с опроса команды.

Почему Tower, а не что-то проще

Очевидное решение - выделить отдельный сервер с актуальным репозиторием и дать всем SSH-доступ туда. Так и было несколько месяцев. Но без ограничений по доступу и без журнала это просто перенесло проблему на один уровень выше.

Ansible Tower даёт три вещи, которые закрывают именно эту боль:

• Централизованный запуск. Плейбуки запускаются с одного сервера, с одной версией кода из Git. Никаких расхождений между «у меня локально» и «в репозитории».
• Ролевое разграничение доступа. Можно задать кто вообще видит какой Job Template, кто может только запускать, кто может менять. Джуниоры не трогают production-плейбуки случайно.
• Журнал всего. Каждый запуск - запись: кто, когда, какой шаблон, какой инвентарь, результат. Полный лог выполнения сохраняется и доступен для просмотра.

Tower 2.4 - это AWX в виде коммерческого продукта с поддержкой от Red Hat. AWX как open source проект на тот момент не существует, Tower - это то, что есть.

Как разворачивали

Сам Tower ставится через собственный установщик на RHEL/CentOS. Под него выделили отдельную виртуалку - Tower хранит всё в PostgreSQL и использует RabbitMQ для очередей задач, так что ресурсы нужны.

Основная работа - не установка, а структурирование того что уже есть:

Инвентарь. В Tower инвентарь можно синхронизировать из внешних источников - у нас это статические файлы в Git. Настроили Source из SCM, Tower сам тянет инвентарь при обновлении репозитория. Больше не надо следить чтобы список серверов был актуальным - он синхронизируется автоматически.

Job Templates. Каждый плейбук оформили как отдельный шаблон с указанием репозитория, ветки, плейбука и инвентаря. Переменные, которые раньше передавались через -e в командной строке, теперь задаются в шаблоне или через Survey - форму с вопросами перед запуском. Администратор выбирает окружение из списка, а не пишет переменную вручную.

Организации и роли. Tower умеет делить пользователей по организациям и назначать роли - Admin, Auditor, Execute, Use. Мы сделали несколько групп: команда, которая только запускает утверждённые шаблоны; команда, которая может создавать и редактировать шаблоны; и несколько человек с полным доступом. Для production-окружения отдельные шаблоны с ограниченным списком тех, кто может их запускать.

Что реально изменилось

Первое и главное - появился журнал. Открываешь Dashboard, видишь последние запуски, кто и что. Jobs - полная история с фильтрацией по пользователю, шаблону, статусу. Когда через неделю после внедрения на одном из серверов обнаружилась неожиданная правка nginx-конфига, выяснить что произошло заняло минуту вместо получасового расследования.

Второе - исчез разброс версий. Все запускают из одного источника. Плейбук обновился в Git - Tower забрал изменения при следующей синхронизации, и все администраторы уже используют актуальную версию. Ситуация «у меня работало» при расхождении локальных копий больше не воспроизводится.

Третье - неожиданное. Survey-механизм понравился тем администраторам, которые хорошо знают инфраструктуру но не очень комфортно работают с Ansible напрямую. Форма с вопросом «выберите окружение: staging / production» и «введите версию пакета» - это не страшно. Они запускают плейбуки сами, без помощи тех кто знает синтаксис переменных.

Где трёт

Notifications - уведомления о завершении задач. Tower умеет слать письма и Slack-сообщения, настроили, работает. Но формат уведомлений минимальный - статус, имя шаблона, ссылка. Для быстрого разбора «что пошло не так» всё равно приходится открывать веб-интерфейс и смотреть лог.

Лицензирование Tower считается по количеству нод в инвентаре. Пока это не проблема, но нужно помнить при росте инфраструктуры.

Интеграция с внешней LDAP-директорией настроена, пользователи заходят через корпоративные учётки - это работает нормально. Но синхронизация групп AD с ролями в Tower потребовала разобраться в документации плотнее чем хотелось бы.

Где сейчас

Внедрение заняло около двух недель - с учётом структурирования шаблонов и обучения команды. Все запуски плейбуков теперь идут через Tower. Первые результаты видны: хаотичного «запустил с ноутбука непонятно что» больше нет.

Следующий шаг, который обсуждаем - Workflows в Tower: цепочки Job Templates с ветвлением по результату. Пока живём с отдельными шаблонами, но для сложных сценариев развёртывания это было бы удобнее.

Для задач managed-сопровождения Tower меняет важную вещь: аудит изменений перестаёт быть ручным процессом.