Как мы автоматизируем демо-стенды Astra Automation: архитектура WMS и практические сценарии

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

В WMS (Workshop Management System) мы как раз убирали это трение и выстраивали процесс так, чтобы стенд Astra Automation запускался быстро, предсказуемо и без лишней суеты. В итоге получился понятный сценарий: около 10–15 минут на запуск, после чего система уже сама доводит жизненный цикл стенда до завершения.

1. С чего началась проблема

На малом количестве стендов ручной подход обычно выглядит вполне терпимо. Но как только у команды в один период сходятся обучение, демо и пилоты, процесс начинает буксовать: 

• стенды готовятся дольше;

• ручные действия повышают вероятность ошибок;

• конфигурации перестают быть по-настоящему одинаковыми;

• перенос этого подхода на несколько команд превращается в отдельную организационную задачу.

2. Что такое WMS на практике

WMS — это полностью управляемый кодом конвейер на базе Astra Automation, включающий в себя ряд этапов:

• запрос параметров создаваемого стенда;

• развертывание инфраструктуры;

• пост-настройка узлов стендов;

• выдача доступов;

• автоочистка по TTL (time-to-live — «время жизни»).

Ключевой момент: пользователь получает не просто набор виртуальных машин, а готовую рабочую среду с необходимыми компонентами и управляемыми узлами.

3. Репозитории и pipeline

Под капотом наших стендов находится связка из Ansible, Terraform и Astra Automation.

Ответственность между инструментами разделена так: Terraform создает инфраструктурный слой в облаке (сети, ВМ, диски и состояние стенда), Ansible отвечает за конфигурацию и пост-настройку узлов, а Astra Automation добавляет поверх этого управляемый контур: запуск шаблонов,  заполнение исходных параметров, credentials, инвентари, историю выполнения, права доступа и расписания для служебных задач.

Код WMS при этом разделен на два репозитория:

• workshop-env — основной «движок» развертывания;

• workshop-configs — конфигурационный слой с параметрами окружений и профилями стендов.

В workshop-env хранится все, что отвечает за непосредственное создание стенда, включая Ansible playbook’и, Terraform шаблоны, задачи на создание и удаление стендов, настройку inventory и credentials.  Если говорить совсем просто, именно здесь находится логика, по которой стенд разворачивается.

В workshop-configs хранится все, что чаще меняется от сценария к сценарию, включая параметры окружений dev, ci, prod и presale, ID разворачиваемых образов, настройки ресурсов и WID профили. Это репозиторий с данными, который определяет, какой именно стенд нужно получить. 

Это удобно в эксплуатации, потому что логику развертывания и пользовательские настройки можно менять по отдельности. Поэтому обновление playbook’ов или Terraform шаблонов в workshop-env не затрагивает профили, а добавление нового WID или набора образов в workshop-configs не требует правок в pipeline.

Если коротко, архитектура репозиториев выглядит так:

Структура репозиториев

В результате развертывания клиент получает полнофункциональный стенд Astra Automation и преднастроенную среду разработки VS Code.

3.1. Ключевые этапы создания

Ниже представлены основные шаги, выполняемые при создании стенда пользователя, в порядке их выполнения:

1. Подготовка необходимых переменных и генерация runtime-конфигурации.

2. Проверка существования стенда для пользователя — в существующей архитектуре один пользователь может создавать только один стенд.

3. Создание учетных данных пользователя.

4. Развертывание ресурсов в облаке через Terraform.

5. Создание инвентаря в контроллере Astra Automation.

6. Запуск шаблона с пост-конфигурацией виртуальных машин.

7. Вывод endpoint-ов и отправка уведомления пользователю в личный кабинет и на электронную почту.

3.2. Что получает пользователь

Снаружи все выглядит довольно просто. Пользователь выбирает нужный тип стенда, запускает процесс и через некоторое время получает уже готовое окружение.

За простым пользовательским сценарием скрывается несколько автоматизированных этапов: запуск задания в контроллере, подготовка конфигурации, создание ресурсов, пост-настройка и отправка доступа пользователю.

4. Гибкость стендов

WID по сути служит идентификатором готового профиля стенда. Настроенная нами интеграция передает его в параметре wid, после чего WMS забирает из репозитория workshop-configs нужный YAML файл.

Внутри профиля описывается не вся платформа Astra Automation, а именно дополнительные управляемые узлы, которые должны появиться рядом с базовыми компонентами стенда. За базовый стек с Gateway, Controller, Hub, EDA и DB отвечает общая логика развертывания. WID в этой схеме нужен уже для практической части и определяет, каким именно будет окружение, сколько в нем узлов, какого они размера, на каких образах работают и нужен ли им внешний IP адрес.

Сейчас у нас есть несколько типов WID:

• wo-nodes — профиль без дополнительных управляемых узлов, когда нужен только базовый контур Astra Automation;

• default и small — минимальный учебный стенд с одним небольшим узлом Astra Linux;

• medium, medium-2, medium-4, medium-5 — варианты с одним или несколькими узлами среднего размера;

• alse-centos — смешанный стенд с Astra Linux и CentOS;

• presale-demo — расширенный пресейл профиль с Astra Linux, CentOS и кастомным сетевым образом Cisco;

• custom-config — шаблон для будущих кастомных конфигураций.

Например, в presale-demo можно одновременно поднять Astra Linux, CentOS и кастомный сетевой образ:

Стенд с тремя хостами

Это удобно как для демонстраций, так и для практических занятий, где используется смешанная конфигурация стека.

5. Почему стенд получается быстро

Главный практический трюк здесь в том, что для основных компонентов Astra Automation мы заранее готовим образы виртуальных машин, включая Controller, Hub, DB, EDA и Gateway.

Идея простая:

• базовые компоненты уже включены в соответствующие образы;

• при создании стенда не тратим время на полную установку с нуля;

• основной объем работы приходится на инициализацию и донастройку инфраструктуры.

Важно не перепутать этот подход с ручными снапшотами, которые кто-то когда-то собрал и оставил лежать без изменений. Для стендов у нас есть базовый UBI на основе подготовленного образа Astra Linux из линейки MG образов, а первичная настройка виртуальных машин выполняется через cloud-init. После этого из общей базы получаются отдельные образы под конкретные компоненты платформы, такие как Controller, Execution Node, Hub, DB, EDA и Gateway.

Актуальные идентификаторы образов хранятся не в playbook-е, а в конфигурации окружения workshop-configs/environments/prod/vars.yml . Например, там отдельно задаются:

Структура хранения образов

При выходе новой версии Astra Automation мы обновляем не весь механизм развертывания, а набор образов. В основном репозитории workshop-env этот сценарий вынесен в отдельный playbook ansible/playbooks/create_images.yml. Он разворачивает стенд с обновленной версией, снимает образы с полученных виртуальных машин и сохраняет их ID. После этого в дело вступает playbook update_images.yml и обновляет соответствующие aac_image_id, ah_image_id, db_image_id, eda_image_id, exec_image_id и gw_image_id в конфигурациях окружений. После этого новые стенды автоматически начинают использовать свежие образы, а основной pipeline остается прежним.

В результате использования такого подхода развертывание типового стенда укладывается примерно в 10-15 минут (против минимальных 50-60 минут ручного поднятия).

6. Автоочистка

если не автоматизировать процесс удаления развернутых ВМ, временные стенды будут жить вечно.  
Поэтому в WMS мы разработали cleaner, реализующий следующие функции:

• проверка возраста стендов;

• рассылка уведомлений: о скором уничтожении стенда и о том, что стенд удален;

• удаление просроченных окружений тоже автоматизировано. По умолчанию стенд живет 4 часа, и этого времени обычно хватает, чтобы пройти обучающий сценарий или спокойно провести демо.

Для регулярного запуска автопроцедуры очистки стендов со стороны бэкенда в Astra Automation используется расписание.  
С эксплуатационной точки зрения без этого никуда. Если автоочистки нет, демо инфраструктура быстро обрастает временными виртуальными машинами и через какое-то время начинает напоминать кладбище забытых стендов.

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

7. Где WMS особенно полезен

Оказалось, что WMS одинаково хорошо работает в трех мирах:

7.1. Обучение

• каждому обучающемуся предоставляется собственный изолированный стенд;

• WMS предоставляет минимальный time-to-start;

• cleaner реализует автоматическое освобождение ресурсов после практики.

7.2. Presale

• с помощью WMS мы можем быстро запустить стенд для клиента;

• архитектура проекта создана таким образом, что мы можем легко добавить новый состав разворачиваемых хостов;

• end-to-end демонстрация автоматизации на реальных узлах.

7.3. Внутреннее тестирование

• с помощью стендов WMS мы можем проверять работу ansible playbook-ов в повторяемой среде;

• сравнение профилей стенда;

• меньше «у меня не воспроизводится».

8. Что получилось в итоге

Сравним, как изменились ключевые параметры развертывания после внедрения WMS

Таким образом, благодаря использованию dev-ops практик мы полностью автоматизировали процесс создания учебных стендов Astra Automation и сделали воспроизводимость нормой. Скорость развертывания существенно выросла, ручных операций стало заметно меньше, а поддержка стендов теперь максимально предсказуема.