Add restore validation report
All checks were successful
trash-ci / smoke (push) Successful in 0s

This commit is contained in:
bootstrap 2026-05-06 18:10:58 +03:00
parent 72580b1a67
commit 63c029b9df

88
RESTORE_VALIDATION.md Normal file
View File

@ -0,0 +1,88 @@
# Gitea Helm Chart And Restore Validation
Дата проверки: 2026-05-06
## Что входит в чарт
Чарт расположен в `gitea/.helm` и ставится как release `gitea` в namespace `gitea`.
- Gitea `gitea/gitea:1.22.6`.
- Gitea runner `gitea/act_runner:0.2.11`.
- PostgreSQL через dependency `postgresql-preprod:16.4.8` из `cr.yandex/crp3ccidau046kdj8g9q/charts/postgresql-preprod`.
- `universal-chart:0.1.9` используется для runner.
- Для Gitea используется статический Deployment template, потому что нужны sidecar containers для файлового backup без Multi-Attach PVC.
- Ingress/VirtualService в чарте нет, внешний routing остается в отдельном чарте.
- Чувствительные значения не лежат в `values.yaml`; секреты берутся из `gitea-secret`/`postgresql-secret`, шаблон секрета использует `lookup` и generated fallback values.
## Backup
Файлы Gitea backup:
- Реализованы sidecar containers в pod Gitea.
- `gitea-files-archive` читает `/data` read-only и собирает архив во временный `emptyDir`.
- `gitea-files-upload` отправляет архив в S3.
- Такой режим не монтирует `gitea-data` во второй pod и не ловит Multi-Attach на RWO PVC.
PostgreSQL backup:
- В чарте есть `CronJob/gitea-postgresql-backup`.
- Dump создается через `pg_dump` пользователем `gitea`.
- Upload идет в S3 через `amazon/aws-cli:2.15.57`.
Использованные S3 keys:
- Files: `gitops-backups/gitea-files/gitea-files-2026-05-06-145356.tar.gz`
- PostgreSQL: `gitops-backups/postgresql/gitea-postgresql-2026-05-06-145822.sql.gz`
## Restore
Restore запускается через `helm upgrade --install` с отдельным values-файлом:
- `restore.enabled=true`
- `restore.files.enabled=true`
- `restore.postgresql.enabled=true`
- `restore.s3.giteaFilesKey=<files backup key>`
- `restore.s3.postgresqlDumpKey=<postgresql dump key>`
Restore hook делает:
- scale down Deployment `gitea`;
- скачивание backup archives из S3;
- очистку `/data` и распаковку файлового backup;
- drop schema `public` в базе `gitea`;
- restore SQL dump через пользователя `gitea`;
- verification количества public tables и core tables;
- scale up Deployment `gitea`.
## Проверка
Проверено на `yc-infra-prod`, namespace `gitea`.
- Release `gitea` установлен заново после полной очистки namespace/PVC/PV.
- Pods после чистой установки: `gitea`, `gitea-ci-worker`, `postgresql-0`.
- Создан admin user `bootstrap`.
- Создан access token для API/git push.
- В свежий Gitea запушен репозиторий `bootstrap/gitea`.
- В репозиторий добавлен workflow `.gitea/workflows/trash-ci.yaml`.
- Runner зарегистрирован через generated registration token.
- Runner объявился с labels `linux-amd64` и `linux-shell`.
- CI task по `bootstrap/gitea` был принят runner.
- Тестовые файлы для restore созданы в `/data/backup-test` и `/data/gitea/custom/backup-test`.
- Файловый backup отправлен в S3.
- PostgreSQL backup вручную запущен из существующего `CronJob/gitea-postgresql-backup`.
- Restore запущен через `helm upgrade --install`.
- Restore job завершился успешно.
- Verification restore job: `110 public tables`, `3 core tables`.
- После restore Gitea API вернул `bootstrap/gitea|main`.
- После restore на PVC найдены:
- `/data/backup-test/blob.bin`
- `/data/backup-test/generated-at.txt`
- `/data/gitea/custom/backup-test/marker.txt`
- `/data/git/repositories/bootstrap/gitea.git`
- После restore в базе:
- `users=1`
- `repos=1`
- repository `bootstrap/gitea`
- action runs `1` и `2`
Итог: полный цикл install, runner, CI, backup files, backup PostgreSQL и restore из S3 проверен.