Zuev/magistr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Подготовить безопасный production rollout

Browse Source
This commit is contained in:
Zuev
2026-07-29 23:13:17 +03:00
parent a78a93f2f0
commit 8bb7fe97eb
16 changed files with 494 additions and 324 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/DATABASE.md
View File

@@ -913,21 +913,21 @@ lifecycle ресурсов, эффективная сетка целевого
2. Формат имени: `V{номер}__{описание}.sql` (напр. `V1__init.sql`, `V2__add_departments.sql`)
3. **ЗАПРЕЩЕНО** изменять уже закоммиченные файлы миграций — это сломает контрольные суммы Flyway. Исключение допускается только по прямой просьбе пользователя и при полном сбросе tenant-БД.
4. Flyway запускается **программно** при первом обращении к БД тенанта (`TenantConfigWatcher.initDatabaseForTenant()`)
5. Настройка `baselineOnMigrate=true` — если в БД уже есть данные, Flyway начнёт с baseline
5. Настройка `baselineOnMigrate=true` — непустая БД без истории будет помечена baseline и
`V1` не выполнится; поэтому текущую консолидированную V1 применяют только к полностью
пустой tenant-схеме
### Текущие миграции
| Файл | Описание |
|------|----------|
| `V1__init.sql` | Полная baseline-схема: справочники, роли, refresh-сессии JWT, PostgreSQL rate limit и аудит входа, lifecycle-поля, история кафедр, календарные графики, динамическое расписание, точечные изменения с переносом даты, seed, CHECK/UNIQUE/GiST-ограничения, конкурентно безопасные триггеры и комментарии |
| `V2__align_academic_calendar_weeks_to_monday.sql` | Перенумерация сохранённых дней календарного графика по периодам `понедельник–воскресенье`, чтобы неполная первая неделя не заполнялась датами следующей недели |
| `V1__init.sql` | Полная baseline-схема: справочники, роли, refresh-сессии JWT, PostgreSQL rate limit и аудит входа, lifecycle-поля, история кафедр, календарные графики с нумерацией недель `понедельник–воскресенье`, динамическое расписание, точечные изменения с переносом даты, seed, CHECK/UNIQUE/GiST-ограничения, конкурентно безопасные триггеры и комментарии |
### Этап разработки
По прямому решению владельца проекта прежние разработческие миграции V2–V7 были объединены
в baseline `V1`. Новая миграция `V2__align_academic_calendar_weeks_to_monday.sql` создана
после фиксации baseline и накатывается поверх существующих tenant-БД без изменения
контрольной суммы V1.
По прямому решению владельца проекта разработческие миграции V2–V7 объединены в baseline
`V1`. Правильная нумерация недель календарного графика также входит непосредственно в V1.
Перед применением этой редакции требуется полностью пустая tenant-схема.
### Полный сброс БД (локально)

14
docs/INFRASTRUCTURE.md
View File

@@ -325,8 +325,8 @@ kubectl auth can-i update secret/tenants-secret \
--as="system:serviceaccount:magistr:${BACKEND_SERVICE_ACCOUNT}" -n magistr
```
Production rollout и проверка реальных pod являются внешними операциями и без отдельного
разрешения из этой рабочей копии не выполнялись.
Production rollout и проверка реальных pod являются внешними операциями и выполняются из
этой рабочей копии только по отдельному разрешению владельца.
### Ручное обновление backend и frontend
@@ -368,12 +368,16 @@ Deployment-файлов запрещено.
jobs также возвращают registry digest каждого образа.
4. Отдельный обязательный job сканирует опубликованные digests закреплённым Trivy `0.63.0` и
блокирует deploy при исправимых `HIGH`/`CRITICAL` уязвимостях.
5. Deploy job устанавливает фиксированный `kubectl v1.33.12` только после SHA-256 проверки.
Java Agent также имеет точную версию и checksum.
5. Push в `main` выполняет проверки, сборку, публикацию и scan, но не меняет production.
Deploy job запускается только вручную через `workflow_dispatch` и устанавливает
фиксированный `kubectl v1.33.12` после SHA-256 проверки. Java Agent также имеет точную
версию и checksum.
6. `scripts/deploy-images.sh` принимает только `image@sha256:...`, сохраняет предыдущие
ссылки, применяет оба digest и ждёт rollout. При отказе автоматически возвращает оба
предыдущих образа и повторно проверяет их готовность.
7. Workflow-wide concurrency lock не допускает одновременные production deployment.
7. Gitea 1.25 игнорирует `environment` и `concurrency`, поэтому workflow не полагается на
них как на защиту production. Оператор не должен запускать второй ручной deploy, пока
первый не завершён.
`scripts/check-artifact-pinning.sh` проверяет Dockerfile, Compose, Actions, checksum и CI
gates. При передаче `K8S_DIR=../k8s` он дополнительно требует digest у каждого production