Docker Compose மூலம் Rocket.Chat-ஐ நிறுவுவது எப்படி?

நீங்கள் உருவாக்குவது

நீங்கள் முழுமையாகக் கட்டுப்படுத்தும் ஒரு தனிப்பட்ட குழு அரட்டை (team chat): Docker Compose மூலம் உங்கள் சொந்த VPS-ல் இயங்கும் Rocket.Chat, TLS மூலம் பாதுகாக்கப்படுகிறது. ஒவ்வொரு செய்தியும் MongoDB தரவுத்தளத்தில் சேமிக்கப்படுவதால், அதை நீங்கள் backup எடுத்து வேறு இடத்திற்கு மாற்ற முடியும். Rocket.Chat என்பது Slack மற்றும் Teams-க்கு மாற்றாக விளங்கும் முதிர்ச்சியடைந்த open-source மென்பொருள். இதில் channels, direct messages, threads, file sharing, மற்றும் voice/video அழைப்புகள் என அனைத்தும் உங்கள் கட்டுப்பாட்டில் உள்ள வன்பொருளில் இயங்கும். இது மட்டுமே சிறந்த விருப்பம் என்று கூற முடியாது; நீங்கள் இன்னும் முடிவெடுக்கவில்லை என்றால், Mattermost, Rocket.Chat, Synapse மற்றும் Zulip ஒப்பீடு பகுதியில் RAM, database, mobile push, SSO மற்றும் upgrades போன்ற முக்கியமான அம்சங்களை ஒப்பிட்டுப் பார்க்கலாம். இந்த application சில நிமிடங்களில் இயங்கக்கூடிய ஒரு single container ஆகும். இதில் ஏற்படும் சிக்கல்கள் பெரும்பாலும் அதனுடன் இணைந்த தரவுத்தளத்திலேயே இருக்கும். எனவே, இந்த வழிகாட்டியின் பெரும்பகுதி MongoDB-ஐப் பற்றியது. குறிப்பாக, பலரை ஆச்சரியப்படுத்தும் ஒரு தேவை: Rocket.Chat ஒரு standalone MongoDB-ல் இயங்காது. அதற்கு ஒரு replica set தேவை; அந்த "set" ஒரே ஒரு node-ஆக இருந்தாலும் அது அவசியம்.

முன்நிபந்தனைகள் மற்றும் யாரும் சொல்லாத RAM கணக்கீடு

server-ன் அளவை உண்மையாகத் தீர்மானிக்கவும். ஒரு சிறிய குழுவிற்குத் தேவையான குறைந்தபட்ச அளவு 2 vCPU மற்றும் 4 GB RAM ஆகும். Rocket.Chat-ன் Node.js process-க்கு மட்டும் சுமார் 1 முதல் 1.5 GB RAM தேவைப்படும். MongoDB-ன் WiredTiger cache, (மொத்த RAM - 1 GB)-ல் 50% அல்லது 0.256 GB - இதில் எது அதிகமோ அதை இயல்பாக எடுத்துக்கொள்ளும். இந்த இயல்புநிலை அமைப்பு, mongod அந்த machine-ல் மட்டுமே இயங்குவதாகக் கருதுகிறது. இது மொத்த RAM-ஐ அடிப்படையாகக் கொண்டது; Node ஏற்கனவே பயன்படுத்தும் RAM-ஐ இது கணக்கில் கொள்வதில்லை. எனவே, 4 GB RAM கொண்ட machine-ல் இது 1.5 GB-யையும், 2 GB RAM கொண்ட machine-ல் சுமார் 0.5 GB-யையும் எடுத்துக்கொள்ளும். இதனுடன் Node-ன் heap, cache-க்கு வெளியே mongod பயன்படுத்தும் நினைவகம் மற்றும் operating system-ன் தேவை ஆகியவையும் சேரும். 2 GB VPS-ல் இவை தொடக்கத்தில் இயங்கினாலும், உண்மையான traffic வரும்போது மோதிக்கொள்ளும்: MongoDB அதன் cache-ஐ அதிகரிக்கும், Node அதன் heap-ஐ அதிகரிக்கும், kernel-ல் பக்கங்கள் (pages) தீர்ந்துவிடும். அப்போது out-of-memory killer, மிகப்பெரிய process-ஐ, அதாவது பெரும்பாலும் mongod-ஐ, நிறுத்திவிடும். container Killed என்ற பிழையைக் காட்டும், Docker அதை restart செய்யும். இதனால், சுமையைச் சமாளிக்க வேண்டிய chat server அடிக்கடி செயலிழக்கும். 2 பேர் மட்டும் சோதித்துப் பார்க்க 2 GB போதுமானது; ஆனால் இது ஒரு குழுவிற்கான server அல்ல. 4 GB-ல் தொடங்கவும்; டஜன் கணக்கான பயனர்கள், video calls அல்லது வளரும் upload history இருந்தால் 8 GB வழங்கவும். server-ல் இயங்கும் பிற சேவைகளுக்கும் RAM ஒதுக்க வேண்டும்: ஒரே VPS-ல் Notion போன்ற AFFiNE workspace-ஐ அமைத்தால், அது மேலும் நான்கு container-களைச் சேர்க்கும். அவற்றுக்கான RAM, Rocket.Chat-ன் RAM-லிருந்து அல்லாமல் கூடுதலாக இருக்க வேண்டும்.

தொடங்குவதற்கு முன் மூன்று விஷயங்கள் தயாராக இருக்க வேண்டும். VPS-ன் public IP-ஐக் குறிக்கும் A record கொண்ட ஒரு domain name அவசியம். Rocket.Chat-ன் real-time வசதிகள் மற்றும் mobile clients-க்கு வெறும் IP போதாது, நிலையான hostname தேவை. server firewall மற்றும் உங்கள் provider-ன் network firewall ஆகிய இரண்டிலும் 80 மற்றும் 443 ports திறந்திருக்க வேண்டும் (பெரும்பாலான control panel-களில் இது தனி அமைப்பாக இருக்கும்). மேலும், root அல்லது sudo வசதி கொண்ட புதிய Ubuntu 24.04 KVM VPS தேவை. chat server-ஐ முதலில் நிறுவுவது சரியானதா என்று நீங்கள் இன்னும் முடிவெடுக்கவில்லை என்றால், 2026-ல் எவற்றை self-host செய்வது என்பதற்கான வழிகாட்டி இதில் உள்ள சாதக பாதகங்களை விளக்குகிறது.

Docker engine மற்றும் Compose plugin-ஐ நிறுவுதல்

Ubuntu வழங்கும் docker.io தொகுப்பையோ அல்லது பழைய docker-compose Python binary-யையோ பயன்படுத்தாமல், Docker-ன் சொந்த apt repository-ஐப் பயன்படுத்தவும். நவீன Compose என்பது docker compose என்று அழைக்கப்படும் ஒரு Docker plugin ஆகும்; இதில் இடையில் இடைவெளி (space) இருக்க வேண்டும், hyphen இருக்கக்கூடாது. பழைய docker-compose v1 பதிப்பு காலாவதியாகிவிட்டது; அது கீழே உள்ள 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 version

docker compose version ஒரு version வரியை அச்சிடுவதுதான் சரியான சரிபார்ப்பு முறையாகும். தற்போதைய releases Docker Compose version v5.x என்று அச்சிடும் (2026-10-10 நிலவரப்படி, 2026 அக்டோபர் 2 அன்று வெளியான v5.6.0 சமீபத்திய பதிப்பாகும்); பழைய நிறுவல்கள் இன்னும் v2.x என்று அச்சிடலாம், Docker இரண்டையும் ஆதரிக்கிறது. Docker, Compose v5-ஐ v2-க்கு இணையான செயல்பாடுகளைக் கொண்டதாகக் குறிப்பிடுகிறது; பழைய v2 மற்றும் v3 compose file format-களுடன் குழப்பத்தைத் தவிர்க்கவே இது v5 என்று பெயரிடப்பட்டுள்ளது, எனவே இந்த வழிகாட்டிக்கு இரண்டில் எது இருந்தாலும் சரிதான். docker: 'compose' is not a docker command என்று பிழை ஏற்பட்டால், plugin நிறுவப்படவில்லை என்று அர்த்தம்; இது பின்னர் குழப்பமான தோல்விகளுக்கு வழிவகுக்கும் என்பதால், இங்கேயே அதைச் சரிசெய்யவும்.

Compose கோப்பு: ஒற்றை-முனை (single-node) replica set-ஆக MongoDB

இதுவே பலரும் தவறு செய்யும் பகுதி, எனவே கவனமாகப் படிக்கவும். Rocket.Chat புதிய செய்திகளை நிகழ்நேரத்தில் (real time) இணைக்கப்பட்ட clients-க்கு அனுப்ப MongoDB change streams-ஐப் பயன்படுத்துகிறது. இந்த change streams ஒரு replica set-ல் மட்டுமே கிடைக்கும். Rocket.Chat-ஐ ஒரு சாதாரண standalone mongod-உடன் இணைத்தால், அது இணையும், ஆனால் change stream-ஐத் திறக்க முடியாமல் தோல்வியடைந்து, மீண்டும் மீண்டும் restart ஆகிக்கொண்டே இருக்கும். இதற்குத் தீர்வு கடினமானது அல்ல: நீங்கள் ஒரு சாதாரண MongoDB container-ஐ இயக்குகிறீர்கள், ஆனால் அதை --replSet-உடன் தொடங்கி, பின்னர் ஒரு உறுப்பினர் கொண்ட 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-க்கு அல்ல. செயலி (app) தானாக TLS-ஐக் கொண்டிருக்கவில்லை, எனவே அதே server-ல் உள்ள reverse proxy மட்டுமே அதை அணுக வேண்டும்; அதை எல்லா interface-களிலும் bind செய்தால், plaintext login பக்கம் நேரடியாகப் பொது இணையத்தில் (public internet) தெரிந்துவிடும். MongoDB ஹோஸ்டுக்கு (host) வெளியிடப்படவில்லை; அது Compose-ன் உள் நெட்வொர்க்கில் mongodb என்ற பெயரில் மட்டுமே அணுகக்கூடியது. இதுவே MONGO_URL பயன்படுத்தும் hostname ஆகும். MONGO_URL என்பது ?replicaSet=rs0-ஐக் கொண்டுள்ளது, இது set-ன் பெயரைத் தெளிவாகக் குறிப்பிடுகிறது; சீரான செயல்பாட்டிற்காக இதை அமைக்குமாறு MongoDB பரிந்துரைக்கிறது. இதைத் தவிர்க்கவில்லை என்றால் எதுவும் பாதிப்படையாது: directConnection இயல்பாக false-ஐக் கொண்டிருக்கும், எனவே driver replica set-ஐக் கண்டறிந்து primary-க்குச் செயல்பாடுகளை அனுப்பும். Rocket.Chat-ஆல் தீர்க்கக்கூடிய (resolve) hostname-ஐக் கொண்டு set தொடங்கப்பட்டால் இது சாத்தியம், அதை அடுத்த பகுதி கவனித்துக்கொள்ளும். MONGO_OPLOG_URL என்பது oplog இருக்கும் local தரவுத்தளத்தைக் குறிக்கிறது; நவீன Rocket.Chat change streams-ஐ விரும்புகிறது, ஆனால் இதை அமைப்பது பாதிப்பை ஏற்படுத்தாது மற்றும் பழைய code paths-ஐச் சரியாக இயங்க வைக்கும். depends_on என்பது condition: service_healthy-ஐப் பயன்படுத்துகிறது, எனவே MongoDB ஒரு ping-க்கு பதிலளிக்கும் வரை Compose காத்திருக்கும், அதன் பின்னரே Rocket.Chat தொடங்கும்; இதற்காகவே healthcheck உள்ளது.

இரண்டு images-க்கும் சரியான version tags-ஐக் குறிக்கவும், அதாவது mongo:8.0 மற்றும் 8.5.1 போன்ற ஒரு குறிப்பிட்ட Rocket.Chat release. ஒருபோதும் :latest-ஐப் பயன்படுத்த வேண்டாம், இது கவனிக்கப்படாத docker pull-ஐ எதிர்பாராத, மாற்ற முடியாத (un-migratable) மேம்படுத்தலாக மாற்றிவிடும். நீங்கள் version-ஐக் குறிக்கும் முன், தற்போதைய நிலையான Rocket.Chat release மற்றும் அது ஆதரிக்கும் MongoDB பதிப்புகளைச் சரிபார்க்கவும். Rocket.Chat ஒவ்வொரு release-க்கும் இயந்திரத்தால் படிக்கக்கூடிய தகவல் ஆவணத்தை வெளியிடுகிறது: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' என்பது 8.5.1-க்கு compatibleMongoVersions: ["8.0"]-ஐத் தருகிறது, எனவே mongo:8.0 மட்டுமே ஆதரிக்கப்படும் engine ஆகும். மேலும், ஒரு release நீண்ட கால ஆதரவு (long-term-support) கொண்டதா என்பதைத் தெரிவிக்கும் lts flag-ஐயும் இது வழங்குகிறது, இது நீங்கள் அடிக்கடி கவனிக்க விரும்பாத server-களுக்குப் பயனுள்ளதாக இருக்கும். எல்லா திட்டங்களும் version செய்யப்பட்ட image-ஐ வெளியிடுவதில்லை, அத்தகைய சூழலில், நீங்கள் source-ஐக் குறிக்க வேண்டும்: openGym workout tracker-ஐ நீங்களே ஹோஸ்ட் செய்தல் என்பது ஒரு குறிப்பிட்ட git tag-ஐ checkout செய்து, மாறும் branch-ஐப் பின்பற்றுவதற்குப் பதிலாக அதிலிருந்து build செய்வதைக் குறிக்கும்.

Replica set-ஐத் தொடங்குதல்

Stack-ஐ இயக்கவும்:

sudo docker compose up -d

Rocket.Chat உடனடியாக crash ஆகும், Docker அதைத் தொடர்ந்து restart செய்யும். Replica set இன்னும் உருவாக்கப்படாததால் இது எதிர்பார்க்கப்படும் ஒன்றுதான். அதை ஒருமுறை கைமுறையாக உருவாக்கவும்:

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

சரியான முடிவு { ok: 1 } ஆகும். சில நொடிகளில் அந்த ஒற்றை node தன்னைத்தானே primary-ஆகத் தேர்ந்தெடுத்துக்கொள்ளும்; இதை உறுதிப்படுத்த:

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

நீங்கள் PRIMARY என்பதைப் பார்க்க வேண்டும். இந்தப் பக்கத்திலேயே மிக முக்கியமான விவரம் host: "mongodb:27017" argument ஆகும். நீங்கள் members பட்டியல் இல்லாமல் வெறும் rs.initiate()-ஐ இயக்கினால், MongoDB அந்த replica set-ஐ container-ன் internal hostname-ல் விளம்பரப்படுத்தும், இது a1b2c3d4e5f6 போன்ற ஒரு random hash ஆக இருக்கும். Rocket.Chat அதன் சொந்த container-லிருந்து இணையும்போது, அந்தப் பெயரை resolve செய்ய முடியாது. இதனால் MongoDB driver DNS பிழையைச் சந்தித்து, MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 என்று log செய்துகொண்டே இருக்கும். எப்போதும் உங்கள் MONGO_URL-க்கு பொருந்தும் explicit service name-ஐக் கொண்டே initiate செய்யவும்.

முதல் முறை தொடங்குதல்: செயல்பாட்டைக் கண்காணித்தல்

Replica set முதன்மையாக அமைக்கப்பட்டவுடன், 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
+--------------------------------------------+

முதல் முறை தொடங்குவது மெதுவாக இருக்கும், ஏனெனில் application database migrations-ஐ இயக்கி indexes-ஐ உருவாக்கும். எனவே, கவலைப்படுவதற்கு முன் ஒன்று அல்லது இரண்டு நிமிடங்கள் காத்திருக்கவும். ஒருவேளை log-ல் MongoServerSelectionError: Server selection timed out after 30000 ms மற்றும் அதன் வகை ReplicaSetNoPrimary எனத் தொடர்ந்து வந்தால், replica set இன்னும் தொடங்கப்படவில்லை என்று அர்த்தம். ஒருவேளை ஏதேனும் random hash-உடன் getaddrinfo ENOTFOUND எனத் தொடர்ந்து வந்தால், அது தவறான host-உடன் தொடங்கப்பட்டுள்ளது என்று அர்த்தம். எதுவாக இருந்தாலும், முந்தைய நிலைக்குச் சென்று சரிபார்க்கவும். SERVER RUNNING என்று நீங்கள் பார்த்தவுடன், Rocket.Chat 127.0.0.1:3000-ல் listening நிலையில் இருக்கும். இப்போது அதற்கு முன்னால் ஒரு சரியான hostname மற்றும் TLS-ஐ அமைக்க வேண்டிய நேரம் இது.

TLS-க்கு பின்னால் கொண்டு செல்லுதல்

Rocket.Chat-ஐ ஒருபோதும் plain HTTP-ல் வெளிப்படுத்த வேண்டாம். http:// மூலம் ஒருமுறை உள்நுழைந்தால், அந்தப் பாதையில் இருக்கும் எவருக்கும் உங்கள் admin கடவுச்சொல்லை நீங்கள் வழங்கியதாகிவிடும். அதே server-ல் ஒரு reverse proxy மூலம் TLS termination செய்து, அதை 127.0.0.1:3000-க்கு forward செய்யவும். இதில் இரண்டு விஷயங்கள் முக்கியம்: proxy-ஆனது WebSocket upgrade headers-ஐ forward செய்ய வேண்டும், ஏனெனில் Rocket.Chat நிகழ்நேரத்தில் (real-time) இயங்கக்கூடியது, இவை இல்லையெனில் அது இயங்காது. மேலும், container-ன் ROOT_URL ஆனது பயனர்கள் உள்ளிடும் public HTTPS முகவரியுடன் சரியாகப் பொருந்த வேண்டும்.

முதலில், application-க்கு 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-ஐ 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 வரிகள் மற்றும் தானியங்கி 80-to-443 redirect ஆகியவற்றைச் சேர்க்கும், மேலும் இது தானாகவே புதுப்பித்தலையும் (renewal) திட்டமிடும். நீங்கள் ஏற்கனவே ஒரு proxy-க்கு பின்னால் பல containers-ஐ இயக்குகிறீர்கள் என்றால், பல Docker apps-களுக்கு தானியங்கி TLS உடன் Traefik என்பது மிகவும் நேர்த்தியான விருப்பமாகும். rocketchat service-ல் router மற்றும் service labels-ஐச் சேர்த்தால் போதும், Traefik உங்களுக்காக certificate-ஐப் பெற்று புதுப்பிக்கும், இதற்கு nginx block தேவையில்லை. எதுவாக இருந்தாலும், compose.yml-ல் ROOT_URL-ஐ https://chat.example.com என அமைத்து, sudo docker compose up -d-ஐ மீண்டும் இயக்கவும், அப்போதுதான் container இந்த மாற்றத்தை ஏற்கும். பொது இணையத்திற்குப் பதிலாக உங்கள் சொந்த network-க்குள் இருந்து மட்டுமே server-ஐ அணுக விரும்பினால், அதற்கு முன்னால் VPS-ல் self-hosted WireGuard VPN-ஐ அமைத்து, proxy-ஐ அந்த tunnel முகவரியுடன் இணைக்கவும்.

முதல்முறை அமைப்பதற்கான வழிகாட்டி (Setup wizard)

https://chat.example.com முகவரிக்குச் செல்லவும்; Rocket.Chat ஒரு சிறிய வழிகாட்டி மூலம் உங்களை வழிநடத்தும். முதலில், admin account விவரங்கள்: உண்மையான பெயர், பயனர் பெயர் (username), மின்னஞ்சல் மற்றும் வலுவான கடவுச்சொல். இதுவே இருக்கும் ஒரே கணக்கு என்பதால், இதைத் தொலைத்துவிடாதீர்கள். அடுத்து, organisation and server info: நிறுவனத்தின் பெயர், துறை, அளவு, தளத்தின் பெயர் மற்றும் இயல்புநிலை மொழி ஆகியவற்றை உள்ளிடவும். இவை மேலோட்டமானவை, எனவே பூர்த்தி செய்துவிட்டு அடுத்த நிலைக்குச் செல்லவும். அதன் பிறகு மிக முக்கியமான தேர்வு: Rocket.Chat Cloud-உடன் workspace-ஐப் பதிவு செய்வது அல்லது அதை standalone நிலையில் வைத்திருப்பது.

பதிவு செய்வது, Rocket.Chat-ன் gateway வழியாக mobile push notifications-ஐப் பெறவும், add-on marketplace-ஐப் பயன்படுத்தவும் வழிவகை செய்யும். ஆனால், இதற்குப் பதிலாக Rocket.Chat-ன் cloud-உடன் ஒரு கட்டுப்பாட்டுத் தொடர்பு (control-plane relationship) ஏற்படும். மேலும், gateway வழியாக அனுப்பப்படும் push notifications உங்கள் workspace-ன் மாதாந்திர வரம்பில் கணக்கிடப்படும். Standalone முறை, server-ஐ முழுமையாகத் தனிப்பட்டதாகவும், பிற சார்புகள் (dependencies) இல்லாமலும் வைத்திருக்கும். ஆனால், அதிகாரப்பூர்வ iOS மற்றும் Android செயலிகளில் push notifications கிடைக்காது. ஏனெனில், அந்தச் செயலிகள் Rocket.Chat-ன் cloud gateway-உடன் மட்டுமே இயங்கும் என்று அதன் ஆவணங்கள் கூறுகின்றன; பதிவு செய்யப்படாத workspace-ல் அந்த gateway இயங்காது. இதற்கு மாற்றாக, உங்கள் சொந்த white-labeled mobile app-ஐ உருவாக்கலாம்: Push அமைப்புகளில் gateway-ஐ அணைத்துவிட்டு, உங்கள் சொந்த APNs certificates மற்றும் Firebase Cloud Messaging விவரங்களை உள்ளிடவும். பிறகு, அதிகாரப்பூர்வ செயலிக்குப் பதிலாக உங்கள் பயனர்களை உங்கள் சொந்த செயலியை நிறுவச் சொல்லவும். தனியுரிமை (privacy) மட்டுமே முக்கியம் மற்றும் உங்கள் பயனர்கள் web app-ஐ மட்டுமே பயன்படுத்துவார்கள் என்றால், அல்லது உங்கள் சொந்த mobile app-ஐ வெளியிடத் தயாராக இருந்தால், standalone முறையைத் தேர்ந்தெடுக்கவும். அதிகாரப்பூர்வ செயலிகளில் push notifications கட்டாயம் தேவை என்றால், பதிவு செய்யும் முறையைத் தேர்ந்தெடுக்கவும். இதை நீங்கள் பின்னர் Admin பகுதியில் மாற்றிக்கொள்ளலாம்.

எவரையும் அனுமதிக்கும் முன் பாதுகாப்பை உறுதிப்படுத்துங்கள்

Rocket.Chat இயல்பாகவே open registration on என்ற அமைப்பில் வெளிவருகிறது. இதில் Registration Form என்பது Public என அமைக்கப்பட்டிருக்கும். எனவே, URL-ஐக் கண்டறியும் எவரும் கணக்கை உருவாக்க முடியும். பொதுவான hostname-ல் இது ஒரு திறந்த கதவு போன்றது. Admin → Settings → Accounts → Registration பகுதிக்குச் சென்று, Registration Form என்பதை Disabled என மாற்றவும். இதன் மூலம் நீங்கள் கைமுறையாகவோ அல்லது அழைப்பு இணைப்பு (invite link) மூலமாகவோ கணக்குகளை உருவாக்கலாம், அல்லது Secret URL என அமைக்கலாம். அதே இடத்தில், உங்களுக்குத் தேவைப்பட்டால் ஒழிய Allow Anonymous Read மற்றும் Allow Anonymous Write ஆகியவற்றை முடக்கவும். ஒவ்வொரு கணக்கையும் கைமுறையாக உருவாக்குவது கடினமாகத் தோன்றினால், உங்கள் குழு பயன்படுத்தும் பிற சேவைகளுடன் ஒருங்கிணைக்க, Rocket.Chat-ன் OAuth login-ஐ self-hosted Authentik SSO server-க்கு மாற்றவும். இதன் மூலம் புதிய உறுப்பினர்கள் மற்றும் வெளியேறுபவர்களை ஒரே இடத்தில் நிர்வகிக்க முடியும்.

கோப்பு பதிவேற்றங்கள் (uploads) எங்கு சேமிக்கப்பட வேண்டும் என்பதையும் முடிவு செய்யுங்கள். இயல்பான File Upload சேமிப்பகம் GridFS ஆகும். இது ஒவ்வொரு படம் மற்றும் இணைப்பையும் MongoDB-க்குள்ளேயே சேமிக்கும். இது எளிமையானது, ஆனால் மக்கள் ஸ்கிரீன்ஷாட்களைப் பகிரும்போது உங்கள் தரவுத்தளமும், நீங்கள் எடுக்கும் ஒவ்வொரு mongodump-ம் கட்டுப்பாடின்றி வளரும். Admin → Settings → File Upload பகுதிக்குச் சென்று, சேமிப்பகத்தை local filesystem அல்லது S3-compatible bucket-க்கு மாற்றலாம். மேலும், கோப்பின் அதிகபட்ச அளவை (maximum file size) நிர்ணயிக்கலாம். உங்கள் குழு அவ்வப்போது பகிரப்படும் ஸ்கிரீன்ஷாட்களைத் தாண்டி முழு புகைப்படத் தொகுப்புகளையும் பரிமாறிக் கொண்டால், அவற்றை chat தரவுத்தளத்தில் சேமிக்காமல் பிரத்யேக புகைப்படச் சேவையகத்தில் சேமிப்பது சிறந்தது. PhotoPrism மற்றும் Immich ஒப்பீடு மூலம், ஒவ்வொன்றிற்கும் தேவைப்படும் RAM மற்றும் backup கட்டளைகளை ஒப்பிட்டுப் பார்த்து முடிவெடுக்கலாம். சிறிய குழுக்களுக்கு GridFS போதுமானது; ஆனால் காலப்போக்கில் உங்கள் backup கோப்புகள் பெரிதாகும் என்பதை நினைவில் கொள்ளுங்கள்.

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

அந்த ஒற்றை gzipped archive-தான் உங்கள் முழு workspace ஆகும்: பயனர்கள், channels, செய்திகள், அமைப்புகள் மற்றும் நீங்கள் uploads-ஐ GridFS-ல் வைத்திருந்தால், அந்த கோப்புகளும் இதில் அடங்கும். நீங்கள் uploads-ஐ filesystem அல்லது S3-க்கு மாற்றியிருந்தால், அந்த சேமிப்பகத்தை தனித்தனியாக காப்புப்பிரதி எடுக்கவும். புதிய stack-ல் restore செய்ய, முதலில் replica set-ஐ initialize செய்துவிட்டு, பின்வருவனவற்றைச் செய்யவும்:

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

இந்த archive-ஐ server-க்கு வெளியே, object storage, மற்றொரு server அல்லது VPS செயலிழந்தாலும் காப்புப்பிரதி அழியாதவாறு வேறு ஏதேனும் ஓரிடத்தில் நகலெடுக்கவும். cron மூலம் தினமும் இரவு இந்த dump-ஐ இயக்கவும். நீங்கள் ஒருமுறை கூட restore செய்து பார்க்காத காப்புப்பிரதி என்பது வெறும் நம்பிக்கை மட்டுமே, அது உண்மையான காப்புப்பிரதி அல்ல. தேவைப்படும்போது சிக்கல் வராமல் இருக்க, ஒரு தற்காலிக VPS-ல் restore செய்து பயிற்சி செய்யவும்.

மேம்படுத்தல்கள்: tags-ஐ pin செய்தல், குறிப்புகளை வாசித்தல், MongoDB matrix-ஐ பின்பற்றுதல்

மேம்படுத்தல்களைச் சிக்கலின்றிச் செய்ய இரண்டு விதிகள் உள்ளன. முதலாவதாக, Rocket.Chat-ஐ ஒரு நேரத்தில் ஒரு major version வீதம் மேம்படுத்தவும். இது தொடங்கும்போதே schema migrations-ஐ இயக்கும். Rocket.Chat-ன் மேம்படுத்தல் ஆவணங்கள், major versions-ஐத் தவிர்க்காமல் வரிசையாக மேம்படுத்த அறிவுறுத்துகின்றன; இல்லையெனில் கடுமையான இணக்கத்தன்மை (compatibility) சிக்கல்கள் ஏற்படலாம். மென்பொருள் உங்களைத் தடுக்கும் என்று நம்ப வேண்டாம்: 6.x-லிருந்து நேரடியாக 8.x-க்கு மாறுவது பாதுகாப்பாக மறுக்கப்படும் என்று எந்த ஆவணமும் கூறவில்லை. பாதியிலேயே தோல்வியடையும் migration, lock-ஐ அப்படியே விட்டுவிடும், அதை நீங்களே சரிசெய்ய வேண்டியிருக்கும். Image tag-ஐ அடுத்த major version-ன் சமீபத்திய release-க்கு மாற்றி, அதில் உள்ள breaking changes குறித்த குறிப்புகளை வாசித்து, docker compose up -d-ஐ இயக்கி, logs-ல் migration முடிவடையும் வரை காத்திருந்து பின் அடுத்த கட்டத்திற்குச் செல்லவும். இரண்டாவதாக, MongoDB support matrix-ஐப் பின்பற்றவும். ஒவ்வொரு Rocket.Chat release-ம் குறிப்பிட்ட MongoDB பதிப்புகளை மட்டுமே ஆதரிக்கும், எவை என்பதை curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions மூலம் அறியலாம். MongoDB-ஐ மேம்படுத்தும்போது (உதாரணமாக 7.0-லிருந்து 8.0-க்கு), ஒரு நேரத்தில் ஒரு major version வீதம் உயர்த்தி, ஒவ்வொரு மாற்றத்திற்குப் பிறகும் feature-compatibility version-ஐ அமைக்கவும். MongoDB 8.0-ல் இந்த கட்டளைக்கு confirm: true கட்டாயம் தேவை, இல்லையெனில் உறுதிப்படுத்தல் flag-ஐச் சேர்த்து மீண்டும் இயக்கச் சொல்லி அது மறுத்துவிடும்:

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

ஒவ்வொரு மேம்படுத்தலுக்கு முன்பும் mongodump எடுக்கவும். இதுவே முழுமையான காப்பீட்டுத் திட்டமாகும்.

தோல்வி முறைகள் மற்றும் துல்லியமான சரங்கள் (strings)

docker compose up-க்கு பிறகு Rocket.Chat மீண்டும் மீண்டும் restart ஆகிறது, மேலும் docker compose logs rocketchat ஒரு MongoServerSelectionError-ஆல் நிரம்புகிறது. MongoDB இயங்கிக்கொண்டிருக்கிறது, ஆனால் driver-ஆல் primary-ஐ தேர்ந்தெடுக்க முடியவில்லை. காட்டப்படும் துல்லியமான சரம் நீங்கள் செய்த தவறை உணர்த்தும். Server selection timed out after 30000 ms உடன் topology வகை ReplicaSetNoPrimary என்று இருந்தால், நீங்கள் rs.initiate()-ஐ இயக்கவில்லை என்று அர்த்தம்; அந்த set-க்கு இன்னும் configuration இல்லை. getaddrinfo ENOTFOUND-ஐத் தொடர்ந்து ஒரு random hash இருந்தால், நீங்கள் முறையான host: "mongodb:27017" இல்லாமல் initiate செய்துள்ளீர்கள் என்று அர்த்தம்; இதனால் MongoDB தீர்க்க முடியாத container hostname-ஐ விளம்பரப்படுத்தியுள்ளது. sudo docker compose exec mongodb mongosh --eval 'rs.status()' மூலம் கண்டறியவும்: அது MongoServerError: no replset config has been received எனப் பிழையைக் காட்டினால், set-ஐ initiate செய்யவும்; ஒரு member-ன் name ஒரு random hash-ஆக இருந்தால், service பெயரைப் பயன்படுத்தி மீண்டும் initiate செய்யவும்.

Web UI ஏற்றப்படுகிறது, ஆனால் login சுழன்று கொண்டே இருக்கிறது, முடிவடைவதில்லை. Browser console-ஐத் திறந்தால் WebSocket connection to 'wss://chat.example.com/websocket' failed-ஐக் காண்பீர்கள். இது பெரும்பாலும் ROOT_URL பொருந்தாமை அல்லது upgrade headers-ஐ அனுப்பாத proxy காரணமாகவே நிகழ்கிறது. ROOT_URL என்பது https:// உள்ளிட்ட துல்லியமான public முகவரிக்குச் சமமாக இருப்பதை உறுதி செய்யவும். மேலும், உங்கள் 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. server-ல் RAM தீர்ந்துவிட்டது. இதற்கு நிரந்தரத் தீர்வு அதிக RAM கொண்ட VPS-க்கு மாறுவதுதான், குறைந்தபட்சம் 4 GB தேவை. தற்காலிகத் தீர்வாக swap-ஐச் சேர்க்கவும் மற்றும் MongoDB-ன் cache-ஐ அதன் command-ல் --wiredTigerCacheSizeGB கொண்டு கட்டுப்படுத்தவும். இதை default அளவை விடக் குறைவாக அமைக்கவும். உதாரணமாக, 4 GB box-ல் 1 (default 1.5) அல்லது 2 GB box-ல் 0.3 (default சுமார் 0.5) என அமைக்கலாம். ஆனால், அதிக சுமை இருக்கும்போது 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 பிழையுடன் தோல்வியடைகிறது. ஏதோ ஒன்று ஏற்கனவே port 3000-ஐப் பயன்படுத்திக்கொண்டிருக்கிறது. பெரும்பாலும் இது சரியாக நிறுத்தப்படாத முந்தைய Rocket.Chat container அல்லது வேறொரு application-ஆக இருக்கலாம். sudo ss -ltnp | grep :3000 மூலம் அதைக் கண்டறிந்து, அந்த process அல்லது container-ஐ நிறுத்தவும். அல்லது mapping-ன் host பகுதியை 127.0.0.1:3001:3000 என மாற்றி, உங்கள் proxy-ன் proxy_pass-ஐ அதற்கேற்ப புதுப்பிக்கவும்.

FAQ

Rocket.Chat-க்கு MongoDB replica set உண்மையிலேயே தேவையா?

ஆம், ஒரே ஒரு database node கொண்ட server-க்கும் இது அவசியம். Rocket.Chat நிகழ்நேரத்தில் செய்திகளை அனுப்ப MongoDB change streams-ஐப் பயன்படுத்துகிறது. இந்த change streams வசதி replica set-ல் மட்டுமே கிடைக்கும்; standalone mongod-ஆல் இதைச் செயல்படுத்த முடியாது. இதற்குப் பல இயந்திரங்கள் தேவையில்லை; --replSet rs0 மூலம் ஒரு MongoDB container-ஐத் தொடங்கி, rs.initiate() கட்டளை மூலம் ஒரே ஒரு member கொண்ட set-ஐ உருவாக்கினால் போதும். இந்த நிலையைத் தவிர்த்தால், driver-ஆல் primary node-ஐக் கண்டறிய முடியாது. இதனால் Rocket.Chat MongoServerSelectionError: Server selection timed out பிழையுடன் மீண்டும் மீண்டும் restart ஆகிக்கொண்டே இருக்கும், boot ஆகாது.

சுய-விருப்பில் (self-hosted) இயங்கும் Rocket.Chat-க்கு எவ்வளவு RAM தேவை?

குறைந்தபட்சம் 4 GB RAM-ஐத் திட்டமிடுங்கள்; அதிகப் பயன்பாடுள்ள குழுக்களுக்கு 8 GB தேவைப்படும். Rocket.Chat-ன் Node process சுமார் 1 முதல் 1.5 GB வரை பயன்படுத்தும். MongoDB-ன் இயல்பான WiredTiger cache, (மொத்த RAM - 1 GB)-ல் பாதியாக இருக்கும்; இது அந்த server-ல் வேறு எந்தப் பணியும் நடக்காதது போலக் கணக்கிடப்படும். 2 GB RAM கொண்ட server-ல், இந்த cache, Node-ன் heap மற்றும் mongod-ன் பயன்பாடு ஆகியவை ஒன்றோடொன்று மோதிக்கொள்ளும். இதனால், ஏதேனும் சுமை ஏற்படும்போது out-of-memory killer, mongod-ஐ நிறுத்திவிடும்; logs-ல் Killed மற்றும் exit code 137 ஆகியவற்றைக் காணலாம். 2 GB என்பது சில சோதனைப் பயனர்களுடன் மென்பொருளைச் சோதிக்க மட்டுமே போதுமானது.

Rocket.Chat-ஐ HTTPS-க்கு பின்னால் எவ்வாறு அமைப்பது?

அதே VPS-ல் ஒரு reverse proxy-ஐ இயக்கி, TLS termination செய்து, அதை 127.0.0.1:3000-க்கு forward செய்யவும். container-ன் ROOT_URL-ஐ உங்கள் பொதுவான https:// முகவரிக்கு அமைக்கவும். proxy, WebSocket upgrade headers-ஐ forward செய்ய வேண்டும், இல்லையெனில் login செயல்முறை முடங்கிவிடும். ஒரே ஒரு application-க்கு Certbot உடன் nginx பயன்படுத்துவது எளிது; பல container-களை ஒரே proxy-க்கு பின்னால் இயக்கி, தானியங்கி certificate மேலாண்மை தேவைப்பட்டால் Traefik சிறந்த தேர்வாகும்.

சுய-விருப்பில் இயங்கும் Rocket.Chat-ஐ எவ்வாறு backup எடுப்பது?

Volume-ஐ நகலெடுப்பதற்குப் பதிலாக, mongodump மூலம் சீரான database dump-ஐ எடுக்கவும்: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. இந்த archive-ல் பயனர்கள், channels, செய்திகள், அமைப்புகள் மற்றும் GridFS-ல் சேமிக்கப்பட்ட கோப்புகள் அனைத்தும் இருக்கும். இதை server-லிருந்து வெளியே நகலெடுத்து, cron மூலம் தினமும் தானியக்கமாக்கவும். ஒரு தற்காலிக server-ல் mongorestore செய்து பார்க்கவும், அப்போதுதான் restore சரியாக வேலை செய்கிறதா என்பது உறுதியாகும்.

MongoDB-ஐப் பாதிக்காமல் Rocket.Chat-ஐ எவ்வாறு upgrade செய்வது?

Rocket.Chat-ஐ ஒரு நேரத்தில் ஒரு major version-ஆக மட்டும் upgrade செய்யவும். boot ஆகும்போது அது migrations-ஐ இயக்கும். major version-களைத் தவிர்த்தால் கடுமையான இணக்கத்தன்மை (compatibility) சிக்கல்கள் ஏற்படும் என அதன் ஆவணங்கள் எச்சரிக்கின்றன. image tag-ஐ மாற்றும் முன், ஒவ்வொரு release-ன் குறிப்புகளையும் படிக்கவும். உங்கள் இலக்கு release எந்த MongoDB version-களை ஆதரிக்கிறது என்பதை curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions மூலம் சரிபார்க்கவும். MongoDB-ஐ மாற்றும்போது, ஒரு நேரத்தில் ஒரு major version-ஆக உயர்த்தி, ஒவ்வொரு மாற்றத்திற்குப் பிறகும் confirm: true மூலம் setFeatureCompatibilityVersion-ஐ அமைக்கவும். எப்போதும் முதலில் ஒரு mongodump எடுக்கவும்.