Rocket.Chat Docker Compose తో సెల్ఫ్ హోస్ట్ చేయడం

మీరు నిర్మించేది ఏమిటి

మీకు పూర్తిగా స్వంతమైన ఒక ప్రైవేట్ టీమ్ చాట్: మీ స్వంత VPSపై Docker Compose కింద నడుస్తున్న Rocket.Chat, TLS ద్వారా భద్రపరచబడిన, ప్రతి సందేశం మీరు బ్యాకప్ చేసి తరలించగలిగే MongoDB డేటాబేస్‌లో నిల్వ ఉంటుంది. Rocket.Chat అనేది పరిణతి చెందిన ఓపెన్-సోర్స్ Slack మరియు Teams ప్రత్యామ్నాయం — ఛానెళ్లు, డైరెక్ట్ సందేశాలు, త్రెడ్‌లు, ఫైల్ షేరింగ్, మరియు వాయిస్ వీడియోలు, అన్నీ మీరు అద్దెకు తీసుకుని నియంత్రించే హార్డ్‌వేర్‌లోనే ఉంటాయి. ఈ అప్లికేషన్ ఒకే కంటైనర్, కొన్ని నిమిషాల్లో ప్రారంభమవుతుంది. వాస్తవానికి ఏది తప్పుగా జరిగినా దాని పక్కనే ఉన్న డేటాబేస్‌లోనే ఉంటుంది. కాబట్టి ఈ గైడ్ ఎక్కువగా MongoDB గురించే ఉంటుంది. ముఖ్యంగా, అందరినీ మొదటిసారి ఆశ్చర్యానికి గురిచేసే ఒక అవసరం: Rocket.Chat స్టాండలోన్ MongoDBపై నడవదు. దానికి రెప్లికా సెట్ కావాలి, ఆ "సెట్" ఒకే ఒక్క నోడ్ అయినా సరే.

ముందస్తు అవసరాలు, మరియు ఎవరూ చెప్పని RAM లెక్కలు

సర్వర్ పరిమాణాన్ని ఆచరణాత్మకంగా అంచనా వేయండి. ఒక చిన్న బృందానికి వాస్తవ కనిష్ట అవసరం 2 vCPU మరియు 4 GB RAM. Rocket.Chat యొక్క Node.js ప్రాసెస్ ఒంటరిగా దాదాపు 1 నుండి 1.5 GB వాడుతుంది. MongoDB యొక్క WiredTiger క్యాష్ అప్రమేయంగా మిగిలిన RAMలో సగభాగాన్ని తీసుకుంటుంది. 2 GB VPSలో, బూట్ సమయంలో ఈ రెండూ సరిగ్గా అమరుతాయి. వాస్తవ ట్రాఫిక్ రాగానే అవి ఢీ కొడతాయి. MongoDB దాని క్యాష్‌ను పెంచుకుంటుంది. Node దాని హీప్‌ను పెంచుకుంటుంది. కర్నల్‌కు పేజీలు అడుగంటిపోతాయి. అప్పుడు out-of-memory killer అతిపెద్ద ప్రాసెస్‌ను అంతం చేస్తుంది — సాధారణంగా అది mongod అవుతుంది. కంటైనర్ Killed అని ప్రింట్ చేస్తుంది. Docker దాన్ని రీస్టార్ట్ చేస్తుంది. ఫలితంగా, సాధారణంగా తట్టుకోగలిగే లోడ్‌లో కొన్ని నిమిషాలకోసారి పడిపోయే చాట్ సర్వర్ మీకు దొరుకుతుంది. 2 GB అనేది ఇద్దరు వ్యక్తులతో పరీక్షించడానికి సరిపోతుంది. అది బృంద సర్వర్‌కు సరిపోదు. 4 GBతో ప్రారంభించండి. ఒకవేళ డజన్ల కొద్దీ ఏకకాలిక వినియోగదారులు, వీడియో కాల్‌లు, లేదా పెరుగుతున్న అప్‌లోడ్ చరిత్ర అనుకుంటే 8 GB ఇవ్వండి.

మీరు ప్రారంభించడానికి ముందు మూడు పనులు సిద్ధంగా ఉండాలి. VPS యొక్క పబ్లిక్ IPని సూచిస్తూ A record కలిగిన ఒక డొమైన్ పేరు — Rocket.Chat యొక్క రియల్-టైమ్ ఫీచర్లు మరియు మొబైల్ క్లయింట్‌లకు స్థిరమైన హోస్ట్‌పేరు కావాలి, కేవలం నగ్న IP సరిపోదు. సర్వర్ ఫైర్‌వాల్ మరియు మీ ప్రొవైడర్ నెట్‌వర్క్ ఫైర్‌వాల్ రెండింటిలోనూ పోర్టులు 80 మరియు 443 తెరిచి ఉండాలి, ఇది చాలా ప్యానెల్‌లలో వేరే కంట్రోల్‌గా ఉంటుంది. మరియు root లేదా sudo తో కూడిన కొత్త Ubuntu 24.04 KVM VPS కావాలి. ఒక చాట్ సర్వర్‌ను మొదట నడపడం సరైన ఎంపికా అని మీరు ఇంకా నిర్ణయించుకుంటూ ఉంటే, 2026లో స్వయం-హోస్ట్ చేయడానికి విలువైనవి ఏవి అనే గైడ్ ఈ సమస్యలను వివరిస్తుంది.

Docker ఇంజిన్ మరియు Compose ప్లగిన్‌ను ఇన్‌స్టాల్ చేయండి

Docker యొక్క స్వంత apt రిపాజిటరీని ఉపయోగించండి. Ubuntu అందించే docker.io ప్యాకేజీని కాదు. పాత స్టాండలోన్ docker-compose Python బైనరీని కూడా వాడవద్దు. ఆధునిక Compose అనేది ఒక Docker ప్లగిన్. దీన్ని మీరు docker compose అని పిలుస్తారు — హైఫన్ కాదు, స్పేస్. పాత docker-compose v1 ఇప్పుడు వాడుకలో లేదు. దానివల్ల దిగువ పేర్కొన్న healthcheck మరియు dependency సింటాక్స్ సరిగ్గా పనిచేయదు.

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 వంటి ఫలితాన్ని ముద్రిస్తుంది. ఇదే ముఖ్యమైన తనిఖీ. దీను docker: 'compose' is not a docker command అని ఎర్రర్ ఇస్తే, ప్లగిన్ ఇన్‌స్టాల్ కాలేదని అర్థం. దీన్ని ఇక్కడే పరిష్కరించండి. లేదంటే తర్వాత దారితీసే అయోమయ సమస్యలను ఎదుర్కోవలసి వస్తుంది.

కంపోజ్ ఫైలు: మోంగోడిబి ఒంటరి-నోడ్ రెప్లికా సెట్‌గా

చాలామంది ఈ భాగాన్ని తప్పుగా అర్థం చేసుకుంటారు. కాబట్టి దీన్ని నెమ్మదిగా చదవండి. కనెక్ట్ అయిన క్లయింట్‌లకు రియల్ టైమ్‌లో కొత్త సందేశాలను పంపడానికి Rocket.Chat మోంగోడిబి ఛేంజ్ స్ట్రీమ్‌లను ఉపయోగిస్తుంది. ఛేంజ్ స్ట్రీమ్‌లు రెప్లికా సెట్‌పై మాత్రమే అందుబాటులో ఉంటాయి. మీరు Rocket.Chatను సాధారణ స్టాండలోన్ mongod వైపు పాయింట్ చేస్తే, అది కనెక్ట్ అవుతుంది. ఛేంజ్ స్ట్రీమ్‌ను తెరవడంలో విఫలమవుతుంది. అప్పటినుండి అది నిరంతరం రీస్టార్ట్ లూప్‌లో చిక్కుకుంటుంది. పరిష్కారం క్లిష్టం కాదు: మీరు ఒక ఒంటరి, సాధారణ మోంగోడిబి కంటైనర్‌ను నడుపుతారు. కానీ దాన్ని --replSetతో ప్రారంభిస్తారు. తర్వాత ఒక-సభ్యుడి సెట్‌ను ప్రారంభీకరిస్తారు.

పని డైరెక్టరీ మరియు 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 పోర్ట్ 0.0.0.0కు కాకుండా 127.0.0.1:3000కి పబ్లిష్ చేయబడింది — యాప్‌కు TLS లేదు, కాబట్టి ఒకే సర్వర్‌లోని రివర్స్ ప్రాక్సీ మాత్రమే దానిని చేరుకోగలదు; దాన్ని ప్రతి ఇంటర్‌ఫేస్‌కు బైండ్ చేస్తే ప్లెయిన్‌టెక్స్ట్ లాగిన్ పేజీ నేరుగా పబ్లిక్ ఇంటర్నెట్‌లోకి వెళ్లిపోతుంది. మోంగోడిబి హోస్ట్‌కు పబ్లిష్ చేయబడదు; అది కంపోజ్ అంతర్గత నెట్‌వర్క్‌పై mongodb పేరుతో మాత్రమే చేరుకోగలదు, ఇది MONGO_URL ఉపయోగించే హోస్ట్‌నేమ్ ఖచ్చితంగా ఉంటుంది. MONGO_URL అందులో ?replicaSet=rs0ను కలిగి ఉంటుంది — దాన్ని వదిలేస్తే, సర్వర్ రెప్లికా సెట్ అయినప్పటికీ, డ్రైవర్ దాన్ని స్టాండలోన్‌గా భావిస్తుంది, మరియు ఛేంజ్ స్ట్రీమ్‌లు మళ్లీ విఫలమవుతాయి. MONGO_OPLOG_URL అనేది ఆప్‌లాగ్ ఉన్న local డేటాబేస్‌ను సూచిస్తుంది; ఆధునిక Rocket.Chat ఛేంజ్ స్ట్రీమ్‌లను ఇష్టపడుతుంది, అయితే దీన్ని సెట్ చేయడం హాని కలిగించదు మరియు పాత కోడ్ పాత్‌లను సక్రమంగా పని చేసేలా ఉంచుతుంది. depends_on అనేది condition: service_healthyను ఉపయోగిస్తుంది, కాబట్టి మోంగోడిబి pingకి స్పందించే వరకు వేచి ఉన్న తర్వాతే కంపోజ్ Rocket.Chatను ప్రారంభిస్తుంది — హెల్త్‌చెక్ అంతకే ఉపయోగపడుతుంది.

రెండు ఇమేజ్‌లపైనా నిజమైన వెర్షన్ ట్యాగ్‌లను పిన్ చేయండి — mongo:8.0 మరియు ఇక్కడ చూపిన విధంగా స్పష్టమైన Rocket.Chat విడుదల అయిన 8.5.1 — మరియు ఎప్పుడూ :latestను ఉపయోగించవద్దు, ఇది ఎప్పుడూ పర్యవేక్షించని docker pullను ప్రమాదవశాత్తూ, మైగ్రేట్ చేయలేని అప్‌గ్రేడ్‌గా మారుస్తుంది. మీరు పిన్ చేయడానికి ముందు, ప్రస్తుత స్థిరమైన Rocket.Chat విడుదల మరియు అది మద్దతు ఇచ్చే మోంగోడిబి వెర్షన్‌లను తనిఖీ చేయండి. Rocket.Chat ప్రతి విడుదలకు మెషీన్-రీడబుల్ సమాచార పత్రాన్ని ప్రచురిస్తుంది: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' అనేది 8.5.1 కోసం compatibleMongoVersions: ["8.0"]ను అందిస్తుంది, కాబట్టి mongo:8.0 మాత్రమే మద్దతు ఇచ్చే ఇంజిన్, దానితోపాటు ఒక lts ఫ్లాగ్ ఉంటుంది, అది ఆ విడుదల మీరు పర్యవేక్షించాలనుకోని సర్వర్ కోసం పిన్ చేయడానికి విలువైన లాంగ్-టర్మ్-సపోర్ట్ బిల్డ్ కాదా అని చెబుతుంది.

రెప్లికా సెట్‌ను ప్రారంభించండి

స్టాక్‌ను ప్రారంభించండి:

sudo docker compose up -d

Rocket.Chat తక్షణమే క్రాష్ అవుతుంది. రెప్లికా సెట్ ఇంకా లేనందున Docker దాన్ని నిరంతరం రీస్టార్ట్ చేస్తుంది. ఇది అంచనాగానే ఉంది. దాన్ని ఒకసారి మాన్యువల్‌గా సృష్టించండి:

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

సరైన ఫలితం { ok: 1 }. కొన్ని సెకన్లలో సింగిల్ నోడ్ తనను తాను ప్రైమరీగా ఎన్నుకుంటుంది. దీన్ని ఈ కమాండ్‌తో నిర్ధారించండి:

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

మీరు PRIMARY చూడాలి. ఈ పేజీ మొత్తంలో అత్యంత ముఖ్యమైన వివరం host: "mongodb:27017" ఆర్గ్యుమెంట్. మీరు సభ్యుల జాబితా లేకుండా ఒక నగ్న rs.initiate() నడిపితే, MongoDB కంటైనర్ యొక్క అంతర్గత హోస్ట్‌నేమ్ కింద రెప్లికా సెట్‌ను ప్రకటిస్తుంది — అది a1b2c3d4e5f6 వంటి ఒక యాదృచ్ఛిక హాష్. దాని స్వంత కంటైనర్ నుండి అనుసంధానించే Rocket.Chat ఆ పేరును పరిష్కరించలేకపోతుంది. కాబట్టి MongoDB డ్రైవర్ దానిపై DNS విఫలమవుతుంది. అప్పుడు అది MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 లాగ్ చేస్తూ నిరంతరం లూప్‌లో తిరుగుతుంది. మీ MONGO_URLతో సరిపోలే స్పష్టమైన సర్వీస్ పేరుతో ఎల్లప్పుడూ ప్రారంభించండి.

మొదటి బూట్: సర్వర్ ప్రారంభమవడాన్ని గమనించండి

సెట్ ప్రాథమికంగా మారిన తర్వాత, 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 రకపు టోపాలజీ వివరణతో పునరావృతం చేస్తే, రెప్లికా సెట్ ప్రారంభించబడలేదు. అది యాదృచ్ఛిక హాష్‌పై getaddrinfo ENOTFOUND ను పునరావృతం చేస్తే, అది తప్పుడు హోస్ట్‌తో ప్రారంభించబడింది. రెండు సందర్భాల్లోనూ, ఒక దశ వెనుకకు వెళ్లండి. మీరు SERVER RUNNING చూసిన తర్వాత, Rocket.Chat అనువర్తనం 127.0.0.1:3000 పై వింటూ ఉంటుంది. దాని ముందు ఒక నిజమైన హోస్ట్‌పేరు మరియు TLS ఉంచడానికి సమయం వచ్చింది.

దీన్ని TLS వెనుక ఉంచండి

Rocket.Chat ను సాధారణ HTTP పై ఎప్పుడూ బహిర్గతం చేయవద్దు. http:// ద్వారా ఒకసారి లాగిన్ అయ్యేసి, మార్గంలో ఉన్న ఎవరికైనా మీ అడ్మిన్ పాస్‌వర్డ్‌ను అప్పగించినట్లే. అదే సర్వర్‌లో రివర్స్ ప్రాక్సీలో TLS ను ముగించి, 127.0.0.1:3000 కు ఫార్వర్డ్ చేయండి. ఇక్కడ రెండు విషయాలు ముఖ్యం: ప్రాక్సీ తప్పనిసరిగా WebSocket అప్‌గ్రేడ్ హెడర్‌లను ఫార్వర్డ్ చేయాలి, ఎందుకంటే Rocket.Chat రియల్-టైమ్ అప్లికేషన్ మరియు ఆ హెడర్‌లు లేకుండా పనిచేయడం లేదు, మరియు కంటైనర్ యొక్క ROOT_URL వినియోగదారులు టైప్ చేసే పబ్లిక్ HTTPS చిరునామాతో సరిగ్గా సరిపోలాలి.

యాప్‌కు ప్రాక్సీ చేస్తూ, అప్‌గ్రేడ్ హెడర్‌లను ఫార్వర్డ్ చేసే సాధారణ HTTP nginx సర్వర్ బ్లాక్‌తో ప్రారంభించండి. దాన్ని /etc/nginx/sites-available/rocketchat గా సేవ్ చేయండి, sites-enabled లోకి సిమ్‌లింక్ చేయండి, మరియు రీలోడ్ చేయండి:

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;
    }
}

ప్రస్తుతానికి దాన్ని పోర్ట్ 80 పైనే ఉంచండి — listen 443 ssl; తో ఉన్న బ్లాక్‌కి సర్టిఫికేట్ లేకపోతే sudo nginx -t కూడా పాస్ కాదు. nginx ను రీలోడ్ చేయండి (sudo nginx -t && sudo systemctl reload nginx), తర్వాత సర్టిఫికేట్ జారీ చేయండి. Ubuntu లో అత్యంత సులభమైన మార్గం Certbot మరియు nginx తో Let's Encrypt TLS సర్టిఫికేట్‌లు: certbot --nginx పైన ఉన్న బ్లాక్‌ను అదే చోట మార్చి, listen 443 ssl;, ssl_certificate లైన్‌లు, మరియు 80 నుండి 443 కు ఆటోమేటిక్ రీడైరెక్ట్‌ను జోడిస్తుంది, మరియు మీ కోసం రెన్యూవల్‌ను షెడ్యూల్ చేస్తుంది. ఒక ప్రాక్సీ వెనుక మీరు ఇప్పటికే అనేక కంటైనర్‌లను నడుపుతుంటే, అనేక Docker యాప్‌ల కోసం ఆటోమేటిక్ TLS తో Traefik వికాసంగా ఉంటుంది — rocketchat సర్వీస్‌కు రౌటర్ మరియు సర్వీస్ లేబుల్‌లను జోడించండి, అయితే Traefik మీ కోసం సర్టిఫికేట్‌ను అభ్యర్థించి రెన్యూ చేస్తుంది, nginx బ్లాక్ అసలు అవసరం ఉండదు. ఏ మార్గం తీసుకున్నా, compose.yml లో ROOT_URL ను https://chat.example.com కు సెట్ చేసి, కంటైనర్ ఆ మార్పును స్వీకరించేలా sudo docker compose up -d ను మళ్లీ రన్ చేయండి. సర్వర్‌ను పబ్లిక్ ఇంటర్నెట్ కంటే మీ స్వంత నెట్‌వర్క్ లోపల నుండి మాత్రమే చేరుకోగలిగేలా చేయాలనుకుంటే, దానికి VPS లో సెల్ఫ్-హోస్టెడ్ WireGuard VPN తో ముందుగా ఉంచి, ప్రాక్సీని టనెల్ చిరునామాకు బైండ్ చేయండి.

మొదటి-రన్ సెటప్ విజార్డ్

https://chat.example.com కు వెళ్లండి. Rocket.Chat మిమ్మల్ని ఒక చిన్న విజార్డ్ ద్వారా తీసుకువెళ్తుంది. ముందుగా, అడ్మిన్ ఖాతా — నిజమైన పేరు, యూజర్‌నేమ్, ఇమెయిల్, మరియు బలమైన పాస్‌వర్డ్; ఇది ఉనికిలో ఉన్న ఏకైక ఖాతా, కాబట్టి దాన్ని కోల్పోవద్దు. తరువాత, సంస్థ మరియు సర్వర్ సమాచారం — పేరు, పరిశ్రమ, పరిమాణం, సైట్ పేరు మరియు డిఫాల్ట్ భాష; ఇవి కేవలం ప్రదర్శన ప్రయోజనాల కోసం, నింపి ముందుకు సాగండి. అప్పుడు నిజంగా ముఖ్యమైన ఎంపిక: ఈ వర్క్‌స్పేస్‌ను Rocket.Chat Cloud తో రిజిస్టర్ చేయడం, లేదా దాన్ని స్టాండ్‌ఎలోన్‌గా ఉంచడం.

రిజిస్టర్ చేయడం వలన Rocket.Chat యొక్క గేట్‌వే ద్వారా మొబైల్ పుష్ నోటిఫికేషన్‌లు మరియు ఆడ్-ఆన్ మార్కెట్‌ప్లేస్ లభిస్తాయి. దీనికి ప్రతిఫలంగా Rocket.Chat యొక్క క్లౌడ్‌తో ఒక కంట్రోల్-ప్లేన్ సంబంధం ఏర్పడుతుంది. స్టాండ్‌ఎలోన్ సర్వర్‌ను పూర్తిగా ప్రైవేట్‌గా మరియు డిపెండెన్సీ-లేనిదిగా ఉంచుతుంది. కానీ iOS మరియు Android పుష్ నోటిఫికేషన్‌లు పనిచేయడం ఆగిపోతుంది, ఎందుకంటే Apple మరియు Google స్వయంగా నిర్మించిన యాప్‌కు పుష్ సర్టిఫికేట్‌లను కలిగి ఉండటానికి అనుమతివ్వవు — అధికారిక యాప్‌లు క్లౌడ్ గేట్‌వే ద్వారా రూట్ అవుతాయి. గోప్యతే మీ ప్రధాన ఉద్దేశ్యమైతే మరియు మీ యూజర్లు వెబ్ యాప్‌లోనే ఉంటే స్టాండ్‌ఎలోన్ ఎంచుకోండి; మొబైల్ పుష్ తప్పనిసరి అయితే రిజిస్ట్రేషన్ ఎంచుకోండి. మీరు తరువాత Admin కింద మీ నిర్ణయాన్ని మార్చుకోవచ్చు.

ఎవరినైనా ఆహ్వానించే ముందు యాక్సెస్‌ను లాక్ చేయండి

Rocket.Chat అంతర్నిర్మితంగా ఓపెన్ రిజిస్ట్రేషన్ ఆన్‌తో వస్తుంది — డిఫాల్ట్‌గా రిజిస్ట్రేషన్ ఫారమ్ Publicకి సెట్ చేయబడి ఉంటుంది, కాబట్టి URL కనుగొన్న ఎవరైనా ఖాతాను సృష్టించగలరు. పబ్లిక్ హోస్ట్‌నేమ్‌లో అది ఒక అనుమతి లేని ప్రవేశ ద్వారం. Admin → Settings → Accounts → Registrationకి వెళ్లి Registration Formను Disabledకి సెట్ చేయండి, తద్వారా మీరు ఖాతాలను మాన్యువల్‌గా లేదా ఆహ్వాన లింక్ ద్వారా సృష్టిస్తారు, లేదా Secret URLకి సెట్ చేయండి. అక్కడే ఉన్నప్పుడు, మీకు ప్రత్యేకంగా పబ్లిక్ రీడ్-ఓన్లీ ఛానెల్ కావాలనుకోకపోతే Allow Anonymous Read మరియు Allow Anonymous Writeను ఆఫ్ చేయండి.

అప్‌లోడ్‌లు ఎక్కడికి వెళ్తాయో కూడా నిర్ణయించండి. డిఫాల్ట్ File Upload స్టోరేజ్ GridFS, ఇది ప్రతి ఇమేజ్ మరియు అటాచ్‌మెంట్‌ను MongoDB లోపలనే నిల్వ చేస్తుంది. అది సరళం, కానీ దానర్థం మీ డేటాబేస్ — మరియు మీరు తీసుకునే ప్రతి mongodump — వినియోగదారులు స్క్రీన్‌షాట్‌లను పేస్ట్ చేసేకొద్దీ పరిమితి లేకుండా పెరుగుతుంది. Admin → Settings → File Upload కింద, మీరు స్టోరేజ్‌ను లోకల్ ఫైల్‌సిస్టమ్ లేదా S3-కంపాటిబుల్ బకెట్‌కు మార్చవచ్చు, మరియు సరైన గరిష్ట ఫైల్ పరిమాణాన్ని సెట్ చేయవచ్చు. చిన్న బృందానికి GridFS సరిపోతుంది; కానీ మీ బ్యాకప్‌లు కాలక్రమేణా భారీగా మారుతాయని గుర్తించండి.

mongodumpతో బ్యాకప్‌లు

మీ డేటా మొత్తం mongodb_data వాల్యూమ్‌లో ఉంటుంది. నడుస్తున్న డేటాబేస్ కింద నుండి వాల్యూమ్‌ను నేరుగా కాపీ చేయవద్దు — mongodumpతో ఒక స్థిరమైన డంప్ తీసుకోండి, దాన్ని హోస్ట్‌లోని ఫైల్‌కి స్ట్రీమ్ చేయండి:

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

ఆ ఒక్క gzip ఆర్కైవ్ మీ మొత్తం వర్క్‌స్పేస్: వినియోగదారులు, ఛానెల్‌లు, సందేశాలు, సెట్టింగ్‌లు మరియు — మీరు అప్‌లోడ్‌లను 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 కు — ఒక్కో మేజర్ చొప్పన అడుగువేయండి మరియు ప్రతి హోప్ తర్వాత ఫీచర్-కంపాటిబిలిటీ వర్షన్‌ను సెట్ చేయండి. MongoDB 8.0 లో ఆ కమాండ్‌కు స్పష్టమైన confirm: true అవసరం, లేదా కన్ఫర్మేషన్ ఫ్లాగ్‌తో దానిని మళ్లీ నడపమని చెబుతూ ఒక సందేశంతో అది తిరస్కరిస్తుంది:

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

రెండు కాంపోనెంట్‌లలో దేనినైనా అప్‌గ్రేడ్ చేయడానికి ముందు mongodump తీసుకోండి. అదే మొత్తం భీమా పాలసీ.

వైఫల్య రకాలు, స్పష్టమైన స్ట్రింగులతో

Rocket.Chat అనునది docker compose up తర్వాత తిరిగి-ప్రారంభ లూపులను చేస్తుంది, మరియు docker compose logs rocketchat అనునది MongoServerSelectionErrorతో నిండిపోతుంది. MongoDB నడుస్తోంది కానీ డ్రైవర్ ఒక ప్రాథమికాన్ని ఎంచుకోలేకపోతుంది, మరియు స్పష్టమైన స్ట్రింగ్ మీరు చేసిన తప్పు ఏదో చెబుతుంది. ReplicaSetNoPrimary టోపాలజీ రకంతో Server selection timed out after 30000 ms అంటే మీరు rs.initiate() నడపలేదు — సెట్‌కు ఇంకా కాన్ఫిగరేషన్ లేదు. getaddrinfo ENOTFOUND తర్వాత ఒక యాదృచ్ఛిక హాష్ వస్తే, మీరు స్పష్టమైన host: "mongodb:27017" లేకుండా ప్రారంభించారని అర్థం, కాబట్టి MongoDB పరిష్కరించలేని కంటైనర్ హోస్ట్‌పేర్‌ను ప్రకటించింది. 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 బ్లాక్ proxy_http_version 1.1తో Upgrade మరియు Connection "upgrade"ను సెట్ చేస్తుందని నిర్ధారించుకోండి. వీటిలో దేనినైనా మార్చి 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. ఒక తాత్కాలిక పరిష్కారంగా స్వాప్ జోడించండి మరియు దాని commandలో --wiredTigerCacheSizeGB 1తో MongoDB క్యాచ్‌ను పరిమితం చేయండి, కానీ స్వాప్ వాస్తవ లోడ్‌లో తదుపరి 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 రెప్లికా సెట్ అవసరమా?

అవును, ఒకే డేటాబేస్ నోడ్ ఉన్న ఒంటరి సర్వరుకు కూడా. Rocket.Chat సందేశాలను నిజ సమయంలో పంపడానికి MongoDB మార్పు స్ట్రీమ్‌లను ఉపయోగిస్తుంది. మార్పు స్ట్రీమ్‌లు రెప్లికా-సెట్-మాత్రమే ఫీచర్. స్టాండలోన్ mongod దాన్ని తెరవలేదు. మీకు బహుళ మెషీన్‌లు అవసరం లేదు. మీరు --replSet rs0 తో ప్రారంభమైన ఒక MongoDB కంటైనర్‌ను నడుపండి. rs.initiate() తో ఒక-సభ్యుడి సెట్‌ను ప్రారంభించండి. ఆ దశను దాటేస్తే డ్రైవర్ ఎప్పటికీ ప్రైమరీని కనుగొనదు. దీనివల్ల Rocket.Chat అనువర్తనం బూటింగ్ పూర్తి చేయకుండా MongoServerSelectionError: Server selection timed out తో రీస్టార్ట్ లూప్‌లో చిక్కుకుంటుంది.

సెల్ఫ్-హోస్టెడ్ Rocket.Chat కి ఎంత RAM అవసరం?

ఆచరణాత్మక కనీసంగా 4 GB ప్రణాళిక చేయండి. రద్దీగా ఉన్న బృందానికి 8 GB కేటాయించండి. Rocket.Chat యొక్క Node ప్రక్రియ దాదాపు 1 నుండి 1.5 GB వాడుతుంది. MongoDB తన WiredTiger క్యాచ్ కోసం మిగిలిన RAM లో దాదాపు సగం తీసుకుంటుంది. కాబట్టి 2 GB మెషీన్‌పై ఈ రెండూ ఢీకొట్టుకుంటాయి. వాస్తవ లోడ్ ఉన్నప్పుడు అవుట్-ఆఫ్-మెమరీ కిల్లర్ ఏదైనా లోడ్ కింద mongod ను ఆపేస్తుంది. లాగ్‌లలో Killed కనిపిస్తుంది, ఎగ్జిట్ కోడ్ 137 వస్తుంది. సాఫ్ట్‌వేర్‌ను కేవలం కొన్ని టెస్ట్ యూజర్‌లతో అంచనా వేయడానికి 2 GB సరిపోతుంది.

నేను Rocket.Chat ను HTTPS వెనుక ఎలా ఉంచాలి?

అదే VPS పై ఒక రివర్స్ ప్రాక్సీ నడపండి. అది TLS ను ముగిస్తుంది. 127.0.0.1:3000 కు అభ్యర్థనలను పంపుతుంది. కంటైనర్ యొక్క ROOT_URL ను మీ పబ్లిక్ https:// చిరునామాకు సెట్ చేయండి. లేదంటే ప్రాక్సీ WebSocket అప్‌గ్రేడ్ హెడర్‌లను ఫార్వర్డ్ చేయాలి. లేదంటే లాగిన్ హాంగ్ అవుతుంది. nginx తో Certbot అనేది సింగిల్-యాప్ సెటప్‌కు అత్యంత సరళమైనది. మీరు ఒకే ప్రాక్సీ వెనుక అనేక కంటైనర్‌లు నడిపి, స్వయంచాలక సర్టిఫికేట్ నిర్వహణ కావాలంటే Traefik ఉపయోగించండి.

సెల్ఫ్-హోస్టెడ్ Rocket.Chat ను ఎలా బ్యాకప్ చేయాలి?

వాల్యూమ్‌ను కాపీ చేయడం కంటే mongodump తో స్థిరమైన డేటాబేస్ డంప్ తీయండి: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. ఆ ఆర్కైవ్‌లో యూజర్‌లు, ఛానెల్‌లు, సందేశాలు, సెట్టింగులు ఉంటాయి. మీరు స్టోరేజ్ GridFS పై ఉంచినట్లయితే అప్‌లోడ్ చేసిన ఫైళ్లు కూడా ఉంటాయి. దాన్ని సర్వర్ నుండి బయటకు కాపీ చేయండి. cron తో ప్రతి రాత్రి స్వయంచాలకంగా చేయండి. ఒక తాత్కాలిక మెషీన్‌పై mongorestore ను రిహార్స్ చేయండి. దానివల్ల రిస్టోర్ వాస్తవంగా పనిచేస్తుందో లేదో మీకు తెలుస్తుంది.

MongoDB పాడుకాకుండా Rocket.Chat ను ఎలా అప్‌గ్రేడ్ చేయాలి?

Rocket.Chat ను ఒక్కో మేజర్ వెర్షన్ చొప్పన అప్‌గ్రేడ్ చేయండి. ఇది బూట్ పై మైగ్రేషన్‌లను నడుపుతుంది. మేజర్ వెర్షన్‌లను దాటడాన్ని తిరస్కరిస్తుంది. పిన్నెడ్ ఇమేజ్ ట్యాగ్‌ను మార్చే ముందు ప్రతి రిలీజ్ గమనికలను చదవండి. మీ లక్ష్య రిలీజ్ ఏ MongoDB వెర్షన్‌లకు మద్దతు ఇస్తుందో curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions తో తనిఖీ చేయండి. మీరు MongoDB ను మార్చేటప్పుడు, ఒక్కో మేజర్ వెర్షన్ చొప్పన ముందుకు వెళ్లండి. ప్రతి హాప్ తర్వాత confirm: true తో setFeatureCompatibilityVersion సెట్ చేయండి. ముందుగా ఎల్లప్పుడూ mongodump తీసుకోండి.