RustDesk w Dockerze: poradnik po konteneryzowanym serwerze

Próbujesz samodzielnie hostować RustDesk bez walki z ręcznymi kompilacjami, zależnościami czy kruchemi obrazami VM. Ten przewodnik pokazuje, jak uruchomić gotowy do produkcji stos serwerowy RustDesk z użyciem Docker i Docker Compose, abyś mógł zarządzać aktualizacjami, kopiami zapasowymi i skalowaniem jak osoba z operacji — nie hobbysta.

Dlaczego używać Dockera dla RustDesk

Kontenery dają dwie natychmiastowe korzyści dla samodzielnie hostowanego stosu zdalnego dostępu: reprodukowalne wdrożenia i izolację. Zamiast kompilować hbbs/hbbr lokalnie lub uruchamiać pakiety zależne od platformy, pobierasz obraz Docker, montujesz trwały wolumin i uruchamiasz. To upraszcza aktualizacje, CI/CD i migracje hosta. Jeśli już uruchamiasz inne usługi w kontenerach (NGINX, certbot, monitoring), dodanie RustDesk w ten sposób utrzymuje spójność stosu.

Kiedy nie konteneryzować: jeśli potrzebujesz niestandardowo załatanych binarek lub głębokiej integracji z jądrem dla bardzo wydajnego relay, instalacja natywna może być lepsza. Również jeśli potrzebujesz oficjalnie wspieranego SLA od dostawcy, sprawdź, czy dostawca wspiera uruchamianie w kontenerach.

Komponenty serwera RustDesk — krótkie omówienie

RustDesk dzieli rolę serwera na przynajmniej dwie części:

• hbbs — serwer ID/sygnalizacji. Obsługuje rejestrację i rendezvous klientów.
• hbbr — serwer relay (gdy przejście przez NAT zawiedzie). Przekazuje ruch między peerami.

W produkcji zazwyczaj uruchamia się oba. Pojedynczy lekki host może uruchamiać obie usługi; w większych wdrożeniach rozdziela się je, umieszcza instancje hbbr za load balancerem i dodaje autoskalowanie dla pojemności relay.

Szybki start: przykładowe wdrożenie Docker Compose

Wymagania wstępne: Ubuntu 22.04 LTS (lub dowolny Linux z Docker Engine 20.10+), Docker Compose v2.x, nazwa domeny (przykład: rustdesk.example.com). Przydziel co najmniej 512 MB RAM dla małego serwera testowego; 1 GB+ zalecane dla relay, który obsłuży wiele aktywnych sesji.

Poniżej praktyczny przykład Docker Compose, który uruchamia hbbs i hbbr jako oddzielne serwisy, montuje trwałe dane i publikuje standardowe porty RustDesk. Zanim go uruchomisz, sprawdź oficjalne tagi obrazu rustdesk/rustdesk-server dla najnowszego stabilnego tagu i zastąp rustdesk/rustdesk-server:latest, jeśli chcesz przypiąć wersję.

version: '3.8'

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    command: ["hbbs", "--listen", "0.0.0.0:21115"]
    ports:
      - "21115:21115/tcp"
      - "21115:21115/udp"
    volumes:
      - ./data/hbbs:/data
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    command: ["hbbr", "--listen", "0.0.0.0:21116", "--relay", "0.0.0.0:21116"]
    ports:
      - "21116:21116/tcp"
      - "21116:21116/udp"
    volumes:
      - ./data/hbbr:/data
    restart: unless-stopped

networks:
  default:
    external: false

Wyjaśnienie:

• Uruchamiamy hbbs na portach TCP/UDP 21115 i hbbr na 21116 — to są powszechne domyślne porty dla buildów serwera RustDesk. Potwierdź mapowanie portów dla obrazu, którego używasz (niektóre buildy społecznościowe używają innych domyślnych wartości).
• Trwałe woluminy ./data/hbbs i ./data/hbbr zachowują Twoje dane rejestracji i relay między restartami.
• Użyj restart: unless-stopped dla podstawowej odporności; w produkcji powiąż to z politykami restartu Twojej platformy orkiestracyjnej.

Udostępnianie bezpiecznie: TLS, reverse proxy i zapora

Ruch sygnalizacyjny i relay RustDesk można chronić za pomocą TLS i standardowych reguł zapory. Istnieją dwa powszechne podejścia:

1. Bezpośredni TLS z proxy przed hbbs (zalecane dla zarządzania certyfikatami na poziomie web).
2. Trzymaj hbbr jako surowy relay TCP/UDP i zabezpiecz sieć hosta (użyj ufw/nftables), jednocześnie zabezpieczając hbbs za pomocą TLS.

Większość konfiguracji używa NGINX lub Traefik do terminowania TLS i przekazywania ruchu do hbbs. Przykładowy blok serwera NGINX do terminowania TLS dla rustdesk.example.com:

server {
  listen 443 ssl;
  server_name rustdesk.example.com;

  ssl_certificate /etc/letsencrypt/live/rustdesk.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/rustdesk.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:21115;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

# Optional: redirect http to https
server {
  listen 80;
  server_name rustdesk.example.com;
  return 301 https://$host$request_uri;
}

Użyj certbot (Let's Encrypt) lub swojego CA, aby uzyskać certyfikaty. Jeśli Twój relay (hbbr) działa na publicznym UDP/TCP, wystaw te porty bezpośrednio i ogranicz dostęp zaporą do oczekiwanych zakresów IP, lub umieść węzły relay w prywatnej sieci za load balancerem.

DNS, klienci i przechodzenie przez NAT

Wskaż rekord A DNS (np. rustdesk.example.com) na publiczne IP serwera. W kliencie RustDesk ustaw adres serwera na tę domenę (dla ID i wyszukiwania relay). Klienci używają serwera ID do rendezvous; jeśli obaj klienci są za restrykcyjnym NAT, hbbr przekaże sesję przez twój relay.

Jeśli zarządzasz maszynami klienckimi w LAN, możesz uruchomić wewnętrzny DNS lub rozpowszechnić plik konfiguracyjny, który wskazuje klientom wewnętrzne IP hbbs dla szybszych połączeń lokalnych.

Skalowanie i wskazówki dotyczące zasobów

Ile CPU/RAM potrzebuje relay? To zależy od jednoczesnych sesji i typu sesji:

• Mały serwer testowy: 1 vCPU, 512 MB RAM — kilka bezczynnych połączeń.
• Relay produkcyjny (lekka eksploatacja): 2 vCPU, 1–2 GB RAM — dziesiątki jednoczesnych sesji.
• Relay o dużej przepustowości: 4+ vCPU, 4+ GB RAM oraz przepustowość sieci dopasowana do oczekiwanego ruchu (np. 100+ Mbps).

Zalecamy autoskalowanie instancji hbbr za load balancerem, jeśli spodziewasz się skoków (remote control z dużą ilością mediów, udostępnianie ekranu). Użyj orkiestracji kontenerów (Kubernetes, Docker Swarm) lub prostego skalowania horyzontalnego z TCP/UDP load balancerem (haproxy, cloud LB), który zachowuje adresy IP klientów.

Kopie zapasowe, aktualizacje i przypinanie wersji

Zawsze montuj trwałe woluminy dla danych i regularnie je twórz kopie zapasowe. Minimalny skrypt backupu:

# daily-backup.sh
TIMESTAMP=$(date +%F)
mkdir -p /backups/rustdesk/$TIMESTAMP
rsync -a ./data /backups/rustdesk/$TIMESTAMP/
# rotate: keep 14 days
find /backups/rustdesk -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;

Dla aktualizacji przypinaj obraz Docker tagiem zamiast :latest. Przeprowadź testy stagingowe przed podniesieniem obrazu serwera. Przykładowy workflow:

1. Pobierz nowy obraz: docker pull rustdesk/rustdesk-server:1.3.0 (przykład).
2. Uruchom testowy kontener z tymi samymi woluminami i wykonaj testy smoke.
3. Zaplanuj okno konserwacyjne i zamień kontenery na hostach produkcyjnych.

Rozwiązywanie problemów i typowe pułapki

Zacznij od logów: docker logs rustdesk-hbbs i docker logs rustdesk-hbbr. Typowe problemy:

• Klienci nie mogą się zarejestrować: sprawdź, czy hbbs jest osiągalny pod domeną i czy TLS jest ważny.
• Sesje przechodzą przez relay, ale wydajność jest słaba: sprawdź CPU/pamięć i sieć hosta relay. Pakiety relay są zwykle UDP; upewnij się, że UDP jest dozwolone przez zaporę i w regułach grup bezpieczeństwa chmury.
• Klienci mają niezgodne wersje: używaj dopasowanych lub kompatybilnych wersji klient/serwer RustDesk. Jeśli przypinasz obraz serwera, upewnij się, że klienci nie korzystają z przestarzałych funkcji protokołu.

Jeśli przechodzenie przez NAT systematycznie zawodzi dla wielu klientów, problemem zwykle jest symmetric NAT lub zapory korporacyjne. W takich przypadkach polegaj na relayach hbbr i monitoruj opóźnienia/przepustowość, aby zapewnić akceptowalną jakość użytkowania.

Aspekty bezpieczeństwa

Samodzielne hostowanie przenosi odpowiedzialność na Ciebie. Kluczowe kroki:

• Terminuj TLS na reverse proxy i używaj silnych szyfrów. Uzyskaj certyfikaty od Let's Encrypt lub zaufanego CA.
• Zabezpiecz hosta: otwieraj tylko niezbędne porty, włącz automatyczne aktualizacje zabezpieczeń systemu i korzystaj z zapory (ufw/nftables).
• Ogranicz dostęp do interfejsów administracyjnych i monitoruj logi pod kątem prób brute force. Rozważ segmentację sieci; umieść węzły relay w oddzielnej podsieci, jeśli to możliwe.

Jeśli chcesz szerszej dyskusji na temat zabezpieczania dostępu zdalnego, zobacz nasz artykuł o bezpieczeństwo pulpitu zdalnego i jak działa nasz model bezpieczeństwa. A jeśli ta lista obowiązków jest dłuższa niż chcesz przejąć, zarządzany przekaźnik się tym zajmuje — zobacz cennik.

Kiedy lepiej skorzystać z dostawcy zarządzanego

Hostowanie we własnym zakresie z Dockerem daje kontrolę, ale bądź szczery co do sytuacji, w których się to opłaca: gdy wymóg tego wymusza — zgodność z przepisami, sieć odizolowana, wymóg lokalizacji danych. Gdy nic takiego nie występuje, zarządzany przekaźnik zazwyczaj wygrywa pod względem całkowitych kosztów, gdy doliczysz dyżury dla własnego serwera, łatanie systemu operacyjnego, przechowywanie kluczy, odnawianie certyfikatów i jedną region bez failover. Tenvo uruchamia tę samą architekturę hbbs/hbbr, obsługiwaną dla Ciebie: Free $0, Lite $2.99/mies., Pro $7.99/mies. — zobacz cennik, lub plany biznesowe dla zespołu.

Następne kroki i źródła

Lista kontrolna od laboratorium do produkcji:

1. Wybierz host z Docker Engine 20.10+ i Docker Compose v2.x.
2. Utwórz trwałe woluminy i zadanie backupu uruchamiane codziennie.
3. Przypnij obraz serwera i waliduj aktualizacje w stagingu.
4. Terminuj TLS za pomocą NGINX/Traefik i uzyskaj certyfikaty od Let's Encrypt.
5. Monitoruj hosty relay i skaluj hbbr, gdy CPU lub przepustowość osiągną progi zdrowia.

Wolisz pominąć obowiązki operacyjne? Zarządzany przekaźnik Tenvo jest już postawiony, monitorowany i łatany — instalujesz klienta i łączysz się: Free $0, Lite $2.99/mies., Pro $7.99/mies. Pobierz klienty i instalatory, lub zobacz jak wersja zarządzana wypada w porównaniu do zwykłego RustDesk. Dla szerszej konfiguracji nasz przewodnik po konfiguracji dostępu zdalnego omawia sieć, uwierzytelnianie i użyteczność w różnych narzędziach.

Uruchamianie RustDesk w Dockerze to sposób, który można utrzymać, i jeśli jakiś wymóg stawia cię w tej sytuacji, powyższy stack to całe zadanie. Jeśli nic takiego nie występuje, ta sama architektura jest już dostępna w działającym środowisku — pełne porównanie kompromisów, koszt po koszcie, znajduje się w naszym szczerym przewodniku po samodzielnym hostowaniu pulpitu zdalnego.

Gotowy, aby spróbować? Pobierz klientów i uruchom własny stack — lub pomiń obowiązki operacyjne i rozpocznij na zarządzanym przekaźniku: cennik, lub plany biznesowe dla zespołu.