Bởi Matt Connor 2026-07-15 · Cập nhật ngày 2026-07-23

Cách tự host Rocket.Chat bằng Docker Compose

Q: Làm thế nào để backup Rocket.Chat tự host?

Hãy thực hiện database dump nhất quán bằng mongodump thay vì copy volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Bản archive đó chứa user, channel, message, settings, và cả các file đã upload nếu bạn để storage trên GridFS. Hãy copy bản backup này ra khỏi server, tự động hóa bằng cron hàng đêm, và hãy tập dượt mongorestore trên một máy test để đảm bảo việc restore thực sự hoạt động.

Hướng dẫn cài đặt Rocket.Chat trên VPS bằng Docker Compose. Lưu ý cấu hình MongoDB replica set và yêu cầu tối thiểu 4GB RAM để tránh lỗi crash hệ thống.

Những gì bạn sẽ xây dựng

Một ứng dụng chat nội bộ cho nhóm mà bạn toàn quyền sở hữu: Rocket.Chat chạy trên VPS riêng của bạn thông qua Docker Compose, được bảo mật bằng TLS, với mọi tin nhắn được lưu trữ trong một database MongoDB mà bạn có thể backup và di chuyển. Rocket.Chat là giải pháp thay thế mã nguồn mở hoàn chỉnh cho Slack và Teams — bao gồm các channel, tin nhắn trực tiếp, thread, chia sẻ file, cùng voice và video, tất cả chạy trên phần cứng mà bạn thuê và kiểm soát. Ứng dụng này là một container duy nhất và có thể khởi chạy trong vài phút. Mọi vấn đề phát sinh thực tế đều nằm ở database đi kèm, vì vậy phần lớn hướng dẫn này sẽ tập trung vào MongoDB, đặc biệt là một yêu cầu khiến nhiều người bất ngờ khi mới bắt đầu: Rocket.Chat sẽ không chạy được với một MongoDB standalone. Nó yêu cầu một replica set, ngay cả khi "set" đó chỉ gồm một node duy nhất.

Điều kiện tiên quyết, và bài toán RAM mà không ai nói với bạn

Hãy chọn cấu hình máy thật trung thực. Mức tối thiểu thực tế cho một nhóm nhỏ là 2 vCPU và 4 GB RAM. Tiến trình Node.js của Rocket.Chat cần khoảng 1 đến 1.5 GB riêng lẻ, và WiredTiger cache của MongoDB mặc định sẽ chiếm khoảng một nửa lượng RAM còn lại. Trên một VPS 2 GB, cả hai có thể khởi động bình thường nhưng sẽ xung đột ngay khi có traffic thực tế: MongoDB mở rộng cache, Node mở rộng heap, kernel hết trang nhớ (pages), và out-of-memory killer sẽ kill tiến trình lớn nhất — thường là mongod. Container sẽ báo lỗi Killed, Docker khởi động lại nó, và bạn sẽ có một chat server bị sập vài phút một lần dù tải rất nhẹ. 2 GB là đủ để chạy thử cho hai người; nó không phải là server cho một team. Hãy bắt đầu với 4 GB, và dùng 8 GB nếu bạn dự kiến có hàng chục người dùng đồng thời, gọi video, hoặc lịch sử upload ngày càng lớn.

Bạn cũng cần chuẩn bị ba thứ trước khi bắt đầu. Một tên miền với A record trỏ về IP public của VPS — các tính năng thời gian thực và client mobile của Rocket.Chat cần một hostname ổn định chứ không phải IP thuần túy. Mở port 80 và 443 trên cả firewall của server và firewall mạng của nhà cung cấp (đây là một phần quản lý riêng biệt trên hầu hết các panel). Và một VPS Ubuntu 24.04 KVM mới có quyền root hoặc sudo. Nếu bạn vẫn đang cân nhắc xem chat server có phải là dịch vụ đầu tiên nên tự chạy hay không, hãy xem hướng dẫn về những gì đáng để tự host trong năm 2026 để hiểu các đánh đổi.

Cài đặt Docker engine và Compose plugin

Hãy sử dụng repository apt chính thức của Docker. Đừng dùng package docker.io có sẵn trên Ubuntu hay bản binary Python docker-compose cũ kỹ. Compose hiện đại là một Docker plugin, bạn gọi nó bằng lệnh docker compose — dùng dấu cách, không phải dấu gạch ngang. Bản docker-compose v1 cũ đã ngừng hỗ trợ và xử lý sai cú pháp healthcheck và dependency ở dưới đây.

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

Kiểm tra xem cả hai thành phần đã có mặt chưa:

sudo docker version
sudo docker compose version

Nếu docker compose version in ra kết quả tương tự Docker Compose version v2.x là bạn đã thành công. Nếu gặp lỗi docker: 'compose' is not a docker command, nghĩa là plugin chưa được cài đặt và bạn sẽ gặp lỗi khó hiểu về sau — hãy sửa lỗi ngay tại đây.

File compose: MongoDB dưới dạng single-node replica set

Đây là phần mà mọi người hay làm sai, nên hãy đọc kỹ. Rocket.Chat sử dụng change streams của MongoDB để đẩy tin nhắn mới đến các client đang kết nối theo thời gian thực, và change streams chỉ khả dụng trên một replica set. Nếu bạn trỏ Rocket.Chat đến một mongod standalone thông thường, nó sẽ kết nối được, nhưng không thể mở được change stream và sẽ bị restart-loop mãi mãi. Cách khắc phục rất đơn giản: bạn chạy một container MongoDB bình thường, nhưng khởi chạy nó với --replSet và sau đó khởi tạo một set chỉ có một member.

Tạo một thư mục làm việc và một file 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:

Một vài lựa chọn ở đây là có chủ đích. Bản port của Rocket.Chat được publish lên 127.0.0.1:3000, không phải 0.0.0.0 — bản thân ứng dụng không có TLS, nên chỉ có reverse proxy trên cùng một máy mới được phép kết nối; nếu bind nó vào mọi interface, trang login plaintext sẽ bị lộ trực tiếp lên internet công cộng. MongoDB không được publish ra host; nó chỉ có thể truy cập qua mạng nội bộ của Compose với tên gọi mongodb, đây chính là hostname mà MONGO_URL sử dụng. MONGO_URL đi kèm với ?replicaSet=rs0 — nếu bỏ qua tham số này, driver sẽ coi server là standalone mặc dù nó là một replica set, và change streams vẫn sẽ lỗi. MONGO_OPLOG_URL trỏ đến database local nơi chứa oplog; Rocket.Chat hiện đại ưu tiên dùng change streams, nhưng việc thiết lập này không gây hại và giúp các code path cũ hoạt động bình thường. depends_on sử dụng condition: service_healthy, nên Compose sẽ đợi cho đến khi MongoDB phản hồi một ping trước khi khởi chạy Rocket.Chat — đó là mục đích của healthcheck.

Hãy dùng tag version cụ thể cho cả hai image — mongo:8.0 và một bản release Rocket.Chat cụ thể như 8.5.1 ở đây — và đừng bao giờ dùng :latest, vì nó sẽ biến một bản docker pull không cần can thiệp thành một bản upgrade ngẫu nhiên không thể migrate được. Hãy kiểm tra bản release Rocket.Chat stable hiện tại và các phiên bản MongoDB mà nó hỗ trợ trước khi pin version. Rocket.Chat cung cấp một tài liệu thông tin có thể đọc bằng máy cho mỗi bản release: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' trả về compatibleMongoVersions: ["8.0"] cho bản 8.5.1, vì vậy mongo:8.0 là engine duy nhất được hỗ trợ, cùng với một flag lts cho bạn biết bản release đó có phải là bản long-term-support đáng để pin cho một server mà bạn không muốn phải chăm sóc thủ công hay không.

Khởi tạo replica set

Chạy stack:

sudo docker compose up -d

Rocket.Chat sẽ crash ngay lập tức và Docker sẽ liên tục restart nó — đây là hiện tượng bình thường vì replica set chưa tồn tại. Hãy tạo nó bằng tay một lần:

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

Kết quả đúng là { ok: 1 }. Trong vài giây, node đơn lẻ sẽ tự bầu chính nó làm primary; kiểm tra bằng lệnh:

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

Bạn sẽ thấy PRIMARY. Chi tiết quan trọng nhất trên toàn bộ trang này là tham số host: "mongodb:27017". Nếu bạn chạy lệnh rs.initiate() mà không có danh sách thành viên, MongoDB sẽ quảng bá replica set dưới hostname nội bộ của container — một mã hash ngẫu nhiên như a1b2c3d4e5f6. Rocket.Chat, khi kết nối từ container riêng của nó, không thể phân giải (resolve) được tên đó, dẫn đến MongoDB driver bị lỗi DNS và lặp vô tận với log MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Luôn khởi tạo với service name cụ thể khớp với MONGO_URL của bạn.

Lần boot đầu tiên: theo dõi quá trình khởi động

Khi set đã là primary, lần restart tiếp theo của Rocket.Chat sẽ kết nối bình thường và bắt đầu các migration lần đầu. Hãy theo dõi log:

sudo docker compose logs -f rocketchat

Dòng bạn đang chờ là startup banner:

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

Lần boot đầu tiên sẽ chậm — ứng dụng đang chạy database migrations và build index, nên hãy đợi một hoặc hai phút trước khi lo lắng. Nếu log lặp lại MongoServerSelectionError: Server selection timed out after 30000 ms với topology description là ReplicaSetNoPrimary, nghĩa là replica set chưa được khởi tạo; nếu lặp lại getaddrinfo ENOTFOUND kèm một hash ngẫu nhiên, nghĩa là nó đã được khởi tạo với sai host. Trong cả hai trường hợp, hãy quay lại bước trước đó. Khi bạn thấy SERVER RUNNING, Rocket.Chat đang lắng nghe trên 127.0.0.1:3000 và đã đến lúc thiết lập hostname thật và TLS cho nó.

Đặt phía sau TLS

Đừng bao giờ để Rocket.Chat chạy trên HTTP thuần. Chỉ cần đăng nhập qua http:// một lần là bạn đã giao mật khẩu admin cho bất kỳ ai trên đường truyền. Hãy terminate TLS tại một reverse proxy trên cùng một máy và forward đến 127.0.0.1:3000. Có hai điều quan trọng: proxy phải forward các WebSocket upgrade headers, vì Rocket.Chat hoạt động theo thời gian thực và sẽ lỗi nếu thiếu chúng, và ROOT_URL của container phải khớp chính xác với địa chỉ HTTPS công khai mà người dùng nhập.

Bắt đầu với một nginx server block HTTP thuần để proxy đến ứng dụng và forward các upgrade headers. Lưu nó thành /etc/nginx/sites-available/rocketchat, tạo symlink vào sites-enabled, và reload:

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

    client_max_body_size 100M;

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

Tạm thời cứ để ở port 80 — một block với listen 443 ssl; mà không có certificate sẽ không vượt qua được sudo nginx -t. Reload nginx (sudo nginx -t && sudo systemctl reload nginx), sau đó cấp certificate. Cách gọn nhất trên Ubuntu là Sử dụng Let's Encrypt TLS certificates với Certbot và nginx: certbot --nginx sẽ ghi đè block ở trên, thêm listen 443 ssl;, các dòng ssl_certificate, và tự động redirect từ 80 sang 443, đồng thời tự động lên lịch gia hạn cho bạn. Nếu bạn đã chạy nhiều container phía sau một proxy, Sử dụng Traefik với automatic TLS cho nhiều Docker apps là lựa chọn gọn gàng hơn — chỉ cần thêm router và service labels vào service rocketchat, Traefik sẽ tự động request và renew certificate mà không cần block nginx nào cả. Dù dùng cách nào, hãy đặt ROOT_URL thành https://chat.example.com trong compose.yml và chạy lại sudo docker compose up -d để container nhận thay đổi. Nếu bạn muốn server chỉ có thể truy cập từ mạng nội bộ thay vì internet công cộng, hãy dùng self-hosted WireGuard VPN trên VPS làm lớp bảo vệ và bind proxy vào địa chỉ tunnel.

Trình hướng dẫn thiết lập lần đầu

Truy cập vào https://chat.example.com và Rocket.Chat sẽ dẫn dắt bạn qua một trình hướng dẫn ngắn. Đầu tiên là tài khoản admin — bao gồm tên thật, username, email và một mật khẩu mạnh; đây là tài khoản duy nhất tồn tại, vì vậy đừng để mất nó. Tiếp theo là thông tin tổ chức và server — tên, ngành nghề, quy mô, tên trang web và ngôn ngữ mặc định; các thông tin này chỉ mang tính thẩm mỹ, bạn cứ điền vào rồi tiếp tục. Sau đó là lựa chọn quan trọng nhất: đăng ký workspace này với Rocket.Chat Cloud, hoặc giữ ở chế độ standalone.

Việc đăng ký sẽ kích hoạt thông báo push trên di động thông qua gateway của Rocket.Chat và marketplace, nhưng đổi lại server sẽ có một mối liên kết control-plane với cloud của Rocket.Chat. Chế độ standalone giúp server hoàn toàn riêng tư và không phụ thuộc bên ngoài, nhưng thông báo push trên iOS và Android sẽ ngừng hoạt động, vì Apple và Google không cho phép một ứng dụng tự xây dựng nắm giữ các chứng chỉ push — các ứng dụng chính thức sẽ định tuyến thông qua cloud gateway. Hãy chọn standalone nếu ưu tiên hàng đầu là quyền riêng tư và người dùng của bạn chủ yếu dùng web app; hãy chọn đăng ký nếu thông báo push trên di động là bắt buộc. Bạn có thể thay đổi quyết định này sau này trong phần Admin.

Khóa bảo mật trước khi mời người dùng

Rocket.Chat mặc định để chế độ open registration on — Registration Form được thiết lập là Public, nên bất kỳ ai có URL đều có thể tạo tài khoản. Điều này giống như một cánh cửa mở trên một hostname công khai. Hãy vào Admin → Settings → Accounts → Registration và chuyển Registration Form thành Disabled để bạn tự tạo tài khoản thủ công hoặc qua link mời, hoặc chuyển thành Secret URL. Tại đây, hãy tắt Allow Anonymous Read và Allow Anonymous Write trừ khi bạn thực sự muốn có một channel công khai chỉ cho phép đọc.

Bạn cũng cần quyết định nơi lưu trữ các file upload. Mặc định File Upload sử dụng storage là GridFS, lưu mọi hình ảnh và tệp đính kèm ngay bên trong MongoDB. Cách này đơn giản, nhưng nó khiến database — và mọi mongodump bạn chụp — sẽ tăng dung lượng không kiểm soát khi người dùng dán ảnh chụp màn hình. Trong phần Admin → Settings → File Upload, bạn có thể chuyển storage sang local filesystem hoặc một S3-compatible bucket, đồng thời thiết lập giới hạn dung lượng file hợp lý. Với một team nhỏ, GridFS là đủ dùng; nhưng hãy lưu ý rằng các bản backup sẽ nặng dần theo thời gian.

Backup với mongodump

Tất cả dữ liệu của bạn nằm trong volume mongodb_data. Đừng chỉ copy volume khi database đang chạy — hãy dùng mongodump để tạo một bản dump nhất quán, stream trực tiếp vào một file trên host:

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

File archive nén gzipped đó chứa toàn bộ workspace của bạn: users, channels, messages, settings, và cả các file nếu bạn để uploads trên GridFS. Nếu bạn chuyển uploads sang filesystem hoặc S3, hãy backup kho lưu trữ đó riêng biệt. Để restore lên một stack mới, hãy khởi tạo replica set trước, sau đó:

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

Hãy copy file archive ra khỏi máy chủ — dùng object storage, một server khác, hoặc bất cứ nơi nào mà nếu VPS bị lỗi thì bản backup vẫn còn nguyên — và thiết lập chạy dump từ cron hàng đêm. Một bản backup mà bạn chưa từng restore chỉ là một hy vọng, không phải là bản backup thực sự; hãy thực hành restore một lần trên một VPS tạm thời để đảm bảo nó hoạt động trước khi bạn thực sự cần đến.

Nâng cấp: pin tag, đọc ghi chú, tuân thủ matrix của Mongo

Có hai quy tắc giúp việc nâng cấp diễn ra suôn sẻ. Thứ nhất, nâng cấp Rocket.Chat từng phiên bản major một. Hệ thống sẽ chạy schema migrations khi khởi động và sẽ từ chối nhảy thẳng các phiên bản major; nếu bạn cố nâng từ 6.x lên thẳng 8.x, hệ thống sẽ dừng lại với lỗi migration thay vì làm hỏng dữ liệu. Hãy cập nhật image tag lên bản release mới nhất của phiên bản major kế tiếp, đọc release notes để xem các thay đổi gây lỗi (breaking changes), chạy docker compose up -d, và theo dõi log cho đến khi quá trình migrating hoàn tất trước khi tiếp tục. Thứ hai, tuân thủ matrix hỗ trợ của MongoDB. Mỗi bản release của Rocket.Chat chỉ hỗ trợ một tập hợp các phiên bản MongoDB nhất định, và curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions sẽ cho bạn biết phiên bản nào. Khi bạn nâng cấp MongoDB — ví dụ từ 7.0 lên 8.0 — hãy thực hiện từng bước major một và thiết lập feature-compatibility version sau mỗi bước nhảy. Trên MongoDB 8.0, lệnh đó yêu cầu một confirm: true rõ ràng, nếu không nó sẽ báo lỗi và yêu cầu bạn chạy lại với flag xác nhận:

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

Hãy thực hiện mongodump trước mỗi lần nâng cấp bất kỳ thành phần nào. Đó là toàn bộ phương án bảo hiểm của bạn.

Các lỗi thường gặp, kèm theo chuỗi thông báo chính xác

Rocket.Chat bị restart-loop ngay sau docker compose up, và docker compose logs rocketchat đầy MongoServerSelectionError. MongoDB vẫn đang chạy nhưng driver không thể chọn được primary, và chuỗi thông báo chính xác sẽ cho bạn biết lỗi nằm ở đâu. Server selection timed out after 30000 ms với topology type là ReplicaSetNoPrimary nghĩa là bạn chưa chạy rs.initiate() — replica set chưa có cấu hình. getaddrinfo ENOTFOUND kèm theo một mã hash ngẫu nhiên nghĩa là bạn đã khởi tạo mà không có host: "mongodb:27017" cụ thể, dẫn đến việc MongoDB quảng bá một container hostname không thể phân giải được. Kiểm tra bằng sudo docker compose exec mongodb mongosh --eval 'rs.status()': nếu báo lỗi MongoServerError: no replset config has been received, hãy khởi tạo set; nếu hiển thị một member có name là mã hash ngẫu nhiên, hãy khởi tạo lại bằng service name.

Web UI tải được nhưng bước login bị xoay vòng vô tận và không hoàn tất. Mở browser console, bạn sẽ thấy WebSocket connection to 'wss://chat.example.com/websocket' failed. Lỗi này hầu hết là do mismatch ROOT_URL hoặc do proxy không forward các upgrade headers. Hãy xác nhận ROOT_URL bằng chính xác địa chỉ public bao gồm cả https://, và đảm bảo nginx location block đã set Upgrade và Connection "upgrade" với proxy_http_version 1.1. Thay đổi một trong hai và chạy lại docker compose up -d.

Một container liên tục bị die và docker compose ps báo nó bị Restarting. docker compose logs bị cắt ngang và sudo dmesg | tail hiển thị Out of memory: Killed process 12345 (mongod) từ oom-killer; exit code là 137. Máy đã hết RAM. Cách khắc phục triệt để là nâng cấp lên VPS lớn hơn — tối thiểu 4 GB. Để xử lý tạm thời, hãy thêm swap và giới hạn MongoDB cache bằng --wiredTigerCacheSizeGB 1 trong command, nhưng swap chỉ trì hoãn lỗi OOM tiếp theo khi tải thực tế tăng cao:

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

docker compose up lỗi với Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Đang có một tiến trình khác chiếm port 3000 — thường là một container Rocket.Chat cũ chưa dừng hoàn toàn, hoặc một ứng dụng khác. Tìm nó bằng sudo ss -ltnp | grep :3000, stop tiến trình hoặc container đó, hoặc đổi host side của mapping thành 127.0.0.1:3001:3000 và cập nhật proxy_pass của proxy cho khớp.

FAQ

Rocket.Chat có thực sự cần MongoDB replica set không?

Có, ngay cả khi bạn chỉ dùng một server với một node database duy nhất. Rocket.Chat gửi tin nhắn theo thời gian thực bằng cách sử dụng MongoDB change streams, mà change streams là tính năng chỉ dành riêng cho replica-set — một mongod standalone không thể mở được tính năng này. Bạn không cần nhiều máy vật lý; bạn chỉ cần chạy một MongoDB container với --replSet rs0 và khởi tạo một set gồm một thành viên bằng rs.initiate(). Nếu bỏ qua bước này, driver sẽ không tìm thấy primary, dẫn đến việc Rocket.Chat bị restart-loop với MongoServerSelectionError: Server selection timed out và không thể khởi động xong.

Rocket.Chat tự host cần bao nhiêu RAM?

Hãy chuẩn bị tối thiểu 4 GB để chạy thực tế và 8 GB cho một team đông người. Process Node của Rocket.Chat sử dụng khoảng 1 đến 1.5 GB và MongoDB sẽ chiếm khoảng một nửa lượng RAM còn lại cho WiredTiger cache. Do đó, trên một VPS 2 GB, hai thành phần này sẽ xung đột và OOM killer sẽ terminate mongod khi có tải thực tế, gây ra lỗi Killed trong logs và exit code 137. 2 GB chỉ đủ để bạn chạy thử phần mềm với một vài user test.

Làm thế nào để chạy Rocket.Chat qua HTTPS?

Hãy chạy một reverse proxy trên cùng VPS đó để terminate TLS và forward traffic đến 127.0.0.1:3000, đồng thời thiết lập ROOT_URL của container thành địa chỉ https:// công khai của bạn. Proxy phải forward các WebSocket upgrade headers nếu không quá trình login sẽ bị treo. Dùng Certbot với nginx là cách thiết lập đơn giản nhất cho một ứng dụng; Traefik sẽ gọn hơn nếu bạn chạy nhiều container sau một proxy và muốn tự động quản lý certificate.

Làm thế nào để backup Rocket.Chat tự host?

Hãy thực hiện database dump nhất quán bằng mongodump thay vì copy volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Bản archive đó chứa user, channel, message, settings, và cả các file đã upload nếu bạn để storage trên GridFS. Hãy copy bản backup này ra khỏi server, tự động hóa bằng cron hàng đêm, và hãy tập dượt mongorestore trên một máy test để đảm bảo việc restore thực sự hoạt động.

Làm thế nào để upgrade Rocket.Chat mà không làm lỗi MongoDB?

Hãy upgrade Rocket.Chat từng phiên bản major một — hệ thống sẽ chạy migrations khi boot và không cho phép skip các bản major — và hãy đọc kỹ release notes của từng phiên bản trước khi thay đổi image tag. Kiểm tra xem phiên bản MongoDB nào được phiên bản mục tiêu hỗ trợ bằng curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions; khi nâng cấp MongoDB, hãy thực hiện từng bước major một và thiết lập setFeatureCompatibilityVersion bằng confirm: true sau mỗi bước. Luôn luôn thực hiện mongodump trước.

#rocket-chat#Docker #docker-compose#mongodb#tự lưu trữ #tls