Перенести документацию в docs и добавить социальный граф

2026-07-13 12:58:41 +04:00
parent c9cfb394d7
commit af12d7b954
91 changed files with 653 additions and 2 deletions
@@ -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)