Дашборд Superset для просмотра статуса деплоя сервисов Git

1       Что было неудобно? И для чего это всё?

Изначально я занимался одним проектом со стороны тестирования в роли старшего тестировщика. У нас микросервисная архитектура — около 15 сервисов хранится в Git. Для тестирования на стенде нужно развернуть примерно 5-7 сервисов за один релиз. Всего стендов два, и после тестирования их же нужно деплоить в продакшн.

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

 Со временем мне стало важно быстро понимать, какие ветки задеплоены на конкретных стендах для всех сервисов, входящих в релиз. В Git такой возможности прямо из коробки нет — нельзя выбрать сразу список сервисов из разных проектов и посмотреть их окружения в виде таблицы или списка.

 Поэтому мне приходилось делать так: заходить в каждый проект, открывать репозиторий сервиса, искать меню «Operate», затем «Environments» и там уже смотреть нужный стенд. И так — для каждого сервиса при деплое на тестовый стенд, при обновлении в продакшн или во время тестирования. 

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

2       Как было по умолчанию?

Я знаю большинство сервисов и могу быстро проверить в Git по любому из них установленную ветку. Мы постоянно создаем и обновляем чек-листы для каждого релиза — в них указаны все сервисы, их версии, теги и ветки. За несколько минут я могу пройтись по всем сервисам релиза в Git, сравнить это с чек-листом и убедиться, что на нужном стенде стоит правильная версия.

Со временем к этому привыкаешь, и на выполнение таких проверок уходит всё меньше времени. Однако с ростом количества проектов появляется новая сложность: у каждого проекта есть свой ответственный тестировщик, который должен следить за тем, чтобы все сервисы во время релиза работали корректно.

3       Почему выбрал Superset?

Несмотря на это, периодически хотелось видеть нужный мне срез сервисов на стенде сразу, а не ходить каждый раз по списку в Git. Ранее что-то подобное видел в разных системах мониторинга. Поинтересовался, что есть в наличии у разработки и девопсов. Из доступного и уже используемого ПО в компании был Superset (BI-платформа с открытым исходным кодом, служащая для визуализации данных и аналитики бизнеса — из вики). Ранее не сталкивался, но альтернатив не было. Посмотрел, как можно в нём отображать информацию — строить красивые графики, таблички и т.д. Сформировал требования, отдал в команду BI. 

4       Как создавал дашборд в Superset?

Процесс состоял из нескольких этапов:

1) Настроить интеграцию Supeset и БД Git

Сделал через запрос в техподдержку.

2) Написать запрос, который вытаскивает необходимые данные из БД

Получил доступ к тестовой базе данных и изучил, какие таблицы и поля нужны. Попробовал написать собственный запрос, но из-за нехватки знаний столкнулся с трудностями. Тогда обратился за помощью к девопсам. Мы вместе посидели около 40 минут, и в итоге я получил рабочий запрос, который до сих пор немного дорабатываю при необходимости.

3) Вставить запрос в Superset и вывести его в дашборд

Здесь мне помог админ BI. Мы прошли несколько итераций, связанных с особенностями именно Superset и настройкой дашборда. Например, запрос к базе данных выполняется без ошибок, а на дашборде отображается неправильно или выглядит не так, как хотелось бы. В течение недели мы решили эти вопросы.

4) Настроить доступы для пользователей

Также через админа сделали, создали несколько групп, раздали права, я получил доступ на редактирование запроса и к формированию дашборда.

5       Использование дашборда

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

Список могу фильтровать по любому значению любого столбца (настраивается в Superset).

В гите проставляю метки (topics) для фильтрации по проекту.

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

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

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

6       Что дальше?

— Периодически вношу изменения в интерфейс — именование столбцов, настройки фильтрации и поиска 

— Добавляю на регулярной основе новые сервисы 

— Планирую добавить столбец для отображения даты отката, т.к. в гите деплой и откат в разных полях хранятся (нужно в БД поискать табличку с откатами, добавить в запрос, в дашборд добавить столбец)

— Планирую добавить возможность просмотра сервисов на стенде за выбранную дату, без привязки к конкретному релизу — что-то вроде версионности. Пока выглядит сложно и кажется проще реализовать это через Git. Но для одного сервиса это легко сделать, а для нескольких — удобнее использовать дашборд.

Вот так, шаг за шагом, мы решаем задачи и совершенствуем наши инструменты. Надеюсь, мой опыт был полезен и вдохновит вас на новые идеи. Удачи в ваших проектах!