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

This commit is contained in:
AidarKC
2026-07-10 11:57:33 +04:00
parent 2b23aa7b95
commit 0fb1147eb7
18 changed files with 564 additions and 33 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
```