Docker Compose سے Rocket.Chat خود میزبان کریں

آپ کیا بنا رہے ہیں

ایک نجی ٹیم چیٹ جس کے آپ خود مالک ہیں: اپنے VPS پر Docker Compose کے تحت چلنے والا Rocket.Chat، جسے TLS ختم کرتا ہے، اور ہر پیغام MongoDB ڈیٹا بیس میں محفوظ ہوتا ہے جس کا آپ بیک اپ لے سکتے اور منتقل کر سکتے ہیں۔ Rocket.Chat ایک پختہ اوپن سورس Slack اور Teams کا متبادل ہے، چینلز، براہ راست پیغامات، تھریڈز، فائل شیئرنگ، اور صوتی و بصری کالز، یہ سب اس ہارڈویئر پر جو آپ کرائے پر لیتے اور کنٹرول کرتے ہیں۔ ایپلیکیشن ایک واحد کنٹینر ہے جو منٹوں میں تیار ہو جاتا ہے۔ ہر وہ چیز جو حقیقتاً خراب ہوتی ہے اس کے ساتھ والے ڈیٹا بیس میں رہتی ہے، اس لیے یہ گائیڈ زیادہ تر MongoDB کے بارے میں ہے، اور خاص طور پر اس ایک شرط کے بارے میں جو پہلی بار ہر کسی کو حیران کر دیتی ہے: Rocket.Chat ایک اسٹینڈ اکیلا MongoDB کے ساتھ نہیں چلے گا۔ اسے ایک ریپلیکا سیٹ درکار ہے، چاہے وہ "سیٹ" ایک ہی نوڈ ہی کیوں نہ ہو۔

شرائط، اور RAM کا وہ حساب جو کوئی نہیں بتاتا

مشین کا سائز ایمانداری سے طے کریں۔ ایک چھوٹی ٹیم کے لیے حقیقت پسندانہ کم از کم حد 2 vCPU اور 4 GB RAM ہے۔ Rocket.Chat کا Node.js عمل خود تقریباً 1 سے 1.5 GB چاہتا ہے، اور MongoDB کا WiredTiger کیشے بطور ڈیفالٹ بقیہ RAM کا تقریباً آدھا حصہ لے لیتا ہے۔ 2 GB والے VPS پر یہ دونوں بوٹ کے وقت تو فٹ ہو جاتے ہیں لیکن جیسے ہی حقیقی ٹریفک آتی ہے، تصادم ہو جاتا ہے: MongoDB اپنا کیشے بڑھاتا ہے، Node اپنا ہیپ بڑھاتا ہے، کرنل کے پیجز ختم ہو جاتے ہیں، اور آؤٹ-آف-میموری کلر سب سے بڑے عمل کو ختم کر دیتا ہے، جو عموماً mongod ہوتا ہے۔ کنٹینر Killed پرنٹ کرتا ہے، Docker اسے دوبارہ شروع کرتا ہے، اور آپ کو ایک چیٹ سرور ملتا ہے جو اس بوجھ کے نیچے ہر چند منٹ میں ڈاؤن ہو جاتا ہے جسے وہ آسانی سے سنبھال لینا چاہیے۔ 2 GB دو افراد کے ساتھ تجربہ کرنے کے لیے ٹھیک ہے؛ یہ ٹیم کا سرور نہیں ہے۔ 4 GB سے شروع کریں، اور اگر آپ کو درجنوں بیک وقت صارفین، ویڈیو کالز، یا بڑھتی ہوئی اپ لوڈ ہسٹری کی توقع ہے تو اسے 8 GB دیں۔

شروع کرنے سے پہلے آپ کو تین چیزیں بھی درکار ہیں۔ ایک ڈومین نام جس کا A ریکارڈ VPS کے پبلک IP کی طرف اشارہ کرتا ہو، Rocket.Chat کی ریئل ٹائم خصوصیات اور موبائل کلائنٹس کو ایک مستحکم ہوسٹ نام چاہیے، نہ کہ صرف ایک IP۔ سرور فائر وال اور آپ کے فراہم کنندہ کی نیٹ ورک فائر وال دونوں پر پورٹ 80 اور 443 کھلے ہوں، جو زیادہ تر پینلز پر ایک علیحدہ کنٹرول ہوتا ہے۔ اور ایک تازہ Ubuntu 24.04 KVM VPS جس میں روٹ یا سوڈو رسائی ہو۔ اگر آپ ابھی یہ فیصلہ کر رہے ہیں کہ کیا چیٹ سرور چلانے کے لیے پہلی صحیح سروس ہے، تو 2026 میں خود میزبانی کے قابل چیزوں کی گائیڈ تجارت کے نقصانات کو واضح کرتی ہے۔

ڈوکر انجن اور کمپوز پلگ ان انسٹال کریں

ڈوکر کا اپنا ایپٹ ریپوزٹری استعمال کریں، نہ کہ وہ docker.io پیکج جو اوبنٹو فراہم کرتا ہے اور نہ ہی قدیم اسٹینڈ-الون docker-compose پائیتھون بائنری۔ جدید کمپوز ایک ڈوکر پلگ ان ہے جسے آپ docker compose کے طور پر استعمال کرتے ہیں، ایک اسپیس، ہائفن نہیں۔ پرانا docker-compose ورژن 1 اب میعاد ختم ہے اور نیچے دیے گئے ہیلتھ چیک اور انحصار کے سینٹیکس کو غلط طریقے سے ہینڈل کرتا ہے۔

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 کی غلطی دے، تو پلگ ان انسٹال نہیں ہوا اور آپ بعد میں الجھا دینے والی ناکامیوں کا سامنا کرنے والے ہیں، اسے یہیں درست کریں۔

کمپوز فائل: سنگل نوڈ ریپلیکا سیٹ کے طور پر MongoDB

یہ وہ حصہ ہے جہاں لوگ غلطی کرتے ہیں، اس لیے اسے آہستہ پڑھیں۔ Rocket.Chat نئے پیغامات کو منسلک کلائنٹس تک فوری طور پر پہنچانے کے لیے MongoDB چینج سٹریمز استعمال کرتا ہے، اور چینج سٹریمز صرف ریپلیکا سیٹ پر دستیاب ہیں۔ Rocket.Chat کو ایک سادہ اسٹینڈ الون mongod کی طرف اشارہ کریں تو یہ کنیکٹ ہو جائے گا، چینج سٹریم کھولنے میں ناکام ہو گا، اور مسلسل ری سٹارٹ لوپ میں پھنس جائے گا۔ اس کا حل کوئی غیر معمولی نہیں ہے: آپ ایک عام، واحد MongoDB کنٹینر چلاتے ہیں، لیکن اسے --replSet کے ساتھ شروع کرتے ہیں اور پھر ایک رکنی سیٹ شروع کرتے ہیں۔

ایک ورکنگ ڈائریکٹری اور ایک compose.yml بنائیں:

services:
  mongodb:
    image: mongo:8.0
    restart: always
    command: ["mongod", "--replSet", "rs0", "--bind_ip_all", "--oplogSize", "128"]
    volumes:
      - mongodb_data:/data/db
      - mongodb_config:/data/configdb
    healthcheck:
      test: ["CMD", "mongosh", "--quiet", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 10s
      retries: 12

  rocketchat:
    image: registry.rocket.chat/rocketchat/rocket.chat:8.5.1
    restart: always
    depends_on:
      mongodb:
        condition: service_healthy
    environment:
      MONGO_URL: "mongodb://mongodb:27017/rocketchat?replicaSet=rs0"
      MONGO_OPLOG_URL: "mongodb://mongodb:27017/local?replicaSet=rs0"
      ROOT_URL: "https://chat.example.com"
      PORT: "3000"
    ports:
      - "127.0.0.1:3000:3000"

volumes:
  mongodb_data:
  mongodb_config:

یہاں چند انتخابات جان بوجھ کر کیے گئے ہیں۔ Rocket.Chat پورٹ کو 127.0.0.1:3000 پر شائع کیا گیا ہے، 0.0.0.0 پر نہیں، ایپ میں خود کوئی TLS نہیں ہے، اس لیے صرف اسی باکس پر موجود ریورس پراکسی کو اس تک رسائی حاصل کرنی چاہیے؛ اسے ہر انٹرفیس پر بائنڈ کرنا ایک سادہ متن والا لاگ ان صفحہ براہ راست عوامی انٹرنیٹ پر ڈال دے گا۔ MongoDB کو میزبان پر بالکل بھی شائع نہیں کیا گیا ہے؛ یہ صرف Compose کے اندرونی نیٹ ورک پر mongodb کے نام سے قابل رسائی ہے، جو بالکل وہی ہوسٹ نام ہے جسے MONGO_URL استعمال کرتا ہے۔ MONGO_URL میں ?replicaSet=rs0 ہوتا ہے، اسے چھوڑ دیں تو ڈرائیور سرور کو اسٹینڈ الون سمجھتا ہے حالانکہ یہ ایک ریپلیکا سیٹ ہے، اور چینج سٹریمز پھر بھی ناکام ہو جاتے ہیں۔ MONGO_OPLOG_URL اس local ڈیٹا بیس کی طرف اشارہ کرتا ہے جہاں oplog رہتا ہے؛ جدید Rocket.Chat چینج سٹریمز کو ترجیح دیتا ہے، لیکن اسے سیٹ کرنا بے ضرر ہے اور پرانے کوڈ پاتھز کو خوش رکھتا ہے۔ depends_on میں condition: service_healthy استعمال ہوتا ہے، لہٰذا Compose اس وقت تک انتظار کرتا ہے جب تک MongoDB ایک ping کا جواب نہیں دیتا، تب ہی Rocket.Chat شروع کرتا ہے، ہیلتھ چیک یہی کام کرتا ہے۔

دونوں امیجز پر اصلی ورژن ٹیگز لگائیں، mongo:8.0 اور ایک واضح Rocket.Chat ریلیز جیسے کہ یہاں 8.5.1، اور کبھی بھی :latest استعمال نہ کریں، جو ایک غیر نگرانی شدہ docker pull کو ایک حادثاتی، ناقابل منتقلی اپ گریڈ میں بدل دیتا ہے۔ پن کرنے سے پہلے موجودہ مستحکم 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 جھنڈا جو بتاتا ہے کہ آیا وہ ریلیز ایک طویل مدتی سپورٹ بلڈ ہے جسے ایسے سرور کے لیے پن کرنا مناسب ہے جس کی آپ کم نگرانی کرنا چاہتے ہیں۔

ریپلیکا سیٹ شروع کریں

اسٹیک کو اوپر لائیں:

sudo docker compose up -d

Rocket.Chat فوراً کریش ہونا شروع کر دے گا اور Docker اسے مسلسل دوبارہ شروع کرتا رہے گا، یہ متوقع ہے، کیونکہ ریپلیکا سیٹ ابھی موجود نہیں ہے۔ اسے ایک بار، دستی طور پر بنائیں:

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

درست نتیجہ { ok: 1 } ہے۔ چند سیکنڈوں میں واحد نوڈ خود کو پرائمری منتخب کر لیتا ہے؛ اس سے تصدیق کریں:

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

آپ PRIMARY دیکھنا چاہتے ہیں۔ اس پورے صفحے کی سب سے اہم تفصیل host: "mongodb:27017" آرگیومنٹ ہے۔ اگر آپ ممبرز کی فہرست کے بغیر صرف rs.initiate() چلاتے ہیں، تو MongoDB ریپلیکا سیٹ کو کنٹینر کے اندرونی ہوسٹ نام کے تحت مشتہر کرتا ہے، جو ایک بے ترتیب ہیش جیسا a1b2c3d4e5f6 ہوتا ہے۔ Rocket.Chat، اپنے کنٹینر سے کنیکٹ ہوتے ہوئے، اس نام کو حل نہیں کر سکتا، اس لیے MongoDB ڈرائیور اس پر DNS فیل کرتا ہے اور MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 لاگ کرتے ہوئے مسلسل لوپ میں پھنس جاتا ہے۔ ہمیشہ اس واضح سروس نام کے ساتھ شروع کریں جو آپ کے MONGO_URL سے میل کھاتا ہو۔

پہلا بوٹ: اسے چلتے ہوئے دیکھیں

ایک بار جب سیٹ پرائمری بن جائے، تو Rocket.Chat کا اگلا ری اسٹارٹ صاف طریقے سے جڑتا ہے اور اپنی پہلی رن مائیگریشن شروع کرتا ہے۔ لاگز دیکھیں:

sudo docker compose logs -f rocketchat

جس لائن کا آپ انتظار کر رہے ہیں وہ اسٹارٹ اپ بینر ہے:

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

پہلا بوٹ سست ہوتا ہے، ایپ ڈیٹا بیس مائیگریشن چلاتی ہے اور انڈیکس بناتی ہے، اس لیے پریشان ہونے سے پہلے اسے ایک یا دو منٹ دیں۔ اگر اس کی بجائے لاگ MongoServerSelectionError: Server selection timed out after 30000 ms کو ٹوپولوجی تفصیل قسم ReplicaSetNoPrimary کے ساتھ دہراتا ہے، تو ریپلیکا سیٹ شروع نہیں کیا گیا؛ اگر یہ getaddrinfo ENOTFOUND کو کسی بے ترتیب ہیش پر دہراتا ہے، تو اسے غلط ہوسٹ کے ساتھ شروع کیا گیا تھا۔ دونوں صورتوں میں، ایک قدم پیچھے جائیں۔ ایک بار جب آپ SERVER RUNNING دیکھیں، تو Rocket.Chat 127.0.0.1:3000 پر سن رہا ہے اور اب وقت ہے کہ ایک حقیقی ہوسٹ نام اور TLS لگایا جائے۔

اسے TLS کے پیچھے رکھیں

Rocket.Chat کو کبھی بھی سادہ HTTP پر ظاہر نہ کریں۔ http:// پر ایک بار لاگ ان کریں اور آپ نے اپنا ایڈمن پاس ورڈ راستے میں موجود کسی کو بھی دے دیا۔ اسی مشین پر ایک ریورس پراکسی میں TLS کو ختم کریں اور 127.0.0.1:3000 کو فارورڈ کریں۔ دو چیزیں اہم ہیں: پراکسی کو WebSocket اپ گریڈ ہیڈرز فارورڈ کرنے چاہئیں، کیونکہ Rocket.Chat ریئل ٹائم ہے اور ان کے بغیر کام نہیں کرتا، اور کنٹینر کا ROOT_URL عوامی HTTPS ایڈریس سے بالکل مماثل ہونا چاہیے جو صارفین ٹائپ کرتے ہیں۔

ایک سادہ HTTP nginx سرور بلاک سے شروع کریں جو ایپ کو پراکسی کرتا ہے اور اپ گریڈ ہیڈرز فارورڈ کرتا ہے۔ اسے /etc/nginx/sites-available/rocketchat کے طور پر محفوظ کریں، اسے sites-enabled میں سم لنک کریں، اور دوبارہ لوڈ کریں:

server {
    listen 80;
    server_name chat.example.com;

    client_max_body_size 100M;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

اسے ابھی پورٹ 80 پر چھوڑ دیں، listen 443 ssl; والا بلاک اور کوئی سرٹیفکیٹ نہ ہونے پر sudo nginx -t بھی پاس نہیں کرے گا۔ nginx کو دوبارہ لوڈ کریں (sudo nginx -t && sudo systemctl reload nginx)، پھر سرٹیفکیٹ جاری کریں۔ اوبنٹو پر سب سے صاف راستہ Certbot اور nginx کے ساتھ Let's Encrypt TLS سرٹیفکیٹس ہے: certbot --nginx اوپر والے بلاک کو اپنی جگہ پر دوبارہ لکھتا ہے، listen 443 ssl;, ssl_certificate لائنز، اور ایک خودکار 80-to-443 ری ڈائریکٹ شامل کرتا ہے، اور یہ آپ کے لیے تجدید کا شیڈول بناتا ہے۔ اگر آپ پہلے ہی ایک پراکسی کے پیچھے کئی کنٹینرز چلاتے ہیں، تو بہت سی ڈوکر ایپس کے لیے خودکار TLS کے ساتھ Traefik زیادہ صاف ستھرا آپشن ہے، rocketchat سروس میں راؤٹر اور سروس لیبل شامل کریں اور Traefik بغیر کسی nginx بلاک کے آپ کے لیے سرٹیفکیٹ کی درخواست اور تجدید کرتا ہے۔ دونوں صورتوں میں، compose.yml میں ROOT_URL کو https://chat.example.com پر سیٹ کریں اور sudo docker compose up -d دوبارہ چلائیں تاکہ کنٹینر تبدیلی کو اپنا لے۔ اگر آپ چاہتے ہیں کہ سرور صرف آپ کے اپنے نیٹ ورک کے اندر سے قابل رسائی ہو نہ کہ عوامی انٹرنیٹ سے، تو اسے VPS پر خود میزبان WireGuard VPN کے ساتھ سامنے رکھیں اور پراکسی کو ٹنل ایڈریس پر باندھیں۔

پہلی بار چلنے والا سیٹ اپ وزرڈ

https://chat.example.com پر جائیں اور Rocket.Chat ایک مختصر وزرڈ کے ذریعے آپ کی رہنمائی کرتا ہے۔ پہلے، ایڈمن اکاؤنٹ، ایک اصل نام، صارف نام، ای میل، اور ایک مضبوط پاس ورڈ؛ یہ واحد اکاؤنٹ ہے جو موجود ہے، لہذا اسے مت کھوئیں۔ اگلا، تنظیم اور سرور کی معلومات، نام، صنعت، سائز، سائٹ کا نام اور ڈیفالٹ زبان؛ یہ ظاہری ترتیبات ہیں، انہیں پُر کریں اور آگے بڑھیں۔ پھر وہ انتخاب جو اصل میں اہمیت رکھتا ہے: اس ورک اسپیس کو رجسٹر کریں Rocket.Chat Cloud کے ساتھ، یا اسے اسٹینڈ الون رکھیں۔

رجسٹر کرنے سے Rocket.Chat کے گیٹ وے اور ایڈ آن مارکیٹ پلیس کے ذریعے موبائل پُش نوٹیفیکیشنز فعال ہو جاتی ہیں، جس کی قیمت Rocket.Chat کے کلاؤڈ کے ساتھ کنٹرول-پلین تعلق ہے۔ اسٹینڈ الون سرور کو مکمل طور پر نجی اور انحصار سے پاک رکھتا ہے، لیکن iOS اور Android پُش نوٹیفیکیشنز کام کرنا بند کر دیتی ہیں، کیونکہ Apple اور Google کسی خود ساختہ ایپ کو پُش سرٹیفکیٹس رکھنے کی اجازت نہیں دیتے، سرکاری ایپس کلاؤڈ گیٹ وے کے ذریعے روٹ ہوتی ہیں۔ اسٹینڈ الون کا انتخاب کریں اگر پرائیویسی ہی اصل مقصد ہے اور آپ کے صارفین ویب ایپ میں رہتے ہیں؛ اگر موبائل پُش ناقابلِ مذاکرات ہے تو رجسٹریشن کا انتخاب کریں۔ آپ بعد میں ایڈمن کے تحت اپنا فیصلہ تبدیل کر سکتے ہیں۔

کسی کو مدعو کرنے سے پہلے اسے مقفل کریں

Rocket.Chat بطور ڈیفالٹ کھلی رجسٹریشن آن کے ساتھ آتا ہے، رجسٹریشن فارم Public پر سیٹ ہوتا ہے، لہٰذا جو بھی URL تلاش کر لے وہ اکاؤنٹ بنا سکتا ہے۔ عوامی ہوسٹ نام پر یہ ایک کھلا دروازہ ہے۔ ایڈمن → سیٹنگز → اکاؤنٹس → رجسٹریشن پر جائیں اور رجسٹریشن فارم کو Disabled پر سیٹ کریں، تاکہ آپ ہاتھ سے یا دعوتی لنک کے ذریعے اکاؤنٹس بنائیں، یا Secret URL پر سیٹ کریں۔ جب آپ وہاں ہوں، گمنام پڑھنے کی اجازت دیں اور گمنام لکھنے کی اجازت دیں کو بند کر دیں جب تک کہ آپ خاص طور پر ایک عوامی صرف پڑھنے کا چینل نہیں چاہتے۔

یہ بھی طے کریں کہ اپ لوڈز کہاں جائیں گی۔ ڈیفالٹ فائل اپ لوڈ اسٹوریج GridFS ہے، جو ہر تصویر اور منسلکہ کو خود MongoDB کے اندر محفوظ کرتا ہے۔ یہ سادہ ہے، لیکن اس کا مطلب ہے کہ آپ کا ڈیٹا بیس، اور آپ جو بھی mongodump لیتے ہیں، لوگوں کے اسکرین شاٹس چسپاں کرنے کے ساتھ بغیر کسی حد کے بڑھتا ہے۔ ایڈمن → سیٹنگز → فائل اپ لوڈ کے تحت آپ اسٹوریج کو مقامی فائل سسٹم یا S3-مطابقت رکھنے والے بکٹ میں تبدیل کر سکتے ہیں، اور ایک معقول زیادہ سے زیادہ فائل سائز سیٹ کر سکتے ہیں۔ ایک چھوٹی ٹیم کے لیے GridFS ٹھیک ہے؛ بس جان لیں کہ وقت کے ساتھ آپ کے بیک اپ بھاری ہوتے جاتے ہیں۔

mongodump کے ذریعے بیک اپ

آپ کا تمام ڈیٹا mongodb_data والیوم میں رہتا ہے۔ چلتے ہوئے ڈیٹا بیس کے نیچے سے والیوم کو یونہی کاپی نہ کریں، بلکہ mongodump کے ذریعے یکساں ڈمپ لیں اور اسے ہوسٹ پر ایک فائل میں سٹریم کریں:

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

وہ ایک gzip آرکائیو آپ کا پورا ورک سپیس ہے: صارفین، چینلز، پیغامات، سیٹنگز، اور اگر آپ نے اپ لوڈز GridFS پر چھوڑے ہیں تو فائلیں بھی۔ اگر آپ نے اپ لوڈز کو فائل سسٹم یا S3 پر منتقل کیا ہے تو اس سٹور کا بیک اپ الگ سے لیں۔ تازہ سٹیک پر بحالی کے لیے پہلے ریپلیکا سیٹ شروع کریں، پھر:

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

آرکائیو کو سرور سے باہر کاپی کریں، آبجیکٹ سٹوریج، دوسرا سرور، کہیں بھی جہاں VPS کے مرنے سے بیک اپ اس کے ساتھ ختم نہ ہو، اور ڈمپ کو cron سے ہر رات چلائیں۔ وہ بیک اپ جسے آپ نے کبھی بحال نہیں کیا، وہ امید ہے، بیک اپ نہیں؛ بحالی کی مشق ایک وقتی VPS پر ایک بار کریں تاکہ آپ کو معلوم ہو کہ یہ کام کرتا ہے، ضرورت پڑنے سے پہلے۔

اپ‌گریڈز: ٹیگز کو پن کریں، ریلیز نوٹس پڑھیں، مونگو میٹرکس کا احترام کریں

دو اصول اپ‌گریڈز کو بے‌خطر رکھتے ہیں۔ پہلا، Rocket.Chat کو ایک وقت میں ایک بڑے ورژن (major version) سے اپ‌گریڈ کریں۔ یہ بوٹ پر اسکیما مائیگریشنز چلاتا ہے اور جان بوجھ کر بڑے ورژن کودنے سے انکار کر دیتا ہے؛ 6.x سے سیدھا 8.x پر جانے کی کوشش کریں تو یہ ڈیٹا خراب کرنے کے بجائے مائیگریشن کی خرابی کے ساتھ رک جاتا ہے۔ امیج ٹیگ کو اگلے بڑے ورژن کی تازہ ترین ریلیز پر بڑھائیں، اس ریلیز کے نوٹس میں تبدیلیوں (breaking changes) کے لیے پڑھیں، 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 چل رہا ہے لیکن ڈرائیور پرائمری منتخب نہیں کر سکتا، اور عین سٹرنگ بتاتی ہے کہ آپ نے کون سی غلطی کی۔ Server selection timed out after 30000 ms جس کی ٹوپولوجی ٹائپ ReplicaSetNoPrimary ہے، اس کا مطلب ہے کہ آپ نے کبھی 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۔ عارضی طور پر سویپ شامل کریں اور MongoDB کی کیش کو اس کی command میں --wiredTigerCacheSizeGB 1 سے محدود کریں، لیکن سویپ صرف حقیقی بوجھ کے تحت اگلے OOM میں تاخیر کرتا ہے:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

docker compose up Error response from daemon: driver failed programming external connectivity ... bind: address already in use کے ساتھ ناکام ہو جاتا ہے۔ پورٹ 3000 پر پہلے سے کچھ اور موجود ہے، اکثر پچھلا Rocket.Chat کنٹینر جو صحیح سے بند نہیں ہوا، یا کوئی دوسری ایپ۔ اسے sudo ss -ltnp | grep :3000 سے تلاش کریں، اس پراسس یا کنٹینر کو روکیں، یا میپنگ کے ہوسٹ سائیڈ کو 127.0.0.1:3001:3000 میں تبدیل کریں اور اپنی پراکسی کے proxy_pass کو مماثل کرنے کے لیے اپ ڈیٹ کریں۔

FAQ

کیا Rocket.Chat کو واقعی MongoDB ریپلیکا سیٹ کی ضرورت ہے؟

ہاں، ایک ڈیٹابیس نوڈ والے سنگل سرور کے لیے بھی۔ Rocket.Chat MongoDB چینج اسٹریمز کے ذریعے ریئل ٹائم میں پیغامات پہنچاتا ہے، اور چینج اسٹریمز صرف ریپلیکا سیٹ کی خصوصیت ہیں، ایک اسٹینڈ-الون mongod اسے نہیں کھول سکتا۔ آپ کو متعدد مشینوں کی ضرورت نہیں ہے؛ آپ --replSet rs0 کے ساتھ شروع کردہ ایک MongoDB کنٹینر چلاتے ہیں اور rs.initiate() کے ساتھ ایک رکنی سیٹ شروع کرتے ہیں۔ اس قدم کو چھوڑ دیں تو ڈرائیور کو کبھی پرائمری نہیں ملتی، لہٰذا Rocket.Chat MongoServerSelectionError: Server selection timed out کے ساتھ دوبارہ شروع ہونے کے چکر میں پھنس جاتا ہے اور بوٹنگ کبھی مکمل نہیں کرتا۔

سیلف ہوسٹڈ Rocket.Chat کو کتنی RAM درکار ہے؟

عملی کم از کم کے طور پر 4 GB اور مصروف ٹیم کے لیے 8 GB کا منصوبہ بنائیں۔ Rocket.Chat کا Node عمل تقریباً 1 سے 1.5 GB استعمال کرتا ہے اور MongoDB اپنے WiredTiger کیشے کے لیے بقیہ RAM کا تقریباً نصف لے لیتا ہے، چنانچہ 2 GB والے باکس پر یہ دونوں آپس میں ٹکراتے ہیں اور آؤٹ-آف-میموری کلر کسی بھی حقیقی بوجھ کے تحت mongod کو ختم کر دیتا ہے، جو لاگز میں Killed اور ایگزٹ کوڈ 137 دکھاتا ہے۔ دو GB صرف چند ٹیسٹ صارفین کے ساتھ سافٹ ویئر جانچنے کے لیے کافی ہے۔

میں Rocket.Chat کو HTTPS کے پیچھے کیسے رکھوں؟

اسی VPS پر ایک ریورس پراکسی چلائیں جو TLS کو ختم کرے اور 127.0.0.1:3000 کو فارورڈ کرے، اور کنٹینر کی ROOT_URL کو اپنے عوامی https:// ایڈریس پر سیٹ کریں۔ پراکسی کو WebSocket اپ گریڈ ہیڈرز فارورڈ کرنے چاہئیں ورنہ لاگ ان رک جائے گا۔ Certbot کے ساتھ nginx سب سے آسان سنگل-ایپ سیٹ اپ ہے؛ اگر آپ ایک پراکسی کے پیچھے کئی کنٹینر چلاتے ہیں اور خودکار سرٹیفکیٹ مینجمنٹ چاہتے ہیں تو Traefik زیادہ صاف ستھرا ہے۔

میں سیلف ہوسٹڈ Rocket.Chat کا بیک اپ کیسے لوں؟

والیوم کاپی کرنے کے بجائے mongodump کے ساتھ یکساں ڈیٹابیس ڈمپ لیں: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz۔ اس آرکائیو میں صارفین، چینلز، پیغامات اور سیٹنگز، نیز اگر آپ نے اسٹوریج GridFS پر چھوڑی ہے تو اپ لوڈ کردہ فائلیں شامل ہیں۔ اسے سرور سے کاپی کریں، cron کے ذریعے رات کو خودکار بنائیں، اور ایک عارضی باکس پر mongorestore کی مشق کریں تاکہ آپ جان لیں کہ بحالی واقعی کام کرتی ہے۔

میں MongoDB کو توڑے بغیر Rocket.Chat کو کیسے اپ گریڈ کروں؟

Rocket.Chat کو ایک وقت میں ایک بڑے ورژن سے اپ گریڈ کریں، یہ بوٹ پر مائیگریشنز چلاتا ہے اور بڑے ورژن چھوڑنے سے انکار کرتا ہے، اور پن شدہ امیج ٹیگ بڑھانے سے پہلے ہر ریلیز کے نوٹس پڑھیں۔ curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions کے ساتھ چیک کریں کہ آپ کا ہدف شدہ ریلیز MongoDB کے کن ورژنز کو سپورٹ کرتا ہے، اور جب آپ MongoDB منتقل کریں تو ایک وقت میں ایک بڑے ورژن سے بڑھیں اور ہر چھلانگ کے بعد confirm: true کے ساتھ setFeatureCompatibilityVersion سیٹ کریں۔ ہمیشہ پہلے ایک mongodump لیں۔