Docker Compose ద్వారా Rocket.Chat ను హోస్ట్ చేయడం ఎలా?

మీరు ఏమి నిర్మిస్తున్నారు

మీరు పూర్తిగా నియంత్రించే ఒక ప్రైవేట్ టీమ్ చాట్: మీ స్వంత VPSలో Docker Compose ద్వారా నడుస్తున్న Rocket.Chat, దీనికి TLS termination ఉంటుంది. ప్రతి సందేశం మీరు బ్యాకప్ తీసుకోగల మరియు తరలించగల MongoDB డేటాబేస్‌లో నిక్షిప్తమై ఉంటుంది. Rocket.Chat అనేది Slack మరియు Teams కు ఒక పరిణతి చెందిన ఓపెన్-సోర్స్ ప్రత్యామ్నాయం. ఇందులో ఛానెల్‌లు, డైరెక్ట్ మెసేజ్‌లు, థ్రెడ్‌లు, ఫైల్ షేరింగ్, వాయిస్ మరియు వీడియో కాల్స్ వంటి సౌకర్యాలు మీరు అద్దెకు తీసుకున్న మరియు నియంత్రించే హార్డ్‌వేర్‌పై అందుబాటులో ఉంటాయి. అయితే, ఇది మాత్రమే నమ్మదగిన ఎంపిక కాదు. మీరు ఇంకా ఎంపిక చేసుకునే పనిలో ఉంటే, Mattermost, Rocket.Chat, Synapse మరియు Zulip ల పోలిక మీకు సహాయపడుతుంది. ఇది RAM, డేటాబేస్, మొబైల్ పుష్, SSO మరియు అప్‌గ్రేడ్‌ల వంటి భవిష్యత్తులో ఇబ్బంది కలిగించే అంశాల ఆధారంగా వీటిని పోలుస్తుంది. ఈ అప్లికేషన్ నిమిషాల్లోనే సిద్ధమయ్యే ఒకే ఒక కంటైనర్. వాస్తవానికి సమస్యలు తలెత్తే ప్రతిదీ దాని పక్కనే ఉన్న డేటాబేస్‌లోనే ఉంటుంది. కాబట్టి, ఈ గైడ్‌లో ఎక్కువ భాగం MongoDB గురించి ఉంటుంది. ముఖ్యంగా, మొదటిసారి చేసే వారికి ఆశ్చర్యం కలిగించే ఒక అవసరం ఉంది: Rocket.Chat అనేది standalone MongoDB తో నడవదు. దీనికి replica set అవసరం, ఆ "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 వద్ద మెమరీ అయిపోతుంది. అప్పుడు out-of-memory killer అత్యధిక మెమరీ వాడుతున్న ప్రాసెస్‌ను, సాధారణంగా mongod ను నిలిపివేస్తుంది. కంటైనర్ Killed అని చూపిస్తుంది, Docker దానిని రీస్టార్ట్ చేస్తుంది. ఫలితంగా, తక్కువ లోడ్ ఉన్నా కూడా చాట్ సర్వర్ తరచుగా ఆగిపోతుంది. 2 GB అనేది కేవలం ఇద్దరు వ్యక్తులు పరీక్షించుకోవడానికి మాత్రమే సరిపోతుంది; ఇది టీమ్ సర్వర్ కాదు. 4 GBతో ప్రారంభించండి. ఒకవేళ డజన్ల కొద్దీ వినియోగదారులు, వీడియో కాల్స్ లేదా ఎక్కువ అప్‌లోడ్ హిస్టరీ ఉంటే 8 GB RAM కేటాయించండి. సర్వర్‌లో నడిచే ఇతర సేవల కోసం కూడా అదనపు మెమరీని లెక్కించండి: ఒకే VPSలో Notion-వంటి AFFiNE workspace ను ఉంచితే, అది మరో నాలుగు కంటైనర్లను అదనంగా చేరుస్తుంది. కాబట్టి వాటికి అవసరమైన RAMను Rocket.Chat వాడే మెమరీకి అదనంగా పరిగణించాలి.

ప్రారంభించే ముందు మీకు మూడు విషయాలు సిద్ధంగా ఉండాలి. VPS యొక్క పబ్లిక్ IPకి పాయింట్ చేసిన A record కలిగిన డొమైన్ పేరు ఉండాలి; Rocket.Chat యొక్క రియల్-టైమ్ ఫీచర్లు మరియు మొబైల్ క్లయింట్ల కోసం కేవలం IP కాకుండా స్థిరమైన హోస్ట్ నేమ్ అవసరం. సర్వర్ ఫైర్‌వాల్ మరియు మీ ప్రొవైడర్ నెట్‌వర్క్ ఫైర్‌వాల్ రెండింటిలోనూ Ports 80 మరియు 443 ఓపెన్ చేసి ఉండాలి (చాలా ప్యానెల్స్‌లో ఇది ప్రత్యేక నియంత్రణలో ఉంటుంది). అలాగే, root లేదా sudo యాక్సెస్ ఉన్న తాజా Ubuntu 24.04 KVM VPS ఉండాలి. చాట్ సర్వర్ అనేది మీరు హోస్ట్ చేయాల్సిన మొదటి సేవ అవునో కాదో నిర్ణయించుకోవడానికి, 2026లో దేనిని self-host చేయడం విలువైనది అనే గైడ్ లోని లాభనష్టాలను పరిశీలించండి.

Docker engine మరియు Compose plugin ను ఇన్‌స్టాల్ చేయడం

Ubuntu అందించే docker.io ప్యాకేజీని కాకుండా, Docker సొంత apt రిపోజిటరీని ఉపయోగించండి. అలాగే పాతబడిన standalone docker-compose Python బైనరీని వాడవద్దు. ఆధునిక Compose అనేది ఒక Docker plugin, దీనిని మీరు docker compose అని పిలవాలి (హైఫన్ లేకుండా, స్పేస్‌తో). పాత docker-compose v1 వెర్షన్ ఇప్పటికే నిలిపివేయబడింది (end-of-life), ఇది కింద పేర్కొన్న 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 అని ఎర్రర్ వస్తే, plugin ఇన్‌స్టాల్ కాలేదని అర్థం. దీనిని ఇక్కడే సరిచేయండి, లేకపోతే తర్వాత గందరగోళానికి గురిచేసే సమస్యలు ఎదురవుతాయి.

Compose ఫైల్: సింగిల్-నోడ్ రెప్లికా సెట్‌గా MongoDB

చాలామంది ఇక్కడే తప్పు చేస్తారు, కాబట్టి దీన్ని జాగ్రత్తగా చదవండి. Rocket.Chat కొత్త సందేశాలను కనెక్ట్ అయిన క్లయింట్‌లకు నిజ సమయంలో పంపడానికి MongoDB change streams ను ఉపయోగిస్తుంది. ఈ change streams కేవలం రెప్లికా సెట్‌లో మాత్రమే అందుబాటులో ఉంటాయి. Rocket.Chat ను సాధారణ standalone mongod కి పాయింట్ చేస్తే, అది కనెక్ట్ అవుతుంది కానీ change stream ను తెరవలేక, నిరంతరం restart-loop లో పడిపోతుంది. దీనికి పరిష్కారం చాలా సులభం: మీరు ఒక సాధారణ MongoDB కంటైనర్‌ను రన్ చేస్తారు, కానీ దాన్ని --replSet తో ప్రారంభించి, ఒకే సభ్యుడు ఉన్న సెట్‌ను initialize చేస్తారు.

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

రెండు ఇమేజ్‌లకు ఖచ్చితమైన వెర్షన్ ట్యాగ్‌లను పిన్ చేయండి, ఉదాహరణకు mongo:8.0 మరియు ఇక్కడ ఉన్నట్లుగా ఒక స్పష్టమైన Rocket.Chat రిలీజ్ 8.5.1. ఎప్పుడూ :latest ని ఉపయోగించవద్దు, ఇది అప్రయత్నంగా జరిగే docker pull అప్‌డేట్‌లను, తిరిగి మార్చలేని అప్‌గ్రేడ్‌లుగా మారుస్తుంది. మీరు పిన్ చేసే ముందు ప్రస్తుత stable Rocket.Chat రిలీజ్ మరియు అది సపోర్ట్ చేసే MongoDB వెర్షన్‌లను తనిఖీ చేయండి. 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) బిల్డ్ అవునో కాదో తెలిపే lts ఫ్లాగ్ ఉంటుంది, ఇది మీరు నిరంతరం పర్యవేక్షించాల్సిన అవసరం లేని సర్వర్లకు ఉపయోగపడుతుంది. ప్రతి ప్రాజెక్ట్ వెర్షన్ ఉన్న ఇమేజ్‌ను ప్రచురించదు, అటువంటి సందర్భాల్లో మీరు సోర్స్ కోడ్ వద్ద పిన్ చేయాలి: openGym వర్కౌట్ ట్రాకర్‌ను self-hosting చేయడం అంటే మారుతున్న బ్రాంచ్‌ను అనుసరించకుండా, ఒక నిర్దిష్ట git ట్యాగ్‌ను చెక్-అవుట్ చేసి దాని నుండి బిల్డ్ చేయడం.

Replica set ను ప్రారంభించడం

Stack ను ప్రారంభించండి:

sudo docker compose up -d

Rocket.Chat వెంటనే క్రాష్ అవ్వడం మొదలవుతుంది మరియు Docker దానిని పదేపదే రీస్టార్ట్ చేస్తుంది. 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" ఆర్గ్యుమెంట్. మీరు మెంబర్స్ లిస్ట్ లేకుండా కేవలం rs.initiate() అని రన్ చేస్తే, MongoDB ఆ replica set ను కంటైనర్ యొక్క అంతర్గత హోస్ట్ నేమ్ (ఉదాహరణకు a1b2c3d4e5f6 వంటి ఒక random hash) తో ప్రకటిస్తుంది. Rocket.Chat తన సొంత కంటైనర్ నుండి కనెక్ట్ అయ్యేటప్పుడు ఆ పేరును రిజాల్వ్ చేయలేదు, దీనివల్ల MongoDB డ్రైవర్ DNS ఫెయిల్యూర్ చూపిస్తూ MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 అని లాగ్ చేస్తూ లూప్‌లో పడిపోతుంది. ఎల్లప్పుడూ మీ MONGO_URL కి సరిపోయే explicit సర్వీస్ నేమ్‌తోనే initiate చేయండి.

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

సెట్ ప్రైమరీగా మారిన తర్వాత, 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 పై వింటున్నట్లు (listening) అర్థం, ఇప్పుడు దానికి ముందు సరైన హోస్ట్‌నేమ్ మరియు TLS ను అమర్చాల్సిన సమయం ఆసన్నమైంది.

TLS వెనుక ఉంచండి

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

ముందుగా అప్లికేషన్‌కు proxy చేసే మరియు upgrade headers ను ఫార్వర్డ్ చేసే plain HTTP nginx సర్వర్ బ్లాక్‌తో ప్రారంభించండి. దీన్ని /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; మరియు సర్టిఫికేట్ లేని బ్లాక్ sudo nginx -t పరీక్షలో నెగ్గదు. Nginx ను reload చేయండి (sudo nginx -t && sudo systemctl reload nginx), ఆపై సర్టిఫికేట్ జారీ చేయండి. Ubuntu లో దీనికి అత్యంత సులభమైన మార్గం Certbot మరియు nginx తో Let's Encrypt TLS సర్టిఫికేట్లు: certbot --nginx పైన ఉన్న బ్లాక్‌ను ఉన్నచోటే మారుస్తుంది, listen 443 ssl; ను, ssl_certificate లైన్లను జోడిస్తుంది మరియు 80-to-443 ఆటోమేటిక్ రీడైరెక్ట్‌ను ఏర్పాటు చేస్తుంది, అలాగే ఇది సర్టిఫికేట్ రెన్యూవల్‌ను కూడా షెడ్యూల్ చేస్తుంది. మీరు ఇప్పటికే ఒకే proxy వెనుక అనేక కంటైనర్లను నడుపుతుంటే, అనేక Docker అప్లికేషన్ల కోసం ఆటోమేటిక్ TLS తో Traefik మరింత మెరుగైన ఎంపిక. rocketchat సర్వీస్‌కు router మరియు service లేబుల్స్‌ను జోడిస్తే, Traefik మీ కోసం సర్టిఫికేట్‌ను అభ్యర్థించి రెన్యూ చేస్తుంది, దీనికి nginx బ్లాక్ అవసరం ఉండదు. ఏ పద్ధతిని ఎంచుకున్నా, compose.yml లో ROOT_URL ను https://chat.example.com గా సెట్ చేసి, sudo docker compose up -d ను మళ్ళీ రన్ చేయండి, తద్వారా కంటైనర్ ఈ మార్పును గుర్తిస్తుంది. సర్వర్ పబ్లిక్ ఇంటర్నెట్ నుండి కాకుండా, మీ సొంత నెట్‌వర్క్ లోపల నుండి మాత్రమే అందుబాటులో ఉండాలంటే, దాని ముందు VPS పై self-hosted WireGuard VPN ను ఉంచి, proxy ని tunnel అడ్రస్‌కు bind చేయండి.

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

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

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

ఎవరికైనా అనుమతి ఇచ్చే ముందు భద్రపరచండి

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

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

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

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

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

ఆ ఒక్క gzipped ఆర్కైవ్ మీ మొత్తం వర్క్‌స్పేస్: ఇందులో యూజర్లు, ఛానెల్‌లు, సందేశాలు, సెట్టింగ్‌లు ఉంటాయి; ఒకవేళ మీరు అప్‌లోడ్‌లను GridFS లో ఉంచినట్లయితే, ఆ ఫైళ్లు కూడా ఇందులో ఉంటాయి. మీరు అప్‌లోడ్‌లను ఫైల్‌సిస్టమ్‌కు లేదా S3 కి తరలించినట్లయితే, ఆ స్టోర్‌ను విడిగా బ్యాకప్ చేయండి. కొత్త స్టాక్‌పై రీస్టోర్ చేయడానికి, ముందుగా replica set ను ఇనిషియలైజ్ చేసి, ఆపై ఇలా చేయండి:

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

ఈ ఆర్కైవ్‌ను సర్వర్ వెలుపల, ఆబ్జెక్ట్ స్టోరేజ్, మరొక సర్వర్ లేదా VPS విఫలమైనా బ్యాకప్ సురక్షితంగా ఉండే మరేదైనా చోట కాపీ చేయండి. ఈ డంప్ ప్రక్రియను ప్రతిరోజూ రాత్రి cron ద్వారా రన్ చేయండి. మీరు ఎప్పుడూ రీస్టోర్ చేసి చూడని బ్యాకప్ కేవలం ఒక ఆశ మాత్రమే, అది నిజమైన బ్యాకప్ కాదు; మీకు అవసరమైనప్పుడు ఇబ్బంది కలగకుండా, ఒకసారి తాత్కాలిక VPS పై రీస్టోర్ చేసి ప్రాక్టీస్ చేయండి.

అప్‌గ్రేడ్‌లు: ట్యాగ్‌లను పిన్ చేయడం, నోట్స్ చదవడం, MongoDB మ్యాట్రిక్స్‌ను పాటించడం

అప్‌గ్రేడ్‌లు సాఫీగా జరగడానికి రెండు నియమాలు పాటించాలి. మొదటిది, 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})'

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

వైఫల్య రీతులు, ఖచ్చితమైన స్ట్రింగ్‌లతో

docker compose up తర్వాత Rocket.Chat రీస్టార్ట్-లూప్‌లోకి వెళ్తుంది మరియు 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 బ్లాక్ 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 RAM ఉండాలని ప్లాన్ చేసుకోండి, బిజీగా ఉండే టీమ్ కోసం అయితే 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 వెనుక ఎలా ఉంచాలి?

TLS termination చేసే ఒక reverse proxy ని అదే VPS లో రన్ చేసి, దానిని 127.0.0.1:3000 కి ఫార్వర్డ్ చేయండి. కంటైనర్ యొక్క ROOT_URL ని మీ పబ్లిక్ https:// అడ్రస్‌కు సెట్ చేయండి. ప్రాక్సీ తప్పనిసరిగా WebSocket upgrade హెడర్లను ఫార్వర్డ్ చేయాలి, లేకపోతే లాగిన్ అవ్వదు. 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 ని ఒకసారికి ఒక మేజర్ వెర్షన్ చొప్పున అప్‌గ్రేడ్ చేయండి. ఇది బూట్ అయ్యేటప్పుడు మైగ్రేషన్లను రన్ చేస్తుంది మరియు మేజర్ వెర్షన్లను స్కిప్ చేయడానికి అనుమతించదు. పిన్ చేసిన ఇమేజ్ ట్యాగ్‌ను మార్చే ముందు ప్రతి రిలీజ్ నోట్స్‌ను చదవండి. మీ టార్గెట్ రిలీజ్ ఏ MongoDB వెర్షన్లకు మద్దతు ఇస్తుందో curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions ద్వారా తనిఖీ చేయండి. మీరు MongoDB ని అప్‌గ్రేడ్ చేసేటప్పుడు, ఒకసారికి ఒక మేజర్ వెర్షన్ చొప్పున పెంచండి మరియు ప్రతి అప్‌గ్రేడ్ తర్వాత confirm: true తో setFeatureCompatibilityVersion ని సెట్ చేయండి. ఎల్లప్పుడూ ముందుగా ఒక mongodump తీసుకోండి.