Rocket.Chat Docker Compose வெளியீடு முழு வழிகாட்டி

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

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

முன்தேவைகள், மற்றும் யாரும் சொல்லாத RAM கணக்கீடு

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

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

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

Ubuntu இல் இருக்கும் docker.io package-உம் அல்லாமல், பழைய standalone 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 போன்ற ஏதோ ஒன்றை print செய்கிறது; இதுதான் முக்கியமான சரிபார்ப்பு. docker: 'compose' is not a docker command என error தோன்றினால், plugin நிறுவப்படவில்லை; இதனால் பிறகு குழப்பமான தோல்விகள் ஏற்படும் — இங்கேயே இதைச் சரி செய்யவும்.

compose கோப்பு: ஒற்றை-முனை replica set ஆக MongoDB

பலர் இந்தப் பகுதியில் தவறு செய்கிறார்கள். எனவே மெதுவாகப் படிக்கவும். Rocket.Chat ஆனது இணைக்கப்பட்ட கிளையன்ட்களுக்கு புதிய செய்திகளை நிகழ்நேரத்தில் தள்ளுவதற்கு MongoDB change streams ஐப் பயன்படுத்துகிறது. change streams கள் ஒரு replica set இல் மட்டுமே கிடைக்கின்றன. Rocket.Chat ஐ சாதாரண தனித்த mongod க்கு சுட்டினால், அது இணையும். ஆனால் change stream ஐத் திறக்க முடியாமல் தோல்வியடையும். பின்னர் அது தொடர்ந்து மறுதொடக்கம் செய்யும். தீர்வு சிக்கலானதல்ல: நீங்கள் ஒரு சாதாரண MongoDB container ஐ இயக்குகிறீர்கள். ஆனால் அதை --replSet உடன் தொடங்குகிறீர்கள். பிறகு ஒரு உறுப்பு கொண்ட set ஐத் துவக்குகிறீர்கள்.

ஒரு பணிக் கோப்பகத்தையும் ஒரு 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 இல்லை. எனவே அதே சேவையகத்தில் உள்ள reverse proxy மட்டுமே அதை அணுக வேண்டும். அதை ஒவ்வொரு interface இலும் bind செய்தால், ஒரு plaintext உள்நுழைவுப் பக்கம் நேரடியாகப் பொது இணையத்தில் வந்து சேரும். MongoDB போர்ட் பணியகத்தில் வெளியிடப்படவில்லை. அது Compose இன் உள் நெட்வொர்க் வழியாக mongodb என்ற பெயரில் மட்டுமே அணுகக்கூடியதாக உள்ளது. இதுதான் MONGO_URL பயன்படுத்தும் hostname ஆகும். MONGO_URL ஆனது ?replicaSet=rs0 ஐக் கொண்டுள்ளது. இதை விட்டால், சேவையகம் replica set ஆக இருந்தாலும் driver அதை standalone ஆகக் கருதும். change streams மீண்டும் தோல்வியடையும். MONGO_OPLOG_URL ஆனது oplog இருக்கும் local தரவுத்தளத்தைச் சுட்டுகிறது. நவீன Rocket.Chat க்கு change streams போதுமானது. ஆனால் இதை அமைப்பது பாதிப்பை ஏற்படுத்தாது. மேலும் பழைய குறியீடு பாதைகளையும் செயல்பட வைக்கும். depends_on ஆனது condition: service_healthy ஐப் பயன்படுத்துகிறது. எனவே MongoDB ஒரு ping க்கு பதிலளிக்கும் வரை Compose காத்திருக்கும். பிறகே அது Rocket.Chat ஐத் தொடங்கும். இதுதான் healthcheck இன் பயன்.

இரண்டு image களிலும் உண்மையான version tag களைப் பொருத்தவும் — mongo:8.0 மற்றும் இங்கே காட்டப்பட்டுள்ளபடி ஒரு வெளிப்படையான Rocket.Chat வெளியீடு போன்றது 8.5.1. :latest ஐ ஒருபோதும் பயன்படுத்த வேண்டாம். அது ஒரு கவனிக்கப்படாத docker pull ஐ தவறுதலாகவும் மாற்ற முடியாததாகவும் இருக்கும் ஒரு மேம்பாடாக மாற்றிவிடும். நீங்கள் version ஐப் பொருத்தும் முன், தற்போதைய நிலையான Rocket.Chat வெளியீட்டையும் அது ஆதரிக்கும் MongoDB version களையும் சரிபார்க்கவும். Rocket.Chat ஒவ்வொரு வெளியீட்டிற்கும் ஒரு இயந்திரத்தால் படிக்கக்கூடிய தகவல் ஆவணத்தை வெளியிடுகிறது: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' ஆனது 8.5.1 க்கு compatibleMongoVersions: ["8.0"] ஐ வழங்குகிறது. எனவே mongo:8.0 தான் ஒரே ஆதரிக்கப்படும் engine. மேலும் ஒரு lts flag ஆனது அந்த வெளியீடு நீண்ட கால ஆதரவு கொண்ட build ஆ என்பதைக் கூறும். நீங்கள் தொடர்ந்து கவனித்துக்கொள்ள விரும்பாத ஒரு சேவையகத்திற்கு அத்தகைய வெளியீட்டைப் பொருத்துவது பயனுள்ளதாக இருக்கும்.

ரெப்ளிகா செட்டைத் தொடங்கவும்

ஸ்டாக்கை எழுப்பவும்:

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 }. சில வினாடிகளில் ஒற்றை நோடு தன்னைத் தானே primary ஆகத் தேர்ந்தெடுத்துக்கொள்ளும். பின்வரும் கட்டளையால் உறுதிப்படுத்தவும்:

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

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

முதல் துவக்கம்: சேவை தொடங்குவதைக் கவனிக்கவும்

தொகுப்பு primary ஆகும்போது, Rocket.Chat-ன் அடுத்த மறுதொடக்கம் சரியாக இணைந்து முதல்-இயக்க மைகிரேஷன்களைத் தொடங்கும். லாக்கைப் பின்தொடரவும்:

sudo docker compose logs -f rocketchat

நீங்கள் காத்திருக்கும் வரி தொடக்க பேனர் ஆகும்:

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

முதல் துவக்கம் மெதுவாக இருக்கும் — செயலி டேட்டாபேஸ் மைகிரேஷன்களை இயக்கி index-களை உருவாக்குகிறது, எனவே கவலைப்படுவதற்கு முன்பு ஒரு நிமிடம் அல்லது இரண்டு நிமிடம் காத்திருக்கவும். அதற்கு பதிலாக லாக் MongoServerSelectionError: Server selection timed out after 30000 ms-ஐ ReplicaSetNoPrimary வகை topology description-உடன் திரும்பத் திரும்பக் காட்டினால், replica set தொடங்கப்படவில்லை; அது ஒரு சீரற்ற hash-ல் getaddrinfo ENOTFOUND-ஐ திரும்பத் திரும்பக் காட்டினால், தவறான host-உடன் அது தொடங்கப்பட்டுள்ளது. இரண்டு நிலைகளிலும், ஒரு படி பின்செல்லவும். SERVER RUNNING-ஐப் பார்த்ததும், Rocket.Chat ஆனது 127.0.0.1:3000-ல் கேட்கிறது, இப்போது அதற்கு முன்பு ஒரு உண்மையான hostname மற்றும் TLS-ஐ வைக்க வேண்டிய நேரம்.

TLS பின்னால் வைக்கவும்

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

முதலில் plain HTTP nginx server block ஒன்றை உருவாக்கி, அது பயன்பாட்டிற்கு proxy செய்து upgrade headers-ஐ அனுப்பட்டும். அதை /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; கொண்ட ஒரு block, certificate இல்லாமல் sudo nginx -t-கூட கடக்காது. nginx-ஐ reload செய்யவும் (sudo nginx -t && sudo systemctl reload nginx), பிறகு certificate-ஐ பெறவும். Ubuntu-வில் மிக சுத்தமான வழி Certbot மற்றும் nginx உடன் Let's Encrypt TLS சான்றிதழ்கள் ஆகும்: certbot --nginx மேற்கொண்ட block-ஐ இடத்திலேயே மாற்றி, listen 443 ssl;, ssl_certificate வரிகள் மற்றும் தானியங்கி 80-to-443 redirect ஆகியவற்றைச் சேர்க்கிறது; மேலும் அது புதுப்பித்தலை உங்களுக்காக திட்டமிடுகிறது. நீங்கள் ஏற்கனவே ஒரு proxy பின்னால் பல containers இயக்குகிறீர்கள் என்றால், பல Docker பயன்பாடுகளுக்கு தானியங்கி TLS உடன் Traefik சுத்தமான விருப்பம் — rocketchat சேவையில் router மற்றும் service labels-ஐ சேர்க்கவும்; Traefik உங்களுக்காக certificate-ஐ கோரி புதுப்பிக்கும், nginx block ஏதும் தேவையில்லை. எப்படியாக இருந்தாலும், compose.yml-ல் ROOT_URL-ஐ https://chat.example.com ஆக அமைத்து sudo docker compose up -d-ஐ மீண்டும் இயக்கவும், இதனால் container மாற்றத்தை ஏற்றுக்கொள்ளும். சேவையகம் பொது இணையத்திற்கு பதிலாக உங்கள் சொந்த நெட்வொர்க்கிற்குள் மட்டுமே அணுகக்கூடியதாக இருக்க வேண்டும் என்றால், அதற்கு முன்னால் VPS-ல் self-hosted WireGuard VPN அமைத்து proxy-ஐ tunnel முகவரியுடன் bind செய்யவும்.

முதல்-இயக்க அமைப்பு வழிகாட்டி

https://chat.example.com ஐத் திறக்கவும். Rocket.Chat ஒரு சிறிய வழிகாட்டியைத் தொடங்கும். முதலில், நிர்வாகக் கணக்கு — உண்மையான பெயர், பயனர்பெயர், மின்னஞ்சல், மற்றும் வலுவான கடவுச்சொல்; இதுவே உள்ள ஒரே கணக்கு, எனவே இதை இழக்க வேண்டாம். அடுத்து, நிறுவனம் மற்றும் சேவையகத் தகவல் — பெயர், தொழில், அளவு, தளப் பெயர் மற்றும் இயல்புநிலை மொழி; இவை வெறும் தோற்றத்திற்கானவை, நிரப்பிவிட்டு தொடரவும். பிறகு முக்கியமான தேர்வு: இந்தப் பணியிடத்தை Rocket.Chat Cloud உடன் பதிவுசெய்வது, அல்லது தனித்த நிலையில் வைப்பது.

பதிவுசெய்வது Rocket.Chat-இன் நுழைவாயில் வழியாக மொபைல் push அறிவிப்புகளையும் add-on marketplace-ஐயும் இயக்குகிறது. ஆனால் இதற்கு பரிமாறாக Rocket.Chat-இன் கிளவுடுடன் ஒரு control-plane தொடர்பு ஏற்படுகிறது. தனித்த நிலை சேவையகத்தை முழுமையாகத் தனிப்பட்டதாகவும் சார்பற்றதாகவும் வைத்திருக்கும். ஆனால் iOS மற்றும் Android push அறிவிப்புகள் செயலிழக்கும். ஏனெனில் Apple மற்றும் Google தாங்களே உருவாக்கிய செயலியொன்று push சான்றிதழ்களை வைத்திருக்க அனுமதிக்காது — அதிகாரப்பூர்வ செயலிகள் கிளவுடு நுழைவாயில் வழியே செல்கின்றன. தனியுரிமை மட்டுமே நோக்கம் என்றாலும் உங்கள் பயனர்கள் web செயலியிலேயே இருந்தால் தனித்த நிலையைத் தேர்ந்தெடுக்கவும். மொபைல் push அவசியம் என்றால் பதிவைத் தேர்ந்தெடுக்கவும். பிறகு Admin பிரிவில் உங்கள் முடிவை மாற்றிக்கொள்ளலாம்.

யாரையும் அழைப்பதற்கு முன் அணுகலைப் பூட்டுங்கள்

Rocket.Chat இயல்புநிலையாக பதிவைத் திறந்தே வைத்து வருகிறது — இயல்புநிலையில் Registration Form ஆனது Public என அமைக்கப்பட்டிருப்பதால், URL-ஐக் கண்டுபிடிக்கும் எவரும் கணக்கை உருவாக்கலாம். பொது hostname ஒன்றில் இது ஒரு திறந்த வாசலாகும். Admin → Settings → Accounts → Registration க்குச் சென்று Registration Form ஆனது Disabled என அமையுங்கள்; இதன்மூலம் நீங்கள் கைமுறையாகவோ அழைப்பு இணைப்பு மூலமோ கணக்குகளை உருவாக்கலாம், அல்லது Secret URL என அமையுங்கள். அங்கிருக்கும்போதே, பொதுவான வாசிப்பு-மட்டும் சேனல் ஒன்று குறிப்பாக வேண்டுமென்றாலொழிய, Allow Anonymous Read மற்றும் Allow Anonymous Write ஆகியவற்றை முடக்குங்கள்.

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

mongodump உடன் காப்புப்பிரதிகள்

உங்கள் எல்லா தரவும் mongodb_data volume-இல் உள்ளது. இயங்கும் database-இலிருந்து volume-ஐ நேரடியாக நகலெடுக்க வேண்டாம். மாறாக, mongodump கொண்டு ஒரு நிலையான dump எடுத்து, அதை host-இல் உள்ள ஒரு file-இற்கு stream செய்யவும்:

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

அந்த ஒற்றை gzipped archive தான் உங்கள் முழு workspace-ம்: users, channels, messages, settings, மேலும் uploads-ஐ GridFS-இல் விட்டிருந்தால் files-ம் கூட. uploads-ஐ filesystem அல்லது S3-க்கு நகர்த்தியிருந்தால், அந்த store-ஐ தனியாக காப்புப்பிரதி எடுக்கவும். ஒரு புதிய 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 செயலிழந்தால் காப்புப்பிரதியும் சேர்த்தே அழிந்துவிடாத எந்த இடம் வேண்டுமானாலும் — மேலும் dump-ஐ cron மூலம் இரவு தோறும் இயக்கவும். நீங்கள் ஒருபோதும் restore செய்திராத காப்புப்பிரதி என்பது காப்புப்பிரதி அல்ல, வெறும் நம்பிக்கை மட்டுமே; ஒரு தற்காலிக VPS-இல் restore-ஐ ஒருமுறை சோதித்துப் பாருங்கள், தேவைப்படும் முன்பே அது சரியாக வேலை செய்கிறது என்பதை உறுதி செய்துகொள்ள.

மேம்படுத்தல்கள்: குறிச்சொற்களைப் பொருத்தவும், குறிப்புகளைப் படிக்கவும், Mongo அணி அட்டவணையைக் கடைப்பிடிக்கவும்

இரண்டு விதிகள் மேம்படுத்தல்களை எளிமையாக்குகின்றன. முதலாவது, Rocket.Chat-ஐ ஒரு முக்கிய பதிப்பில் ஒரு நேரத்தில் மேம்படுத்தவும். இது துவக்கத்தின் போது schema இடம்பெயர்வுகளை இயக்குகிறது. மேலும் இது வெளிப்படையாக முக்கிய பதிப்புகளைத் தாண்டுவதை நிராகரிக்கிறது. 6.x இலிருந்து நேரடியாக 8.x க்குச் செல்ல முயற்சித்தால், உங்கள் தரவைச் சேதப்படுத்துவதற்குப் பதிலாக இடம்பெயர்வுப் பிழையுடன் அது நின்றுவிடும். image குறிச்சொல்லை அடுத்த முக்கிய பதிப்பின் சமீபத்திய வெளியீட்டிற்கு மாற்றவும். அந்த வெளியீட்டின் குறிப்புகளை முறிவு மாற்றங்களுக்காகப் படிக்கவும். 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 இயங்கிக் கொண்டிருக்கிறது ஆனால் டிரைவர் ஒரு primary-ஐத் தேர்ந்தெடுக்க முடியவில்லை, மேலும் சரியான சரம் நீங்கள் செய்த தவறு எது என்று கூறுகிறது. ReplicaSetNoPrimary என்ற topology type உடன் கூடிய Server selection timed out after 30000 ms என்பது நீங்கள் rs.initiate()-ஐ இயக்கவே இல்லை என்பதைக் குறிக்கிறது — இந்த set-க்கு இன்னும் config இல்லை. ஒரு குறிப்பிலட்ட hash உடன் தொடரும் getaddrinfo ENOTFOUND என்பது நீங்கள் வெளிப்படையான 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 குறிப்பிலட்ட hash ஆக இருந்தால், service name உடன் மீண்டும் initiate செய்யவும்.

Web UI ஏற்றப்படுகிறது ஆனால் login முடிவற்ற முறையில் சுழல்கிறது மற்றும் ஒருபோதும் முடிவதில்லை. உலாவி console-ஐத் திறந்தால் WebSocket connection to 'wss://chat.example.com/websocket' failed-ஐ நீங்கள் காண்பீர்கள். இது கிட்டத்தட்ட எப்போதும் ஒரு ROOT_URL பொருத்தமின்மை அல்லது upgrade headers-ஐ முன்னோக்கி அனுப்பாத ஒரு proxy ஆகும். ROOT_URL ஆனது https:// உட்பட சரியான பொது முகவரிக்கு சமம் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள், மேலும் உங்கள் nginx location block ஆனது proxy_http_version 1.1 உடன் Upgrade மற்றும் Connection "upgrade"-ஐ அமைக்கிறது என்பதையும் உறுதிப்படுத்திக் கொள்ளுங்கள். இரண்டில் ஒன்றை மாற்றி 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 ஆகும். பெட்டியில் RAM தீர்ந்துவிட்டது. உண்மையான தீர்வு ஒரு பெரிய VPS — குறைந்தபட்சம் 4 GB. ஒரு தற்காலிக தீர்வாக swap சேர்த்து MongoDB-ன் cache-ஐ அதன் 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 உடன் தோல்வியடைகிறது. ஏதோ ஒன்று ஏற்கனவே port 3000-ஐ வைத்திருக்கிறது — பெரும்பாலும் சரியாக நிற்காத ஒரு முந்தைய Rocket.Chat container, அல்லது வேறு ஒரு app. sudo ss -ltnp | grep :3000 உடன் அதைக் கண்டறியவும், அந்த process அல்லது container-ஐ நிறுத்தவும், அல்லது mapping-ன் host side-ஐ 127.0.0.1:3001:3000-ஆக மாற்றி உங்கள் proxy-ன் proxy_pass-ஐ அதற்கேற்ப புதுப்பிக்கவும்.

FAQ

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

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

Self-hosted Rocket.Chat க்கு எவ்வளவு RAM தேவை?

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

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

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

Self-hosted Rocket.Chat-ஐ எப்படி காப்புப் பிரதி எடுப்பது?

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

MongoDB-ஐ உடைக்காமல் Rocket.Chat-ஐ எப்படி மேம்படுத்துவது?

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