Зафиксировать накопленные изменения по deploy и devnet

2026-07-10 11:57:33 +04:00
parent 2b23aa7b95
commit 0fb1147eb7
18 changed files with 564 additions and 33 deletions
@@ -1,14 +0,0 @@
-# Изоляция страницы DEVNET пополнения от mainnet
-
- краткое описание фичи:
-  Страница `shine-UI/js/pages/devnet-topup-view.js` переведена на полностью автономную работу только с `https://api.devnet.solana.com`. Проверка баланса и перевод SOL на этой странице больше не используют общие Solana-настройки UI.
- что именно проверять:
-  1. Открыть страницу `devnet-topup-view` с параметром `wallet`.
-  2. Убедиться, что на странице отображается сеть `DEVNET`.
-  3. Проверить, что балансы отправителя и получателя читаются из devnet.
-  4. Выполнить перевод и убедиться, что транзакция проходит именно в devnet.
-  5. Убедиться, что изменение глобального Solana endpoint в других экранах UI не влияет на эту страницу.
- ожидаемый результат:
-  Страница всегда показывает devnet-балансы и отправляет перевод только через devnet, независимо от глобального RPC в приложении.
- статус:
-  pending
@@ -0,0 +1,39 @@
+# 4 тестовых SHiNE-сервера на одном VPS (`178.208.90.249`)
+
+- статус: `pending`
+
+## Кратко
+
+Поднят отдельный тестовый стенд:
+- `t1.shineup.me`
+- `t2.shineup.me`
+- `t3.shineup.me`
+- `t4.shineup.me`
+
+Каждый домен ведёт на свой SHiNE-инстанс под пользователем `player`, все инстансы работают через Solana `devnet`.
+
+## Что проверять
+
+- UI каждого домена открывается без ошибок:
+  - `https://t1.shineup.me`
+  - `https://t2.shineup.me`
+  - `https://t3.shineup.me`
+  - `https://t4.shineup.me`
+- регистрация/логин клиента может работать через каждый из этих серверов
+- WebSocket-подключение реально идёт на свой инстанс, а не в соседний
+- чтение PDA и server-ui формы по умолчанию используют `devnet`
+- межсерверный sync после ручных тестов действительно использует `access_servers/sync_servers`
+- не происходит путаницы данных между `t1/t2/t3/t4`
+
+## Ожидаемый результат
+
+- каждый домен работает независимо
+- у каждого инстанса своя БД и свои локальные данные
+- `Caddy` корректно проксирует `/ws` на `7101..7104`
+- серверы не падают после старта
+- если devnet RPC временно даёт `429`, последовательный рестарт по одному инстансу позволяет подтянуть `sync_servers`
+
+## Примечание
+
+Подробная схема размещения описана в:
+- [Dev_Docs/deploy/test-server/178.208.90.249_quad_devnet.md](/home/ai/work/SHiNE/SHiNE-server-sha256/Dev_Docs/deploy/test-server/178.208.90.249_quad_devnet.md)
@@ -0,0 +1,16 @@
+Lf dc` hfm# TURN: только один живой узел для звонков
+
+- краткое описание:
+  - в серверном конфиге оставлен только один TURN-узел `185.229.109.118:3478` для ICE-конфига звонков;
+  - мёртвый узел `93.170.12.154:3478` убран из локальной конфигурации и test-деплоя `t2`.
+- что проверять:
+  - открыть два клиента на `t2.shineup.me`;
+  - начать аудиозвонок между ними;
+  - убедиться, что `GetCallIceConfig` отдаёт только TURN `185.229.109.118`;
+  - убедиться, что звонок выходит из стадии `connecting` и появляется `call_connected` либо как минимум `relay`-кандидаты в клиентской диагностике.
+- ожидаемый результат:
+  - клиентам больше не предлагается `93.170.12.154`;
+  - звонок проходит стабильнее, чем до изменения;
+  - в серверных логах нет новых `incoming_failed/outgoing_failed` только из-за нерабочего TURN.
+- статус:
+  - pending
@@ -38,6 +38,11 @@
 - Reserve test UI deploy: `./gradlew deployUITest`
 - Локальный запуск: `./gradlew startLocal`

+## Отдельные тестовые VPS
+
+- Отдельный стенд с 4 devnet-серверами на одном VPS описан в:
+  - `Dev_Docs/deploy/test-server/README.md`
+
 ## Политика подтверждений

 - `shineup.me` — production.
@@ -0,0 +1,173 @@
+# VPS `178.208.90.249` (`player`) — 4 тестовых SHiNE-сервера на devnet
+
+## Назначение
+
+Этот VPS используется как отдельный тестовый стенд для одновременного запуска 4 SHiNE-серверов:
+- `server_t1` → `https://t1.shineup.me`
+- `server_t2` → `https://t2.shineup.me`
+- `server_t3` → `https://t3.shineup.me`
+- `server_t4` → `https://t4.shineup.me`
+
+Все 4 инстанса работают через Solana `devnet`.
+
+## Каталоги
+
+Структура в домашней папке пользователя `player`:
+- `/home/player/t1/server`
+- `/home/player/t1/UI`
+- `/home/player/t2/server`
+- `/home/player/t2/UI`
+- `/home/player/t3/server`
+- `/home/player/t3/UI`
+- `/home/player/t4/server`
+- `/home/player/t4/UI`
+
+Дополнительно:
+- подробная памятка на самом сервере: `/home/player/Agents.md`
+
+## Порты и systemd
+
+Соответствие инстансов:
+- `t1` → localhost `7101` → `shine-t1.service`
+- `t2` → localhost `7102` → `shine-t2.service`
+- `t3` → localhost `7103` → `shine-t3.service`
+- `t4` → localhost `7104` → `shine-t4.service`
+
+Каждый unit запускает один и тот же jar:
+- `/home/player/tX/server/shine-server.jar`
+
+Рабочая директория каждого unit:
+- `/home/player/tX/server`
+
+Это важно, потому что сервер читает внешний `application.properties` именно из текущей рабочей директории.
+
+## Конфиги сервера
+
+У каждого инстанса свой файл:
+- `/home/player/tX/server/application.properties`
+
+Ключевые параметры в нём:
+- `server.port=710X`
+- `server.SHiNE.login=server_tX`
+- `db.path=data/shine.sqlite`
+- `solana.cluster=devnet`
+- `solana.rpcUrl=https://api.devnet.solana.com`
+- `server.ui.indexPath=/home/player/tX/UI/index.html`
+- `server.info.url=https://tX.shineup.me`
+- `server.info.origin=devnet`
+
+Важно:
+- Program ID SHiNE одинаковые для mainnet и devnet.
+- Поэтому для перевода инстанса на devnet достаточно правильных `solana.cluster` и `solana.rpcUrl`.
+
+## Конфиги UI
+
+У каждого домена лежит отдельная копия `shine-UI`.
+
+В каждой копии меняется `js/deploy-config.js`:
+- `defaultServerLogin=server_tX`
+- `defaultServerAddress=tX.shineup.me`
+- `defaultSolanaCluster=devnet`
+- `defaultSolanaEndpoint=https://api.devnet.solana.com`
+
+За счёт этого:
+- UI по умолчанию открывает именно свой сервер
+- `server-ui` формы по умолчанию используют именно `devnet`
+
+## Caddy
+
+Конфиг:
+- `/etc/caddy/Caddyfile`
+
+Логика по каждому сайту одинаковая:
+- статические файлы берутся из `/home/player/tX/UI`
+- путь `/ws` проксируется на `127.0.0.1:710X`
+
+Права доступа:
+- каталог `/home/player` и `/home/player/tX` должен быть доступен на `+x` для чтения через Caddy
+- все каталоги и файлы в `/home/player/tX/UI` должны быть читаемы пользователем `caddy`
+
+## Что уже проверено
+
+После настройки было подтверждено:
+- `https://t1.shineup.me` отвечает `HTTP 200`
+- `https://t2.shineup.me` отвечает `HTTP 200`
+- `https://t3.shineup.me` отвечает `HTTP 200`
+- `https://t4.shineup.me` отвечает `HTTP 200`
+- `Caddy` успешно выпустил сертификаты Let's Encrypt на все 4 домена
+- все 4 процесса Java слушают свои порты `7101..7104`
+- в логах есть строка `WS сервер запущен на ws://localhost:710X/ws`
+
+## Важный operational-нюанс
+
+Официальный `https://api.devnet.solana.com` может отдавать `HTTP 429`, если несколько инстансов одновременно делают bootstrap PDA/sync-серверов на старте.
+
+На практике это уже проявилось:
+- `t3` и `t4` подтянули `sync_servers` сразу
+- `t1` и `t2` на первом одновременном старте словили `429`
+- после последовательного рестарта `shine-t1` и `shine-t2` они тоже успешно сохранили `sync_servers`
+
+Если после очередного деплоя какой-то инстанс не подтянул `sync_servers`, сначала делать не массовый рестарт, а по одному:
+
+```bash
+sudo systemctl restart shine-t1
+sleep 8
+sudo systemctl restart shine-t2
+sleep 8
+sudo systemctl restart shine-t3
+sleep 8
+sudo systemctl restart shine-t4
+```
+
+## Как обновлять сервер
+
+1. Локально собрать jar:
+
+```bash
+./gradlew shadowJar
+```
+
+2. Залить `SHiNE-server/build/libs/shine-server.jar` в каждый нужный каталог:
+- `/home/player/t1/server/shine-server.jar`
+- `/home/player/t2/server/shine-server.jar`
+- `/home/player/t3/server/shine-server.jar`
+- `/home/player/t4/server/shine-server.jar`
+
+3. Если менялся runtime-конфиг, обновить соответствующий `application.properties`.
+
+4. Перезапускать сервисы лучше по одному, с паузой, чтобы снизить шанс `429` от devnet RPC.
+
+## Как обновлять UI
+
+1. Взять свежую локальную папку `shine-UI/`.
+2. Для каждой копии подставить свой `deploy-config.js`.
+3. Скопировать файлы в `/home/player/tX/UI/`.
+4. Проверить права чтения для Caddy.
+
+## Полезные команды на VPS
+
+Проверка сервисов:
+
+```bash
+sudo systemctl --no-pager --full status caddy shine-t1 shine-t2 shine-t3 shine-t4
+```
+
+Перезапуск одного инстанса:
+
+```bash
+sudo systemctl restart shine-t1
+```
+
+Логи одного инстанса:
+
+```bash
+tail -n 200 /home/player/t1/server/logs/app.log
+sudo journalctl -u shine-t1 -n 200 --no-pager
+```
+
+Проверка Caddy:
+
+```bash
+sudo caddy validate --config /etc/caddy/Caddyfile
+curl -I https://t1.shineup.me
+```
@@ -0,0 +1,12 @@
+# Тестовый VPS с 4 SHiNE-серверами
+
+В этой папке описан отдельный тестовый VPS `178.208.90.249`, на котором подняты 4 независимых SHiNE-инстанса под доменами `t1.shineup.me` ... `t4.shineup.me`.
+
+Текущая основная схема:
+- пользователь на VPS: `player`
+- все 4 инстанса работают через `devnet`
+- каждый инстанс имеет свой каталог `server`, свой каталог `UI`, свой `systemd` unit и свой localhost-порт
+- внешний HTTPS и маршрутизацию `/ws` обслуживает один общий `Caddy`
+
+Детальное описание:
+- [178.208.90.249_quad_devnet.md](/home/ai/work/SHiNE/SHiNE-server-sha256/Dev_Docs/deploy/test-server/178.208.90.249_quad_devnet.md)