Мастер первоначальной настройки применяет подготовленные наборы данных, которые создают модель каталога для главной, правила маппинга, подключения к Kubernetes, Vault и GitLab, источники данных, процессы и виджеты. После мастера главная показывает данные кластеров и репозиториев и позволяет запускать процессы.
Перед началом работы
Для работы мастера требуется разрешение apply:seeds.
Подготовьте адреса внешних систем, которые будут подключены к порталу:
- URL API-сервера Kubernetes, например
https://api.cluster.example.com; - URL Vault или Deckhouse Stronghold, например
https://vault.example.com; - URL GitLab, например
https://gitlab.example.com.
Наборы данных не проверяют, применялись ли они раньше. Повторное применение набора, объекты которого уже есть в портале, завершается ошибкой. Запускайте мастер на портале, где наборы «Каноничной архитектуры» ещё не применялись.
Запуск мастера
Мастер запускается одним из способов:
- кнопкой «Запустить» в баннере «Платформа готова к настройке» на главной;
- кнопкой «Первоначальная настройка» в разделе «Администрирование» → «Справочники» → «Наборы данных».
Баннер видят только пользователи с разрешением apply:seeds. Баннер скрывается для всех пользователей кнопкой «Скрыть» или автоматически после успешного применения всех выбранных наборов.
Чтобы вернуть баннер, включите переключатель «Показывать баннер первоначальной настройки» в разделе «Наборы данных».
Главная выключена после установки портала, поэтому на новой установке баннер не отображается, пока не включён переключатель «Показывать главную».
Шаги мастера
Мастер состоит из пяти шагов: «Пресет», «Выбор», «Параметры», «Проверка», «Прогресс».
Пресет
На шаге «Пресет» выберите один из вариантов:
- «Настройка платформы» — схема каталога, подключения к Kubernetes, Vault и GitLab, процессы и виджеты главной страницы;
- «Настройка платформы с демоданными» — то же самое плюс демоданные: примеры сервисов, ресурсов и запущенных процессов.
Демоданные можно удалить позже в разделе «Наборы данных».
Выбор
На шаге «Выбор» отображаются наборы данных пресета, сгруппированные по слоям: «Схема», «Демоданные», «Инфраструктура», «Провайдеры и операции», «Привязка процессов». Снимите отметку с наборов, которые не нужны.
Мастер не даёт снять отметку с набора, от которого зависят другие выбранные наборы. Такой набор отмечен тегом «Обязательный» и подписью «Нужен для: …». Наборы «Каноничная архитектура (схема)» и «Каноничная архитектура (привязки главной)» заблокированы, пока выбраны наборы с процессами или виджетами для главной.
Параметры
На шаге «Параметры» для каждого выбранного набора отображается панель с его параметрами. Панели с незаполненными обязательными параметрами отмечены звёздочкой.
Мастер заполняет часть параметров автоматически: внешние сервисы и источники данных, которые создаются наборами этого же запуска, подставляются в параметры зависимых наборов. Заполните вручную URL внешних систем. Параметры наборов перечислены в разделе «Наборы данных мастера».
Проверка
На шаге «Проверка» отображается таблица наборов в порядке применения с числом объектов каждого набора. Включите переключатель «Подтвердить применение» и нажмите «Применить».
Прогресс
На шаге «Прогресс» наборы применяются по очереди. Для каждого набора отображается статус: «Ожидает», «Выполняется», «Успех» или «Ошибка».
Если применение набора завершилось ошибкой, очередь останавливается, а объекты уже применённых наборов остаются в портале. Исправьте причину ошибки и нажмите «Повторить с текущего», чтобы продолжить с набора, на котором произошла ошибка. Кнопка «К проверке» возвращает к шагу «Проверка».
Пока очередь выполняется, окно мастера закрыть нельзя. После успешного применения всех наборов отображается сообщение «Все выбранные наборы успешно применены».
Наборы данных мастера
Наборы данных применяются в порядке зависимостей. В таблице перечислены наборы, которые входят в пресеты мастера:
| Набор данных | Что создаёт | Параметры |
|---|---|---|
| «Каноничная архитектура (схема)» | Ресурсы каталога «Архитектура», «Системы», «Микросервисы», «Общие ресурсы», «Kubernetes», «Ingresses», «Deployments», «Namespaces», «Привязки секретов», «GitLab», «Groups», «Кластеры», «Справка», «Интеграции», связи между ними и набор маппинга «Главная (по умолчанию)» с идентификатором home-default | — |
| «Каноничная архитектура (демоданные)» | Демонстрационные сущности системы Billing: системы, микросервисы, окружения, общие ресурсы, развёртывания, кластеры, гайды, интеграции. Входит только в пресет «Настройка платформы с демоданными» | — |
| «Kubernetes» | Внешний сервис «Kubernetes» и тип учётных данных «Kubernetes токен» | «URL Kubernetes API» — обязательный |
| «Vault» | Внешний сервис «Vault» и тип учётных данных «Vault токен» | «URL Vault» — обязательный |
| «GitLab» | Внешний сервис «GitLab» и типы учётных данных «GitLab токен», «GitLab username» | «URL GitLab» — обязательный |
| «Реестр шаблонов микросервисов» | Действия и процессы «Создать микросервис из шаблона», «Обновить микросервис из шаблона», «Развернуть микросервис на окружение», «Удалить микросервис с окружения» | «Провайдер VCS», «Внешний сервис», «Источник данных Deployments», «Источник данных Ingresses» |
| «Kubernetes: deployments, ingresses и namespaces» | Источники данных, которые собирают из кластера Deployment, Ingress и неймспейсы | «Внешний сервис Kubernetes» |
| «Привязка общих ресурсов» | Источник данных «Привязки секретов», процессы «Подключить секреты к приложению» и «Отключить общий ресурс» | «Внешний сервис Kubernetes», «Источник данных Deployments» |
| «Управление окружениями» | Процессы «Создать окружение» и «Удалить окружение» | «Внешний сервис Kubernetes», «Источник данных Namespaces» |
| «GitLab: группы» | Источник данных групп GitLab для выбора пространства при создании микросервиса | «Внешний сервис GitLab» |
| «GitLab: активность репозиториев» | Источник данных, который заполняет в карточке микросервиса число открытых запросов на слияние, последний пайплайн и последний коммит | «Внешний сервис GitLab», «Все репозитории», «ID групп GitLab», «Включать подгруппы» |
| «GitLab: виджеты» | Виджеты «GitLab: пайплайны репозитория» и «GitLab: merge requests репозитория» для вкладок карточки микросервиса | «Внешний сервис GitLab» |
| «Deckhouse managed PostgreSQL», «Deckhouse managed Valkey», «Deckhouse managed Kafka» | Действия, процессы заказа и удаления managed-сервиса, источник данных | «Внешний сервис Kubernetes», «Внешний сервис Vault или Stronghold», «Префикс пути Vault» и параметры создания объектов |
| «Каноничная архитектура (привязки главной)» | Добавляет процессы и виджеты выбранных наборов в слоты набора маппинга home-default. Применяется только мастером | — |
Если в наборе «GitLab: активность репозиториев» выключен параметр «Все репозитории», заполните «ID групп GitLab».
Источники данных Kubernetes собирают только объекты с лейблом ddp.deckhouse.io/environment и пропускают неймспейсы d8-* и kube-*.
Какие слоты заполняет набор «Каноничная архитектура (привязки главной)», показано в таблице:
| Набор данных | Слот действия | Категория |
|---|---|---|
| «Управление окружениями» | create_environment, delete_environment | default |
| «Привязка общих ресурсов» | connect_shared_resource, disconnect_shared_resource | default |
| «Deckhouse managed PostgreSQL» | order_resource, delete_shared_resource | PostgreSQL, Deckhouse PostgreSQL |
| «Deckhouse managed Valkey» | order_resource, delete_shared_resource | Valkey, Deckhouse Valkey |
| «Deckhouse managed Kafka» | order_resource, delete_shared_resource | Kafka, Deckhouse Kafka |
| «GitLab: виджеты» | Слоты виджетов microservice_repository_widget, microservice_merge_requests_widget | — |
Набор «Реестр шаблонов микросервисов» процессы в правила маппинга не добавляет: их привязывают к шаблонам вручную после подключения реестра шаблонов.
Действия после мастера
Мастер не выполняет часть настроек, которые зависят от конкретной установки. Выполните их вручную:
- Включите главную: «Администрирование» → «Справочники» → «Правила маппинга» → переключатель «Показывать главную».
- Заполните учётные данные в профиле пользователя: токен сервисного аккаунта Kubernetes, токен Vault, персональный токен и имя пользователя GitLab. Процессы главной выполняют действия с учётными данными пользователя, который их запускает, поэтому учётные данные нужны каждому пользователю, запускающему процессы.
- Подключите реестр шаблонов и выполните синхронизацию. Порядок описан в разделе «Реестр шаблонов».
- Привяжите процессы к шаблонам: «Правила маппинга» → набор по умолчанию → «Маппинг каталога» → «Микросервисы» → «Действия по шаблонам». Для каждого шаблона выберите процессы действий: для действия «Создать микросервис» — процесс «Создать микросервис из шаблона», для действий «Развернуть микросервис на окружение», «Удалить микросервис с окружения» и «Обновить микросервис из шаблона» — одноимённые процессы.
- Если в каталоге есть микросервисы, созданные без шаблона, заполните в разделе «Микросервисы» → «Действия» слоты «Развернуть микросервис на окружение (без шаблона)» и «Удалить микросервис с окружения (без шаблона)».
- Заполните в каталоге параметры окружений, которые не приходят из кластера: тип, кластер, домен и признак «помечено на удаление». Домен окружения также меняется из раздела «Окружения» на главной.
Удаление набора данных
Набор данных удаляется кнопкой «Удалить» на его карточке в разделе «Наборы данных».
При удалении набора с процессами для главной из слотов набора маппинга удаляются только процессы и виджеты этого набора. Набор маппинга по умолчанию при удалении набора данных не удаляется.
Общие правила работы с наборами данных — в разделе «Наборы данных».