6.5 KiB
План: независимые DrHider и Obfuscator
Цель
Получить два полностью независимых production-сервиса:
- DrHider — репозиторий
Nail/drhider, отдельный Flask-инстанс и отдельный upload-буфер. - Obfuscator — репозиторий
forcloud/obfuscator, отдельный Flask-инстанс и отдельный upload-буфер.
После разделения изменения, версии, деплои, сессии и временные файлы одного сервиса не должны влиять на другой.
Целевая схема
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 и разные директории:
/var/www/upload-drhider/
/var/www/upload-obfuscator/
Текущий адрес https://upload.sinefo.ru/drhider-upload/ считать временным legacy-маршрутом. Его не использовать в новой конфигурации Obfuscator.
Этап 1. Разделить production-инстансы
- Создать отдельный Managed Flask-инстанс для
forcloud/obfuscator. - Оставить DrHider подключённым только к
Nail/drhider. - Проверить, что у сервисов разные:
- instance ID;
- hostname;
- переменные окружения;
- настройки Redeploy.
- Не добавлять
upstream, не использовать общий Git remote и не подключать один репозиторий как submodule другого.
Этап 2. Разделить upload-буферы на VM213
- Создать две директории с владельцем пользователя Nginx:
/var/www/upload-drhider/;/var/www/upload-obfuscator/.
- Добавить в Nginx два независимых WebDAV location:
/buffer/дляupload-drhider.sinefo.ru;/buffer/дляupload-obfuscator.sinefo.ru.
- Для каждого location настроить отдельно:
alias;PUT,GET,DELETE;client_max_body_size;- CORS только для своего Flask-инстанса;
- очистку старых временных файлов.
- Не менять и не удалять старый маршрут до завершения миграции и проверки обоих сервисов.
Этап 3. DNS и TLS
Создать A-записи на IP VM213 5.172.178.213:
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. Независимые деплои
Для каждого сервиса отдельно:
- Изменить код только в его репозитории.
- Выполнить локальные тесты и проверку синтаксиса.
- Сделать commit и push в его
master. - Выполнить Redeploy соответствующего Managed Flask-инстанса.
- Проверить
/healthи версию.
Push в Nail/drhider не должен запускать или изменять Obfuscator. Push в forcloud/obfuscator не должен запускать или изменять DrHider.
Этап 6. Проверка изоляции
Для каждого сервиса отдельно проверить:
GET /healthвозвращает правильную версию;- браузерный
OPTIONSвозвращает CORS только для своего origin; PUT -> GET -> DELETEработает через собственный hostname;- файл одного сервиса не виден в директории другого;
- отмена и очистка сессии не затрагивают второй сервис;
- обновление версии одного приложения не меняет
/healthвторого.
Этап 7. Удаление legacy-связей
После успешной миграции и периода наблюдения:
- Перевести оба приложения на новые buffer hostname.
- Проверить отсутствие
contracts.kube5s.ruиupload.sinefo.ru/drhider-upload/в рабочих конфигурациях. - Удалить старый WebDAV location только после подтверждения, что активных клиентов больше нет.
- Обновить README обоих проектов и документацию VM213.
Критерий готовности
Разделение считается завершённым, когда:
- у DrHider и Obfuscator разные production-инстансы;
- у них разные Git-репозитории без общей синхронизации;
- у них разные upload hostname и директории на VM213;
- CORS и TLS настроены для каждого отдельно;
- независимый Redeploy одного сервиса не меняет другой;
- smoke-тесты обоих сервисов проходят одновременно.