द्वारे Docker Compose वापरून Rocket.Chat स्वतः होस्ट करा
VPS वर Docker Compose सह Rocket.Chat चालवा: single-node MongoDB replica set का आवश्यक आहे, TLS व backups कसे मांडायचे आणि सामान्य त्रुटी कशा सोडवायच्या.
तुम्ही काय तयार करणार आहात
तुमच्या पूर्ण नियंत्रणाखालील खाजगी टीम चॅट: Docker Compose अंतर्गत तुमच्या स्वतःच्या VPS वर चालणारे Rocket.Chat, TLS termination सह, आणि प्रत्येक संदेश तुम्ही backup करून स्थलांतरित करू शकता अशा MongoDB database मध्ये साठवलेला. Rocket.Chat हा Slack आणि Teams साठीचा परिपक्व open-source पर्याय आहे. यात channels, direct messages, threads, file sharing तसेच voice आणि video सुविधा आहेत. हे सर्व तुम्ही भाड्याने घेतलेल्या आणि नियंत्रित करत असलेल्या hardware वर चालते. हा एकमेव विश्वासार्ह पर्याय नाही. तुम्ही अजून निवड करत असाल, तर Mattermost, Rocket.Chat, Synapse आणि Zulip यांची तुलना या पर्यायांची पुढील काळात अडचणी निर्माण करणाऱ्या बाबींवर तुलना करते: RAM, database, mobile push, SSO आणि upgrades. हे application एकाच container मध्ये चालते आणि काही मिनिटांत सुरू होते. प्रत्यक्षात उद्भवणाऱ्या बहुतेक समस्या त्याच्या शेजारील database मध्ये असतात. त्यामुळे या मार्गदर्शकाचा मोठा भाग MongoDB विषयी आहे. विशेषतः, सुरुवातीला अनेकांना आश्चर्य वाटणाऱ्या एका आवश्यकतेविषयी: Rocket.Chat standalone MongoDB वर चालत नाही. त्याला replica set आवश्यक असतो, जरी तो "set" एकाच node चा असला तरी.
पूर्वतयारी आणि RAM चे गणित, ज्याबद्दल कोणी सांगत नाही
सर्व्हरची क्षमता वास्तववादी पद्धतीने ठरवा. छोट्या टीमसाठी व्यवहार्य किमान क्षमता 2 vCPU आणि 4 GB RAM आहे. Rocket.Chat च्या Node.js process ला एकट्याला साधारण 1 ते 1.5 GB RAM लागते. MongoDB चा WiredTiger cache उपलब्ध उरलेल्या RAM पैकी साधारण निम्मी RAM default ने वापरतो. 2 GB VPS वर boot वेळी दोन्ही चालू होतात. वास्तविक network traffic सुरू होताच त्यांच्यात RAM साठी स्पर्धा सुरू होते: MongoDB चा cache वाढतो, Node चा heap वाढतो, kernel कडे pages उरत नाहीत आणि out-of-memory killer सर्वात मोठ्या process ला बंद करतो; बहुतेक वेळा तो mongod असतो. Container Killed दाखवतो, Docker तो पुन्हा सुरू करतो आणि अपेक्षित load सहज हाताळता आला पाहिजे अशा स्थितीत chat server दर काही मिनिटांनी बंद पडतो. दोन लोकांसह प्राथमिक चाचणीसाठी 2 GB पुरेसे आहे; team server साठी ते पुरेसे नाही. सुरुवात 4 GB पासून करा. डझनभर concurrent users, video calls किंवा वाढता upload history अपेक्षित असल्यास 8 GB द्या. VPS वर चालणाऱ्या इतर गोष्टींसाठीही RAM राखून ठेवा. त्याच VPS वर Notion-style AFFiNE workspace ठेवल्यास समान pages साठी स्पर्धा करणारे आणखी चार containers जोडले जातात. त्यामुळे त्यांची RAM Rocket.Chat च्या RAM मधून कमी न करता अतिरिक्त असली पाहिजे.
सुरू करण्यापूर्वी आणखी तीन गोष्टी तयार असणे आवश्यक आहे. VPS च्या public IP कडे निर्देश करणारे A record असलेले domain name आवश्यक आहे. Rocket.Chat ची real-time features आणि mobile clients यांना bare IP ऐवजी स्थिर hostname आवश्यक असतो. Server firewall आणि provider च्या network firewall या दोन्हींमध्ये Ports 80 and 443 open असणे आवश्यक आहे. बहुतेक panels मध्ये provider चे network firewall हे स्वतंत्र नियंत्रण असते. तसेच root किंवा sudo असलेला fresh Ubuntu 24.04 KVM VPS आवश्यक आहे. Chat server ही पहिली self-hosted service म्हणून योग्य आहे का, याचा निर्णय अजून घेत असाल, तर 2026 मध्ये self-hosting करण्यासारख्या गोष्टींचे मार्गदर्शन उपलब्ध पर्यायांमधील तडजोडी स्पष्ट करते.
Docker engine आणि Compose plugin स्थापित करा
Docker चे स्वतःचे apt repository वापरा. Ubuntu सोबत येणारे docker.io package वापरू नका. तसेच जुने standalone docker-compose Python binary वापरू नका. आधुनिक Compose हे Docker plugin आहे. ते docker compose म्हणून, म्हणजे hyphen ऐवजी space वापरून, invoke करायचे असते. जुने docker-compose v1 आता end-of-life आहे. खालील healthcheck आणि dependency syntax ते चुकीच्या पद्धतीने हाताळते.
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-pluginदोन्ही घटक उपलब्ध आहेत याची खात्री करा:
sudo docker version
sudo docker compose versiondocker compose version ने Docker Compose version v2.x सारखे output दाखवणे ही महत्त्वाची तपासणी आहे. docker: 'compose' is not a docker command त्रुटी आल्यास plugin स्थापित झालेले नाही. नंतर गोंधळात टाकणाऱ्या त्रुटी येण्यापूर्वी ही समस्या येथेच दुरुस्त करा.
compose फाइल: एकल-नोड replica set म्हणून MongoDB
हा भाग अनेकदा चुकीचा केला जातो, त्यामुळे तो हळूहळू वाचा. Rocket.Chat कनेक्ट केलेल्या क्लायंटना नवीन संदेश real time मध्ये पाठवण्यासाठी MongoDB चे change streams वापरते, आणि change streams फक्त replica set वर उपलब्ध असतात. Rocket.Chat ला साध्या standalone mongod कडे निर्देशित केल्यास ते कनेक्ट होईल, change stream उघडण्यात अपयशी ठरेल आणि सतत restart loop मध्ये जाईल. यावरील उपाय अवघड नाही: एक साधा MongoDB container चालवा, पण तो --replSet सह सुरू करा आणि त्यानंतर एक-सदस्यीय set सुरू करा.
कार्यरत directory आणि 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:येथील काही निवडी हेतुपुरस्सर आहेत. Rocket.Chat चा port 127.0.0.1:3000 वर प्रकाशित केला आहे, 0.0.0.0 वर नाही. अॅपमध्ये स्वतःचे TLS नाही, त्यामुळे त्याच सर्व्हरवरील reverse proxy नेच त्याच्यापर्यंत पोहोचले पाहिजे; तो प्रत्येक interface शी bind केल्यास plaintext login page थेट सार्वजनिक internet वर उघडे पडेल. MongoDB host वर अजिबात प्रकाशित केलेले नाही; ते Compose च्या internal network वर mongodb या नावानेच उपलब्ध आहे. MONGO_URL वापरत असलेले hostname हेच आहे. MONGO_URL मध्ये ?replicaSet=rs0 आहे. ते वगळल्यास server replica set असतानाही driver त्याला standalone समजतो आणि change streams तरीही अपयशी ठरतात. MONGO_OPLOG_URL त्या local database कडे निर्देश करते जिथे oplog साठवला जातो; आधुनिक Rocket.Chat change streams ला प्राधान्य देते, पण ते सेट करणे निरुपद्रवी आहे आणि जुन्या code paths साठी उपयुक्त ठरते. depends_on मध्ये condition: service_healthy वापरले आहे. त्यामुळे Compose, MongoDB च्या ping ला उत्तर मिळेपर्यंत Rocket.Chat सुरू करत नाही. healthcheck यासाठीच असतो.
दोन्ही images वर वास्तविक version tags निश्चित करा: mongo:8.0 आणि येथे दिलेल्या 8.5.1 सारखी स्पष्ट Rocket.Chat release वापरा. :latest कधीही वापरू नका. त्यामुळे unattended docker pull चे अनपेक्षित आणि migration न करता येणाऱ्या upgrade मध्ये रूपांतर होते. Version निश्चित करण्यापूर्वी सध्याची stable Rocket.Chat release आणि ती समर्थित असलेल्या MongoDB versions तपासा. Rocket.Chat प्रत्येक release साठी machine-readable info document प्रकाशित करते: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' वापरल्यास 8.5.1 साठी compatibleMongoVersions: ["8.0"] मिळते. त्यामुळे mongo:8.0 हे एकमेव समर्थित engine आहे. तसेच lts flag त्या release चे long-term-support build आहे का ते सांगते; server ची वारंवार देखभाल करायची नसल्यास अशा build साठी pin करणे योग्य ठरते. प्रत्येक project versioned image प्रकाशित करतोच असे नाही. अशा वेळी pin source वर करावा: openGym workout tracker चे self-hosting याचा अर्थ बदलत राहणाऱ्या branch ऐवजी विशिष्ट git tag checkout करून त्यातून build करणे.
प्रतिकृती संच सुरू करा
स्टॅक सुरू करा:
sudo docker compose up -dRocket.Chat लगेच crash होईल आणि Docker ते पुन्हा पुन्हा सुरू करत राहील. हे अपेक्षित आहे, कारण replica set अद्याप अस्तित्वात नाही. तो एकदाच manually तयार करा:
sudo docker compose exec mongodb mongosh --eval 'rs.initiate({_id: "rs0", members: [{_id: 0, host: "mongodb:27017"}]})'योग्य परिणाम { ok: 1 } असा असेल. काही सेकंदांत single node स्वतःला primary म्हणून elect करतो; याची पडताळणी करण्यासाठी:
sudo docker compose exec mongodb mongosh --quiet --eval 'rs.status().members[0].stateStr'तुम्हाला PRIMARY दिसले पाहिजे. या संपूर्ण पृष्ठावरील सर्वात महत्त्वाचा तपशील म्हणजे host: "mongodb:27017" argument आहे. तुम्ही members list शिवाय साधा rs.initiate() चालवला, तर MongoDB replica set ची जाहिरात container च्या internal hostname अंतर्गत करतो; उदाहरणार्थ a1b2c3d4e5f6 सारखा random hash. Rocket.Chat स्वतःच्या container मधून कनेक्ट होताना त्या नावाचे resolution करू शकत नाही. त्यामुळे MongoDB driver त्यावर DNS resolution करण्यात अपयशी ठरतो आणि MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 log message लिहीत अनिश्चित काळ loop करत राहतो. तुमच्या MONGO_URL शी जुळणारे explicit service name वापरूनच नेहमी initiate करा.
पहिला बूट: सेवा सुरू होताना निरीक्षण करा
Replica set primary झाल्यानंतर Rocket.Chat ची पुढील restart यशस्वीरीत्या कनेक्ट होते आणि पहिल्या रनसाठीच्या migrations सुरू करते. Logs पाहा:
sudo docker compose logs -f rocketchatतुम्ही ज्या ओळीची प्रतीक्षा करत आहात ती startup banner आहे:
+--------------------------------------------+
SERVER RUNNING
Rocket.Chat Version: 8.5.1
NodeJS Version: 22.22.3 - x64
+--------------------------------------------+पहिला बूट धीमा असतो. अॅप database migrations चालवते आणि indexes तयार करते. त्यामुळे काळजी करण्यापूर्वी एक-दोन मिनिटे प्रतीक्षा करा. त्याऐवजी log मध्ये MongoServerSelectionError: Server selection timed out after 30000 ms हा संदेश ReplicaSetNoPrimary प्रकारच्या topology description सह पुन्हा पुन्हा दिसत असेल, तर replica set initiate केलेले नाही. random hash वर getaddrinfo ENOTFOUND हा संदेश पुन्हा पुन्हा दिसत असेल, तर ते चुकीच्या host सह initiate केले गेले आहे. दोन्हीपैकी कोणतीही स्थिती असल्यास, मागील पायरीकडे जा. SERVER RUNNING दिसल्यानंतर Rocket.Chat 127.0.0.1:3000 वर listening करत आहे. आता त्याच्यासमोर वास्तविक hostname आणि TLS configure करण्याची वेळ आली आहे.
TLS मागे ठेवा
Rocket.Chat ला साध्या HTTP वर कधीही उघडे ठेवू नका. http:// वर एकदा लॉग इन केले की, मार्गातील कोणालाही तुमचा admin password मिळतो. त्याच बॉक्सवरील reverse proxy मध्ये TLS termination करा आणि विनंत्या 127.0.0.1:3000 कडे forward करा. दोन गोष्टी महत्त्वाच्या आहेत: proxy ने WebSocket upgrade headers forward करणे आवश्यक आहे, कारण Rocket.Chat real-time पद्धतीने कार्य करते आणि त्यांच्याशिवाय काम करणे थांबवते; तसेच container मधील ROOT_URL वापरकर्ते टाइप करतात त्या सार्वजनिक HTTPS address शी तंतोतंत जुळले पाहिजे.
सुरुवात plain HTTP nginx server block पासून करा. तो app कडे proxy करेल आणि upgrade headers forward करेल. तो /etc/nginx/sites-available/rocketchat म्हणून जतन करा, sites-enabled मध्ये symlink तयार करा आणि reload करा:
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;
}
}आत्ता तो port 80 वरच ठेवा. listen 443 ssl; असलेला आणि certificate नसलेला block sudo nginx -t देखील पार करू शकणार नाही. nginx reload करा (sudo nginx -t && sudo systemctl reload nginx), त्यानंतर certificate जारी करा. Ubuntu वरचा सर्वात सोपा मार्ग म्हणजे Certbot आणि nginx वापरून Let's Encrypt TLS certificates: certbot --nginx वरील block जागेवरच पुन्हा लिहिते, त्यात listen 443 ssl;, ssl_certificate lines आणि automatic 80-to-443 redirect जोडते आणि renewal तुमच्यासाठी schedule करते. तुम्ही आधीच एका proxy मागे अनेक containers चालवत असल्यास, अनेक Docker apps साठी automatic TLS असलेले Traefik हा अधिक सुटसुटीत पर्याय आहे. rocketchat service मध्ये router आणि service labels जोडा; त्यानंतर Traefik तुमच्यासाठी certificate ची विनंती करून renewal करते आणि nginx block ची गरज राहत नाही. कोणताही मार्ग निवडला तरी compose.yml मधील ROOT_URL चे मूल्य https://chat.example.com करा आणि sudo docker compose up -d पुन्हा चालवा, जेणेकरून container मध्ये बदल लागू होईल. सर्व्हर public internet ऐवजी फक्त तुमच्या स्वतःच्या network मधून उपलब्ध हवा असल्यास, त्याच्या पुढे VPS वरील self-hosted WireGuard VPN ठेवा आणि proxy ला tunnel address वर bind करा.
पहिल्यांदा चालवण्याचा सेटअप विझार्ड
https://chat.example.com वर जा. Rocket.Chat तुम्हाला एका छोट्या विझार्डमधून मार्गदर्शन करेल. प्रथम, admin account साठी खरे नाव, username, email आणि मजबूत password द्या. अस्तित्वात असणारे हे एकमेव account आहे. त्यामुळे ते गमावू नका. त्यानंतर organisation and server info भरा: नाव, उद्योग, आकार, site name आणि default language. ही माहिती प्रामुख्याने देखाव्यासाठी आहे. ती भरून पुढे जा. त्यानंतर प्रत्यक्ष महत्त्वाची निवड येते: हे workspace Rocket.Chat Cloud वर register करायचे की ते standalone ठेवायचे.
Register केल्यास Rocket.Chat च्या gateway द्वारे mobile push notifications आणि add-on marketplace उपलब्ध होतात. मात्र Rocket.Chat च्या cloud सोबत control-plane संबंध निर्माण होतो. Standalone ठेवल्यास server पूर्णपणे खाजगी आणि बाह्य dependency शिवाय राहतो. मात्र iOS आणि Android वरील push notifications काम करणे थांबवतात. कारण Apple आणि Google self-built app ला push certificates ठेवण्याची परवानगी देत नाहीत आणि official apps cloud gateway मार्फत जोडल्या जातात. Privacy हा मुख्य उद्देश असेल आणि तुमचे users web app वापरत असतील, तर standalone निवडा. Mobile push अनिवार्य असेल, तर registration निवडा. हा निर्णय नंतर Admin अंतर्गत बदलता येतो.
आमंत्रण देण्यापूर्वी सुरक्षा कडक करा
Rocket.Chat मध्ये डीफॉल्टनुसार open registration सुरू असते. Registration Form ची सेटिंग डीफॉल्टनुसार Public असते. त्यामुळे URL सापडलेली कोणतीही व्यक्ती खाते तयार करू शकते. सार्वजनिक hostname वर हे अनधिकृत प्रवेशासाठी खुले दार ठरते. Admin → Settings → Accounts → Registration येथे जा आणि Registration Form ची सेटिंग Disabled करा. त्यामुळे तुम्ही खाती स्वतः तयार करू शकता किंवा invite link वापरू शकता. पर्याय म्हणून ती Secret URL वर सेट करा. तुम्ही या विभागात असताना, सार्वजनिक read-only channel ची विशेष गरज नसल्यास Allow Anonymous Read आणि Allow Anonymous Write बंद करा. प्रत्येक खाते स्वतः तयार करणे वेळखाऊ वाटत असल्यास आणि तुमची टीम लॉग इन करत असलेली ही एकमेव सेवा नसल्यास, Rocket.Chat चा OAuth login self-hosted Authentik SSO server कडे निर्देशित करा. त्यामुळे नवीन सदस्य आणि सेवा सोडणारे सदस्य प्रत्येक अॅपमध्ये स्वतंत्रपणे हाताळण्याऐवजी एकाच ठिकाणी व्यवस्थापित करता येतात.
Uploads कुठे साठवायचे हेही ठरवा. डीफॉल्ट File Upload storage GridFS असते. ते प्रत्येक image आणि attachment थेट MongoDB मध्ये साठवते. ही पद्धत सोपी आहे. परंतु लोक screenshots पाठवत राहिल्यास तुमचा database आणि तुम्ही घेतलेला प्रत्येक mongodump अमर्यादितपणे वाढत जातो. Admin → Settings → File Upload अंतर्गत तुम्ही storage local filesystem किंवा S3-compatible bucket वर बदलू शकता आणि योग्य maximum file size सेट करू शकता. तुमची टीम अधूनमधून screenshot पाठवण्याऐवजी संपूर्ण photo libraries शेअर करत असल्यास, त्या chat database ऐवजी dedicated photo server वर ठेवणे योग्य आहे. PhotoPrism आणि Immich ची तुलना यापैकी प्रत्येकासाठी लागणाऱ्या RAM च्या तुलनेत आवश्यक backup commands चा खर्च स्पष्ट करते. लहान टीमसाठी GridFS योग्य आहे. मात्र कालांतराने तुमचे backups अधिक मोठे होतील हे लक्षात ठेवा.
mongodump सह बॅकअप
तुमचा सर्व डेटा mongodb_data volume मध्ये आहे. चालू database मधून volume थेट कॉपी करू नका. त्याऐवजी mongodump वापरून सुसंगत dump तयार करा आणि तो host वरील फाइलमध्ये stream करा:
sudo docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > rocketchat-$(date +%F).archive.gzत्या एका gzip केलेल्या archive मध्ये तुमचे संपूर्ण workspace असते: users, channels, messages, settings आणि uploads GridFS वर ठेवले असल्यास त्या files देखील. uploads filesystem किंवा S3 वर हलवले असल्यास त्या store चा स्वतंत्रपणे बॅकअप घ्या. नवीन stack वर restore करण्यासाठी प्रथम replica set initialize करा. त्यानंतर:
sudo docker compose exec -T mongodb mongorestore --archive --gzip --drop < rocketchat-2026-07-15.archive.gzArchive box च्या बाहेर कॉपी करा. ते object storage मध्ये, दुसऱ्या server वर किंवा VPS बंद पडल्यास backup त्याच्यासोबत नष्ट होणार नाही अशा कोणत्याही ठिकाणी ठेवा. तसेच dump दररोज रात्री cron मधून चालवा. ज्या backup चा कधीही restore केलेला नाही, तो backup नसून केवळ अपेक्षा आहे. गरज पडण्यापूर्वी तो कार्यरत आहे याची खात्री करण्यासाठी restore एकदा वापरात नसलेल्या VPS वर करून पाहा.
अपग्रेड: tags pin करा, notes वाचा आणि MongoDB support matrix पाळा
अपग्रेड प्रक्रिया नियंत्रित ठेवण्यासाठी दोन नियम पाळा. पहिला, Rocket.Chat एका वेळी एक major version अपग्रेड करा. सुरू होताना ते schema migrations चालवते आणि major versions वगळून थेट पुढे जाण्यास जाणीवपूर्वक नकार देते. 6.x वरून थेट 8.x वर जाण्याचा प्रयत्न केल्यास तुमचा डेटा खराब करण्याऐवजी migration error देऊन प्रक्रिया थांबते. Image tag पुढील major version च्या latest release वर बदला, त्या release च्या notes मधील breaking changes वाचा, docker compose up -d चालवा आणि पुढे जाण्यापूर्वी logs मधील migration पूर्ण झाल्याचे तपासा. दुसरा, MongoDB support matrix पाळा. प्रत्येक Rocket.Chat release MongoDB च्या विशिष्ट versions संचाला support करते आणि curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions याबद्दल माहिती देते. MongoDB अपग्रेड करताना, उदाहरणार्थ 7.0 वरून 8.0 वर जाताना, एका वेळी एक major version पुढे जा आणि प्रत्येक टप्प्यानंतर feature-compatibility version सेट करा. MongoDB 8.0 मध्ये त्या command साठी स्पष्ट confirm: true आवश्यक असते. अन्यथा confirmation flag सह command पुन्हा चालवण्यास सांगणारा message दाखवून ती नकार देते:
sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'दोन्हीपैकी कोणत्याही component च्या प्रत्येक अपग्रेडपूर्वी mongodump घ्या. हीच संपूर्ण संरक्षण-व्यवस्था आहे.
अपयशाच्या स्थिती आणि अचूक स्ट्रिंग
docker compose up नंतर लगेच Rocket.Chat restart loop मध्ये जाते आणि docker compose logs rocketchat मध्ये MongoServerSelectionError भरते. MongoDB चालू आहे, पण driver primary निवडू शकत नाही. अचूक स्ट्रिंगवरून झालेली चूक समजते. Server selection timed out after 30000 ms चा topology type ReplicaSetNoPrimary असल्यास तुम्ही rs.initiate() चालवलेले नाही. Set मध्ये अद्याप configuration नाही. getaddrinfo ENOTFOUND नंतर random hash दिसत असल्यास तुम्ही स्पष्ट host: "mongodb:27017" न देता initialization केले आहे. त्यामुळे MongoDB ने resolve न होणारे container hostname जाहीर केले. sudo docker compose exec mongodb mongosh --eval 'rs.status()' वापरून निदान करा: MongoServerError: no replset config has been received error आल्यास set initiate करा; एखाद्या member चे name random hash असल्यास service name वापरून पुन्हा initiate करा.
Web UI लोड होते, पण login सतत फिरत राहतो आणि पूर्ण होत नाही. Browser console उघडा. तिथे WebSocket connection to 'wss://chat.example.com/websocket' failed दिसेल. हे जवळजवळ नेहमी ROOT_URL mismatch किंवा upgrade headers forward न करणाऱ्या proxy मुळे होते. ROOT_URL मध्ये https:// सह अचूक public address आहे याची खात्री करा. तसेच nginx च्या location block मध्ये Upgrade आणि Connection "upgrade" हे proxy_http_version 1.1 सह सेट केले आहेत का ते तपासा. यापैकी कोणताही बदल केल्यानंतर docker compose up -d पुन्हा चालवा.
Container वारंवार बंद होते आणि docker compose ps मध्ये Restarting दिसते. docker compose logs मधील ओळ अर्धवट थांबते आणि sudo dmesg | tail मध्ये oom-killer कडून आलेले Out of memory: Killed process 12345 (mongod) दिसते; exit code 137 असतो. मशीनमध्ये RAM अपुरी आहे. कायमस्वरूपी उपाय म्हणजे मोठा VPS वापरणे; किमान 4 GB आवश्यक आहे. तात्पुरत्या उपायासाठी swap जोडा आणि command मधील --wiredTigerCacheSizeGB 1 वापरून MongoDB च्या cache वर मर्यादा घाला. मात्र प्रत्यक्ष भाराखाली swap पुढील OOM होण्यास फक्त विलंब लावते:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfiledocker compose up Error response from daemon: driver failed programming external connectivity ... bind: address already in use सह अपयशी ठरते. Port 3000 आधीच दुसऱ्या प्रक्रियेकडे आहे. अनेकदा स्वच्छपणे बंद न झालेला जुना Rocket.Chat container किंवा दुसरे अॅप याला कारणीभूत असते. sudo ss -ltnp | grep :3000 वापरून ती प्रक्रिया शोधा. ती प्रक्रिया किंवा container बंद करा. किंवा mapping मधील host side बदलून 127.0.0.1:3001:3000 करा आणि त्यानुसार proxy मधील proxy_pass अद्ययावत करा.
FAQ
Rocket.Chat ला खरोखर MongoDB replica set आवश्यक आहे का?
होय. एकाच database node असलेल्या single server साठीही ते आवश्यक आहे. Rocket.Chat, MongoDB change streams वापरून संदेश real time मध्ये वितरित करते. Change streams हे केवळ replica set मध्ये उपलब्ध असलेले feature आहे. Standalone mongod ते सुरू करू शकत नाही. तुम्हाला अनेक machines आवश्यक नाहीत. --replSet rs0 वापरून सुरू केलेला एक MongoDB container चालवा आणि rs.initiate() वापरून one-member set initialise करा. ही पायरी वगळल्यास driver ला primary सापडत नाही. त्यामुळे Rocket.Chat MongoServerSelectionError: Server selection timed out सह वारंवार restart होते आणि boot पूर्ण करत नाही.
Self-hosted Rocket.Chat साठी किती RAM आवश्यक आहे?
व्यवहार्य किमान क्षमतेसाठी 4 GB आणि व्यस्त team साठी 8 GB नियोजित करा. Rocket.Chat ची Node process सुमारे 1 ते 1.5 GB RAM वापरते. MongoDB उर्वरित RAM पैकी साधारण निम्मी RAM WiredTiger cache साठी वापरते. त्यामुळे 2 GB च्या machine वर दोन्हींची RAM साठी स्पर्धा होते. वास्तविक load असताना out-of-memory killer mongod बंद करते. Logs मध्ये Killed दिसते आणि exit code 137 मिळतो. काही test users सह software चे मूल्यमापन करण्यासाठीच 2 GB पुरेसे आहे.
Rocket.Chat ला HTTPS मागे कसे ठेवावे?
TLS termination करून 127.0.0.1:3000 कडे requests forward करणारा reverse proxy त्याच VPS वर चालवा. Container मधील ROOT_URL तुमच्या सार्वजनिक https:// address वर सेट करा. Proxy ने WebSocket upgrade headers forward करणे आवश्यक आहे. अन्यथा login प्रक्रिया अडकते. Single-app setup साठी nginx सह Certbot हा सर्वात सोपा पर्याय आहे. एका proxy मागे अनेक containers चालवत असल्यास आणि certificate management स्वयंचलित हवे असल्यास Traefik अधिक योग्य आहे.
Self-hosted Rocket.Chat चा backup कसा घ्यावा?
Volume कॉपी करण्याऐवजी mongodump वापरून consistent database dump घ्या: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. त्या archive मध्ये users, channels, messages आणि settings असतात. Storage GridFS वर ठेवले असल्यास uploaded files देखील त्यात असतात. तो archive server च्या बाहेर कॉपी करा. cron वापरून ते nightly automate करा. तसेच throwaway box वर mongorestore करून पाहा, जेणेकरून restore प्रत्यक्षात कार्य करते याची खात्री होईल.
MongoDB मध्ये बिघाड न आणता Rocket.Chat upgrade कसे करावे?
Rocket.Chat चे upgrade एका वेळी एक major version अशा पद्धतीने करा. Boot वेळी ते migrations चालवते आणि major versions वगळण्यास नकार देते. Pinned image tag बदलण्यापूर्वी प्रत्येक release च्या notes वाचा. तुमच्या target release ला कोणत्या MongoDB versions समर्थित आहेत हे curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions वापरून तपासा. MongoDB upgrade करताना एका वेळी एक major version पुढे जा. प्रत्येक टप्प्यानंतर confirm: true सह setFeatureCompatibilityVersion सेट करा. सुरुवातीला नेहमी mongodump घ्या.