# План: независимые DrHider и Obfuscator

## Цель

Получить два полностью независимых production-сервиса:

- **DrHider** — репозиторий `Nail/drhider`, отдельный Flask-инстанс и отдельный upload-буфер.
- **Obfuscator** — репозиторий `forcloud/obfuscator`, отдельный Flask-инстанс и отдельный upload-буфер.

После разделения изменения, версии, деплои, сессии и временные файлы одного сервиса не должны влиять на другой.

## Целевая схема

```text
DrHider
  repo: https://gitea.services.ngcloud.ru/Nail/drhider.git
  app: https://drhider.pythonk8s.dev.nubes.ru/
  buffer: https://upload-drhider.sinefo.ru/buffer/

Obfuscator
  repo: https://gitea.services.ngcloud.ru/forcloud/obfuscator.git
  app: https://obfuscator.pythonk8s.services.ngcloud.ru/
  buffer: https://upload-obfuscator.sinefo.ru/buffer/
```

Оба буфера могут находиться на VM213, но должны иметь разные hostname и разные директории:

```text
/var/www/upload-drhider/
/var/www/upload-obfuscator/
```

Текущий адрес `https://upload.sinefo.ru/drhider-upload/` считать временным legacy-маршрутом. Его не использовать в новой конфигурации Obfuscator.

## Этап 1. Разделить production-инстансы

1. Создать отдельный Managed Flask-инстанс для `forcloud/obfuscator`.
2. Оставить DrHider подключённым только к `Nail/drhider`.
3. Проверить, что у сервисов разные:
   - instance ID;
   - hostname;
   - переменные окружения;
   - настройки Redeploy.
4. Не добавлять `upstream`, не использовать общий Git remote и не подключать один репозиторий как submodule другого.

## Этап 2. Разделить upload-буферы на VM213

1. Создать две директории с владельцем пользователя Nginx:
   - `/var/www/upload-drhider/`;
   - `/var/www/upload-obfuscator/`.
2. Добавить в Nginx два независимых WebDAV location:
   - `/buffer/` для `upload-drhider.sinefo.ru`;
   - `/buffer/` для `upload-obfuscator.sinefo.ru`.
3. Для каждого location настроить отдельно:
   - `alias`;
   - `PUT`, `GET`, `DELETE`;
   - `client_max_body_size`;
   - CORS только для своего Flask-инстанса;
   - очистку старых временных файлов.
4. Не менять и не удалять старый маршрут до завершения миграции и проверки обоих сервисов.

## Этап 3. DNS и TLS

Создать A-записи на IP VM213 `5.172.178.213`:

```text
upload-drhider.sinefo.ru      A  5.172.178.213
upload-obfuscator.sinefo.ru   A  5.172.178.213
```

Для обоих hostname выпустить отдельные сертификаты Certbot и проверить автоматическое продление.

## Этап 4. Конфигурация приложений

В DrHider указать только его буфер. В Obfuscator указать только его буфер.

Проверить и при необходимости заменить во всех рабочих файлах:

- фронтендовый `VM_UPLOAD_URL`;
- backend `VM_UPLOAD_PREFIX`;
- значение `vmUploadPrefix` в health/config endpoint;
- CORS origin;
- пути временного хранения и очистки.

Переименовать общие переменные в нейтральные имена, например `UPLOAD_BUFFER_URL`, если это не ломает существующий публичный API.

## Этап 5. Независимые деплои

Для каждого сервиса отдельно:

1. Изменить код только в его репозитории.
2. Выполнить локальные тесты и проверку синтаксиса.
3. Сделать commit и push в его `master`.
4. Выполнить Redeploy соответствующего Managed Flask-инстанса.
5. Проверить `/health` и версию.

Push в `Nail/drhider` не должен запускать или изменять Obfuscator. Push в `forcloud/obfuscator` не должен запускать или изменять DrHider.

## Этап 6. Проверка изоляции

Для каждого сервиса отдельно проверить:

- `GET /health` возвращает правильную версию;
- браузерный `OPTIONS` возвращает CORS только для своего origin;
- `PUT -> GET -> DELETE` работает через собственный hostname;
- файл одного сервиса не виден в директории другого;
- отмена и очистка сессии не затрагивают второй сервис;
- обновление версии одного приложения не меняет `/health` второго.

## Этап 7. Удаление legacy-связей

После успешной миграции и периода наблюдения:

1. Перевести оба приложения на новые buffer hostname.
2. Проверить отсутствие `contracts.kube5s.ru` и `upload.sinefo.ru/drhider-upload/` в рабочих конфигурациях.
3. Удалить старый WebDAV location только после подтверждения, что активных клиентов больше нет.
4. Обновить README обоих проектов и документацию VM213.

## Критерий готовности

Разделение считается завершённым, когда:

- у DrHider и Obfuscator разные production-инстансы;
- у них разные Git-репозитории без общей синхронизации;
- у них разные upload hostname и директории на VM213;
- CORS и TLS настроены для каждого отдельно;
- независимый Redeploy одного сервиса не меняет другой;
- smoke-тесты обоих сервисов проходят одновременно.