RustDesk w Dockerze: przewodnik po konteneryzowanym serwerze RustDesk

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:

Bezpośredni TLS z proxy przed hbbs (zalecane dla zarządzania certyfikatami na poziomie web).
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:

Pobierz nowy obraz: docker pull rustdesk/rustdesk-server:1.3.0 (przykład).
Uruchom testowy kontener z tymi samymi woluminami i wykonaj testy smoke.
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 o zabezpieczaniu zdalnego dostępu, zobacz nasze artykuły o bezpieczeństwie zdalnego pulpitu oraz praktyczne kompromisy w samodzielnym hostingu zdalnego pulpitu.

Kiedy lepiej skorzystać z dostawcy zarządzanego

Samodzielne hostowanie z Dockerem daje kontrolę i prywatność, ale jeśli potrzebujesz w pełni zarządzanego SLA, oficjalnych funkcji enterprise (zarządzanie użytkownikami, scentralizowane rozliczenia) lub gotowej integracji z Windows AD, komercyjni dostawcy tacy jak TeamViewer lub AnyDesk mogą być lepszym wyborem. Bądź realistyczny co do kompromisów: self‑hosted zmniejsza opłaty abonamentowe za stanowisko i daje lokalizację danych, ale kosztuje czas operacyjny na utrzymanie, monitorowanie i zabezpieczanie.

Następne kroki i źródła

Lista kontrolna od laboratorium do produkcji:

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

Chcesz czyste pobranie, aby porównać podejście z kontenerami? Pobierz binarki lub instalatory Tenvo pod /download i sprawdź naszą stronę /pricing dla opcji wdrożeniowych. Jeśli wolisz szerszy przewodnik po konfiguracji dostępu zdalnego, nasz przewodnik po konfiguracji dostępu zdalnego omawia sieć, uwierzytelnianie i użyteczność w kontekście różnych narzędzi.

Uruchamianie RustDesk w Dockerze to solidne, łatwe w utrzymaniu podejście dla większości samodzielnych hostów: upraszcza aktualizacje i dobrze współgra z istniejącą infrastrukturą kontenerową. Jeśli potrzebujesz kopii pliku compose lub pomocy przy adaptacji do Kubernetes, wróć, a przygotuję manifest K8s i przykład Helm chart.

Gotowy, by spróbować? Pobierz niezbędne klienty lub obrazy testowe z /download i uruchom swój konteneryzowany serwer RustDesk już dziś.