Panduan

Oleh Matt Connor 2026-10-10

Cara Self-host Rocket.Chat Menggunakan Docker Compose

Q: Bagaimanakah cara membuat sandaran Rocket.Chat yang dihoskan sendiri?

Lakukan dump pangkalan data yang konsisten dengan mongodump dan bukannya menyalin volum: 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 membiarkan storan pada GridFS. Salin fail tersebut keluar dari pelayan, automasikannya setiap malam dengan cron, dan lakukan latihan mongorestore pada mesin sementara supaya anda tahu proses pemulihan tersebut benar-benar berfungsi.

Panduan lengkap memasang Rocket.Chat pada VPS dengan Docker Compose. Selesaikan ralat replica set MongoDB, konfigurasi TLS, dan strategi sandaran data untuk pasukan anda.

Apa yang anda bina

Sistem sembang pasukan peribadi yang anda miliki sepenuhnya: Rocket.Chat yang dijalankan pada VPS anda sendiri menggunakan Docker Compose, ditamatkan dengan TLS, dengan setiap mesej disimpan dalam pangkalan data MongoDB yang boleh anda sandarkan dan pindahkan. Rocket.Chat ialah alternatif sumber terbuka yang matang kepada Slack dan Teams, yang menawarkan saluran, mesej terus, bebenang, perkongsian fail, serta suara dan video, semuanya pada perkakasan yang anda sewa dan kawal. Walau bagaimanapun, ia bukan satu-satunya pilihan yang boleh dipercayai, dan jika anda masih dalam proses memilih, perbandingan Mattermost, Rocket.Chat, Synapse dan Zulip menyenaraikan perbezaan tersebut berdasarkan perkara yang sering menjadi masalah kemudian hari: RAM, pangkalan data, pemberitahuan tolak (push) mudah alih, SSO dan naik taraf. Aplikasi ini merupakan satu kontena tunggal yang boleh dimulakan dalam beberapa minit. Segala masalah yang mungkin timbul terletak pada pangkalan data di sebelahnya, jadi sebahagian besar panduan ini adalah mengenai MongoDB, dan khususnya satu keperluan yang mengejutkan semua orang pada kali pertama: Rocket.Chat tidak akan berjalan dengan MongoDB kendiri (standalone). Ia memerlukan replica set, walaupun "set" tersebut hanyalah satu nod tunggal.

Prasyarat, dan pengiraan RAM yang jarang diberitahu

Tentukan saiz pelayan dengan jujur. Had 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 sendirian, dan cache WiredTiger MongoDB secara lalai mengambil nilai lebih besar antara 50% daripada (jumlah RAM tolak 1 GB) atau 0.256 GB. Nilai lalai itu mengandaikan mongod memiliki mesin tersebut sepenuhnya: ia dikira daripada jumlah RAM tanpa mengambil kira penggunaan memori oleh Node, jadi ia mencecah 1.5 GB pada pelayan 4 GB dan sekitar 0.5 GB pada pelayan 2 GB, di samping heap Node, memori mongod di luar cache, dan sistem pengendalian. Pada VPS 2 GB, kedua-duanya boleh dimuatkan semasa but tetapi akan bertembung sebaik sahaja trafik sebenar tiba: MongoDB mengembangkan cache-nya, Node mengembangkan heap-nya, kernel kehabisan halaman memori, dan pembunuh out-of-memory (OOM killer) akan menamatkan proses yang paling besar, biasanya mongod. Kontena tersebut mencetak Killed, Docker memulakannya semula, dan anda mendapat pelayan sembang yang terhenti setiap beberapa minit di bawah beban yang sepatutnya boleh ditangani dengan mudah. 2 GB memadai untuk mencuba 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 meningkat. Sediakan bajet untuk sebarang perkhidmatan lain yang dijalankan pada pelayan tersebut juga: meletakkan ruang kerja AFFiNE gaya Notion pada VPS yang sama menambah empat lagi kontena yang bersaing untuk halaman memori yang sama, jadi RAM untuknya perlu ditambah di atas keperluan Rocket.Chat, bukannya diambil daripadanya.

Anda juga memerlukan tiga perkara tersedia sebelum bermula. Nama domain dengan A record yang menghala ke IP awam VPS; ciri masa nyata dan klien mudah alih Rocket.Chat memerlukan nama hos yang stabil, bukan sekadar IP. Port 80 dan 443 dibuka pada firewall pelayan dan firewall rangkaian pembekal anda, yang merupakan kawalan berasingan pada kebanyakan panel. Serta VPS Ubuntu 24.04 KVM yang bersih dengan akses root atau sudo. Jika anda masih membuat keputusan sama ada pelayan sembang adalah perkhidmatan pertama yang sesuai untuk dijalankan, panduan tentang apa yang berbaloi untuk di-self-host pada tahun 2026 membincangkan pertukaran (tradeoffs) yang terlibat.

Memasang enjin Docker dan pemalam Compose

Gunakan repositori apt rasmi Docker, bukan pakej docker.io yang dibekalkan oleh Ubuntu dan bukan binari Python docker-compose yang lama. Compose moden ialah pemalam Docker yang dipanggil sebagai docker compose, dengan ruang, bukannya tanda sempang. docker-compose v1 yang lama telah tamat tempoh hayatnya dan tidak mengendalikan sintaks healthcheck serta dependency 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 tersebut tersedia:

sudo docker version
sudo docker compose version

docker compose version mencetak baris versi adalah semakan yang penting. Keluaran semasa mencetak Docker Compose version v5.x (v5.6.0, dikeluarkan pada 2 Oktober 2026, merupakan versi terkini setakat 2026-10-10); pemasangan yang lebih lama mungkin masih mencetak v2.x, dan Docker menyokong kedua-duanya. Docker menyifatkan Compose v5 sebagai berfungsi sama dengan v2, dinomborkan sebagai v5 untuk mengelakkan kekeliruan dengan format fail compose v2 dan v3 yang lama, jadi kedua-duanya boleh digunakan untuk panduan ini. Jika ia ralat dengan docker: 'compose' is not a docker command, pemalam tersebut tidak dipasang dan anda akan menghadapi kegagalan yang mengelirukan kemudian, selesaikannya di sini.

Fail compose: MongoDB sebagai replica set nod tunggal

Ini adalah bahagian yang sering disalah faham, jadi baca dengan teliti. Rocket.Chat menggunakan change streams MongoDB untuk menolak mesej baharu kepada klien yang bersambung dalam masa nyata, dan change streams hanya tersedia pada replica set. Jika anda menghalakan Rocket.Chat ke mongod kendiri (standalone) biasa, ia akan bersambung, gagal membuka change stream, dan terus berulang (restart-loop) selama-lamanya. Penyelesaiannya tidak rumit: anda menjalankan satu kontena MongoDB biasa, tetapi anda memulakannya dengan --replSet dan kemudian memulakan set satu ahli.

Cipta direktori kerja dan 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 dibuat dengan sengaja. 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 ke setiap antara muka akan mendedahkan halaman log masuk teks biasa terus ke internet awam. MongoDB tidak diterbitkan ke hos langsung; ia hanya boleh dicapai melalui rangkaian dalaman Compose di bawah nama mongodb, yang merupakan nama hos tepat yang digunakan oleh MONGO_URL. MONGO_URL membawa ?replicaSet=rs0, yang menamakan set tersebut secara eksplisit; MongoDB mengesyorkan penetapannya untuk tingkah laku yang konsisten merentas pemacu (drivers). Meninggalkannya kosong tidak akan merosakkan apa-apa secara sendirinya: directConnection secara lalai adalah false, jadi pemacu masih menemui replica set dan menghantar operasi ke nod utama (primary), dengan syarat set tersebut dimulakan dengan nama hos yang boleh diselesaikan oleh Rocket.Chat, yang akan diuruskan dalam bahagian seterusnya. MONGO_OPLOG_URL menghala ke pangkalan data local tempat oplog berada; Rocket.Chat moden lebih mengutamakan change streams, tetapi menetapkannya tidak mendatangkan mudarat dan memastikan laluan kod lama berfungsi dengan baik. depends_on menggunakan condition: service_healthy, jadi Compose menunggu sehingga MongoDB menjawab ping sebelum ia memulakan Rocket.Chat, itulah tujuan healthcheck tersebut.

Tetapkan tag versi sebenar pada kedua-dua imej, mongo:8.0 dan keluaran Rocket.Chat yang eksplisit seperti 8.5.1 di sini, dan jangan sekali-kali menggunakan :latest, yang menukarkan docker pull tanpa pengawasan kepada naik taraf tidak sengaja yang tidak boleh dimigrasi. Semak keluaran stabil Rocket.Chat semasa dan versi MongoDB yang disokongnya sebelum anda menetapkannya. Rocket.Chat menerbitkan dokumen maklumat yang boleh dibaca mesin bagi setiap keluaran: 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 bendera lts yang memberitahu anda sama ada keluaran tersebut adalah binaan sokongan jangka panjang (LTS) yang berbaloi untuk ditetapkan bagi pelayan yang anda tidak mahu pantau secara berterusan. Tidak semua projek menerbitkan imej berversi, dalam kes tersebut penetapan beralih ke sumber: self-hosting penjejak senaman openGym bermaksud menyemak keluar tag git tertentu dan membina daripadanya dan bukannya mengikuti cawangan yang sentiasa berubah.

Memulakan replica set

Naikkan stack tersebut:

sudo docker compose up -d

Rocket.Chat akan terus terhenti serta-merta dan Docker akan sentiasa memulakannya semula; ini adalah perkara biasa kerana replica set belum wujud lagi. Ciptakannya sekali 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 beberapa saat, nod tunggal tersebut akan memilih dirinya sebagai primary; sahkan dengan:

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

Anda sepatutnya melihat PRIMARY. Butiran paling penting dalam keseluruhan halaman ini ialah argumen host: "mongodb:27017". Jika anda menjalankan rs.initiate() kosong tanpa senarai ahli, MongoDB akan mengiklankan replica set tersebut di bawah hostname dalaman kontena, iaitu hash rawak seperti a1b2c3d4e5f6. Rocket.Chat, yang bersambung dari kontena sendiri, tidak dapat menyelesaikan nama tersebut, menyebabkan pemacu MongoDB gagal dalam DNS dan terus mencatat MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 dalam log tanpa henti. Sentiasa mulakan dengan nama servis eksplisit yang sepadan dengan MONGO_URL anda.

But pertama: pantau proses permulaan

Setelah set menjadi primer, but semula Rocket.Chat seterusnya akan bersambung dengan lancar dan memulakan migrasi kali pertama. Ikuti log tersebut:

sudo docker compose logs -f rocketchat

Baris yang anda perlu tunggu ialah sepanduk permulaan:

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

But pertama adalah perlahan, aplikasi menjalankan migrasi pangkalan data dan membina indeks, jadi berikan masa seminit atau dua sebelum anda berasa bimbang. Jika log sebaliknya mengulangi MongoServerSelectionError: Server selection timed out after 30000 ms dengan perihalan topologi jenis ReplicaSetNoPrimary, replica set belum dimulakan; jika ia mengulangi getaddrinfo ENOTFOUND pada hash rawak, ia telah dimulakan dengan hos yang salah. Walau apa pun, kembali satu langkah ke belakang. Sebaik sahaja anda melihat SERVER RUNNING, Rocket.Chat sedang mendengar pada 127.0.0.1:3000 dan sudah tiba masanya untuk meletakkan hostname sebenar serta TLS di hadapannya.

Letakkan di sebalik TLS

Jangan sekali-kali mendedahkan Rocket.Chat melalui HTTP biasa. Log masuk melalui http:// sekali sahaja dan anda telah menyerahkan kata laluan admin anda kepada sesiapa sahaja yang berada di laluan tersebut. Tamatkan TLS dalam reverse proxy pada mesin yang sama dan teruskan ke 127.0.0.1:3000. Dua perkara penting: proksi mesti meneruskan WebSocket upgrade headers, kerana Rocket.Chat adalah masa nyata dan akan tergendala tanpanya, dan ROOT_URL bekas tersebut mesti sepadan dengan alamat HTTPS awam yang ditaip oleh pengguna.

Mulakan dengan blok pelayan nginx HTTP biasa yang melakukan proksi ke aplikasi dan meneruskan upgrade headers. Simpan sebagai /etc/nginx/sites-available/rocketchat, buat symlink ke dalam 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; dan tanpa sijil tidak akan melepasi sudo nginx -t. Muat semula nginx (sudo nginx -t && sudo systemctl reload nginx), kemudian keluarkan sijil tersebut. Laluan paling bersih pada Ubuntu ialah Sijil TLS Let's Encrypt dengan Certbot dan nginx: certbot --nginx menulis semula blok di atas secara terus, menambah listen 443 ssl;, baris ssl_certificate, dan ubah hala automatik 80-ke-443, serta menjadualkan pembaharuan untuk anda. Jika anda sudah menjalankan beberapa bekas di sebalik satu proksi, Traefik dengan TLS automatik untuk banyak aplikasi Docker adalah pilihan yang lebih kemas, tambahkan label router dan service pada perkhidmatan rocketchat dan Traefik akan meminta serta memperbaharui sijil untuk anda, tanpa memerlukan blok nginx langsung. Walau apa pun, tetapkan ROOT_URL kepada https://chat.example.com dalam compose.yml dan jalankan semula sudo docker compose up -d supaya bekas tersebut mengambil perubahan itu. Jika anda mahu pelayan hanya boleh dicapai dari dalam rangkaian anda sendiri dan bukannya internet awam, letakkan di hadapan VPN WireGuard yang dihoskan sendiri pada VPS dan ikat proksi tersebut pada alamat tunnel.

Wizard persediaan kali pertama

Layari https://chat.example.com dan Rocket.Chat akan memandu anda melalui wizard yang ringkas. Pertama, akaun admin, nama sebenar, 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; ini bersifat kosmetik, lengkapkan dan teruskan. Kemudian pilihan yang benar-benar penting: daftarkan ruang kerja ini dengan Rocket.Chat Cloud, atau kekalkan sebagai standalone.

Pendaftaran membolehkan pemberitahuan tolak (push notifications) mudah alih melalui gateway Rocket.Chat dan marketplace add-on, dengan kos hubungan control-plane dengan cloud Rocket.Chat; pemberitahuan yang dihantar melalui gateway juga dikira dalam had bulanan ruang kerja anda. Mod standalone memastikan pelayan kekal peribadi sepenuhnya dan bebas daripada dependency, tetapi aplikasi rasmi iOS dan Android tidak akan menerima pemberitahuan tolak, kerana dokumentasi Rocket.Chat menyatakan aplikasi tersebut hanya berfungsi dengan gateway cloud mereka, dan gateway tidak akan berjalan pada ruang kerja yang tidak berdaftar. Cara untuk mengatasinya adalah dengan membina aplikasi mudah alih white-labeled anda sendiri: matikan gateway dalam tetapan Push, masukkan sijil APNs dan kelayakan Firebase Cloud Messaging anda sendiri, dan minta pengguna anda memasang aplikasi anda sebagai ganti aplikasi rasmi. Pilih standalone jika privasi adalah matlamat utama dan pengguna anda menggunakan aplikasi web, atau jika anda bersedia untuk mengeluarkan aplikasi mudah alih anda sendiri; pilih pendaftaran jika pemberitahuan tolak pada aplikasi rasmi adalah keperluan mutlak. Anda boleh mengubah keputusan anda kemudian di bawah menu Admin.

Kunci akses sebelum anda menjemput sesiapa

Rocket.Chat dihantar dengan pendaftaran terbuka diaktifkan, secara lalai Borang Pendaftaran ditetapkan kepada Public, jadi sesiapa sahaja yang menemui URL tersebut boleh mencipta akaun. Pada hostname awam, ini merupakan pintu terbuka. Pergi ke Admin → Settings → Accounts → Registration dan tetapkan Registration Form kepada Disabled, supaya anda boleh 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 melainkan anda secara khusus mahukan saluran baca-sahaja awam. Jika mencipta setiap akaun secara manual kedengaran membebankan dan ini bukan satu-satunya servis yang dilog masuk oleh pasukan anda, halakan log masuk OAuth Rocket.Chat ke pelayan SSO Authentik yang dihoskan sendiri sebaliknya, supaya ahli yang menyertai dan keluar diuruskan sekali di satu tempat dan bukannya aplikasi demi aplikasi.

Tentukan juga ke mana muat naik akan pergi. Storan File Upload lalai ialah GridFS, yang menyimpan setiap imej dan lampiran di dalam MongoDB itu sendiri. Itu mudah, tetapi ia bermakna 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. Jika pasukan anda bertukar-tukar keseluruhan pustaka foto dan bukannya tangkapan skrin sekali-sekala, perkara itu sepatutnya berada dalam pelayan foto khusus dan bukannya pangkalan data sembang, dan perbandingan PhotoPrism dan Immich menimbang kos RAM bagi setiap satu berbanding arahan sandaran yang diperlukannya. Bagi pasukan kecil, GridFS sudah memadai; cuma ketahui bahawa sandaran anda akan menjadi lebih berat dari semasa ke semasa.

Sandaran dengan mongodump

Semua data anda berada dalam volum mongodb_data. Jangan sekadar menyalin volum tersebut semasa pangkalan data sedang berjalan; lakukan dump yang konsisten dengan mongodump, yang distrim ke fail pada hos:

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

Arkib tunggal yang dimampatkan dengan gzip itu mengandungi keseluruhan ruang kerja anda: pengguna, saluran, mesej, tetapan, dan jika anda membiarkan muat naik pada GridFS, fail-fail tersebut juga disertakan. Jika anda memindahkan muat naik ke sistem fail atau S3, sandarkan storan tersebut secara berasingan. Lakukan pemulihan pada stack yang 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 pelayan, ke storan objek, pelayan lain, atau mana-mana lokasi supaya jika VPS anda rosak, sandaran tersebut tidak hilang bersamanya. Jalankan dump tersebut melalui cron setiap malam. Sandaran yang tidak pernah anda pulihkan hanyalah satu harapan, bukan sandaran sebenar; amalkan proses pemulihan sekali pada VPS sementara supaya anda tahu ia berfungsi sebelum anda benar-benar memerlukannya.

Naik taraf: sematkan tag, baca nota, patuhi matriks Mongo

Dua peraturan menjadikan proses naik taraf lebih terkawal. Pertama, naik taraf Rocket.Chat satu versi utama pada satu masa. Ia menjalankan migrasi skema semasa but, dan dokumentasi naik taraf Rocket.Chat menyatakan untuk sentiasa mengemas kini secara berurutan merentasi versi utama, dengan amaran bahawa melangkau versi utama boleh menyebabkan isu keserasian yang serius. Jangan bergantung pada perisian untuk menghalang anda: tiada apa-apa dalam dokumentasinya menjanjikan bahawa lompatan dari 6.x terus ke 8.x akan ditolak dengan selamat, dan migrasi yang gagal di pertengahan jalan akan membiarkan kunci (lock) ditetapkan dan memerlukan pembaikan manual. Tukar tag imej kepada keluaran terkini bagi versi utama seterusnya, baca nota keluaran tersebut untuk perubahan yang memecahkan keserasian (breaking changes), jalankan docker compose up -d, dan perhatikan log sehingga migrasi selesai sebelum meneruskan. Kedua, patuhi matriks sokongan MongoDB. Setiap keluaran Rocket.Chat menyokong set versi MongoDB yang khusus, dan curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions memberitahu anda versi yang mana. 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 yang eksplisit, atau ia akan menolak 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 polisi insurans yang menyeluruh.

Mod kegagalan, dengan rentetan tepat

Rocket.Chat mengalami gelung mulakan semula sejurus selepas docker compose up, dan docker compose logs rocketchat dipenuhi dengan MongoServerSelectionError. MongoDB sedang berjalan tetapi pemacu tidak dapat memilih nod utama (primary), dan rentetan tepat tersebut memberitahu anda kesilapan yang dilakukan. Server selection timed out after 30000 ms dengan jenis topologi ReplicaSetNoPrimary bermakna anda tidak pernah menjalankan rs.initiate(), set tersebut belum mempunyai konfigurasi. getaddrinfo ENOTFOUND diikuti dengan hash rawak bermakna anda memulakan (initiate) 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-nya adalah hash rawak, mulakan semula dengan nama servis.

UI web dimuatkan tetapi log masuk berputar selama-lamanya dan tidak pernah selesai. Buka konsol pelayar dan anda akan melihat WebSocket connection to 'wss://chat.example.com/websocket' failed. Ini hampir selalu disebabkan oleh ketidakpadanan ROOT_URL atau proksi yang tidak memajukan (forward) header naik taraf (upgrade). Sahkan ROOT_URL adalah sama dengan alamat awam yang tepat termasuk https://, dan blok location nginx anda menetapkan Upgrade dan Connection "upgrade" dengan proxy_http_version 1.1. Tukar mana-mana bahagian tersebut dan jalankan semula docker compose up -d.

Kontena terus mati 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. Pelayan kehabisan RAM. Penyelesaian sebenar ialah VPS yang lebih besar, minimum 4 GB. Sebagai langkah sementara, tambah swap dan hadkan cache MongoDB dengan --wiredTigerCacheSizeGB dalam command miliknya, tetapkan di bawah nilai lalai dan bukannya di atasnya, contohnya 1 pada kotak 4 GB (lalai 1.5) atau 0.3 pada kotak 2 GB (lalai sekitar 0.5), 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 sudah menggunakan port 3000, selalunya kontena Rocket.Chat terdahulu yang tidak berhenti dengan sempurna, atau aplikasi lain. Cari proses tersebut dengan sudo ss -ltnp | grep :3000, hentikan proses atau kontena itu, atau tukar bahagian hos bagi pemetaan kepada 127.0.0.1:3001:3000 dan kemas kini proxy_pass proksi 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 dalam masa nyata menggunakan MongoDB change streams, dan change streams merupakan ciri yang hanya terdapat pada replica set; mongod yang berdiri sendiri tidak boleh membukanya. Anda tidak memerlukan berbilang mesin; anda hanya perlu menjalankan satu kontena MongoDB yang dimulakan dengan --replSet rs0 dan memulakan set satu ahli dengan rs.initiate(). Jika langkah itu dilangkau, pemacu tidak akan menemui primary, menyebabkan Rocket.Chat terperangkap dalam gelung mulakan semula dengan MongoServerSelectionError: Server selection timed out dan tidak akan selesai melakukan but.

Berapakah RAM yang diperlukan oleh Rocket.Chat yang dihoskan sendiri?

Rancang untuk 4 GB sebagai minimum praktikal dan 8 GB untuk pasukan yang aktif. Proses Node Rocket.Chat menggunakan kira-kira 1 hingga 1.5 GB, dan cache WiredTiger lalai MongoDB adalah separuh daripada (jumlah RAM tolak 1 GB), dengan saiz seolah-olah tiada aplikasi lain yang berjalan pada mesin tersebut. Pada mesin 2 GB, cache tersebut, heap Node, dan overhead mongod sendiri akan bertembung, dan out-of-memory killer akan menamatkan mongod di bawah sebarang beban sebenar, memaparkan Killed dalam log dan exit code 137. Dua GB hanya mencukupi untuk menilai perisian tersebut dengan beberapa pengguna ujian.

Bagaimanakah cara meletakkan Rocket.Chat di sebalik HTTPS?

Jalankan reverse proxy pada VPS yang sama untuk melakukan TLS termination dan menghalakan trafik ke 127.0.0.1:3000, serta tetapkan ROOT_URL kontena kepada alamat https:// awam anda. Proksi mesti menghantar header WebSocket upgrade atau proses log masuk akan tergantung. Certbot dengan nginx adalah persediaan aplikasi tunggal yang paling ringkas; Traefik lebih kemas jika anda menjalankan beberapa kontena di sebalik satu proksi dan mahukan pengurusan sijil secara automatik.

Bagaimanakah cara membuat sandaran Rocket.Chat yang dihoskan sendiri?

Lakukan dump pangkalan data yang konsisten dengan mongodump dan bukannya menyalin volum: 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 membiarkan storan pada GridFS. Salin fail tersebut keluar dari pelayan, automasikannya setiap malam dengan cron, dan lakukan latihan mongorestore pada mesin sementara supaya anda tahu proses pemulihan tersebut benar-benar berfungsi.

Bagaimanakah cara menaik taraf Rocket.Chat tanpa merosakkan MongoDB?

Naik taraf Rocket.Chat satu versi utama pada satu masa. Ia menjalankan migrasi semasa but dan dokumentasinya memberi amaran bahawa melangkau versi utama boleh menyebabkan isu keserasian yang serius dan bukannya menghalang anda daripada berbuat demikian. Baca nota setiap keluaran sebelum menukar tag imej yang ditetapkan. Semak versi MongoDB yang disokong oleh keluaran 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 buat mongodump terlebih dahulu.

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