Docker Compose के साथ Rocket.Chat कैसे होस्ट करें

आप क्या बना रहे हैं

एक निजी टीम चैट जिस पर आपका पूर्ण स्वामित्व है: Docker Compose के अंतर्गत आपके अपने VPS पर चल रहा Rocket.Chat, जिसे TLS द्वारा सुरक्षित किया गया है, और जिसका प्रत्येक संदेश एक MongoDB डेटाबेस में सुरक्षित है जिसे आप बैकअप ले सकते हैं और स्थानांतरित कर सकते हैं। Rocket.Chat, Slack और Teams का एक परिपक्व ओपन-सोर्स विकल्प है, जिसमें चैनल, डायरेक्ट मैसेज, थ्रेड्स, फाइल शेयरिंग, और वॉयस व वीडियो कॉल की सुविधा है, जो आपके द्वारा किराए पर लिए गए और नियंत्रित हार्डवेयर पर चलता है। हालाँकि, यह एकमात्र विश्वसनीय विकल्प नहीं है, और यदि आप अभी भी चयन कर रहे हैं, तो Mattermost, Rocket.Chat, Synapse और Zulip की तुलना उन्हें उन पहलुओं पर परखती है जो बाद में समस्या पैदा करते हैं: RAM, डेटाबेस, मोबाइल पुश, SSO और अपग्रेड। यह एप्लिकेशन एक सिंगल कंटेनर है जो कुछ ही मिनटों में तैयार हो जाता है। जो कुछ भी वास्तव में गलत होता है, वह इसके बगल में स्थित डेटाबेस में होता है, इसलिए इस गाइड का अधिकांश भाग MongoDB के बारे में है, और विशेष रूप से उस एक आवश्यकता के बारे में जो पहली बार में सभी को आश्चर्यचकित करती है: Rocket.Chat एक स्टैंडअलोन MongoDB के साथ नहीं चलेगा। इसे एक replica set की आवश्यकता होती है, भले ही वह "सेट" केवल एक सिंगल नोड ही क्यों न हो।

पूर्वापेक्षाएँ, और RAM का वह गणित जो कोई नहीं बताता

सर्वर का आकार ईमानदारी से चुनें। एक छोटी टीम के लिए वास्तविक न्यूनतम आवश्यकता 2 vCPU और 4 GB RAM है। Rocket.Chat की Node.js प्रक्रिया अकेले ही लगभग 1 से 1.5 GB RAM लेती है, और MongoDB का WiredTiger cache डिफ़ॉल्ट रूप से बची हुई RAM का लगभग आधा हिस्सा ले लेता है। 2 GB के VPS पर ये दोनों बूट के समय तो चल जाते हैं, लेकिन वास्तविक ट्रैफिक आते ही आपस में टकराते हैं: MongoDB अपना cache बढ़ाता है, Node अपना heap बढ़ाता है, kernel के पास pages खत्म हो जाते हैं, और out-of-memory killer सबसे बड़ी प्रक्रिया को बंद कर देता है, जो आमतौर पर mongod होती है। कंटेनर Killed प्रिंट करता है, Docker उसे रीस्टार्ट करता है, और आपको एक ऐसा चैट सर्वर मिलता है जो लोड पड़ने पर बार-बार बंद हो जाता है, जबकि उसे सामान्य रूप से काम करना चाहिए था। 2 GB RAM केवल दो लोगों के साथ टेस्टिंग के लिए ठीक है; यह एक टीम सर्वर के लिए पर्याप्त नहीं है। 4 GB से शुरुआत करें, और यदि आप दर्जनों concurrent users, वीडियो कॉल, या बढ़ते हुए अपलोड इतिहास की उम्मीद करते हैं, तो इसे 8 GB दें। सर्वर पर चलने वाली अन्य सेवाओं के लिए भी बजट रखें: एक ही VPS पर Notion-style AFFiNE workspace रखने से चार और कंटेनर जुड़ जाते हैं जो उन्हीं RAM pages के लिए प्रतिस्पर्धा करते हैं, इसलिए उनकी RAM को Rocket.Chat की RAM के ऊपर जोड़ना होगा, न कि उसमें से घटाना।

शुरू करने से पहले आपको तीन चीजें तैयार रखनी होंगी। एक डोमेन नाम जिसका A record VPS के पब्लिक IP पर पॉइंट कर रहा हो; Rocket.Chat के real-time फीचर्स और मोबाइल क्लाइंट्स को एक स्थिर hostname की आवश्यकता होती है, न कि केवल IP की। सर्वर फायरवॉल और आपके प्रोवाइडर के नेटवर्क फायरवॉल, दोनों पर Ports 80 और 443 खुले होने चाहिए; अधिकांश पैनलों में यह एक अलग कंट्रोल होता है। और अंत में, root या sudo एक्सेस के साथ एक नया Ubuntu 24.04 KVM VPS। यदि आप अभी भी यह तय कर रहे हैं कि क्या चैट सर्वर पहली सर्विस के रूप में चलाने के लिए सही है, तो 2026 में क्या self-host करना सार्थक है, इस पर गाइड आपको इसके फायदे और नुकसान समझने में मदद करेगी।

Docker engine और Compose plugin को install करें

Ubuntu द्वारा प्रदान किए गए docker.io पैकेज के बजाय Docker के अपने apt repository का उपयोग करें। पुराने standalone docker-compose Python binary का उपयोग न करें। आधुनिक Compose एक Docker plugin है जिसे आप docker compose के रूप में invoke करते हैं (बीच में space का उपयोग करें, hyphen का नहीं)। पुराना docker-compose v1 अब end-of-life हो चुका है और यह नीचे दी गई healthcheck और dependency syntax को ठीक से handle नहीं करता है।

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 version

docker compose version का Docker Compose version v2.x जैसा कुछ print करना ही वह मुख्य जाँच है जो मायने रखती है। यदि यह docker: 'compose' is not a docker command के साथ error देता है, तो इसका मतलब है कि plugin install नहीं हुआ है और आपको बाद में भ्रमित करने वाली विफलताओं का सामना करना पड़ेगा, इसलिए इसे यहीं ठीक करें।

Compose file: MongoDB को single-node replica set के रूप में चलाना

यह वह हिस्सा है जहाँ लोग गलती करते हैं, इसलिए इसे ध्यान से पढ़ें। Rocket.Chat नए संदेशों को वास्तविक समय में connected clients तक पहुँचाने के लिए MongoDB change streams का उपयोग करता है, और change streams केवल replica set पर ही उपलब्ध होते हैं। यदि आप Rocket.Chat को एक साधारण standalone mongod से जोड़ते हैं, तो यह connect तो हो जाएगा, लेकिन change stream खोलने में विफल रहेगा और बार-बार restart होता रहेगा। इसका समाधान जटिल नहीं है: आप एक सामान्य MongoDB container चलाएं, लेकिन इसे --replSet के साथ start करें और फिर एक-सदस्यीय (one-member) set को initialise करें।

एक 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 पर publish किया गया है, न कि 0.0.0.0 पर। App में स्वयं कोई TLS नहीं है, इसलिए केवल उसी box पर मौजूद reverse proxy को ही इसे access करना चाहिए; इसे हर interface पर bind करने से plaintext login page सीधे public internet पर आ जाएगा। MongoDB को host पर बिल्कुल भी publish नहीं किया गया है; यह केवल Compose के internal network पर mongodb नाम से ही पहुँच योग्य है, जो कि बिल्कुल वही hostname है जिसका उपयोग MONGO_URL करता है। MONGO_URL में ?replicaSet=rs0 शामिल है, यदि आप इसे हटा देते हैं तो driver सर्वर को standalone मान लेगा, भले ही वह एक replica set हो, और change streams फिर भी विफल हो जाएंगे। MONGO_OPLOG_URL उस local database की ओर इशारा करता है जहाँ oplog रहता है; आधुनिक Rocket.Chat change streams को प्राथमिकता देता है, लेकिन इसे set करना नुकसानदेह नहीं है और यह पुराने code paths को सही रखता है। depends_on में condition: service_healthy का उपयोग किया गया है, इसलिए Compose तब तक Rocket.Chat को start नहीं करता जब तक MongoDB ping का जवाब न दे दे, healthcheck का यही उद्देश्य है।

दोनों images पर वास्तविक version tags pin करें, mongo:8.0 और यहाँ 8.5.1 जैसे स्पष्ट Rocket.Chat release का उपयोग करें, और :latest का कभी उपयोग न करें। इससे unattended docker pull अनजाने ऐसे upgrade में बदल जाता है, जिससे migration नहीं किया जा सकता। Pin करने से पहले वर्तमान 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 ही supported engine है। इसमें lts flag भी होता है, जो बताता है कि वह release long-term-support build है या नहीं। यह उस server के लिए pin करने योग्य हो सकता है जिसे आप लगातार monitor नहीं करना चाहते।

हर project versioned image प्रकाशित नहीं करता। ऐसी स्थिति में pin source पर किया जाता है: openGym workout tracker को self-host करना का अर्थ है किसी specific git tag को checkout करके उससे build करना, न कि बदलती हुई branch को follow करना।

Replica set को इनिशियलाइज़ करें

Stack को शुरू करें:

sudo docker compose up -d

Rocket.Chat तुरंत क्रैश होना शुरू हो जाएगा और Docker इसे बार-बार restart करता रहेगा। यह अपेक्षित है, क्योंकि replica set अभी मौजूद नहीं है। इसे एक बार मैन्युअल रूप से बनाएँ:

sudo docker compose exec mongodb mongosh --eval 'rs.initiate({_id: "rs0", members: [{_id: 0, host: "mongodb:27017"}]})'

सही परिणाम { ok: 1 } है। कुछ ही सेकंड में सिंगल नोड खुद को primary चुन लेगा; इसकी पुष्टि इस कमांड से करें:

sudo docker compose exec mongodb mongosh --quiet --eval 'rs.status().members[0].stateStr'

आपको PRIMARY दिखाई देना चाहिए। इस पूरे पेज पर सबसे महत्वपूर्ण विवरण host: "mongodb:27017" आर्गुमेंट है। यदि आप बिना members लिस्ट के केवल rs.initiate() चलाते हैं, तो MongoDB replica set को कंटेनर के इंटरनल होस्टनेम के तहत advertise करता है, जो कि a1b2c3d4e5f6 जैसा एक रैंडम हैश होता है। Rocket.Chat, जो अपने कंटेनर से कनेक्ट हो रहा है, उस नाम को resolve नहीं कर सकता, इसलिए MongoDB ड्राइवर DNS पर फेल हो जाता है और लगातार MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 लॉग करता रहता है। हमेशा उस स्पष्ट सर्विस नाम के साथ इनिशियलाइज़ करें जो आपके MONGO_URL से मेल खाता हो।

पहली बूट: इसे शुरू होते हुए देखें

एक बार जब सेट primary हो जाता है, तो Rocket.Chat का अगला रीस्टार्ट सफलतापूर्वक कनेक्ट हो जाता है और अपनी पहली रन माइग्रेशन शुरू कर देता है। लॉग्स को फॉलो करें:

sudo docker compose logs -f rocketchat

वह लाइन जिसका आपको इंतजार करना है, वह स्टार्टअप बैनर है:

+--------------------------------------------+
        SERVER RUNNING
   Rocket.Chat Version: 8.5.1
        NodeJS Version: 22.22.3 - x64
+--------------------------------------------+

पहली बूट धीमी होती है, ऐप डेटाबेस माइग्रेशन चलाता है और इंडेक्स बनाता है, इसलिए चिंता करने से पहले इसे एक या दो मिनट का समय दें। यदि लॉग इसके बजाय MongoServerSelectionError: Server selection timed out after 30000 ms को ReplicaSetNoPrimary प्रकार के टोपोलॉजी विवरण के साथ दोहराता है, तो रेप्लिका सेट शुरू (initiated) नहीं हुआ है; यदि यह एक रैंडम हैश पर getaddrinfo ENOTFOUND को दोहराता है, तो इसे गलत होस्ट के साथ शुरू किया गया था। किसी भी स्थिति में, एक कदम पीछे जाएँ। एक बार जब आप SERVER RUNNING देख लेते हैं, तो Rocket.Chat 127.0.0.1:3000 पर लिसन कर रहा होता है और अब इसके सामने एक वास्तविक होस्टनेम और TLS लगाने का समय आ गया है।

इसे TLS के पीछे रखें

Rocket.Chat को कभी भी plain HTTP पर expose न करें। एक बार http:// पर लॉग इन करने का मतलब है कि आपने अपना एडमिन पासवर्ड रास्ते में मौजूद किसी भी व्यक्ति को सौंप दिया है। उसी बॉक्स पर एक 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 से बिल्कुल मेल खाना चाहिए जिसे users टाइप करते हैं।

एक plain HTTP nginx server block के साथ शुरुआत करें जो app को proxy करता है और upgrade headers को forward करता है। इसे /etc/nginx/sites-available/rocketchat के रूप में save करें, इसे 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; वाला block और बिना certificate के यह sudo nginx -t को भी पास नहीं करेगा। Nginx (sudo nginx -t && sudo systemctl reload nginx) को reload करें, फिर certificate जारी करें। Ubuntu पर सबसे आसान तरीका Certbot और nginx के साथ Let's Encrypt TLS certificates है: certbot --nginx ऊपर दिए गए block को वहीं rewrite कर देता है, जिसमें 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 request और renew करेगा, जिसमें किसी nginx block की आवश्यकता नहीं होगी। किसी भी स्थिति में, compose.yml में ROOT_URL को https://chat.example.com पर सेट करें और sudo docker compose up -d को फिर से चलाएं ताकि container बदलाव को लागू कर सके। यदि आप चाहते हैं कि server public internet के बजाय केवल आपके अपने network के अंदर से ही reachable हो, तो इसे VPS पर self-hosted WireGuard VPN के पीछे रखें और proxy को tunnel address पर bind करें।

प्रथम-रन सेटअप विज़ार्ड

https://chat.example.com पर ब्राउज़ करें और Rocket.Chat आपको एक संक्षिप्त विज़ार्ड के माध्यम से ले जाएगा। सबसे पहले, admin account, एक वास्तविक नाम, उपयोगकर्ता नाम, ईमेल और एक मजबूत पासवर्ड दर्ज करें; यह एकमात्र खाता है जो मौजूद है, इसलिए इसे न खोएं। इसके बाद, organisation and server info, नाम, उद्योग, आकार, साइट का नाम और डिफ़ॉल्ट भाषा भरें; ये केवल जानकारी के लिए हैं, इन्हें भरें और आगे बढ़ें। फिर वह विकल्प जो वास्तव में मायने रखता है: अपने वर्कस्पेस को Rocket.Chat Cloud के साथ register करें, या इसे standalone रखें।

रजिस्टर करने से Rocket.Chat के गेटवे के माध्यम से मोबाइल पुश नोटिफिकेशन और ऐड-ऑन मार्केटप्लेस सक्षम हो जाते हैं, लेकिन इसके बदले में Rocket.Chat के क्लाउड के साथ एक कंट्रोल-प्लेन संबंध बन जाता है। स्टैंडअलोन रखने से सर्वर पूरी तरह से निजी और निर्भरता-मुक्त रहता है, लेकिन iOS और Android पुश नोटिफिकेशन काम करना बंद कर देते हैं, क्योंकि Apple और Google स्व-निर्मित ऐप को पुश सर्टिफिकेट रखने की अनुमति नहीं देते हैं, आधिकारिक ऐप क्लाउड गेटवे के माध्यम से रूट होते हैं। यदि गोपनीयता ही मुख्य उद्देश्य है और आपके उपयोगकर्ता वेब ऐप का उपयोग करते हैं, तो स्टैंडअलोन चुनें; यदि मोबाइल पुश अनिवार्य है, तो रजिस्ट्रेशन चुनें। आप बाद में Admin के अंतर्गत अपना निर्णय बदल सकते हैं।

किसी को भी आमंत्रित करने से पहले इसे सुरक्षित करें

Rocket.Chat डिफ़ॉल्ट रूप से open registration on के साथ आता है, यानी Registration Form डिफ़ॉल्ट रूप से Public पर सेट होता है। इसका मतलब है कि कोई भी व्यक्ति जिसे URL मिल जाए, वह अकाउंट बना सकता है। एक public hostname पर यह एक खुला दरवाजा है। Admin → Settings → Accounts → Registration पर जाएं और Registration Form को Disabled पर सेट करें, ताकि आप स्वयं अकाउंट बना सकें या invite link का उपयोग कर सकें, या फिर इसे Secret URL पर सेट करें। वहां रहते हुए, Allow Anonymous Read और Allow Anonymous Write को बंद कर दें, जब तक कि आप विशेष रूप से कोई public read-only channel न चाहते हों। यदि हर अकाउंट को मैन्युअल रूप से बनाना कठिन लगता है और यह एकमात्र ऐसी service नहीं है जिसमें आपकी टीम लॉग इन करती है, तो Rocket.Chat के OAuth login को एक self-hosted Authentik SSO server की ओर निर्देशित करें। इससे नए सदस्यों का जुड़ना और छोड़ना हर app के बजाय एक ही जगह से प्रबंधित हो जाएगा।

यह भी तय करें कि uploads कहाँ जाएंगे। डिफ़ॉल्ट File Upload स्टोरेज GridFS है, जो हर image और attachment को सीधे MongoDB के अंदर स्टोर करता है। यह सरल है, लेकिन इसका मतलब है कि आपका database और आपके द्वारा लिया गया हर mongodump, लोगों द्वारा screenshots पेस्ट करने के साथ-साथ बिना किसी सीमा के बढ़ता जाएगा। Admin → Settings → File Upload के अंतर्गत आप स्टोरेज को local filesystem या S3-compatible bucket पर स्विच कर सकते हैं और एक उचित maximum file size सेट कर सकते हैं। यदि आपकी टीम कभी-कभार लिए गए screenshot के बजाय पूरी photo libraries साझा कर रही है, तो उन्हें chat database के बजाय एक समर्पित photo server पर होना चाहिए। PhotoPrism और Immich की तुलना यह बताती है कि प्रत्येक के लिए कितनी RAM की आवश्यकता है और इसके लिए किन backup commands की जरूरत होती है। एक छोटी टीम के लिए GridFS ठीक है; बस यह ध्यान रखें कि समय के साथ आपके backups का आकार बढ़ता जाएगा।

mongodump के साथ बैकअप

आपका सारा डेटा mongodb_data वॉल्यूम में रहता है। चलते हुए डेटाबेस से सीधे वॉल्यूम कॉपी न करें, बल्कि mongodump का उपयोग करके एक कंसिस्टेंट डंप लें और उसे होस्ट पर एक फाइल में स्ट्रीम करें:

sudo docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > rocketchat-$(date +%F).archive.gz

वह एक gzipped आर्काइव ही आपका पूरा वर्कस्पेस है: यूजर्स, चैनल्स, मैसेज, सेटिंग्स और यदि आपने अपलोड्स को GridFS पर रखा है, तो वे फाइलें भी। यदि आपने अपलोड्स को फाइलसिस्टम या S3 पर मूव किया है, तो उस स्टोर का बैकअप अलग से लें। रिस्टोर करने के लिए पहले एक नया स्टैक तैयार करें, रेप्लिका सेट को इनिशियलाइज़ करें और फिर यह चलाएं:

sudo docker compose exec -T mongodb mongorestore --archive --gzip --drop < rocketchat-2026-07-15.archive.gz

आर्काइव को सर्वर से बाहर कॉपी करें, जैसे कि ऑब्जेक्ट स्टोरेज, किसी अन्य सर्वर पर, या ऐसी किसी भी जगह जहाँ VPS के खराब होने पर बैकअप सुरक्षित रहे। इस डंप को cron के जरिए हर रात चलाएं। जिस बैकअप को आपने कभी रिस्टोर करके नहीं देखा, वह केवल एक उम्मीद है, बैकअप नहीं। इसे एक बार किसी अस्थायी VPS पर रिस्टोर करने का अभ्यास करें ताकि जरूरत पड़ने पर आपको पता हो कि यह काम करता है।

अपग्रेड: टैग पिन करें, नोट्स पढ़ें, और Mongo मैट्रिक्स का पालन करें

अपग्रेड को सुरक्षित रखने के लिए दो नियमों का पालन करें। पहला, Rocket.Chat को एक बार में केवल एक मेजर वर्जन ही अपग्रेड करें। यह बूट होने पर स्कीमा माइग्रेशन चलाता है और जानबूझकर एक साथ कई मेजर वर्जन जंप करने से मना करता है; यदि आप सीधे 6.x से 8.x पर जाने का प्रयास करेंगे, तो यह डेटा करप्ट करने के बजाय माइग्रेशन एरर के साथ रुक जाएगा। इमेज टैग को अगले मेजर वर्जन के लेटेस्ट रिलीज पर अपडेट करें, उस रिलीज के नोट्स में ब्रेकिंग बदलाव पढ़ें, docker compose up -d चलाएं, और आगे बढ़ने से पहले लॉग्स में माइग्रेशन पूरा होने तक प्रतीक्षा करें। दूसरा, MongoDB सपोर्ट मैट्रिक्स का पालन करें। प्रत्येक Rocket.Chat रिलीज MongoDB के विशिष्ट वर्जन्स को सपोर्ट करती है, और curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions आपको बताता है कि कौन से वर्जन समर्थित हैं। जब आप MongoDB को अपग्रेड करें, जैसे 7.0 से 8.0, तो एक बार में एक मेजर वर्जन ही आगे बढ़ें और प्रत्येक स्टेप के बाद feature-compatibility वर्जन सेट करें। MongoDB 8.0 पर इस कमांड के लिए स्पष्ट रूप से confirm: true की आवश्यकता होती है, अन्यथा यह एक मैसेज के साथ मना कर देगा कि आप इसे कन्फर्मेशन फ्लैग के साथ दोबारा चलाएं:

sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'

किसी भी घटक (component) को अपग्रेड करने से पहले mongodump जरूर लें। यही आपकी पूरी सुरक्षा नीति है।

विफलता के प्रकार (Failure modes) और सटीक स्ट्रिंग्स

docker compose up के तुरंत बाद Rocket.Chat रीस्टार्ट-लूप में फंस जाता है और docker compose logs rocketchat एक MongoServerSelectionError से भर जाता है। MongoDB चल रहा है लेकिन ड्राइवर primary को select नहीं कर पा रहा है, और सटीक स्ट्रिंग आपको बताती है कि आपने क्या गलती की है। ReplicaSetNoPrimary के टोपोलॉजी प्रकार के साथ Server selection timed out after 30000 ms का मतलब है कि आपने कभी rs.initiate() नहीं चलाया, सेट में अभी तक कोई कॉन्फ़िगरेशन नहीं है। एक रैंडम हैश के बाद getaddrinfo ENOTFOUND का मतलब है कि आपने स्पष्ट host: "mongodb:27017" के बिना इनिशियलाइज़ किया, इसलिए MongoDB ने एक ऐसा कंटेनर होस्टनेम advertise किया जिसे resolve नहीं किया जा सकता। sudo docker compose exec mongodb mongosh --eval 'rs.status()' के साथ डायग्नोस करें: यदि यह MongoServerError: no replset config has been received एरर देता है, तो सेट को इनिशियलाइज़ करें; यदि यह ऐसे मेंबर को दिखाता है जिसका name एक रैंडम हैश है, तो सर्विस नाम के साथ फिर से इनिशियलाइज़ करें।

वेब UI लोड होता है लेकिन लॉगिन स्पिन करता रहता है और कभी पूरा नहीं होता। ब्राउज़र कंसोल खोलें और आपको WebSocket connection to 'wss://chat.example.com/websocket' failed दिखाई देगा। यह लगभग हमेशा ROOT_URL का बेमेल होना या ऐसा प्रॉक्सी है जो अपग्रेड हेडर को फॉरवर्ड नहीं कर रहा है। पुष्टि करें कि ROOT_URL, https:// सहित सटीक पब्लिक एड्रेस के बराबर है, और आपका nginx location ब्लॉक Upgrade और Connection "upgrade" को proxy_http_version 1.1 के साथ सेट करता है। किसी भी बदलाव के बाद docker compose up -d को फिर से चलाएं।

एक कंटेनर बार-बार बंद हो रहा है और docker compose ps दिखाता है कि यह Restarting है। docker compose logs बीच में ही कट जाता है और sudo dmesg | tail oom-killer से Out of memory: Killed process 12345 (mongod) दिखाता है; एग्जिट कोड 137 है। सर्वर की RAM खत्म हो गई है। इसका वास्तविक समाधान एक बड़ा VPS है, कम से कम 4 GB। अस्थायी उपाय के रूप में swap जोड़ें और MongoDB के कैश को उसके command में --wiredTigerCacheSizeGB 1 के साथ सीमित करें, लेकिन swap वास्तविक लोड के तहत केवल अगले OOM को देरी से लाता है:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

docker compose up, Error response from daemon: driver failed programming external connectivity ... bind: address already in use के साथ विफल हो जाता है। कोई अन्य प्रक्रिया पहले से ही पोर्ट 3000 का उपयोग कर रही है, अक्सर यह Rocket.Chat का पिछला कंटेनर होता है जो ठीक से बंद नहीं हुआ, या कोई अन्य ऐप है। इसे sudo ss -ltnp | grep :3000 के साथ खोजें, उस प्रक्रिया या कंटेनर को रोकें, या मैपिंग के होस्ट साइड को 127.0.0.1:3001:3000 में बदलें और अपने प्रॉक्सी के proxy_pass को अपडेट करें।

FAQ

क्या Rocket.Chat को वास्तव में MongoDB replica set की आवश्यकता है?

हाँ, एक सिंगल सर्वर और एक डेटाबेस नोड के लिए भी। Rocket.Chat MongoDB change streams का उपयोग करके रीयल-टाइम में संदेश भेजता है, और change streams केवल replica-set में ही उपलब्ध होते हैं, एक standalone mongod इसे ओपन नहीं कर सकता। आपको कई मशीनों की आवश्यकता नहीं है; आप --replSet rs0 के साथ शुरू किए गए एक MongoDB कंटेनर को चलाएं और rs.initiate() के साथ एक-सदस्यीय सेट को इनिशियलाइज़ करें। यदि आप उस चरण को छोड़ देते हैं, तो ड्राइवर को कभी भी primary नहीं मिलेगा, जिससे Rocket.Chat MongoServerSelectionError: Server selection timed out के साथ रीस्टार्ट-लूप में फंस जाएगा और कभी भी बूट पूरा नहीं कर पाएगा।

self-hosted Rocket.Chat को कितनी RAM की आवश्यकता होती है?

व्यावहारिक न्यूनतम के रूप में 4 GB और एक व्यस्त टीम के लिए 8 GB की योजना बनाएं। Rocket.Chat की Node प्रक्रिया लगभग 1 से 1.5 GB का उपयोग करती है और MongoDB अपने WiredTiger कैश के लिए शेष RAM का लगभग आधा हिस्सा ले लेता है, इसलिए 2 GB वाले बॉक्स पर दोनों के बीच टकराव होता है और out-of-memory killer किसी भी वास्तविक लोड के तहत mongod को समाप्त कर देता है, जो लॉग में Killed और exit code 137 दिखाता है। 2 GB केवल कुछ टेस्ट उपयोगकर्ताओं के साथ सॉफ़्टवेयर का मूल्यांकन करने के लिए पर्याप्त है।

मैं Rocket.Chat को HTTPS के पीछे कैसे रखूँ?

उसी VPS पर एक reverse proxy चलाएं जो TLS को समाप्त (terminate) करे और 127.0.0.1:3000 पर फॉरवर्ड करे, और कंटेनर के ROOT_URL को अपने सार्वजनिक https:// पते पर सेट करें। प्रॉक्सी को WebSocket अपग्रेड हेडर को फॉरवर्ड करना होगा, अन्यथा लॉगिन अटक जाएगा। nginx के साथ Certbot सबसे सरल सिंगल-ऐप सेटअप है; यदि आप एक प्रॉक्सी के पीछे कई कंटेनर चलाते हैं और स्वचालित सर्टिफिकेट प्रबंधन चाहते हैं, तो Traefik अधिक बेहतर है।

मैं self-hosted Rocket.Chat का बैकअप कैसे लूँ?

वॉल्यूम को कॉपी करने के बजाय mongodump के साथ एक सुसंगत डेटाबेस डंप लें: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz। उस आर्काइव में उपयोगकर्ता, चैनल, संदेश और सेटिंग्स शामिल होती हैं, साथ ही यदि आपने स्टोरेज को GridFS पर छोड़ा है तो अपलोड की गई फाइलें भी शामिल होती हैं। इसे सर्वर से बाहर कॉपी करें, cron के साथ इसे हर रात स्वचालित करें, और एक थ्रोअवे बॉक्स पर mongorestore का अभ्यास करें ताकि आप जान सकें कि रिस्टोर वास्तव में काम करता है।

मैं MongoDB को तोड़े बिना Rocket.Chat को अपग्रेड कैसे करूँ?

Rocket.Chat को एक बार में एक प्रमुख संस्करण (major version) अपग्रेड करें, यह बूट पर माइग्रेशन चलाता है और प्रमुख संस्करणों को छोड़ने से इनकार करता है, और पिन किए गए इमेज टैग को बदलने से पहले प्रत्येक रिलीज़ के नोट्स पढ़ें। curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions के साथ जांचें कि आपका लक्ष्य रिलीज़ किन MongoDB संस्करणों का समर्थन करता है, और जब आप MongoDB को स्थानांतरित करते हैं, तो एक बार में एक प्रमुख संस्करण आगे बढ़ें और प्रत्येक हॉप के बाद confirm: true के साथ setFeatureCompatibilityVersion सेट करें। हमेशा पहले mongodump लें।