द्वारे Docker Compose वर Rocket.Chat कसे इंस्टॉल करावे
VPS वर Rocket.Chat self-host करण्यासाठी Docker Compose वापरा. यामध्ये MongoDB replica set सेटअप, TLS सुरक्षा आणि बॅकअप घेण्याच्या अचूक पद्धती दिल्या आहेत.
तुम्ही काय तयार करत आहात
तुमच्या मालकीचे एक खाजगी टीम चॅट: Docker Compose अंतर्गत तुमच्या स्वतःच्या VPS वर चालणारे Rocket.Chat. हे TLS द्वारे सुरक्षित आहे आणि सर्व संदेश MongoDB डेटाबेसमध्ये साठवले जातात, ज्याचा तुम्ही बॅकअप घेऊ शकता आणि तो हलवू शकता. Rocket.Chat हा Slack आणि Teams ला एक प्रगल्भ open-source पर्याय आहे — चॅनेल, direct messages, threads, file sharing, आणि voice व video, सर्व तुमच्या भाड्याने घेतलेल्या आणि तुमच्या नियंत्रणाखालील हार्डवेअरवर उपलब्ध आहेत. हे application एक single container आहे जे काही मिनिटांत सुरू होते. तांत्रिक समस्या प्रामुख्याने डेटाबेसशी संबंधित असतात, म्हणून या मार्गदर्शिकेचा मोठा भाग MongoDB बद्दल आहे. विशेषतः, एक अशी अट आहे जी पहिल्यांदा वाचताना सर्वांना आश्चर्यचकित करते: Rocket.Chat standalone MongoDB वर चालणार नाही. त्याला replica set ची आवश्यकता असते, जरी तो "set" एक single node असला तरीही.
Prerequisites, and the RAM math nobody tells you
सर्व्हरची क्षमता (size) वास्तववादी निवडा. लहान टीमसाठी किमान आवश्यकता 2 vCPU आणि 4 GB RAM इतकी असावी. Rocket.Chat चा Node.js process एकटाच साधारणपणे 1 ते 1.5 GB RAM वापरतो. तसेच, MongoDB चा WiredTiger cache डीफॉल्टनुसार उरलेल्या RAM पैकी अर्धा भाग वापरतो. 2 GB VPS वर हे दोन्ही प्रोसेस सुरू होताना व्यवस्थित चालतात, परंतु ट्रॅफिक वाढताच ते एकमेकांशी संघटित होतात: MongoDB आपला cache वाढवतो, Node आपला heap वाढवतो, kernel कडे पुरेसे pages उरत नाहीत आणि out-of-memory killer सर्वात मोठा असलेला process बंद करतो — सहसा mongod. कंटेनर Killed एरर दाखवतो, Docker तो पुन्हा सुरू करतो आणि लोड असताना तुमचा चॅट सर्व्हर दर काही मिनिटांनी बंद पडतो. दोन व्यक्तींसाठी चाचणी करण्यासाठी 2 GB पुरेसा आहे; परंतु टीमसाठी तो पुरेसा नाही. किमान 4 GB पासून सुरुवात करा. जर तुम्हाला अनेक concurrent users, व्हिडिओ कॉल्स किंवा वाढता upload history हवा असेल, तर 8 GB RAM द्या.
सुरुवात करण्यापूर्वी तुम्हाला या तीन गोष्टींची आवश्यकता आहे. VPS च्या public IP कडे निर्देशित करणारा A record असलेला डोमेन नेम — Rocket.Chat च्या real-time फीचर्स आणि mobile clients साठी स्थिर hostname आवश्यक आहे, केवळ IP पुरेशी नाही. सर्व्हर फायरवॉल आणि तुमच्या प्रोव्हायडरच्या नेटवर्क फायरवॉल (जे बहुतेक पॅनेलमध्ये वेगळे असते) दोन्हीवर Ports 80 आणि 443 open असावेत. आणि root किंवा sudo परवान्यासह एक नवीन Ubuntu 24.04 KVM VPS. जर तुम्हाला चॅट सर्व्हर हा पहिला सेवा (service) म्हणून योग्य आहे की नाही याबद्दल शंका असेल, तर 2026 मध्ये काय self-host करावे याचे guide त्यातील फायदे आणि तोटे स्पष्ट करते.
Docker engine आणि Compose plugin इंस्टॉल करा
Ubuntu मध्ये उपलब्ध असलेले docker.io package किंवा जुना standalone docker-compose Python binary वापरू नका. Docker चे स्वतःचे apt repository वापरा. आधुनिक Compose हा एक Docker plugin आहे, जो तुम्ही docker compose म्हणून वापरता — येथे space वापरा, hyphen नाही. जुना 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 सारखे आउटपुट देणे ही महत्त्वाची तपासणी आहे. जर docker: 'compose' is not a docker command अशी error आली, तर plugin इंस्टॉल झालेला नाही आणि पुढे तुम्हाला गोंधळात टाकणाऱ्या त्रुटी येतील — ती येथेच सुधारा.
The compose file: MongoDB as a single-node replica set
या भागात अनेक चुका होतात, त्यामुळे हे सावकाश वाचा. Rocket.Chat मध्ये नवीन संदेश रिअल-टाइममध्ये क्लायंट्सना पाठवण्यासाठी MongoDB change streams वापरले जातात. change streams फक्त replica set मध्येच उपलब्ध असतात. जर तुम्ही Rocket.Chat ला साध्या standalone mongod ला जोडले, तर ते कनेक्ट होईल, परंतु change stream उघडण्यात अपयशी ठरेल आणि सतत restart-loop मध्ये अडकेल. याचे निराकरण सोपे आहे: तुम्ही एक साधा MongoDB container चालवा, परंतु तो --replSet सह सुरू करा आणि नंतर एक-सदस्यीय (one-member) set इनिशियलाइज करा.
एक working 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 नेच ते एक्सेस केले पाहिजे; सर्व interfaces ला bind केल्यास लॉगिन पेज थेट सार्वजनिक इंटरनेटवर उपलब्ध होईल. MongoDB host वर अजिबात प्रकाशित केलेले नाही; ते फक्त Compose च्या अंतर्गत नेटवर्कवर mongodb या नावाने उपलब्ध आहे, जे MONGO_URL कडून वापरले जाणारे hostname आहे. MONGO_URL मध्ये ?replicaSet=rs0 असते — ते नसेल तर driver सर्व्हरला standalone समजतो (जरी तो replica set असला तरी), आणि change streams काम करत नाहीत. MONGO_OPLOG_URL हे local डेटाबेसकडे निर्देश करते जिथे oplog असते; आधुनिक Rocket.Chat change streams ला प्राधान्य देते, परंतु ते सेट करणे सुरक्षित आहे आणि जुन्या code paths साठी उपयुक्त ठरते. depends_on मध्ये condition: service_healthy वापरले आहे, त्यामुळे Compose, Rocket.Chat सुरू करण्यापूर्वी MongoDB कडून ping मिळण्याची वाट पाहते — healthcheck चा उद्देश हाच आहे.
दोन्ही images वर निश्चित version tags वापरा — येथे mongo:8.0 आणि Rocket.Chat ची स्पष्ट release जसे की 8.5.1 — आणि कधीही :latest वापरू नका, कारण यामुळे unattended docker pull चे अनपेक्षित आणि non-migratable upgrade होऊ शकते. version fix करण्यापूर्वी सध्याची stable Rocket.Chat release आणि त्याद्वारे समर्थित MongoDB versions तपासा. Rocket.Chat प्रत्येक release साठी machine-readable माहिती दस्तऐवज प्रकाशित करते: 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 आहे की नाही, जेणेकरून तुम्हाला सर्व्हरचे सतत व्यवस्थापन करावे लागणार नाही.
Initialise the replica set
stack सुरू करा:
sudo docker compose up -dRocket.Chat लगेच क्रॅश होऊल लागेल आणि Docker ते वारंवार restart करत राहील — हे अपेक्षित आहे, कारण replica set अजून तयार झालेली नाही. ते एकदा मॅन्युअली तयार करा:
sudo docker compose exec mongodb mongosh --eval 'rs.initiate({_id: "rs0", members: [{_id: 0, host: "mongodb:27017"}]})'योग्य निकाल { ok: 1 } असा आहे. काही सेकंदात single node स्वतःला primary म्हणून निवडते; खालील कमांडने तपासा:
sudo docker compose exec mongodb mongosh --quiet --eval 'rs.status().members[0].stateStr'तुम्हाला PRIMARY दिसणे आवश्यक आहे. या संपूर्ण पृष्ठावरील सर्वात महत्त्वाचा तपशील म्हणजे host: "mongodb:27017" argument. जर तुम्ही members list शिवाय फक्त rs.initiate() चालवले, तर MongoDB कंटेनरच्या internal hostname अंतर्गत replica set जाहीर करते — जे a1b2c3d4e5f6 सारखे एक random hash असते. Rocket.Chat, स्वतःच्या कंटेनरमधून कनेक्ट होताना, ते नाव resolve करू शकत नाही, त्यामुळे MongoDB driver DNS fail करतो आणि MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 लॉग करत राहतो. नेहमी तुमच्या MONGO_URL शी जुळणाऱ्या explicit service name ने सुरुवात करा.
First boot: watch it come up
एकदा set primary झाले की, Rocket.Chat चा पुढचा restart व्यवस्थित होईल आणि first-run migrations सुरू होतील. logs तपासा:
sudo docker compose logs -f rocketchatतुम्हाला या startup banner ची प्रतीक्षा आहे:
+--------------------------------------------+
SERVER RUNNING
Rocket.Chat Version: 8.5.1
NodeJS Version: 22.22.3 - x64
+--------------------------------------------+First boot प्रक्रियेला वेळ लागतो — app database migrations आणि indexes तयार करते, त्यामुळे काळजी करण्यापूर्वी एक किंवा दोन मिनिटे वाट पाहा. जर log मध्ये MongoServerSelectionError: Server selection timed out after 30000 ms आणि topology description मध्ये ReplicaSetNoPrimary वारंवार येत असेल, तर replica set initiate झालेले नाही; जर random hash वर getaddrinfo ENOTFOUND वारंवार येत असेल, तर ते चुकीच्या host सह initiate झाले आहे. दोन्ही परिस्थितीत, एक पाऊल मागे जा. एकदा तुम्हाला SERVER RUNNING दिसले की, Rocket.Chat 127.0.0.1:3000 वर listening आहे आणि आता त्याच्या पुढे real hostname आणि TLS सेट करण्याची वेळ आली आहे.
Put it behind TLS
Rocket.Chat कधीही plain HTTP वर उघडा (expose) करू नका. एकदा http:// वर लॉग इन केल्यास, तुमचा admin password मार्गातील कोणालाही मिळू शकतो. त्याच सर्व्हरवर reverse proxy वापरून TLS terminate करा आणि 127.0.0.1:3000 कडे forward करा. दोन गोष्टी महत्त्वाच्या आहेत: proxy ने WebSocket upgrade headers forward करणे आवश्यक आहे, कारण Rocket.Chat real-time आहे आणि त्यांच्याशिवाय ते काम करणार नाही; तसेच, container चा ROOT_URL हा युजर्सनी टाईप केलेल्या public HTTPS address शी तंतोतंत जुळला पाहिजे.
सुरुवात करण्यासाठी, app कडे proxy करणारा आणि upgrade headers forward करणारा एक plain HTTP nginx server block तयार करा. तो /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 (sudo nginx -t && sudo systemctl reload nginx) reload करा, त्यानंतर certificate मिळवा. Ubuntu वर सर्वात सोपा मार्ग म्हणजे Let's Encrypt TLS certificates with Certbot and nginx: certbot --nginx वरील block मध्ये बदल करतो, listen 443 ssl;, ssl_certificate lines आणि automatic 80-to-443 redirect जोडतो, आणि तुमच्यासाठी renewal शेड्यूल करतो. जर तुम्ही एकाच proxy मागे अनेक containers चालवत असाल, तर Traefik with automatic TLS for many Docker apps हा अधिक चांगला पर्याय आहे — rocketchat service मध्ये router आणि service labels जोडा; Traefik स्वतः certificate request आणि renew करतो, त्यासाठी nginx block ची गरज नसते. कोणत्याही प्रकारे, compose.yml मध्ये ROOT_URL ला https://chat.example.com करा आणि sudo docker compose up -d पुन्हा चालवा जेणेकरून container ला बदल समजतील. जर तुम्हाला सर्व्हर सार्वजनिक इंटरनेटऐवजी फक्त तुमच्या स्वतःच्या नेटवर्कमधून उपलब्ध करून द्यायचा असेल, तर self-hosted WireGuard VPN on the VPS वापरा आणि proxy ला tunnel address ला bind करा.
first-run setup wizard
https://chat.example.com आणि Rocket.Chat कडे जा. Rocket.Chat तुम्हाला एका लहान wizard मधून मार्गदर्शन करेल. प्रथम, admin account — तुमचे नाव, username, email आणि एक strong password; हे एकमेव खाते आहे, त्यामुळे ते गमावू नका. त्यानंतर, organisation and server info — नाव, industry, size, site name आणि default language; ही माहिती केवळ सजावटीसाठी आहे, ती भरून पुढे जा. त्यानंतर एक महत्त्वाचा निर्णय: Rocket.Chat Cloud सोबत register this workspace करा, किंवा standalone ठेवा.
Register केल्यामुळे Rocket.Chat च्या gateway आणि add-on marketplace द्वारे mobile push notifications सुरू होतात, परंतु यासाठी Rocket.Chat च्या cloud सोबत control-plane संबंध प्रस्थापित होतो. Standalone ठेवल्यास server पूर्णपणे private आणि dependency-free राहते, परंतु iOS आणि Android push notifications काम करणे थांबवतात; कारण Apple आणि Google स्वतः तयार केलेल्या app ला push certificates देण्यास परवानगी देत नाहीत — अधिकृत apps cloud gateway द्वारे चालतात. जर privacy ही तुमची मुख्य प्राथमिकता असेल आणि तुमचे users web app वापरत असतील, तर standalone निवडा; जर mobile push आवश्यक असेल, तर registration निवडा. तुम्ही नंतर Admin मध्ये जाऊन हा निर्णय बदलू शकता.
कोणालाही आमंत्रित करण्यापूर्वी सुरक्षितता सुनिश्चित करा
Rocket.Chat मध्ये open registration on असते — डीफॉल्टनुसार Registration Form Public वर सेट केलेले असते, त्यामुळे URL शोधणारा कोणीही खाते तयार करू शकतो. सार्वजनिक hostname वर हे एक खुले प्रवेशद्वार आहे. Admin → Settings → Accounts → Registration वर जा आणि Registration Form Disabled वर सेट करा, जेणेकरून तुम्ही मॅन्युअली किंवा invite link द्वारे खाती तयार करू शकाल, किंवा Secret URL वर सेट करा. तिथे असताना, जर तुम्हाला सार्वजनिक read-only चॅनेल नको असेल, तर Allow Anonymous Read आणि Allow Anonymous Write बंद करा.
अपलोड केलेल्या फाइल्स कुठे साठवायच्या ते देखील ठरवा. डीफॉल्ट File Upload स्टोरेज GridFS आहे, जे प्रत्येक इमेज आणि अटॅचमेंट MongoDB मध्येच साठवते. हे सोपे आहे, परंतु याचा अर्थ असा की लोक स्क्रीनशॉट पेस्ट करत असताना तुमचे डेटाबेस — आणि तुमचा प्रत्येक mongodump — अमर्यादपणे वाढत जाते. Admin → Settings → File Upload अंतर्गत तुम्ही स्टोरेज local filesystem किंवा S3-compatible bucket वर बदलू शकता, आणि फाईलची कमाल मर्यादा (maximum file size) सेट करू शकता. लहान टीमसाठी GridFS योग्य आहे; फक्त लक्षात ठेवा की कालांतराने तुमच्या बॅकअप्सचा आकार वाढत जाईल.
mongodump सह Backups
तुमचा सर्व डेटा mongodb_data volume मध्ये असतो. डेटाबेस चालू असताना थेट volume कॉपी करू नका — mongodump वापरून host वरील फाईलमध्ये consistent dump घ्या:
sudo docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > rocketchat-$(date +%F).archive.gzती एक gzipped 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 off the box कॉपी करा — object storage, दुसरा server, किंवा अशी कोणतीही जागा जिथे VPS निकामी झाल्यास बॅकअप सुरक्षित राहील — आणि दररोज रात्री cron द्वारे dump रन करा. ज्या बॅकअपचा तुम्ही कधीही restore केलेला नाही, तो केवळ एक आशा आहे, बॅकअप नाही; बॅकअप काम करतो हे खात्री करण्यासाठी एकदा throwaway VPS वर restore करण्याचा सराव करा.
Upgrades: pin tags, read the notes, respect the Mongo matrix
Upgrades सोप्या ठेवण्यासाठी दोन नियम पाळा. पहिले, Rocket.Chat ची upgrade एका वेळी फक्त एकच major version साठी करा. boot दरम्यान हे schema migrations राबवते आणि थेट major version बदलण्यास नकार देते; जर तुम्ही 6.x कडून थेट 8.x कडे जाण्याचा प्रयत्न केला, तर डेटा corrupt होण्याऐवजी migration error येतो. image tag पुढील major version च्या latest release वर अपडेट करा, breaking changes साठी त्या release notes वाचा, docker compose up -d चालवा, आणि migration पूर्ण होईपर्यंत logs तपासा. दुसरे, MongoDB support matrix चे पालन करा. प्रत्येक Rocket.Chat release मध्ये MongoDB च्या विशिष्ट versions चा सपोर्ट असतो आणि curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions तुम्हाला त्याबद्दल माहिती देते. जेव्हा तुम्ही MongoDB अपडेट करता — उदाहरणार्थ 7.0 कडून 8.0 कडे — तेव्हा प्रत्येक वेळी एक major version ने पुढे जा आणि प्रत्येक टप्प्यानंतर feature-compatibility version सेट करा. MongoDB 8.0 वर या कमांडसाठी explicit confirm: true आवश्यक आहे, अन्यथा confirmation flag सह पुन्हा रन करण्याचा संदेश देऊन ती error देते:
sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'दोन्ही components च्या प्रत्येक upgrade पूर्वी mongodump घ्या. हीच तुमची पूर्ण insurance policy आहे.
Failure modes, with the exact strings
docker compose up नंतर Rocket.Chat लगेच restart-loops मध्ये जाते आणि docker compose logs rocketchat मध्ये MongoServerSelectionError भरते. MongoDB सुरू आहे परंतु driver ला primary निवडता येत नाही; नेमका कोणता चुका झाली आहे हे त्या string मधून समजते. topology type ReplicaSetNoPrimary असलेला Server selection timed out after 30000 ms म्हणजे तुम्ही rs.initiate() रन केलेले नाही — set कडे अद्याप config नाही. getaddrinfo ENOTFOUND आणि त्यानंतर एक random hash म्हणजे तुम्ही explicit host: "mongodb:27017" शिवाय init केले आहे, त्यामुळे MongoDB ने unresolvable container hostname जाहीर केले आहे. sudo docker compose exec mongodb mongosh --eval 'rs.status()' वापरून निदान करा: जर MongoServerError: no replset config has been received error आला, तर set init करा; जर एखाद्या member चा name random hash दिसत असेल, तर service name वापरून पुन्हा re-init करा.
Web UI लोड होते पण login प्रक्रिया पूर्ण न होता सतत फिरत राहते. Browser console उघडा, तिथे तुम्हाला WebSocket connection to 'wss://chat.example.com/websocket' failed दिसेल. हे सहसा ROOT_URL mismatch किंवा proxy कडून upgrade headers forward न झाल्यामुळे होते. 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 मध्ये line मध्येच कट लागते आणि sudo dmesg | tail मध्ये oom-killer कडून Out of memory: Killed process 12345 (mongod) दिसते; exit code 137 आहे. सिस्टममध्ये RAM संपली आहे. कायमस्वरूपी उपाय म्हणजे मोठा VPS वापरणे — किमान 4 GB. तात्पुरता उपाय म्हणून swap वापरा आणि MongoDB च्या command मध्ये --wiredTigerCacheSizeGB 1 वापरून cache मर्यादित करा, परंतु real load असताना 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 error येतो. पोर्ट 3000 आधीच वापरात आहे — सहसा एखादा जुना Rocket.Chat container जो नीट थांबला नाही किंवा दुसरी एखादी app. sudo ss -ltnp | grep :3000 वापरून तो शोधा, तो process किंवा container थांबवा, किंवा mapping च्या host side ला 127.0.0.1:3001:3000 मध्ये बदला आणि त्यानुसार तुमच्या proxy चा proxy_pass अपडेट करा.
FAQ
Rocket.Chat ला खरोखर MongoDB replica set ची गरज आहे का?
हो, अगदी एकच डेटाबेस नोड असलेल्या सिंगल सर्व्हरसाठी सुद्धा. Rocket.Chat रिअल टाइममध्ये मेसेज पाठवण्यासाठी MongoDB change streams वापरते. change streams ही फक्त replica-set साठी असलेली feature आहे; standalone mongod मध्ये ही सुविधा उपलब्ध नसते. तुम्हाला अनेक मशीन्सची गरज नाही; तुम्ही --replSet rs0 वापरून एक MongoDB container सुरू करू शकता आणि rs.initiate() वापरून one-member set इनिशियलाइज करू शकता. जर तुम्ही ही स्टेप वगळली, तर driver ला primary सापडणार नाही, ज्यामुळे Rocket.Chat MongoServerSelectionError: Server selection timed out मुळे restart-loop मध्ये अडकेल आणि boot होण्याची प्रक्रिया पूर्ण होणार नाही.
Self-hosted Rocket.Chat साठी किती RAM आवश्यक आहे?
किमान 4 GB आणि व्यस्त टीमसाठी 8 GB RAM असा विचार करा. Rocket.Chat च्या Node process ला साधारण 1 ते 1.5 GB लागतात आणि MongoDB त्याच्या WiredTiger cache साठी उरलेल्या RAM पैकी साधारण अर्धा भाग वापरते. त्यामुळे 2 GB च्या मशीनवर हे दोन्ही process एकमेकांशी आदळतात आणि real load असताना out-of-memory killer Killed दाखवून आणि exit code 137 देऊन mongod बंद करते. 2 GB RAM फक्त काही टेस्ट युजर्ससह सॉफ्टवेअर तपासण्यासाठी पुरेशी आहे.
मी Rocket.Chat ला HTTPS च्या मागे कसे ठेवू?
त्याच VPS वर reverse proxy चालवा जो TLS terminate करेल आणि 127.0.0.1:3000 कडे forward करेल, आणि कंटेनरचा ROOT_URL तुमच्या public https:// पत्त्यावर सेट करा. Proxy ने WebSocket upgrade headers forward करणे आवश्यक आहे, अन्यथा login प्रक्रिया अडकेल. nginx सोबत Certbot हे सर्वात सोपे single-app setup आहे; जर तुम्ही एका proxy च्या मागे अनेक containers चालवत असाल आणि तुम्हाला automatic 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 मध्ये युजर्स, channels, मेसेज आणि settings असतात, तसेच जर तुम्ही storage GridFS वर ठेवले असेल तर अपलोड केलेल्या फाइल्स सुद्धा असतात. हा archive सर्व्हरच्या बाहेर कॉपी करा, cron वापरून दररोज रात्री याचे ऑटोमेशन करा, आणि रिस्टोअर प्रक्रिया खरोखर काम करते की नाही हे पाहण्यासाठी एखाद्या throwaway box वर mongorestore चा सराव करा.
MongoDB खराब न करता मी Rocket.Chat कसे upgrade करू?
Rocket.Chat ला एकेक major version ने upgrade करा — ते boot होताना migrations चालवते आणि major versions skip करण्यास नकार देते — आणि pinned image tag बदलण्यापूर्वी प्रत्येक release च्या नोट्स वाचा. curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions वापरून तुमचे target release कोणत्या MongoDB versions ला सपोर्ट करते ते तपासा. जेव्हा तुम्ही MongoDB upgrade करता, तेव्हा एकेक major version ने पुढे जा आणि प्रत्येक स्टेप नंतर confirm: true वापरून setFeatureCompatibilityVersion सेट करा. नेहमी आधी mongodump घ्या.