Backstage с отечественными плагинами: как мы сократили онбординг нового сервиса с трёх дней до двух часов

До ноября прошлого года онбординг нового микросервиса в наш кластер выглядел примерно так: разработчик открывает Confluence, ищет актуальную страницу (обычно с третьей попытки, потому что первые две ведут на устаревшие), потом идёт к DevOps-инженеру с просьбой создать репозиторий в Gitflic, потом - к другому инженеру за Harbor-проектом, потом ждёт, пока кто-нибудь настроит namespace в Kubernetes. Три дня в среднем, если все нужные люди доступны.

Сейчас это занимает около двух часов. Большую часть из них занимает сам разработчик, а не очередь ожидания.

Почему Backstage

Backstage - не единственный IDP-фреймворк, но на сегодня самый зрелый в плане экосистемы. У него большая база плагинов, понятная архитектура через Software Catalog и Templates, и главное - достаточно гибкий plugin API, чтобы прикрутить то, чего нет из коробки.

А не хватало именно отечественного стека. Из коробки Backstage знает о GitHub, GitLab, Bitbucket, Artifactory. Про Gitflic и Harbor - нет.

Что написали сами

Плагин для Gitflic взял на себя основное: создание репозитория через API Gitflic, настройка branch-protection, привязка webhook для CI. API у Gitflic задокументировано достаточно, чтобы написать базовый client за пару дней. Сложнее оказалось с авторизацией - Gitflic использует собственный OAuth, и токен нужно прокидывать через Backstage backend, чтобы не светить его в браузере. Стандартный oauth2-proxy здесь не подошёл, написали небольшой прокси-сервис.

Плагин для Harbor проще: Harbor имеет хорошо задокументированный REST API и давно работает в связке с Kubernetes. Создание проекта, назначение квот, генерация robot account для CI - всё это ложится в Backstage Template как последовательность шагов.

Дополнительно подключили Kubernetes plugin из официальной экосистемы Backstage - он умеет показывать состояние deployments прямо в карточке сервиса. Работает через kubeconfig, никаких сложностей не было.

Как выглядит Template

Software Template - это ключевой механизм IDP в Backstage. Разработчик заходит в portal, выбирает шаблон (у нас их три: Spring-сервис, FastAPI-сервис, статический фронтенд), заполняет форму с именем, командой, уровнем окружения - и запускает.

Под капотом Template делает последовательно:

• Создаёт репозиторий в Gitflic с pre-configured структурой: Dockerfile, базовый CI-pipeline, .gitignore.
• Регистрирует Harbor-проект с именем, соответствующим сервису, и создаёт robot account для CI.
• Создаёт namespace в Kubernetes через GitOps: Template делает PR в наш fleet-репозиторий с манифестами namespace, RBAC и NetworkPolicy.
• Регистрирует сервис в Software Catalog - карточка появляется в portal сразу.

PR в fleet-репозиторий требует ревью от дежурного DevOps-инженера - это намеренное решение. Полностью автоматический namespace - риск, на который мы не готовы.

Где острые углы

Первое - синхронизация состояния. Backstage Software Catalog живёт в своей базе, Gitflic и Harbor - в своих. Если кто-то создал репозиторий в Gitflic вручную, минуя portal, Catalog про него не знает. Решается через периодическую синхронизацию (Backstage умеет читать catalog-info.yaml из репозиториев), но настроить её правильно - отдельная задача. У нас сейчас синхронизация раз в час, что иногда создаёт рассинхрон.

Второе - версионирование Templates. Шаблоны лежат в git, это хорошо. Но если Template изменился, уже созданные сервисы об этом не знают. Backstage не имеет механизма «применить обновление шаблона к существующим сервисам» - это нужно делать руками или скриптами. Пока мы просто ведём changelog Templates и уведомляем команды.

Третье - аутентификация. Backstage поддерживает несколько auth-провайдеров. У нас Keycloak как IdP, и интеграция прошла без сюрпризов. Но если нужна более тонкая авторизация (кто может запускать какой Template) - придётся писать кастомные политики. Встроенного RBAC в Backstage достаточно для базовых случаев, для сложных - нет.

Что получилось на выходе

Два часа вместо трёх дней - это реально, хотя не стоит воспринимать цифру как маркетинговый тезис. В двух часах - время ожидания ревью PR от DevOps-инженера. Без этого ожидания, если инженер рядом, - минут сорок.

Больший эффект - в другом месте. DevOps-инженеры перестали быть «кассирами», к которым надо идти за каждым репозиторием. Это примерно 15-20 запросов в неделю, которые теперь обрабатываются автоматически. Время команды переключилось на более интересные вещи.

Backstage при этом не панацея. Его нужно поддерживать: обновлять плагины, следить за совместимостью, писать документацию для самого portal. Это не «поставил и забыл», это отдельный продукт внутри компании. Если команда к этому не готова - portal быстро превратится в ещё один Confluence с устаревшими страницами.

Мы готовы - поэтому работает.