Ansible Tower 3.3: Workflow Templates и цепочки плейбуков с ветвлением

Долгое время наш деплой в Tower выглядел так: кнопка запуска одного Job Template, который делал всё подряд - провизионирование, конфигурацию, рестарт сервисов. Один большой плейбук на двести задач, который выполняется линейно. Если на шаге 150 падала конфигурация nginx, плейбук останавливался, но всё что было до - уже применено. Состояние хоста оказывалось в полупровизионированном виде, и следующий запуск нужно было делать с умом, чтобы не задублировать.

Tower 3.3 добавил Workflow Templates - и это меняет подход к организации автоматизации на уровне архитектуры.

Что такое Workflow Template

Это граф Job Template-ов с ветвлением. Каждый шаг - это существующий Job Template со своим плейбуком, инвентарём и переменными. Между шагами проводятся рёбра: on_success и on_failure. То есть:

• Шаг 1 - провизионирование запускается первым.
• Шаг 2 - конфигурация запускается только если шаг 1 успешен.
• Шаг 3 - smoke-тест запускается только если шаг 2 успешен.
• Шаг 4 - rollback запускается только если шаг 2 или 3 упали.

Это не просто «запустить плейбуки последовательно». Это условная логика без написания кода условий - прямо в UI Tower, через визуальный редактор.

Граф можно ветвить и объединять: два параллельных шага конфигурации (скажем, настройка приложения и настройка мониторинга-агента) сходятся в один шаг дымового теста. Tower параллелит их самостоятельно.

Как это выглядело на конкретной задаче

У нас есть managed-клиент с периодическим деплоем сервисов на несколько групп серверов. До 3.3 деплой делался одним большим плейбуком, который последовательно поднимал зависимости, раскатывал приложение и делал curl-проверку. Это работало, но у плейбука был неудобный интерфейс перезапуска при сбое: нужно было смотреть на какой таске упало, вручную выставлять --start-at-task или комментировать уже выполненные части.

С Workflow Template деплой стал выглядеть как три отдельных Job Template:

Первый - provision-base: устанавливает пакеты, создаёт пользователей, монтирует диски. Идемпотентный, безопасно гонять повторно. Запускается на [new_hosts] группу.

Второй - configure-app: раскатывает конфиг из шаблонов, кладёт артефакт сборки, рестартует сервис. Запускается только при успехе первого.

Третий - smoke-test: простой плейбук с uri модулем, который делает несколько HTTP-запросов к задеплоенному приложению и проверяет коды ответов и ключевые паттерны в теле ответа.

Если smoke-test падает - срабатывает on_failure ребро к четвёртому шагу: notify-oncall, который через Slack-модуль отправляет сообщение с деталями упавшего job-а. Rollback не автоматизирован - это осознанное решение, потому что автоматический rollback в нашем случае опаснее ручного вмешательства. Но факт падения с контекстом прилетает сразу.

Весь этот граф запускается одной кнопкой или по webhook-у из CI. Tower отображает прогресс по каждому шагу прямо в визуальном редакторе - видно что выполнилось, что в процессе, что упало.

RBAC: что изменилось в 3.3

Второй крупный блок обновления - гранулярность прав. В прошлых версиях Tower RBAC работал на уровне организации: пользователь либо Admin, либо User с ограниченными правами. В 3.3 права можно раздавать на уровне:

• отдельного Job Template (запуск но не редактирование, или только просмотр)
• Workflow Template (аналогично)
• конкретного Inventory (чтение, обновление, использование в шаблонах)
• Credential (только использование - пользователь может запускать шаблоны, которые используют credential, но не видит его содержимое)

Для enterprise это существенно. У клиента есть несколько команд: команда платформы (пишет и редактирует плейбуки), команда эксплуатации (запускает деплой на продакшн), команда разработки (запускает деплой на staging). Раньше чтобы дать разработчикам возможность самим катить на staging - нужно было либо делать отдельный Tower, либо давать слишком широкие права.

Сейчас это решается через роли: Dev-team получают роль execute на Workflow Template, который направлен на staging-инвентарь. На продакшн-инвентарь у них нет прав вообще. Команда эксплуатации получает execute на продакшн-шаблоны. Команда платформы - admin на всё. Всё это управляется через Tower UI или API, и аудит кто что запускал пишется в лог автоматически.

Credential-permissions - отдельная ценная вещь. SSH-ключи для продакшна лежат в Tower как Machine Credential. Команда разработки не может их выгрузить или посмотреть, но шаблон может ими воспользоваться при запуске. Это лучше чем раздавать ключи в файлах.

Что стало неудобным

Workflow Template удобен когда плейбуки уже разбиты на логические единицы. Если у вас один большой плейбук на пятьсот задач - workflow из него не сделать без предварительного рефакторинга. Нам пришлось потратить время на разбивку перед тем как пользоваться новым функционалом.

Ещё момент: Workflow Template не может передавать переменные между шагами напрямую. Если шаг 1 что-то вычисляет (например, IP-адрес созданной машины) и это нужно шагу 2 - это надо решать через общий инвентарь или через артефакты во внешнем хранилище. Встроенного механизма пайплайн-переменных нет, и это иногда ощущается.

Где мы сейчас

Для клиентских инсталляций, где деплой состоит из нескольких логически отдельных фаз, Workflow Templates - это первое что мы теперь настраиваем. Разбивка на провизионирование + конфигурация + проверка даёт понятный журнал: видно на каком именно шаге что-то пошло не так, а не в каком месте большого плейбука.

RBAC в 3.3 дорос до состояния, при котором Tower можно давать разным командам с разными уровнями доступа - это делает его реально корпоративным инструментом, а не просто красивым фронтендом к Ansible.

Есть ещё момент с Ansible Tower и лицензиями - стоимость растёт с количеством управляемых узлов, и для крупных инсталляций это становится заметной статьёй. Но это отдельный разговор, не связанный напрямую с функциональностью 3.3.