Oleh Cara Self-host Rocket.Chat Menggunakan Docker Compose
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 sedang bina
Satu ruang sembang pasukan peribadi yang anda miliki sepenuhnya: Rocket.Chat yang berjalan 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 menyediakan saluran, mesej terus, bebenang, perkongsian fail, serta suara dan video, semuanya pada perkakasan yang anda sewa dan kawal. Aplikasi ini merupakan satu bekas tunggal yang boleh dimulakan dalam masa beberapa minit. Segala masalah yang berlaku berpunca daripada 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 kira-kira 1 hingga 1.5 GB secara sendirian, dan cache WiredTiger MongoDB secara lalai akan mengambil kira-kira separuh daripada baki RAM yang ada. 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 memulakan semula kontena itu, dan anda mendapat pelayan sembang yang terputus setiap beberapa minit di bawah beban yang sepatutnya boleh ditangani dengan mudah. 2 GB memadai untuk mencuba fungsi asas dengan dua orang pengguna; ia bukan untuk pelayan pasukan. Mulakan dengan 4 GB, dan sediakan 8 GB jika anda menjangkakan puluhan pengguna serentak, panggilan video, atau sejarah muat naik yang semakin meningkat.
Anda juga perlu menyediakan tiga perkara 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 baharu dengan akses root atau sudo. Jika anda masih mempertimbangkan sama ada pelayan sembang adalah servis pertama yang sesuai untuk dijalankan, panduan tentang apa yang berbaloi untuk di-self-host pada tahun 2026 menggariskan pertimbangan yang perlu dibuat.
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, bukan 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-pluginSahkan kedua-dua komponen tersebut tersedia:
sudo docker version
sudo docker compose versiondocker compose version yang memaparkan sesuatu seperti Docker Compose version v2.x adalah semakan yang penting. Jika ia mengeluarkan ralat 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 jalankan satu kontena MongoDB biasa, tetapi anda mulakannya dengan --replSet dan kemudian lakukan inisialisasi set satu ahli.
Cipta direktori kerja dan satu 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 hostname tepat yang digunakan oleh MONGO_URL. MONGO_URL membawa ?replicaSet=rs0, jika anda meninggalkannya, pemacu (driver) akan menganggap pelayan sebagai kendiri walaupun ia adalah replica set, dan change streams akan tetap gagal. 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 akan 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 jelas seperti 8.5.1 di sini. Jangan gunakan :latest kerana tindakan itu menukar docker pull tanpa pengawasan menjadi peningkatan tidak sengaja yang tidak boleh dimigrasikan. Semak keluaran stabil Rocket.Chat semasa dan versi MongoDB yang disokongnya sebelum menetapkan versi. 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. Oleh itu, mongo:8.0 ialah satu-satunya enjin yang disokong, bersama-sama flag lts yang menunjukkan sama ada keluaran itu ialah binaan sokongan jangka panjang yang wajar ditetapkan versinya untuk pelayan yang tidak mahu anda pantau secara berterusan. Tidak semua projek menerbitkan imej berversi. Dalam keadaan itu, penetapan versi dibuat pada sumber: mengehos sendiri penjejak senaman openGym bermaksud menyemak checkout pada tag git tertentu dan membinanya daripada tag tersebut, bukannya mengikuti branch yang sentiasa berubah.
Memulakan replica set
Naikkan stack tersebut:
sudo docker compose up -dRocket.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 rocketchatBaris 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 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. Mod standalone mengekalkan pelayan supaya benar-benar peribadi dan bebas daripada kebergantungan, tetapi pemberitahuan tolak iOS dan Android akan berhenti berfungsi, kerana Apple dan Google tidak membenarkan aplikasi yang dibina sendiri memegang sijil tolak, aplikasi rasmi pula dihalakan melalui gateway cloud. Pilih standalone jika privasi adalah matlamat utama dan pengguna anda menggunakan aplikasi web; pilih pendaftaran jika pemberitahuan tolak mudah alih adalah keperluan mutlak. Anda boleh mengubah keputusan anda kemudian di bawah Admin.
Kunci akses sebelum membenarkan sesiapa masuk
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 untuk awam. Jika mencipta setiap akaun secara manual dirasakan membebankan dan ini bukan satu-satunya servis yang dilog masuk oleh pasukan anda, halakan log masuk OAuth Rocket.Chat ke pelayan Authentik SSO yang dihoskan sendiri, supaya kemasukan dan penamatan pengguna diuruskan sekali di satu tempat dan bukannya aplikasi demi aplikasi.
Tentukan juga ke mana fail dimuat naik akan disimpan. Storan File Upload lalai ialah GridFS, yang menyimpan setiap imej dan lampiran di dalam MongoDB itu sendiri. Ini mudah, tetapi ia bermakna pangkalan data anda, dan setiap mongodump yang anda ambil, akan terus membesar tanpa had apabila pengguna menampal tangkapan skrin. Di bawah Admin → Settings → File Upload, anda boleh menukar storan kepada sistem fail tempatan atau bucket yang serasi dengan S3, serta menetapkan saiz fail maksimum yang munasabah. Untuk pasukan kecil, GridFS sudah memadai; cuma perlu sedar bahawa sandaran anda akan menjadi semakin 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.gzArkib 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.gzSalin 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: 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. Ia menjalankan migrasi skema semasa but dan sengaja menolak untuk melangkau versi utama; jika anda cuba beralih daripada 6.x terus ke 8.x, ia akan berhenti dengan ralat migrasi dan bukannya merosakkan data anda. Tukar tag imej kepada keluaran terkini bagi versi utama seterusnya, baca nota keluaran tersebut untuk perubahan yang memecahkan keserasian, jalankan docker compose up -d, dan perhatikan log sehingga migrasi selesai sebelum meneruskan langkah seterusnya. 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 daripada 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 menjalankan semula arahan tersebut dengan flag pengesahan:
sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'Ambil mongodump sebelum setiap naik taraf bagi mana-mana komponen. Itu adalah polisi insurans yang menyeluruh.
Mod kegagalan, berserta 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 oleh hash rawak bermakna anda memulakan (initiate) tanpa host: "mongodb:27017" yang eksplisit, jadi MongoDB mengiklankan nama hos kontena yang tidak dapat 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 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 pengepala (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 ialah 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 1 dalam command miliknya, tetapi swap hanya melambatkan OOM seterusnya di bawah beban sebenar:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfiledocker 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 replica set MongoDB?
Ya, walaupun untuk pelayan tunggal dengan satu nod pangkalan data. Rocket.Chat menghantar mesej dalam masa nyata menggunakan change streams MongoDB, dan change streams merupakan ciri khusus 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 ini 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 jumlah RAM yang diperlukan oleh Rocket.Chat yang dihoskan sendiri?
Rancang untuk 4 GB sebagai minimum praktikal dan 8 GB untuk pasukan yang sibuk. Proses Node Rocket.Chat menggunakan kira-kira 1 hingga 1.5 GB dan MongoDB menuntut hampir separuh daripada baki RAM untuk cache WiredTiger-nya. Oleh itu, pada kotak 2 GB, kedua-duanya akan bertembung dan out-of-memory killer akan menamatkan mongod di bawah sebarang beban sebenar, yang menunjukkan Killed dalam log dan kod keluar 137. 2 GB hanya mencukupi untuk menilai perisian dengan beberapa pengguna ujian.
Bagaimanakah cara saya meletakkan Rocket.Chat di sebalik HTTPS?
Jalankan reverse proxy pada VPS yang sama yang menamatkan TLS dan menghalakan trafik ke 127.0.0.1:3000, serta tetapkan ROOT_URL kontena kepada alamat https:// awam anda. Proksi mesti menghantar pengepala (header) naik taraf WebSocket atau proses log masuk akan terhenti. Certbot dengan nginx adalah persediaan aplikasi tunggal yang paling mudah; Traefik lebih kemas jika anda menjalankan beberapa kontena di sebalik satu proksi dan mahukan pengurusan sijil automatik.
Bagaimanakah cara saya 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 kotak sementara supaya anda tahu proses pemulihan benar-benar berfungsi.
Bagaimanakah cara saya menaik taraf Rocket.Chat tanpa merosakkan MongoDB?
Naik taraf Rocket.Chat satu versi utama pada satu masa; ia menjalankan migrasi semasa but dan enggan melangkau versi utama. 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 ambil mongodump terlebih dahulu.