SSD Nodes Learn
Panduan Matt ConnorOleh Matt Connor · Dikemas kini 2026-07-24

Cara pasang Rocket.Chat guna Docker Compose

Panduan bina Rocket.Chat pada VPS menggunakan Docker Compose. Pelajari cara tetapkan MongoDB replica set dan TLS untuk elak ralat pangkalan data pada VPS anda.

Apa yang anda bina

Satu sembang pasukan peribadi milik anda sepenuhnya: Rocket.Chat yang dijalankan pada VPS sendiri menggunakan Docker Compose, dilindungi oleh TLS, dengan setiap mesej disimpan dalam pangkalan data MongoDB yang boleh anda sandarkan dan pindahkan. Rocket.Chat adalah alternatif sumber terbuka yang matang kepada Slack dan Teams — merangkumi saluran, mesej terus, thread, perkongsian fail, serta suara dan video, semuanya pada perkakasan yang anda sewa dan kawal. Aplikasi ini adalah satu bekas (container) tunggal yang boleh diaktifkan dalam masa beberapa minit. Segala ralat yang berlaku biasanya berkaitan dengan pangkalan data di sebelahnya, jadi sebahagian besar panduan ini adalah mengenai MongoDB, terutamanya satu keperluan yang mengejutkan semua orang pada kali pertama: Rocket.Chat tidak akan berjalan menggunakan MongoDB tunggal (standalone). Ia memerlukan replica set, walaupun "set" tersebut hanya terdiri daripada satu nod tunggal.

Prasyarat, dan pengiraan RAM yang jarang diberitahu

Tentukan saiz pelayan dengan jujur. Tahap minimum yang realistik untuk pasukan kecil ialah 2 vCPU dan 4 GB RAM. Proses Node.js Rocket.Chat memerlukan sekitar 1 hingga 1.5 GB secara bersendirian, manakala cache WiredTiger MongoDB akan menggunakan kira-kira separuh daripada baki RAM yang ada secara lalai. Pada VPS 2 GB, kedua-duanya boleh berfungsi semasa but, tetapi akan mengalami konflik sebaik sahaja trafik sebenar tiba: cache MongoDB berkembang, heap Node berkembang, kernel kehabisan halaman, dan out-of-memory killer akan menghentikan proses yang paling besar — biasanya mongod. Kontena akan memaparkan Killed, Docker akan memulakan semula kontena tersebut, dan anda akan mendapat pelayan sembang yang terhenti setiap beberapa minit di bawah bebanan yang sepatutnya boleh ditangani. 2 GB memadai untuk ujian awal dengan dua orang pengguna; ia bukan untuk pelayan pasukan. Mulakan dengan 4 GB, dan berikan 8 GB jika anda menjangkakan puluhan pengguna serentak, panggilan video, atau sejarah muat naik yang semakin bertambah.

Anda juga memerlukan tiga perkara sebelum bermula. Nama domain dengan rekod A yang menghala ke IP awam VPS — ciri masa nyata Rocket.Chat dan klien mudah alih memerlukan nama hos yang stabil, bukan sekadar IP. Port 80 dan 443 mesti dibuka pada firewall pelayan dan juga firewall rangkaian penyedia anda, yang merupakan kawalan berasingan pada kebanyakan panel. Dan VPS Ubuntu 24.04 KVM yang baharu dengan akses root atau sudo. Jika anda masih ragu-ragu sama ada pelayan sembang adalah perkhidmatan pertama yang sesuai untuk dijalankan, panduan tentang apa yang berbaloi untuk dihoskan sendiri pada 2026 menjelaskan segala pertimbangan tersebut.

Pasang Docker engine dan plugin Compose

Gunakan repositori apt Docker sendiri. Jangan gunakan pakej docker.io yang dibekalkan oleh Ubuntu atau binari Python docker-compose yang lama. Compose moden ialah plugin Docker yang dipanggil sebagai docker compose — menggunakan ruang, bukan tanda sempang. Versi lama docker-compose v1 telah tamat tempoh sokongan dan tidak mengendalikan sintaks healthcheck serta kebergantungan di bawah dengan betul.

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

Sahkan kedua-dua komponen telah dipasang:

sudo docker version
sudo docker compose version

Semakan penting ialah apabila docker compose version memaparkan sesuatu seperti Docker Compose version v2.x. Jika ralat docker: 'compose' is not a docker command berlaku, plugin tidak dipasang dan anda akan menghadapi kegagalan yang mengelirukan kemudian — selesaikan masalah ini sekarang.

Fail compose: MongoDB sebagai single-node replica set

Bahagian ini sering disalah faham, jadi sila baca dengan teliti. Rocket.Chat menggunakan change streams MongoDB untuk menghantar mesej baharu kepada klien yang disambungkan secara masa nyata, dan change streams hanya tersedia pada replica set. Jika anda mengarahkan Rocket.Chat ke mongod standalone biasa, ia akan bersambung, gagal membuka change stream, dan mengalami kitaran restart (restart-loop) selama-lamanya. Penyelesaiannya mudah: anda menjalankan satu kontena MongoDB biasa, tetapi anda memulakannya dengan --replSet dan kemudian memulakan (initialise) set satu ahli.

Cipta direktori kerja dan fail 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:

Beberapa pilihan di sini adalah disengajakan. Port Rocket.Chat diterbitkan ke 127.0.0.1:3000, bukan 0.0.0.0 — aplikasi itu sendiri tidak mempunyai TLS, jadi hanya reverse proxy pada mesin yang sama harus mencapainya; mengikatnya (binding) ke setiap interface akan mendedahkan halaman log masuk teks biasa terus ke internet awam. MongoDB tidak diterbitkan ke host sama sekali; ia hanya boleh dicapai melalui rangkaian dalaman Compose di bawah nama mongodb, iaitu hostname yang digunakan oleh MONGO_URL. MONGO_URL mengandungi ?replicaSet=rs0 — jika anda membuangnya, driver akan menganggap pelayan sebagai standalone walaupun ia adalah replica set, dan change streams tetap akan gagal. MONGO_OPLOG_URL merujuk kepada pangkalan data local di mana oplog berada; Rocket.Chat moden lebih mengutamakan change streams, tetapi menetapkannya tidak berbahaya dan mengekalkan keserasian kod lama. depends_on menggunakan condition: service_healthy, jadi Compose akan menunggu sehingga MongoDB menjawab ping sebelum memulakan Rocket.Chat — itulah fungsi healthcheck.

Gunakan tag versi sebenar pada kedua-dua imej — mongo:8.0 dan versi Rocket.Chat yang eksplisit seperti 8.5.1 di sini — dan jangan sekali-kali menggunakan :latest, yang menukarkan docker pull yang tidak dipantau kepada naik taraf tidak sengaja yang tidak boleh dimigrasikan. Semak versi stabil Rocket.Chat semasa dan versi MongoDB yang disokong sebelum anda menetapkan tag. Rocket.Chat menerbitkan dokumen maklumat yang boleh dibaca mesin bagi setiap versi: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' mengembalikan compatibleMongoVersions: ["8.0"] untuk 8.5.1, jadi mongo:8.0 adalah satu-satunya enjin yang disokong, ditambah dengan flag lts yang memberitahu anda sama ada versi tersebut adalah binaan long-term-support yang berbaloi untuk ditetapkan bagi pelayan yang tidak mahu anda pantau secara manual.

Initialise the replica set

Jalankan stack:

sudo docker compose up -d

Rocket.Chat akan mengalami kegagalan (crash) serta-merta dan Docker akan terus memulakan semula (restart) ia — ini adalah perkara biasa kerana replica set belum wujud. Bina replica set secara manual:

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

Hasil yang betul ialah { ok: 1 }. Dalam masa beberapa saat, nod tunggal akan melantik dirinya sebagai primary; sahkan dengan:

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

Anda perlu melihat PRIMARY. Perkara paling penting pada halaman ini ialah argumen host: "mongodb:27017". Jika anda menjalankan rs.initiate() tanpa senarai ahli, MongoDB akan mengiklankan replica set di bawah hostname dalaman kontena — hash rawak seperti a1b2c3d4e5f6. Rocket.Chat, yang bersambung dari kontena sendiri, tidak dapat menyelesaikan (resolve) nama tersebut, menyebabkan pemacu (driver) MongoDB gagal pada DNS dan berulang selamanya dengan log MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Sentiasa mulakan dengan nama servis eksplisit yang sepadan dengan MONGO_URL anda.

Boot pertama: pantau proses permulaan

Setelah set ditetapkan sebagai utama, pemulaan semula Rocket.Chat yang seterusnya akan bersambung dengan lancar dan memulakan migrasi larian pertama. Ikuti log:

sudo docker compose logs -f rocketchat

Baris yang perlu anda tunggu ialah banner permulaan:

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

Boot pertama adalah perlahan — aplikasi menjalankan migrasi pangkalan data dan membina indeks, jadi berikan masa satu atau dua minit sebelum anda bimbang. Jika log mengulang MongoServerSelectionError: Server selection timed out after 30000 ms dengan deskripsi topologi jenis ReplicaSetNoPrimary, replica set tidak dimulakan; jika ia mengulang getaddrinfo ENOTFOUND pada hash rawak, ia dimulakan dengan hos yang salah. Dalam kedua-dua keadaan, kembali ke langkah sebelumnya. Sebaik sahaja anda melihat SERVER RUNNING, Rocket.Chat sedang mendengar pada 127.0.0.1:3000 dan sudah tiba masanya untuk meletakkan hostname sebenar dan TLS di hadapannya.

Letakkannya di belakang TLS

Jangan dedahkan Rocket.Chat menggunakan HTTP biasa. Log masuk melalui http:// sekali sahaja, dan anda telah menyerahkan kata laluan admin kepada sesiapa sahaja dalam laluan tersebut. Tamatkan TLS pada reverse proxy di mesin yang sama dan hantarkan ke 127.0.0.1:3000. Dua perkara adalah penting: proxy mesti menghantar WebSocket upgrade headers kerana Rocket.Chat adalah masa nyata dan akan gagal tanpanya, dan ROOT_URL bekas (container) mesti sepadan tepat dengan alamat HTTPS awam yang ditaip oleh pengguna.

Mulakan dengan blok pelayan nginx HTTP biasa yang menghantar permintaan ke aplikasi dan menghantar upgrade headers. Simpan sebagai /etc/nginx/sites-available/rocketchat, buat pautan simbolik (symlink) ke sites-enabled, dan muat semula:

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;
    }
}

Biarkan ia pada port 80 buat masa ini — blok dengan listen 443 ssl; tanpa sijil tidak akan melepasi sudo nginx -t. Muat semula nginx (sudo nginx -t && sudo systemctl reload nginx), kemudian keluarkan sijil. Cara paling bersih pada Ubuntu adalah Sijil TLS Let's Encrypt dengan Certbot dan nginx: certbot --nginx menulis semula blok di atas, menambah listen 443 ssl;, baris ssl_certificate, dan penghalaan automatik 80-ke-443, serta menjadualkan pembaharuan untuk anda. Jika anda sudah menjalankan beberapa bekas di belakang satu proxy, Traefik dengan TLS automatik untuk banyak aplikasi Docker adalah pilihan yang lebih kemas — tambah label router dan service pada servis rocketchat dan Traefik akan meminta serta memperbaharui sijil untuk anda, tanpa memerlukan blok nginx langsung. Dalam mana-mana cara sekalipun, tetapkan ROOT_URL kepada https://chat.example.com dalam compose.yml dan jalankan semula sudo docker compose up -d supaya bekas mengambil perubahan tersebut. Jika anda mahu pelayan hanya boleh dicapai dari dalam rangkaian anda sendiri dan bukannya internet awam, letakkannya di hadapan VPN WireGuard self-hosted pada VPS dan ikat proxy ke alamat terowong (tunnel address).

Wizard tetapan penggunaan pertama

Layari https://chat.example.com dan Rocket.Chat akan membimbing anda melalui wizard ringkas. Pertama, akaun admin — nama penuh, nama pengguna, e-mel, dan kata laluan yang kuat; ini adalah satu-satunya akaun yang wujud, jadi jangan hilangkannya. Seterusnya, maklumat organisasi dan pelayan — nama, industri, saiz, nama tapak, dan bahasa lalai; maklumat ini hanyalah kosmetik, isi sahaja dan teruskan. Kemudian, pilihan yang penting: daftar ruang kerja ini dengan Rocket.Chat Cloud, atau kekal sebagai standalone.

Pendaftaran membolehkan pemberitahuan push mudah alih melalui gerbang Rocket.Chat dan pasaran add-on, tetapi ia memerlukan hubungan control-plane dengan awan Rocket.Chat. Mod standalone mengekalkan pelayan secara peribadi sepenuhnya dan tanpa kebergantungan, tetapi pemberitahuan push iOS dan Android akan berhenti berfungsi kerana Apple dan Google tidak membenarkan aplikasi binaan sendiri memegang sijil push — aplikasi rasmi menggunakan gerbang awan. Pilih standalone jika privasi adalah keutamaan dan pengguna anda menggunakan aplikasi web; pilih pendaftaran jika pemberitahuan push mudah alih adalah wajib. Anda boleh menukar pilihan ini kemudian di bawah Admin.

Sekat akses sebelum menjemput sesiapa

Rocket.Chat disertakan dengan pendaftaran terbuka pada — secara lalai, Borang Pendaftaran ditetapkan kepada Public, jadi sesiapa yang menemui URL tersebut boleh mencipta akaun. Ini merupakan pintu terbuka pada hos awam. Pergi ke Admin → Settings → Accounts → Registration dan tetapkan Registration Form kepada Disabled, supaya anda mencipta akaun secara manual atau melalui pautan jemputan, atau kepada Secret URL. Semasa anda berada di sana, matikan Allow Anonymous Read dan Allow Anonymous Write kecuali jika anda mahukan saluran baca sahaja yang awam.

Tentukan juga lokasi muat naik fail. Storan File Upload lalai ialah GridFS, yang menyimpan setiap imej dan lampiran di dalam MongoDB itu sendiri. Ini adalah ringkas, tetapi ia bermaksud pangkalan data anda — dan setiap mongodump yang anda ambil — akan berkembang tanpa had apabila orang menampal tangkapan skrin. Di bawah Admin → Settings → File Upload, anda boleh menukar storan kepada sistem fail tempatan atau bucket yang serasi dengan S3, dan menetapkan saiz fail maksimum yang munasabah. Untuk pasukan kecil, GridFS sudah memadai; cuma perlu tahu bahawa sandaran (backup) anda akan menjadi lebih besar dari semasa ke semasa.

Sandaran dengan mongodump

Semua data anda berada dalam volum mongodb_data. Jangan salin volum semasa pangkalan data sedang berjalan — lakukan dump yang konsisten dengan mongodump, dan strim ke fail pada hos:

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

Arkib gzipped tunggal itu adalah keseluruhan ruang kerja anda: pengguna, saluran, mesej, tetapan, dan — jika anda menetapkan muat naik pada GridFS — fail juga. Jika anda memindahkan muat naik ke sistem fail atau S3, buat sandaran untuk storan tersebut secara berasingan. Pulihkan pada susunan baharu dengan memulakan replica set terlebih dahulu, kemudian:

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

Salin arkib tersebut keluar dari mesin — storan objek, pelayan lain, atau mana-mana lokasi di mana kegagalan VPS tidak akan turut memadamkan sandaran tersebut — dan jalankan dump daripada cron setiap malam. Sandaran yang tidak pernah dipulihkan hanyalah harapan, bukan sandaran; cuba lakukan pemulihan sekali pada VPS percubaan supaya anda tahu ia berfungsi sebelum anda memerlukannya.

Naik Taraf: pin tag, baca nota, patuhi matriks Mongo

Dua peraturan memastikan proses naik taraf berjalan lancar. Pertama, naik taraf Rocket.Chat satu versi utama pada satu masa. Sistem ini menjalankan migrasi skema semasa but. Ia sengaja menghalang lompatan versi utama; jika anda cuba melompat dari 6.x terus ke 8.x, proses akan terhenti dengan ralat migrasi bagi mengelakkan kerosakan data. Kemas kini tag imej ke versi rilis terbaharu bagi versi utama seterusnya, baca nota rilis tersebut untuk perubahan yang memecahkan fungsi (breaking changes), jalankan docker compose up -d, dan pastikan log menunjukkan migrasi selesai sebelum meneruskan langkah seterusnya. Kedua, patuhi matriks sokongan MongoDB. Setiap rilis Rocket.Chat menyokong set versi MongoDB yang khusus, dan curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions menyatakan versi tersebut. Apabila anda menaik taraf MongoDB — contohnya dari 7.0 ke 8.0 — lakukan satu versi utama pada satu masa dan tetapkan versi keserasian ciri (feature-compatibility version) selepas setiap langkah. Pada MongoDB 8.0, arahan tersebut memerlukan confirm: true secara eksplisit, atau ia akan ditolak dengan mesej yang meminta anda menjalankannya semula dengan flag pengesahan:

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

Lakukan mongodump sebelum setiap naik taraf bagi mana-mana komponen. Itu adalah satu-satunya perlindungan anda.

Mod kegagalan, dengan rentetan teks yang tepat

Rocket.Chat mengalami kitaran semula (restart-loops) sejurus selepas docker compose up, dan docker compose logs rocketchat dipenuhi dengan MongoServerSelectionError. MongoDB sedang berjalan tetapi pemacu (driver) tidak dapat memilih primary, dan rentetan teks yang tepat akan memberitahu kesilapan yang anda lakukan. Server selection timed out after 30000 ms dengan jenis topologi ReplicaSetNoPrimary bermaksud anda tidak menjalankan rs.initiate() — set tersebut belum mempunyai konfigurasi. getaddrinfo ENOTFOUND diikuti dengan hash rawak bermaksud anda memulakan tanpa host: "mongodb:27017" yang eksplisit, jadi MongoDB mengiklankan nama hos kontena yang tidak boleh diselesaikan. Diagnosis dengan sudo docker compose exec mongodb mongosh --eval 'rs.status()': jika ia ralat MongoServerError: no replset config has been received, mulakan set tersebut; jika ia menunjukkan ahli yang name adalah hash rawak, mulakan semula dengan nama perkhidmatan.

UI web dimuatkan tetapi log masuk berpusing selamanya dan tidak selesai. Buka konsol pelayar dan anda akan melihat WebSocket connection to 'wss://chat.example.com/websocket' failed. Ini hampir sentiasa disebabkan oleh ketidakpadanan ROOT_URL atau proxy yang tidak memanjangkan (forwarding) pengepala upgrade. Sahkan ROOT_URL adalah sama dengan alamat awam yang tepat termasuk https://, dan blok nginx location anda menetapkan Upgrade dan Connection "upgrade" dengan proxy_http_version 1.1. Tukar mana-mana bahagian dan jalankan semula docker compose up -d.

Sesuatu kontena terus terhenti dan docker compose ps menunjukkan ia Restarting. docker compose logs terputus di tengah baris dan sudo dmesg | tail menunjukkan Out of memory: Killed process 12345 (mongod) daripada oom-killer; kod keluar adalah 137. Sistem kehabisan RAM. Penyelesaian sebenar adalah VPS yang lebih besar — minimum 4 GB. Sebagai penyelesaian sementara, tambah swap dan hadkan cache MongoDB dengan --wiredTigerCacheSizeGB 1 dalam command, tetapi swap hanya melambatkan OOM seterusnya di bawah beban sebenar:

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

docker compose up gagal dengan Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Sesuatu telah menggunakan port 3000 — selalunya kontena Rocket.Chat terdahulu yang tidak berhenti dengan bersih, atau aplikasi lain. Cari ia dengan sudo ss -ltnp | grep :3000, hentikan proses atau kontena tersebut, atau tukar bahagian hos pemetaan kepada 127.0.0.1:3001:3000 dan kemas kini proxy_pass proxy anda supaya sepadan.

FAQ

Adakah Rocket.Chat benar-benar memerlukan MongoDB replica set?

Ya, walaupun untuk pelayan tunggal dengan satu nod pangkalan data. Rocket.Chat menghantar mesej secara masa nyata menggunakan MongoDB change streams, dan change streams hanyalah ciri untuk replica-set — mongod yang berdiri sendiri tidak boleh membukanya. Anda tidak memerlukan banyak mesin; anda hanya perlu menjalankan satu kontena MongoDB yang dimulakan dengan --replSet rs0 dan mulakan set satu ahli dengan rs.initiate(). Jika langkah ini dilewati, pemacu tidak akan menemui primary, menyebabkan Rocket.Chat mengalami kitaran semula dengan MongoServerSelectionError: Server selection timed out dan gagal memulakan proses.

Berapakah RAM yang diperlukan oleh Rocket.Chat self-hosted?

Sediakan 4 GB sebagai minimum praktikal dan 8 GB untuk pasukan yang sibuk. Proses Node Rocket.Chat menggunakan sekitar 1 hingga 1.5 GB dan MongoDB menggunakan kira-kira separuh daripada baki RAM untuk cache WiredTiger. Pada mesin 2 GB, kedua-duanya akan bertembung dan out-of-memory killer akan menamatkan mongod di bawah beban sebenar, menunjukkan Killed dalam log dan kod keluar 137. 2 GB hanya mencukupi untuk menilai perisian dengan beberapa pengguna ujian sahaja.

Bagaimanakah cara untuk meletakkan Rocket.Chat di belakang HTTPS?

Jalankan reverse proxy pada VPS yang sama untuk menamatkan TLS dan menghantar trafik ke 127.0.0.1:3000, dan tetapkan ROOT_URL kontena kepada alamat https:// awam anda. Proxy mesti menghantar header WebSocket upgrade atau proses log masuk akan tergantung. Certbot dengan nginx adalah tetapan aplikasi tunggal yang paling mudah; Traefik adalah lebih kemas jika anda menjalankan beberapa kontena di belakang satu proxy dan mahukan pengurusan sijil automatik.

Bagaimanakah cara untuk membuat sandaran (backup) Rocket.Chat self-hosted?

Lakukan pangkalan data dump yang konsisten dengan mongodump dan bukannya menyalin volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Arkib tersebut mengandungi pengguna, saluran, mesej, dan tetapan, serta fail yang dimuat naik jika anda menggunakan storan pada GridFS. Salin arkib tersebut keluar dari pelayan, automatikkan setiap malam dengan cron, dan lakukan latihan mongorestore pada mesin ujian supaya anda tahu proses pemulihan (restore) benar-benar berfungsi.

Bagaimanakah cara untuk menaik taraf Rocket.Chat tanpa merosakkan MongoDB?

Naik taraf Rocket.Chat satu versi utama pada satu masa — ia menjalankan migrasi semasa but dan tidak membenarkan lompatan versi utama — dan baca nota setiap versi sebelum menukar tag imej yang ditetapkan. Semak versi MongoDB yang disokong oleh versi sasaran anda dengan curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions, dan apabila anda memindahkan MongoDB, lakukan satu versi utama pada satu masa dan tetapkan setFeatureCompatibilityVersion dengan confirm: true selepas setiap langkah. Sentiasa lakukan mongodump terlebih dahulu.