2.6 KiB
2.6 KiB
14. Модель деплоя
Назначение
Модель деплоя описывает запуск платформы в SaaS-режиме для нескольких tenants с общей frontend-сборкой и tenant-aware backend-конфигурацией.
Поведение системы
- Одна frontend-сборка обслуживает несколько доменов.
- Tenant определяется на runtime по host.
- Backend/edge отдает соответствующий bootstrap и API конфигурацию.
- UI-режимы layout/widgets/footer/static pages переключаются только через bootstrap без перекомпиляции frontend.
Обязательные параметры деплоя (JSON/env)
- supportedHosts
- defaultTenantPolicy
- apiGatewayBaseUrl
- bootstrapEndpoint
- observability (logs/metrics/traces)
Опциональные параметры
- CDN policy
- региональные endpoint
- feature rollouts
- fallback tenant (только по утвержденной политике)
Строгие правила
- Нельзя собирать отдельный frontend-бандл под каждый tenant как основной процесс.
- Нельзя использовать ручные правки frontend для запуска нового клиента.
- Деплой должен поддерживать zero-downtime обновления.
- Конфигурация окружений должна быть отделена от бизнес-данных tenants.
- В bootstrap и публичных API запрещено хранить секреты.
Пример deployment-конфигурации (сокращенно)
{
"environment": "production",
"supportedHosts": ["store-a.com", "store-b.com"],
"bootstrapEndpoint": "https://api.platform.com/bootstrap",
"apiGatewayBaseUrl": "https://api.platform.com",
"observability": {
"logs": true,
"metrics": true,
"traces": true
}
}
Ответственность Frontend
- Корректно работать в multi-host режиме без перекомпиляции.
- Логировать runtime-ошибки tenant resolution/bootstrap.
Ответственность Backend/DevOps
- Обеспечить маршрутизацию доменов на единый frontend runtime.
- Поддерживать tenant-aware конфигурацию на edge/API уровне.
- Обеспечить CI/CD с валидацией контрактов и smoke-тестами tenants.