Laravel Reverb z Dockerem: przewodnik produkcyjny

2 min. czytaniaZaktualizowano

Reverb jest długo działającym serwerem WebSocket, nie komendą developerską awansowaną na produkcję. Opublikuj konfigurację, a następnie jawnie ustaw publiczne i wewnętrzne adresy w config/reverb.php oraz zmiennych REVERB_*.

env
REVERB_APP_ID=app-id
REVERB_APP_KEY=app-key
REVERB_APP_SECRET=app-secret
REVERB_SERVER_HOST=0.0.0.0
REVERB_SERVER_PORT=8080
REVERB_HOST=ws.example.com
REVERB_PORT=443
REVERB_SCHEME=https

SERVER_* opisuje binding procesu w Dockerze, a wartości publiczne opisują adres Echo przez TLS. Proxy przekazuje upgrade WebSocket, wystawiaj tylko WSS i ogranicz allowed origins do prawdziwych originów aplikacji.

Skalowanie jest decyzją o shared state

Jedna instancja to prawidłowy pierwszy deployment. Wiele instancji wymaga wspieranego skalowania poziomego i wspólnego backendu, aby każdy node widział broadcasty oraz stan kanałów; sam load balancer nie scala izolowanych procesów. Użyj odpowiedniej ścieżki Redis, wdrażaj config spójnie i przetestuj dwa połączenia trafiające do różnych instancji.

Nadzoruj php artisan reverb:start polityką restartu kontenera lub process managerem, dodaj health signal, zbieraj logi strukturalne i restartuj świadomie przy deployu. Monitoruj połączenia, reconnecty, latency eventów, CPU, file descriptors oraz odpowiedzi proxy.

Publiczny WSS i wewnętrzny proces

Adres procesu w Dockerze różni się od adresu, pod którym Echo łączy się z przeglądarki. Sekrety pozostają po stronie serwera; VITE_ publikuje tylko metadane połączenia.

env
REVERB_SERVER_HOST=0.0.0.0
REVERB_SERVER_PORT=8080
REVERB_HOST=ws.example.com
REVERB_PORT=443
REVERB_SCHEME=https
VITE_REVERB_APP_KEY=${REVERB_APP_KEY}
VITE_REVERB_HOST=ws.example.com
VITE_REVERB_PORT=443
VITE_REVERB_SCHEME=https
nginx
location /app/ {
    proxy_pass http://reverb:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 60s;
}

Testuj cały łańcuch: event ShouldBroadcast, autoryzację private channel, kolejkę i listener Echo. Przy restarcie sprawdź reconnect, a przed replikami potwierdź dokumentowaną ścieżkę shared Redis na dwóch instancjach. Monitoruj połączenia, pamięć, file descriptors, latency eventów i błędy upgrade Nginx.

Kiedy tego NIE używać

Nie używaj WebSocket dla strony, która może tanio odświeżać się na żądanie albo pollingiem. Nie wystawiaj wewnętrznego portu do internetu. Przy globalnej skali i wymaganiu managed reliability kompatybilny hosted broadcaster może być lepszym kompromisem niż utrzymywanie pojemności oraz incident response Reverb.

Powiązane artykuły

Wsparcie istniejącego systemu

Potrzebujesz pomocy z działającą aplikacją?

Pomagam firmom rozwijać działające systemy, porządkować wdrożenia i dodawać nowe funkcje bez dokładania chaosu do projektu.

Komentarze (0)
Zaloguj się, aby dodać komentarz

Musisz być zalogowany, aby dodać komentarz.

Zaloguj się

Potrzebujesz kogoś, kto weźmie odpowiedzialność za kolejny krok?

Porozmawiajmy o Twoim projekcie i określmy zakres, który ma sens dla Twoich celów.