Autor: Rocket.Chat z Docker Compose: instalacja na własnym VPS
Instrukcja wdrożenia Rocket.Chat przy użyciu Docker Compose. Dowiedz się, jak poprawnie skonfigurować wymagany replica set MongoDB, wdrożyć TLS oraz uniknąć błędów przy starcie.
Co budujesz
Prywatny komunikator zespołowy, którego jesteś wyłącznym właścicielem: Rocket.Chat uruchomiony na własnym VPS przy użyciu Docker Compose, z terminacją TLS, gdzie każda wiadomość znajduje się w bazie danych MongoDB, którą można archiwizować i przenosić. Rocket.Chat to dojrzała alternatywa open-source dla Slacka i Teams, oferująca kanały, wiadomości bezpośrednie, wątki, udostępnianie plików oraz komunikację głosową i wideo, a wszystko to na wynajętym i kontrolowanym przez Ciebie sprzęcie. Aplikacja to pojedynczy kontener, który uruchamia się w kilka minut. Wszystkie potencjalne problemy dotyczą bazy danych, dlatego większość tego przewodnika skupia się na MongoDB, a w szczególności na jednym wymaganiu, które zaskakuje każdego za pierwszym razem: Rocket.Chat nie zadziała z pojedynczą instancją (standalone) MongoDB. Wymaga on zestawu replik (replica set), nawet jeśli ten "zestaw" składa się tylko z jednego węzła.
Wymagania wstępne i matematyka pamięci RAM, o której nikt nie mówi
Należy uczciwie dobrać parametry serwera. Realne minimum dla małego zespołu to 2 vCPU i 4 GB pamięci RAM. Proces Node.js aplikacji Rocket.Chat wymaga samodzielnie około 1 do 1,5 GB, a pamięć podręczna WiredTiger silnika MongoDB domyślnie zajmuje około połowy pozostałej pamięci RAM. Na serwerze VPS z 2 GB pamięci obie usługi uruchomią się, ale zaczną kolidować w momencie pojawienia się rzeczywistego ruchu: MongoDB powiększy swoją pamięć podręczną, Node zwiększy stertę, jądro systemu wyczerpie strony pamięci, a mechanizm out-of-memory killer zakończy największy proces, zazwyczaj mongod. Kontener wyświetli Killed, Docker go zrestartuje, a serwer czatu będzie przerywał działanie co kilka minut pod obciążeniem, które powinien bez problemu obsłużyć. 2 GB wystarczy do testów dla dwóch osób; nie jest to konfiguracja dla zespołu. Należy zacząć od 4 GB, a w przypadku oczekiwania dziesiątek jednoczesnych użytkowników, rozmów wideo lub rosnącej historii plików, zapewnić 8 GB.
Przed rozpoczęciem należy również spełnić trzy warunki. Nazwa domeny z rekordem A wskazującym na publiczny adres IP serwera VPS; funkcje czasu rzeczywistego Rocket.Chat oraz klienci mobilni wymagają stabilnej nazwy hosta, a nie samego adresu IP. Otwarte porty 80 i 443 zarówno na zaporze sieciowej serwera, jak i na zaporze sieciowej dostawcy, która w większości paneli zarządzania stanowi oddzielny element. Oraz świeża instalacja Ubuntu 24.04 KVM VPS z dostępem root lub sudo. Jeśli decyzja o tym, czy serwer czatu jest odpowiednią pierwszą usługą do uruchomienia, jeszcze nie zapadła, przewodnik po tym, co warto hostować samodzielnie w 2026 roku przedstawia związane z tym kompromisy.
Instalacja silnika Docker oraz wtyczki Compose
Należy korzystać z oficjalnego repozytorium apt firmy Docker, a nie z pakietu docker.io dostarczanego przez Ubuntu ani przestarzałego, samodzielnego pliku binarnego docker-compose w języku Python. Nowoczesny Compose jest wtyczką Dockera, którą wywołuje się za pomocą docker compose, używając spacji, a nie łącznika. Stara wersja docker-compose v1 nie jest już wspierana i nieprawidłowo obsługuje poniższą składnię healthcheck oraz zależności.
sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginNależy potwierdzić obecność obu komponentów:
sudo docker version
sudo docker compose versiondocker compose version wyświetlające wynik w formacie Docker Compose version v2.x stanowi kluczową weryfikację. Jeśli pojawi się błąd docker: 'compose' is not a docker command, oznacza to, że wtyczka nie została zainstalowana. Należy naprawić ten problem na tym etapie, aby uniknąć trudnych do zdiagnozowania błędów w przyszłości.
Plik compose: MongoDB jako replikowany zestaw jednowęzłowy
To jest etap, na którym często popełniane są błędy, dlatego należy zapoznać się z nim uważnie. Rocket.Chat wykorzystuje strumienie zmian (change streams) MongoDB do przesyłania nowych wiadomości do połączonych klientów w czasie rzeczywistym, a strumienie zmian są dostępne tylko w replikowanym zestawie (replica set). Skierowanie Rocket.Chat na zwykłą, samodzielną instancję mongod spowoduje nawiązanie połączenia, niepowodzenie otwarcia strumienia zmian i zapętlenie procesu restartu. Rozwiązanie nie jest skomplikowane: należy uruchomić pojedynczy, standardowy kontener MongoDB, ale z flagą --replSet, a następnie zainicjować zestaw jednowęzłowy.
Utwórz katalog roboczy oraz plik compose.yml:
services:
mongodb:
image: mongo:8.0
restart: always
command: ["mongod", "--replSet", "rs0", "--bind_ip_all", "--oplogSize", "128"]
volumes:
- mongodb_data:/data/db
- mongodb_config:/data/configdb
healthcheck:
test: ["CMD", "mongosh", "--quiet", "--eval", "db.adminCommand('ping')"]
interval: 10s
timeout: 10s
retries: 12
rocketchat:
image: registry.rocket.chat/rocketchat/rocket.chat:8.5.1
restart: always
depends_on:
mongodb:
condition: service_healthy
environment:
MONGO_URL: "mongodb://mongodb:27017/rocketchat?replicaSet=rs0"
MONGO_OPLOG_URL: "mongodb://mongodb:27017/local?replicaSet=rs0"
ROOT_URL: "https://chat.example.com"
PORT: "3000"
ports:
- "127.0.0.1:3000:3000"
volumes:
mongodb_data:
mongodb_config:Kilka wyborów w tym miejscu jest celowych. Port Rocket.Chat jest publikowany na 127.0.0.1:3000, a nie 0.0.0.0; sama aplikacja nie posiada TLS, więc dostęp do niej powinien mieć wyłącznie reverse proxy działający na tej samej maszynie. Powiązanie jej z każdym interfejsem wystawiłoby stronę logowania przesyłaną otwartym tekstem bezpośrednio na publiczny Internet. MongoDB nie jest w ogóle publikowane na hoście; jest dostępne tylko wewnątrz sieci Compose pod nazwą mongodb, która jest dokładnie taką nazwą hosta, jakiej używa MONGO_URL. MONGO_URL zawiera ?replicaSet=rs0; pominięcie tego parametru sprawi, że sterownik potraktuje serwer jako samodzielną instancję, mimo że jest to replikowany zestaw, przez co strumienie zmian nadal nie będą działać. MONGO_OPLOG_URL wskazuje na bazę danych local, w której znajduje się oplog; nowoczesny Rocket.Chat preferuje strumienie zmian, ale ustawienie to jest bezpieczne i zapewnia kompatybilność ze starszymi ścieżkami kodu. depends_on wykorzystuje condition: service_healthy, dzięki czemu Compose czeka, aż MongoDB odpowie na ping, zanim uruchomi Rocket.Chat – do tego właśnie służy healthcheck.
Należy przypiąć konkretne tagi wersji dla obu obrazów, mongo:8.0 oraz jawnie wskazanego wydania Rocket.Chat, takiego jak 8.5.1, i nigdy nie używać :latest. Spowodowałoby to nieobsługiwaną aktualizację docker pull bez nadzoru, której nie można następnie przeprowadzić w ramach migracji. Przed przypięciem wersji należy sprawdzić bieżące stabilne wydanie Rocket.Chat oraz obsługiwane przez nie wersje MongoDB. Rocket.Chat publikuje dla każdego wydania dokument informacyjny w formacie możliwym do odczytu maszynowego: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' zwraca compatibleMongoVersions: ["8.0"] dla wersji 8.5.1, dlatego mongo:8.0 jest jedynym obsługiwanym silnikiem. Dokument zawiera również flagę lts, która wskazuje, czy dane wydanie jest wersją z długoterminowym wsparciem i warto je przypiąć na serwerze, który nie powinien wymagać stałego nadzoru. Nie każdy projekt publikuje obraz z wersją. W takim przypadku wersję należy przypiąć w źródle: samodzielne hostowanie trackera treningowego openGym oznacza przełączenie na konkretny tag git i zbudowanie projektu na jego podstawie zamiast śledzenia zmiennej gałęzi.
Inicjalizacja zestawu replik
Uruchom stos:
sudo docker compose up -dRocket.Chat zacznie natychmiast ulegać awarii, a Docker będzie go stale restartował. Jest to zachowanie oczekiwane, ponieważ zestaw replik jeszcze nie istnieje. Należy go utworzyć ręcznie:
sudo docker compose exec mongodb mongosh --eval 'rs.initiate({_id: "rs0", members: [{_id: 0, host: "mongodb:27017"}]})'Poprawnym wynikiem jest { ok: 1 }. W ciągu kilku sekund pojedynczy węzeł wybierze siebie jako węzeł główny (primary); potwierdź to poleceniem:
sudo docker compose exec mongodb mongosh --quiet --eval 'rs.status().members[0].stateStr'Oczekiwany wynik to PRIMARY. Najważniejszym szczegółem na całej tej stronie jest argument host: "mongodb:27017". Jeśli uruchomisz zwykłe rs.initiate() bez listy członków, MongoDB ogłosi zestaw replik pod wewnętrzną nazwą hosta kontenera, czyli losowym hashem typu a1b2c3d4e5f6. Rocket.Chat, łącząc się z własnego kontenera, nie może rozwiązać tej nazwy, przez co sterownik MongoDB zgłasza błąd DNS i zapętla się, logując MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Zawsze inicjuj zestaw z jawną nazwą usługi, która odpowiada Twojemu MONGO_URL.
Pierwsze uruchomienie: monitorowanie procesu
Gdy zestaw jest główny (primary), kolejny restart Rocket.Chat przebiega poprawnie i rozpoczyna migracje przy pierwszym uruchomieniu. Monitoruj dzienniki:
sudo docker compose logs -f rocketchatWiersz, na który należy czekać, to baner startowy:
+--------------------------------------------+
SERVER RUNNING
Rocket.Chat Version: 8.5.1
NodeJS Version: 22.22.3 - x64
+--------------------------------------------+Pierwsze uruchomienie jest powolne, ponieważ aplikacja wykonuje migracje bazy danych i buduje indeksy. Należy odczekać minutę lub dwie przed podjęciem działań naprawczych. Jeśli dziennik powtarza MongoServerSelectionError: Server selection timed out after 30000 ms z opisem topologii typu ReplicaSetNoPrimary, zestaw replik nie został zainicjowany. Jeśli powtarza getaddrinfo ENOTFOUND z losowym hashem, został zainicjowany z błędnym hostem. W obu przypadkach należy wrócić do poprzedniego kroku. Gdy pojawi się SERVER RUNNING, Rocket.Chat nasłuchuje na 127.0.0.1:3000 i jest to moment na skonfigurowanie właściwej nazwy hosta oraz TLS przed aplikacją.
Zabezpieczenie za pomocą TLS
Nigdy nie udostępniaj Rocket.Chat przez nieszyfrowany protokół HTTP. Jednokrotne zalogowanie przez http:// powoduje przekazanie hasła administratora każdemu, kto znajduje się na ścieżce połączenia. Terminację TLS należy przeprowadzić na odwrotnym proxy (reverse proxy) działającym na tym samym serwerze, przekazując ruch do 127.0.0.1:3000. Dwie kwestie są kluczowe: proxy musi przekazywać nagłówki aktualizacji WebSocket, ponieważ Rocket.Chat działa w czasie rzeczywistym i bez nich przestaje funkcjonować, a parametr ROOT_URL kontenera musi być dokładnie zgodny z publicznym adresem HTTPS wpisywanym przez użytkowników.
Rozpocznij od bloku serwera nginx w trybie zwykłego HTTP, który przekazuje ruch do aplikacji i przesyła nagłówki aktualizacji. Zapisz go jako /etc/nginx/sites-available/rocketchat, utwórz dowiązanie symboliczne w sites-enabled i przeładuj konfigurację:
server {
listen 80;
server_name chat.example.com;
client_max_body_size 100M;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Na razie pozostaw go na porcie 80; blok z listen 443 ssl; bez certyfikatu nie przejdzie nawet weryfikacji sudo nginx -t. Przeładuj nginx (sudo nginx -t && sudo systemctl reload nginx), a następnie wystaw certyfikat. Najczystszą metodą w systemie Ubuntu jest uzyskanie certyfikatów TLS Let's Encrypt za pomocą Certbot i nginx: certbot --nginx automatycznie modyfikuje powyższy blok, dodając listen 443 ssl;, linie ssl_certificate oraz automatyczne przekierowanie z portu 80 na 443, a także harmonogram odnawiania certyfikatów. Jeśli uruchamiasz już kilka kontenerów za jednym proxy, lepszym rozwiązaniem będzie Traefik z automatycznym TLS dla wielu aplikacji Docker; dodaj etykiety routera i usługi do serwisu rocketchat, a Traefik samodzielnie wystąpi o certyfikat i będzie go odnawiał, eliminując potrzebę tworzenia bloku nginx. Niezależnie od wybranej metody, ustaw ROOT_URL na https://chat.example.com w pliku compose.yml i uruchom ponownie sudo docker compose up -d, aby kontener uwzględnił zmianę. Jeśli chcesz, aby serwer był dostępny wyłącznie z sieci lokalnej, a nie z publicznego Internetu, umieść go za własnym serwerem VPN WireGuard na VPS i powiąż proxy z adresem tunelu.
Kreator konfiguracji przy pierwszym uruchomieniu
Przejdź pod adres https://chat.example.com, a Rocket.Chat przeprowadzi użytkownika przez krótki kreator. Pierwszym krokiem jest utworzenie konta administratora – należy podać imię i nazwisko, nazwę użytkownika, adres e-mail oraz silne hasło. Jest to jedyne istniejące konto, dlatego należy zadbać o jego bezpieczeństwo. Następnie należy podać informacje o organizacji i serwerze, takie jak nazwa, branża, wielkość, nazwa witryny oraz domyślny język. Są to dane informacyjne, które można wypełnić i przejść dalej. Kolejny wybór ma kluczowe znaczenie: rejestracja obszaru roboczego w chmurze Rocket.Chat Cloud lub pozostawienie go w trybie standalone.
Rejestracja umożliwia korzystanie z mobilnych powiadomień push za pośrednictwem bramy Rocket.Chat oraz dostęp do sklepu z dodatkami, co wiąże się jednak z utrzymywaniem relacji z infrastrukturą chmurową Rocket.Chat. Tryb standalone zapewnia pełną prywatność serwera i brak zależności zewnętrznych, jednak powiadomienia push na systemach iOS i Android przestają działać. Wynika to z faktu, że Apple i Google nie pozwalają na obsługę certyfikatów push przez samodzielnie skompilowane aplikacje, dlatego oficjalne aplikacje korzystają z bramy chmurowej. Wybierz tryb standalone, jeśli priorytetem jest prywatność, a użytkownicy korzystają głównie z aplikacji webowej. Wybierz rejestrację, jeśli powiadomienia mobilne są niezbędne. Decyzję można zmienić później w panelu administracyjnym.
Zabezpiecz instancję przed udostępnieniem
Rocket.Chat jest domyślnie dostarczany z Public włączoną rejestracją, co oznacza, że każda osoba znająca adres URL może utworzyć konto. W przypadku publicznego hosta stanowi to poważne zagrożenie. Przejdź do Admin → Settings → Accounts → Registration i ustaw Registration Form na Disabled, aby tworzyć konta ręcznie lub za pomocą linków zaproszeniowych, albo na Secret URL. Przy okazji wyłącz opcje Allow Anonymous Read oraz Allow Anonymous Write, chyba że celowo udostępniasz kanał publiczny w trybie tylko do odczytu. Jeśli ręczne tworzenie kont jest zbyt czasochłonne, a Rocket.Chat nie jest jedyną usługą w organizacji, skonfiguruj logowanie OAuth w Rocket.Chat, wskazując na własny serwer Authentik SSO. Dzięki temu zarządzanie użytkownikami odbywa się centralnie, a nie w każdej aplikacji z osobna.
Określ również miejsce przechowywania plików. Domyślnym magazynem File Upload jest GridFS, który przechowuje wszystkie obrazy i załączniki bezpośrednio w bazie MongoDB. Jest to rozwiązanie proste, ale powoduje, że baza danych oraz każdy mongodump rosną w niekontrolowany sposób wraz z przesyłanymi zrzutami ekranu. W sekcji Admin → Settings → File Upload możesz zmienić magazyn na lokalny system plików lub zasobnik zgodny z S3 oraz ustawić rozsądny limit rozmiaru pliku. W przypadku małych zespołów GridFS jest wystarczający, należy jednak pamiętać, że kopie zapasowe będą z czasem coraz większe.
Tworzenie kopii zapasowych za pomocą mongodump
Wszystkie dane znajdują się w wolumenie mongodb_data. Nie należy kopiować wolumenu bezpośrednio z działającej bazy danych; zamiast tego należy wykonać spójny zrzut za pomocą mongodump, przesyłając go strumieniowo do pliku na hoście:
sudo docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > rocketchat-$(date +%F).archive.gzTo pojedyncze archiwum skompresowane za pomocą gzip stanowi cały obszar roboczy: użytkowników, kanały, wiadomości, ustawienia oraz pliki, jeśli przechowywane są w GridFS. Jeśli pliki zostały przeniesione do systemu plików lub S3, należy je zabezpieczyć oddzielnie. Przywracanie na nowej instancji wymaga najpierw zainicjowania zestawu replik (replica set), a następnie wykonania polecenia:
sudo docker compose exec -T mongodb mongorestore --archive --gzip --drop < rocketchat-2026-07-15.archive.gzKopię archiwum należy przechowywać poza serwerem – w pamięci obiektowej, na innym serwerze lub w dowolnym miejscu, gdzie awaria VPS nie spowoduje utraty kopii zapasowej. Proces zrzutu należy uruchamiać codziennie za pomocą cron. Kopia zapasowa, która nigdy nie została przywrócona, jest jedynie nadzieją, a nie zabezpieczeniem; należy przećwiczyć proces przywracania na testowym serwerze VPS, aby mieć pewność, że działa on poprawnie przed wystąpieniem rzeczywistej potrzeby.
Aktualizacje: przypinanie tagów, lektura notatek, przestrzeganie macierzy MongoDB
Dwie zasady sprawiają, że aktualizacje przebiegają bezproblemowo. Po pierwsze, aktualizuj Rocket.Chat o jedną główną wersję naraz. Aplikacja uruchamia migracje schematu podczas startu i celowo blokuje przeskakiwanie wersji głównych; próba przejścia z 6.x bezpośrednio na 8.x zakończy się błędem migracji zamiast uszkodzeniem danych. Zmień tag obrazu na najnowsze wydanie kolejnej wersji głównej, zapoznaj się z notatkami do tego wydania pod kątem zmian powodujących niekompatybilność, uruchom docker compose up -d i obserwuj dzienniki, aż migracja dobiegnie końca, zanim przejdziesz dalej. Po drugie, przestrzegaj macierzy wsparcia MongoDB. Każde wydanie Rocket.Chat wspiera określony zestaw wersji MongoDB, a curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions wskazuje, które z nich są obsługiwane. Podczas aktualizacji MongoDB, na przykład z 7.0 na 8.0, przechodź o jedną wersję główną naraz i ustawiaj wersję kompatybilności funkcji (feature-compatibility version) po każdym kroku. W MongoDB 8.0 polecenie to wymaga jawnego użycia confirm: true, w przeciwnym razie operacja zostanie odrzucona z komunikatem nakazującym ponowne uruchomienie z flagą potwierdzenia:
sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'Wykonaj mongodump przed każdą aktualizacją któregokolwiek z komponentów. To cała polisa ubezpieczeniowa.
Tryby awarii i dokładne komunikaty
Rocket.Chat wpada w pętlę restartów zaraz po docker compose up, a docker compose logs rocketchat zapełnia się wpisem MongoServerSelectionError. MongoDB działa, ale sterownik nie może wybrać węzła głównego (primary), a dokładny komunikat wskazuje na popełniony błąd. Server selection timed out after 30000 ms z typem topologii ReplicaSetNoPrimary oznacza, że nie wykonano rs.initiate(); zestaw nie posiada jeszcze konfiguracji. getaddrinfo ENOTFOUND z losowym hashem oznacza, że inicjacja odbyła się bez jawnego host: "mongodb:27017", przez co MongoDB rozgłosiło nierozpoznawalną nazwę hosta kontenera. Diagnozę przeprowadź za pomocą sudo docker compose exec mongodb mongosh --eval 'rs.status()': jeśli wystąpi błąd MongoServerError: no replset config has been received, zainicjuj zestaw; jeśli widoczny jest członek, którego name jest losowym hashem, zainicjuj ponownie, używając nazwy usługi.
Interfejs webowy ładuje się, ale logowanie trwa w nieskończoność. Otwórz konsolę przeglądarki, gdzie zobaczysz WebSocket connection to 'wss://chat.example.com/websocket' failed. Zazwyczaj wynika to z niedopasowania ROOT_URL lub proxy, które nie przekazuje nagłówków upgrade. Upewnij się, że ROOT_URL odpowiada dokładnemu adresowi publicznemu wraz z https:// oraz że blok location w nginx ustawia Upgrade i Connection "upgrade" za pomocą proxy_http_version 1.1. Po zmianie któregokolwiek z tych parametrów uruchom ponownie docker compose up -d.
Kontener ciągle się wyłącza, a docker compose ps wskazuje na Restarting. docker compose logs urywa się w połowie linii, a sudo dmesg | tail pokazuje Out of memory: Killed process 12345 (mongod) od oom-killer; kod wyjścia to 137. Serwerowi brakuje pamięci RAM. Jedynym skutecznym rozwiązaniem jest większy VPS, minimum 4 GB. Jako rozwiązanie tymczasowe dodaj swap i ogranicz pamięć podręczną MongoDB za pomocą --wiredTigerCacheSizeGB 1 w pliku command, jednak swap jedynie opóźni kolejny błąd OOM przy rzeczywistym obciążeniu:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfiledocker compose up kończy się błędem Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Port 3000 jest już zajęty, często przez poprzedni kontener Rocket.Chat, który nie został poprawnie zatrzymany, lub przez inną aplikację. Znajdź proces za pomocą sudo ss -ltnp | grep :3000, zatrzymaj go lub zmień mapowanie portu po stronie hosta na 127.0.0.1:3001:3000 i zaktualizuj proxy_pass w konfiguracji proxy.
FAQ
Czy Rocket.Chat rzeczywiście wymaga zestawu replik MongoDB?
Tak, nawet w przypadku pojedynczego serwera z jednym węzłem bazy danych. Rocket.Chat dostarcza wiadomości w czasie rzeczywistym przy użyciu strumieni zmian MongoDB (change streams), a jest to funkcja dostępna wyłącznie w zestawach replik; samodzielna instancja mongod nie może ich otworzyć. Nie potrzeba do tego wielu maszyn; wystarczy uruchomić jeden kontener MongoDB z flagą --replSet rs0 i zainicjować jednoelementowy zestaw za pomocą rs.initiate(). Pominięcie tego kroku sprawi, że sterownik nie znajdzie węzła nadrzędnego (primary), przez co Rocket.Chat wpadnie w pętlę restartów z błędem MongoServerSelectionError: Server selection timed out i nigdy nie zakończy procesu uruchamiania.
Ile pamięci RAM potrzebuje samodzielnie hostowany Rocket.Chat?
Należy zaplanować 4 GB jako minimum praktyczne oraz 8 GB dla aktywnego zespołu. Proces Node w Rocket.Chat zajmuje około 1 do 1,5 GB, a MongoDB rezerwuje mniej więcej połowę pozostałej pamięci RAM na swój cache WiredTiger. Na maszynie z 2 GB pamięci oba procesy wchodzą w konflikt, co powoduje, że mechanizm out-of-memory killer kończy działanie mongod przy jakimkolwiek realnym obciążeniu, co objawia się błędem Killed w logach oraz kodem wyjścia 137. 2 GB wystarcza jedynie do przetestowania oprogramowania z kilkoma użytkownikami testowymi.
Jak umieścić Rocket.Chat za HTTPS?
Należy uruchomić reverse proxy na tym samym VPS, które obsłuży terminację TLS i przekaże ruch do 127.0.0.1:3000, a następnie ustawić zmienną ROOT_URL kontenera na publiczny adres https://. Proxy musi przekazywać nagłówki WebSocket upgrade, w przeciwnym razie logowanie zawiesi się. Certbot z nginx to najprostsza konfiguracja dla pojedynczej aplikacji; Traefik jest lepszym rozwiązaniem, jeśli uruchamiasz kilka kontenerów za jednym proxy i wymagasz automatycznego zarządzania certyfikatami.
Jak wykonać kopię zapasową samodzielnie hostowanego Rocket.Chat?
Należy wykonać spójny zrzut bazy danych za pomocą mongodump zamiast kopiowania wolumenu: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. To archiwum zawiera użytkowników, kanały, wiadomości i ustawienia, a także przesłane pliki, jeśli przechowywanie pozostało w GridFS. Kopię należy pobrać z serwera, zautomatyzować proces za pomocą cron i przeprowadzić próbne odtworzenie mongorestore na tymczasowej maszynie, aby upewnić się, że procedura przywracania działa poprawnie.
Jak zaktualizować Rocket.Chat bez uszkodzenia MongoDB?
Rocket.Chat należy aktualizować o jedną główną wersję naraz, ponieważ przeprowadza on migracje przy starcie i odmawia pomijania głównych wersji. Przed zmianą przypiętego tagu obrazu należy przeczytać informacje o wydaniu. Należy sprawdzić, które wersje MongoDB obsługuje docelowe wydanie za pomocą curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions, a podczas aktualizacji MongoDB przechodzić przez kolejne wersje główne pojedynczo i ustawiać setFeatureCompatibilityVersion za pomocą confirm: true po każdym kroku. Zawsze należy najpierw wykonać mongodump.