ஆல் Matt Connor 2026-07-15 · புதுப்பிக்கப்பட்டது 2026-08-26

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

Q: சுய-வழங்கி 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 மூலம் தினமும் தானியக்கமாக்குங்கள். மேலும், ஒரு தற்காலிக கணினியில் mongorestore செய்து பாருங்கள், அப்போதுதான் restore சரியாக வேலை செய்கிறதா என்பது உங்களுக்குத் தெரியும்.

Docker Compose பயன்படுத்தி உங்கள் VPS-ல் Rocket.Chat-ஐ நிறுவுங்கள். MongoDB replica set கட்டமைப்பு, TLS பாதுகாப்பு மற்றும் தரவு பேக்கப் எடுக்கும் முறைகளை இதில் காணலாம்.

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

நீங்கள் முழுமையாகக் கட்டுப்படுத்தும் ஒரு தனிப்பட்ட குழு அரட்டை (team chat) தளம்: Docker Compose மூலம் உங்கள் சொந்த VPS-ல் இயங்கும் Rocket.Chat, இது TLS மூலம் பாதுகாக்கப்படுகிறது. ஒவ்வொரு செய்தியும் MongoDB தரவுத்தளத்தில் சேமிக்கப்படுவதால், அதை நீங்கள் எப்போது வேண்டுமானாலும் பேக்கப் எடுத்து மாற்றிக்கொள்ளலாம். Rocket.Chat என்பது Slack மற்றும் Teams தளங்களுக்கு மாற்றாக விளங்கும் முதிர்ச்சியடைந்த திறந்தநிலை மென்பொருள் (open-source). இதில் சேனல்கள், நேரடி செய்திகள், த்ரெட்கள் (threads), கோப்பு பகிர்வு, குரல் மற்றும் வீடியோ அழைப்புகள் என அனைத்தும் நீங்கள் வாடகைக்கு எடுத்து நிர்வகிக்கும் வன்பொருளிலேயே இயங்கும். இந்த அப்ளிகேஷன் சில நிமிடங்களில் இயங்கக்கூடிய ஒரு ஒற்றை கன்டெய்னர் (container) ஆகும். இதில் ஏற்படும் பெரும்பாலான சிக்கல்கள் அதனுடன் இணைந்த தரவுத்தளத்திலேயே இருக்கும். எனவே, இந்த வழிகாட்டியின் பெரும்பகுதி MongoDB-ஐப் பற்றியது. குறிப்பாக, பலரை ஆச்சரியப்படுத்தும் ஒரு முக்கியத் தேவை: Rocket.Chat ஒரு standalone MongoDB-ல் இயங்காது. அதற்கு ஒரு replica set தேவை, அந்த "set"-ல் ஒரே ஒரு நோட் (node) மட்டுமே இருந்தாலும் அது கட்டாயம்.

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

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

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

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

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

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

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

இரண்டு images-க்கும் உண்மையான version tags-ஐ pin செய்யுங்கள்: mongo:8.0 மற்றும் இங்கே உள்ள 8.5.1 போன்ற explicit Rocket.Chat release-ஐ பயன்படுத்துங்கள். தானாக நடைபெறும் docker pull, திட்டமிடப்படாத மற்றும் migration செய்ய முடியாத upgrade-ஆக மாறக்கூடும் என்பதால், :latest-ஐ ஒருபோதும் பயன்படுத்த வேண்டாம். Pin செய்வதற்கு முன், தற்போதைய stable Rocket.Chat release-ஐயும் அது ஆதரிக்கும் MongoDB versions-ஐயும் சரிபார்க்கவும்.

Rocket.Chat ஒவ்வொரு release-க்கும் machine-readable info document-ஐ வெளியிடுகிறது: 8.5.1-க்கு curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}', compatibleMongoVersions: ["8.0"]-ஐத் திருப்பித் தருகிறது. எனவே mongo:8.0 மட்டுமே ஆதரிக்கப்படும் engine ஆகும். மேலும், அந்த release long-term-support build ஆக உள்ளதா என்பதைக் காட்டும் lts flag-உம் உள்ளது. Server-ஐ தொடர்ந்து கண்காணிக்க வேண்டாம் என விரும்பினால், அத்தகைய release-ஐ pin செய்வது பயனுள்ளதாக இருக்கும்.

ஒவ்வொரு project-மும் versioned image-ஐ வெளியிடாது. அத்தகைய நிலையில் pin source-க்கு மாற்றப்படும்: openGym workout tracker-ஐ self-hosting செய்வது என்பது moving branch-ஐப் பின்பற்றுவதற்குப் பதிலாக, குறிப்பிட்ட git tag-ஐ checkout செய்து அதிலிருந்து 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 முகவரியுடன் இணைக்கவும்.

முதல்முறை அமைப்பதற்கான wizard

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

பதிவு செய்வது, Rocket.Chat-ன் gateway வழியாக mobile push notifications மற்றும் add-on marketplace வசதிகளைச் செயல்படுத்தும், ஆனால் Rocket.Chat cloud-உடன் ஒரு கட்டுப்பாட்டுத் தொடர்பு ஏற்படும். Standalone முறையில் server முழுமையாகத் தனிப்பட்டதாகவும், எவ்விதச் சார்பும் இல்லாமலும் இருக்கும். ஆனால், iOS மற்றும் Android push notifications வேலை செய்யாது; ஏனெனில், சொந்தமாக உருவாக்கப்பட்ட app-ல் push certificates-ஐ வைத்திருக்க Apple மற்றும் Google அனுமதிப்பதில்லை, அதிகாரப்பூர்வமான apps cloud gateway வழியாகவே இயங்குகின்றன. தனியுரிமை மட்டுமே முக்கியம் மற்றும் உங்கள் பயனர்கள் web app-ஐ மட்டுமே பயன்படுத்துவார்கள் என்றால் standalone-ஐத் தேர்ந்தெடுக்கவும்; mobile push கட்டாயம் தேவை என்றால் பதிவைத் தேர்ந்தெடுக்கவும். 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-ஐ a self-hosted Authentik SSO server-க்கு மாற்றவும். இதன் மூலம், பணியாளர்கள் சேரும்போதும் வெளியேறும்போதும் ஒவ்வொரு செயலியிலும் தனித்தனியாக மாற்றங்கள் செய்யாமல், ஒரே இடத்தில் நிர்வகிக்கலாம்.

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

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 செய்து பயிற்சி செய்யவும்.

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

மேம்படுத்தல்களைச் சிக்கலின்றிச் செய்ய இரண்டு விதிகள் உள்ளன. முதலாவதாக, Rocket.Chat-ஐ ஒரு நேரத்தில் ஒரு major version மட்டுமே மேம்படுத்தவும். இது தொடங்கும்போதே schema migration-களைச் செய்யும், மேலும் நேரடியாக major version-களைத் தாண்டிச் செல்ல அனுமதிக்காது; 6.x-லிருந்து நேரடியாக 8.x-க்கு மாற முயன்றால், தரவு சிதைவதைத் தவிர்க்க migration பிழையுடன் அது நின்றுவிடும். Image tag-ஐ அடுத்த major version-ன் சமீபத்திய release-க்கு மாற்றவும், அந்த release-ன் குறிப்புகளில் உள்ள மாற்றங்களை வாசிக்கவும், docker compose up -d-ஐ இயக்கவும், migration முடிவடையும் வரை logs-ஐக் கவனிக்கவும். இரண்டாவதாக, MongoDB support matrix-ஐப் பின்பற்றவும். ஒவ்வொரு Rocket.Chat release-ம் குறிப்பிட்ட MongoDB version-களை மட்டுமே ஆதரிக்கும், அதை 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-loop), மேலும் docker compose logs rocketchat ஒரு MongoServerSelectionError-ஆல் நிரம்புகிறது. MongoDB இயங்குகிறது, ஆனால் டிரைவரால் முதன்மை (primary) பகுதியைத் தேர்ந்தெடுக்க முடியவில்லை. துல்லியமான சரம் நீங்கள் செய்த தவறைச் சுட்டிக்காட்டும். Server selection timed out after 30000 ms மற்றும் அதன் topology வகை ReplicaSetNoPrimary எனில், நீங்கள் rs.initiate()-ஐ இயக்கவில்லை என்று அர்த்தம்; அந்த தொகுப்பில் இன்னும் கட்டமைப்பு (config) இல்லை. getaddrinfo ENOTFOUND மற்றும் அதைத் தொடர்ந்து ஒரு சீரற்ற ஹாஷ் (random hash) இருந்தால், நீங்கள் வெளிப்படையான host: "mongodb:27017" இல்லாமல் தொடங்கியுள்ளீர்கள் என்று அர்த்தம்; எனவே MongoDB தீர்க்க முடியாத (unresolvable) கண்டெய்னர் ஹோஸ்ட் பெயரை விளம்பரப்படுத்துகிறது. sudo docker compose exec mongodb mongosh --eval 'rs.status()' மூலம் கண்டறியவும்: அது MongoServerError: no replset config has been received எனப் பிழையைக் காட்டினால், தொகுப்பைத் தொடங்கவும் (initiate); ஒரு உறுப்பினரின் name சீரற்ற ஹாஷ் ஆக இருந்தால், சர்வீஸ் பெயரைப் பயன்படுத்தி மீண்டும் தொடங்கவும்.

Web UI ஏற்றப்படுகிறது, ஆனால் உள்நுழைவு (login) முடிவடையாமல் சுழன்று கொண்டே இருக்கிறது. பிரவுசர் கன்சோலைத் திறந்தால் WebSocket connection to 'wss://chat.example.com/websocket' failed-ஐக் காண்பீர்கள். இது பெரும்பாலும் ROOT_URL பொருந்தாமை அல்லது upgrade headers-ஐ அனுப்பாத ப்ராக்ஸி (proxy) காரணமாக நிகழ்கிறது. ROOT_URL என்பது https:// உட்பட துல்லியமான பொது முகவரியுடன் (public address) ஒத்துப்போகிறதா என்பதை உறுதிப்படுத்தவும். மேலும், உங்கள் 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) காட்டப்படுகிறது; வெளியேறும் குறியீடு (exit code) 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 மூலம் அதைக் கண்டறிந்து, அந்த செயல்முறையை (process) அல்லது கண்டெய்னரை நிறுத்தவும். அல்லது மேப்பிங்கின் ஹோஸ்ட் பக்கத்தை 127.0.0.1:3001:3000 என மாற்றி, உங்கள் ப்ராக்ஸியின் proxy_pass-ஐ அதற்கேற்ப புதுப்பிக்கவும்.

FAQ

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

ஆம், ஒரே ஒரு database node கொண்ட server-ஆக இருந்தாலும் இது அவசியம். Rocket.Chat, MongoDB change streams-ஐப் பயன்படுத்தி செய்திகளை நிகழ்நேரத்தில் (real-time) அனுப்புகிறது. இந்த change streams வசதி replica set-ல் மட்டுமே கிடைக்கும்; ஒரு standalone mongod-ஆல் இதைச் செயல்படுத்த முடியாது. இதற்குப் பல கணினிகள் தேவையில்லை; --replSet rs0-ஐப் பயன்படுத்தி ஒரு MongoDB container-ஐத் தொடங்கி, rs.initiate() மூலம் ஒரே ஒரு member கொண்ட set-ஐ உருவாக்கினால் போதுமானது. இந்த நிலையைத் தவிர்த்தால், driver-ஆல் primary-ஐக் கண்டறிய முடியாது. இதனால் 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-ல் பாதியை எடுத்துக்கொள்ளும். எனவே, 2 GB உள்ள கணினியில் இவை இரண்டும் மோதிக்கொள்ளும். ஏதேனும் சுமை ஏற்படும்போது, 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-க்கு அனுப்பவும். container-ன் ROOT_URL-ஐ உங்கள் பொதுவான https:// முகவரிக்கு அமைக்கவும். proxy-ஆனது WebSocket upgrade headers-ஐ அனுப்ப வேண்டும், இல்லையெனில் login செயல்முறை முடங்கிவிடும். nginx உடன் Certbot பயன்படுத்துவது ஒற்றை-app அமைப்பிற்கு எளிதானது; பல 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 மூலம் தினமும் தானியக்கமாக்குங்கள். மேலும், ஒரு தற்காலிக கணினியில் mongorestore செய்து பாருங்கள், அப்போதுதான் restore சரியாக வேலை செய்கிறதா என்பது உங்களுக்குத் தெரியும்.

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

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

#rocket-chat #docker #docker-compose #mongodb #self-hosting #tls