SHiNE-server/Deploy Server/servers-inventory.md

2.1 KiB

SHiNE Deployment Servers Inventory

Scope

This folder contains all deployment-related notes and server records for SHiNE.

Legacy Production Server

  • Name: VPS-02 (legacy)
  • Access: root@194.87.0.247
  • Current role: old production server
  • Confirmed services:
    • coturn is installed and active (systemd: active/running)
    • caddy is installed (reported by project context; verify version on host if needed)
  • TURN configuration observed on host:
    • listening-port=3478
    • external-ip=194.87.0.247
    • relay-ip=194.87.0.247
    • auth mode: use-auth-secret + static-auth-secret
  • SHiNE deployment note:
    • This host is used as current/legacy runtime for SHiNE.
    • Gradle-based deployment is used in this project (see repository deploy tasks and scripts).

Target Production Server (Migration)

  • Name: VPS-05 (new)
  • Access: root@45.136.124.227
  • Planned role: new primary production server for gradual migration
  • Baseline setup done:
    • ripgrep installed
    • user player created
    • user player added to sudo group
    • deployment directory created: /home/player/SHiNE
  • Rule:
    • All SHiNE-related runtime files and deployments on VPS-05 should be placed under /home/player/SHiNE.

Additional TURN Node

  • Name: promo-node-93
  • Access: ubuntu@93.170.12.154 (and player user for SHiNE operations)
  • Role: additional TURN node for SHiNE calls
  • TURN setup:
    • coturn installed and active
    • listening-port=3478
    • tls-listening-port=5349
    • use-auth-secret + shared static-auth-secret
    • relay UDP port range: 49152-50152
  • Runtime files:
    • /etc/turnserver.conf
    • /home/player/SHiNE/coturn/turnserver.conf
  • Cleanup done:
    • Disabled old reverse SSH tunnel (reverse-ssh.service) that exposed 0.0.0.0:1200 -> localhost:22 to 194.87.0.247.
  1. Install and configure runtime dependencies (JDK, Caddy, DB, TURN if required).
  2. Mirror SHiNE deployment process from VPS-02 using existing Gradle deployment flow.
  3. Move traffic gradually and validate logs/metrics before final cutover.