SSD Nodes Learn
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-07-24

התקנת Rocket.Chat עם Docker Compose

מדריך להקמת Rocket.Chat על VPS באמצעות Docker Compose. כולל הגדרת MongoDB replica set, הצפנת TLS ופתרון בעיות זיכרון בשרתים עם RAM מוגבל.

מה אתם בונים

צ'אט צוות פרטי בבעלותכם המלאה: Rocket.Chat הפועל על VPS משלכם באמצעות Docker Compose, עם הצפנת TLS, כאשר כל הודעה נשמרת במסד נתונים MongoDB שניתן לגבות ולהעביר. Rocket.Chat הוא תחליף מבוסס קוד פתוח ומבוסס ל-Slack ו-Teams — כולל ערוצים, הודעות פרטיות, שרשורים, שיתוף קבצים, ושיחות קול ווידאו, הכל על חומרה שאתם שוכרים ושולטים בה. האפליקציה היא קונטיינר בודד שעולה תוך דקות. כל הנתונים הקריטיים נשמרים במסד הנתונים הסמוך, לכן רוב המדריך עוסק ב-MongoDB, ובמיוחד בדרישה אחת שמפתיעה את כולם בפעם הראשונה: Rocket.Chat לא יעבוד מול MongoDB בגרסת standalone. הוא דורש replica set, גם אם ה-"set" מורכב מצומת (node) יחיד.

דרישות קדם, וחישוב ה-RAM שאף אחד לא מספר לכם

בחרו את גודל השרת בצורה ריאלית. המינימום הריאלי עבור צוות קטן הוא 2 vCPU ו-4 GB של RAM. תהליך ה-Node.js של Rocket.Chat דורש כ-1 עד 1.5 GB בפני עצמו, ו-cache ה-WiredTiger של MongoDB תופס ברירת מחדל כחצי מכל מה שנותר ב-RAM. ב-VPS עם 2 GB, שניהם יצליחו לעלות בעת העלייה, אך יתנגשו ברגע שיגיע תעבורה אמיתית: ה-cache של MongoDB יגדל, ה-heap של Node יגדל, ה-kernel יסיים את דפי הזיכרון שלו, וה-out-of-memory killer יסגור את התהליך הגדול ביותר — בדרך כלל mongod. ה-container ידפיס Killed, Docker יפעיל אותו מחדש, ותקבל שרת צ'אט שקורס בכל כמה דקות תחת עומס שהוא אמור לעמוד בו בקלות. 2 GB מתאים לבדיקות ראשוניות עם שני משתמשים; זה לא שרת לצוות. התחילו עם 4 GB, ותנו לשרת 8 GB אם אתם צופים עשרות משתמשים בו-זמנית, שיחות וידאו, או היסטוריית העלאות קבצים גדלה.

אתם זקוקים גם לשלושה דברים לפני שתתחילו. שם דומיין עם A record המצביע ל-IP הציבורי של ה-VPS — התכונות של Rocket.Chat בזמן אמת והלקוחות בנייד זקוקים לשם מארח (hostname) יציב, לא לכתובת IP בלבד. פורטים 80 ו-443 פתוחים גם בחומת האש של השרת וגם בחומת האש של ספק ה-VPS, שהוא בקרת נפרדת ברוב ממשקי הניהול. ו-Ubuntu 24.04 KVM VPS חדש עם הרשאות root או sudo. אם אתם עדיין מתלבטים אם שרת צ'אט הוא השירות הראשון הנכון להפעיל, ה-מדריך למה כדאי לארח בעצמכם ב-2026 מציג את היתרונות והחסרונות.

Install the Docker engine and the Compose plugin

השתמש במאגר ה-apt של Docker. אל תשתמש בחבילת docker.io של Ubuntu או בקובץ ה-Python הישן והנפרד docker-compose. Compose המודרני הוא plugin של Docker שנקרא באמצעות docker compose — עם רווח, לא מקף. גרסה docker-compose v1 הישנה אינה נתמכת יותר (end-of-life) והיא אינה מפרשת נכון את תחביר ה-healthcheck והתלות (dependency) המופיע להלן.

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

ודא ששני הרכיבים קיימים:

sudo docker version
sudo docker compose version

הבדיקה החשובה היא שdocker compose version מדפיס תוצאה בסגנון Docker Compose version v2.x. אם מופיעה שגיאה docker: 'compose' is not a docker command, ה-plugin לא הותקן ותיתקל בשגיאות לא מובנות בהמשך — תקן זאת כעת.

קובץ ה-compose: MongoDB כ-replica set בעל צומת יחיד

זהו החלק שמשתמשים נוטים לטעות בו, לכן קראו אותו בעיון. Rocket.Chat משתמשת ב-change streams של MongoDB כדי לדחוף הודעות חדשות ללקוחות מחוברים בזמן אמת. change streams זמינים רק בתוך replica set. אם תכוון את Rocket.Chat ל-mongod standalone רגיל, היא תתחבר, אך תיכשל בפתיחת ה-change stream ותיכנס ללולאת הפעלה מחדש (restart-loop) בלתי פוסקת. הפתרון אינו מורכב: מריצים container רגיל של MongoDB, אך מפעילים אותו עם --replSet ולאחר מכן מבצעים initialization ל-set בעל איבר אחד.

צרו ספריית עבודה וקובץ compose.yml:

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

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

volumes:
  mongodb_data:
  mongodb_config:

מספר בחירות כאן הן מכוונות. גרסת ה-Rocket.Chat פורסמה ל-127.0.0.1:3000 ולא ל-0.0.0.0 — לאפליקציה עצמה אין TLS, לכן רק ה-reverse proxy באותו שרת אמור לגשת אליה; קישור שלה לכל interface יהפוך דף התחברות בטקסט גלוי (plaintext) לנגיש ישירות באינטרנט הציבורי. MongoDB אינו פורסם ל-host כלל; ניתן להגיע אליו רק דרך הרשת הפנימית של Compose תחת השם mongodb, שהוא בדיוק ה-hostname שבו משתמש ה-MONGO_URL. ה-MONGO_URL כולל את ?replicaSet=rs0 — אם תסירו זאת, ה-driver יתייחס לשרת כ-standalone למרות שהוא replica set, ו-change streams עדיין ייכשלו. ה-MONGO_OPLOG_URL מצביע על מסד הנתונים local שבו נמצא ה-oplog; Rocket.Chat מודרנית מעדיפה change streams, אך הגדרת הפרמטר אינה מזיקה ושומרת על תאימות לקוד ישן יותר. ה-depends_on משתמש ב-condition: service_healthy, לכן Compose ממתין עד ש-MongoDB ישיב ל-ping לפני שהוא מפעיל את Rocket.Chat — זהו תפקיד ה-healthcheck.

קבעו גרסאות (version tags) ספציפיות עבור שני ה-images — mongo:8.0 וגרסה מפורשת של Rocket.Chat כגון 8.5.1 כאן — ואל תשתמשו לעולם ב-:latest, שעלולה להפוך docker pull לא מנוטר לשדרוג מקרי שלא ניתן לביצוע migration. בדקו את גרסת ה-Rocket.Chat היציבה הנוכחית ואת גרסאות ה-MongoDB שהיא תומכת בהן לפני שתקבעו גרסה. Rocket.Chat מפרסמת מסמך מידע קריא למכונה עבור כל גרסה: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' מחזיר את compatibleMongoVersions: ["8.0"] עבור 8.5.1, לכן mongo:8.0 היא המנוע היחיד הנתמך, בנוסף ל-flag מסוג lts המציין האם אותה גרסה היא גרסת LTS (תמיכה ארוכת טווח) ששווה לקבוע עבור שרת שמעדיפים שלא לנהל באופן ידני.

Initialise the replica set

הפעילו את ה-stack:

sudo docker compose up -d

Rocket.Chat יתחיל לקרוס מיד ו-Docker ימשיך להפעיל אותו מחדש — זהו מצב צפוי, מכיוון ש-replica set עדיין לא קיים. צרו אותו באופן ידני:

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

תוצאה תקינה היא { ok: 1 }. תוך שניות ספורות הצומת הבודד יבחר את עצמו כ-primary; אשרו זאת באמצעות:

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

עליכם לראות את PRIMARY. הפרט החשוב ביותר בדף זה הוא הארגומנט host: "mongodb:27017". אם תריצו rs.initiate() ללא רשימת חברים, MongoDB יפרסם את ה-replica set תחת ה-hostname הפנימי של ה-container — האש (hash) אקראי כמו a1b2c3d4e5f6. Rocket.Chat, המתחבר מתוך ה-container שלו, לא יוכל לפתור (resolve) את השם הזה, ולכן ה-MongoDB driver ייכשל ב-DNS ויכנס ללולאה אינסופית עם הודעת שגיאה MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. תמיד התחילו עם שם השירות המפורש התואם ל-MONGO_URL.

First boot: watch it come up

לאחר שה-set הופך ל-primary, ההפעלה הבאה של Rocket.Chat תתבצע בצורה תקינה ותתחיל בביצוע ה-migrations הראשונים. עקבו אחר ה-logs:

sudo docker compose logs -f rocketchat

השורה שעליה עליכם להמתין היא ה-startup banner:

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

ההפעלה הראשונה איטית — האפליקציה מבצעת database migrations ובניית indexes, לכן המתינו דקה או שתיים לפני שתפעילו חרדה. אם ה-log חוזר על MongoServerSelectionError: Server selection timed out after 30000 ms עם topology description מסוג ReplicaSetNoPrimary, ה-replica set לא הופעל; אם הוא חוזר על getaddrinfo ENOTFOUND עם hash אקראי, הוא הופעל עם ה-host הלא נכון. בכל מקרה, חזרו צעד אחד אחורה. ברגע שתראו את SERVER RUNNING, Rocket.Chat מאזין ב-127.0.0.1:3000 וזה הזמן להגדיר hostname אמיתי ו-TLS לפניו.

Put it behind TLS

לעולם אל תחשוף את Rocket.Chat ב-HTTP רגיל. התחברות דרך http:// פעם אחת בלבד מעבירה את סיסמת ה-admin לכל מי שנמצא בנתיב התקשורת. בצע TLS termination ב-reverse proxy על אותה מכונה והעבר את התעבורה ל-127.0.0.1:3000. שני דברים הם קריטיים: ה-proxy חייב להעביר את ה-WebSocket upgrade headers, כיוון ש-Rocket.Chat פועל בזמן אמת וייכשל ללא הם, וכתובת ה-ROOT_URL של ה-container חייבת להיות זהה בדיוק לכתובת ה-HTTPS הציבורית שהמשתמשים מקלידים.

התחל עם nginx server block ב-HTTP רגיל שמבצע proxy לאפליקציה ומעביר את ה-upgrade headers. שמור אותו כ-/etc/nginx/sites-available/rocketchat, צור קישור סימלי (symlink) לתוך sites-enabled, ובצע 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;
    }
}

השאר את השרת בפורט 80 כרגע — block עם listen 443 ssl; וללא תעודה לא יעבור אפילו את sudo nginx -t. בצע reload ל-nginx (sudo nginx -t && sudo systemctl reload nginx), ולאחר מכן הנפק את התעודה. הדרך הפשוטה ביותר ב-Ubuntu היא Let's Encrypt TLS certificates with Certbot and nginx: certbot --nginx מעדכן את ה-block לעיל, מוסיף את listen 443 ssl;, את שורות ה-ssl_certificate, והפניה אוטומטית מ-80 ל-443, ומקבע מועד חידוש עבורך. אם אתה מריץ כבר מספר containers מאחורי proxy אחד, Traefik with automatic TLS for many Docker apps היא האופציה המסודרת יותר — הוסף router ו-service labels לשירות ה-rocketchat ו-Traefik יבקש ויחדש את התעודה עבורך, ללא צורך ב-nginx block כלל. בכל מקרה, הגדר את ROOT_URL ל-https://chat.example.com בתוך compose.yml והרץ מחדש את sudo docker compose up -d כדי שה-container יקלוט את השינוי. אם ברצונך שהשרת יהיה נגיש רק מתוך הרשת הפנימית שלך ולא מהאינטרנט הציבורי, השתמש ב-self-hosted WireGuard VPN on the VPS וקשר את ה-proxy לכתובת ה-tunnel.

אשף ההתקנה הראשונית

עברו אל https://chat.example.com ו-Rocket.Chat תדריך אתכם באמצעות אשף קצר. ראשית, הגדרת חשבון מנהל (admin account) — שם מלא, שם משתמש, כתובת email וסיסמה חזקה; זהו החשבון היחיד שיהיה קיים, לכן אל תאבדו אותו. לאחר מכן, פרטי ארגון ושרת — שם, תחום עיסוק, גודל הארגון, שם האתר ושפה ברירת מחדל; אלו פרטים קוסמטיים, מלאו אותם והמשיכו הלאה. לאחר מכן תגיע הבחירה המשמעותית: רישום מרחב העבודה (workspace) ב-Rocket.Chat Cloud, או שמירה על מצב עצמאי (standalone).

רישום מאפשר קבלת התראות Push לנייד דרך ה-gateway של Rocket.Chat ודרך חנות התוספים, אך המחיר הוא קשר עם ה-control-plane של ענן Rocket.Chat. מצב standalone שומר על השרת פרטי לחלוטין וללא תלות חיצונית, אך התראות ה-push ב-iOS וב-Android יפסיקו לעבוד; זאת מכיוון ש-Apple ו-Google לא מאפשרות לאפליקציה שנבנתה באופן עצמאי להחזיק את תעודות ה-push — האפליקציות הרשמיות מעבירות את התראות ה-push דרך ה-cloud gateway. בחרו ב-standalone אם הפרטיות היא המטרה העיקרית והמשתמשים שלכם משתמשים באפליקציית ה-web; בחרו ברישום אם התראות ה-push לנייד הן תנאי הכרחי. ניתן לשנות את הבחירה מאוחר יותר תחת Admin.

הגדירו הגבלות לפני הזמנת משתמשים

Rocket.Chat מגיע עם open registration on — כברירת מחדל, ה-Registration Form מוגדר כ-Public, ולכן כל מי שמוצא את ה-URL יכול ליצור חשבון. ב-hostname ציבורי, זהו מעין דלת פתוחה. עברו אל Admin → Settings → Accounts → Registration ושנו את ה-Registration Form ל-Disabled, כדי שתוכלו ליצור חשבונות באופן ידני או באמצעות קישור הזמנה, או ל-Secret URL. באותו אזור, כבו את Allow Anonymous Read ואת Allow Anonymous Write, אלא אם אתם רוצים במפורש ערוץ ציבורי לקריאה בלבד.

החליטו גם היכן נשמרים קבצים המועלים. ברירת המחדל של ה-File Upload היא GridFS, אשר שומרת כל תמונה וקובץ מצורף בתוך ה-MongoDB עצמו. זהו פתרון פשוט, אך המשמעות היא שה-database שלכם — וכל mongodump שאתם לוקחים — יגדלו ללא הגבלה ככל שמשתמשים ית貼りמו צילומי מסך. תחת Admin → Settings → File Upload תוכלו להחליף את ה-storage למערכת קבצים מקומית (local filesystem) או ל-S3-compatible bucket, ולהגדיר גודל קובץ מקסימלי הגיוני. עבור צוות קטן, GridFS הוא פתרון תקין; רק זכרו שהגיבויים שלכם יהיו כבדים יותר עם הזמן.

גיבויים באמצעות mongodump

כל הנתונים שלך נמצאים ב-mongodb_data volume. אל תעתיק את ה-volume בזמן שהדאטה-בייס פועל — בצע dump עקבי באמצעות mongodump, עם הפניה (stream) לקובץ ב-host:

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

ארכיון ה-gzipped היחיד הזה מכיל את כל סביבת העבודה שלך: משתמשים, ערוצים, הודעות, הגדרות, ואם הגדרת העלאות ב-GridFS — גם את הקבצים. אם העברת את ההעלאות למערכת הקבצים או ל-S3, גבה את האחסון הזה בנפרד. כדי לשחזר על סביבה חדשה, ראשית בצע initialization ל-replica set, ולאחר מכן:

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

העתק את הארכיון אל מחוץ למכונה — לאחסון אובייקטים (object storage), לשרת אחר, או לכל מקום שאינו תלוי ב-VPS המקורי — והרץ את ה-dump כ-cron מדי לילה. גיבוי שמעולם לא שוחזר הוא רק תקווה, לא גיבוי; תרגל שחזור פעם אחת על VPS זמני כדי לוודא שהוא עובד לפני שתזדקק לו.

Upgrades: pin tags, read the notes, respect the Mongo matrix

שתי כללים מבטיחים שعملיות ה-upgrades יהיו פשוטות. ראשון, שדרגו את Rocket.Chat גרסה ראשית אחת בכל פעם. המערכת מבצעת schema migrations בזמן העלייה (boot) ומסרבת במכוון לקפוץ בין גרסאות ראשיות; ניסיון לעבור מ-6.x ישירות ל-8.x יגרום לשגיאת migration במקום לשמור על תקינות הנתונים. עדכנו את ה-image tag לגרסה האחרונה של הגרסה הראשית הבאה, קראו את ה-release notes שלה כדי לבדוק breaking changes, הריצו את docker compose up -d, וודאו שהלוגים מסימים את ה-migration לפני שתמשיכו. שני, הקפידו על ה-MongoDB support matrix. כל גרסה של Rocket.Chat תומכת בסט ספציפי של גרסאות MongoDB, ו-curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions מציין אילו גרסאות. כאשר אתם משדרגים את MongoDB — לדוגמה מ-7.0 ל-8.0 — עשו זאת שלב אחד בכל פעם והגדירו את ה-feature-compatibility version לאחר כל קפיצה. ב-MongoDB 8.0 הפקודה דורשת confirm: true מפורש, אחרת המערכת תסרב ותציג הודעה המורה להריץ אותה מחדש עם דגל אישור:

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

בצעו mongodump לפני כל שדרוג של כל אחד מהרכיבים. זהו כל אמצעי ההגנה שלכם.

Failure modes, with the exact strings

Rocket.Chat נכנס ללולאת הפעלה מחדש מיד לאחר docker compose up, ו-docker compose logs rocketchat מתמלא ב-MongoServerSelectionError. ה-MongoDB פועל אך ה-driver אינו יכול לבחור primary, והמחרוזת המדויקת תציין את הטעות שביצעת. Server selection timed out after 30000 ms עם topology type מסוג ReplicaSetNoPrimary פירושו שלא הרצת את rs.initiate() — ל-set אין קונפיגורציה עדיין. getaddrinfo ENOTFOUND ולאחריו hash אקראי פירושו שהפעלת את ה-set ללא ה-host: "mongodb:27017" המפורש, ולכן ה-MongoDB פרסם hostname של container שלא ניתן לפתרון. בצע אבחון באמצעות sudo docker compose exec mongodb mongosh --eval 'rs.status()': אם מופיעה שגיאת MongoServerError: no replset config has been received, בצע init ל-set; אם מופיע member שה-name שלו הוא hash אקראי, בצע re-init באמצעות ה-service name.

ממשק ה-web UI נטען אך תהליך ההתחברות נתקע בטעינה (spinning) לנצח. פתח את קונסול הדפדפן ותראה את WebSocket connection to 'wss://chat.example.com/websocket' failed. זה כמעט תמיד נובע מ-ROOT_URL mismatch או מ-proxy שאינו מעביר את ה-upgrade headers. ודא ש-ROOT_URL שווה לכתובת הציבורית המדויקת כולל את https://, וכי בלוק ה-nginx location שלך מגדיר את Upgrade ו-Connection "upgrade" עם proxy_http_version 1.1. שנה את אחד מהם והרץ מחדש את docker compose up -d.

container קורס שוב ושוב ו-docker compose ps מראה שהוא Restarting. ה-docker compose logs נקטע באמצע השורה ו-sudo dmesg | tail מציג את Out of memory: Killed process 12345 (mongod) מה-oom-killer; קוד היציאה הוא 137. השרת נגמר לו ה-RAM. הפתרון האמיתי הוא VPS גדול יותר — לפחות 4 GB. כפתרון זמני, הוסף swap והגבל את ה-cache של MongoDB באמצעות --wiredTigerCacheSizeGB 1 בתוך ה-command שלו, אך swap רק ידחה את ה-OOM הבא תחת עומס אמיתי:

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

docker compose up נכשל עם Error response from daemon: driver failed programming external connectivity ... bind: address already in use. תהליך כלשהו כבר תופס את פורט 3000 — לרוב container קודם של Rocket.Chat שלא נסגר בצורה מסודרת, או אפליקציה אחרת. מצא אותו באמצעות sudo ss -ltnp | grep :3000, עצור את התהליך או ה-container, או שנה את צד ה-host של המיפוי ל-127.0.0.1:3001:3000 ועדכן את ה-proxy_pass של ה-proxy שלך בהתאם.

FAQ

האם Rocket.Chat באמת זקוק ל-MongoDB replica set?

כן, גם עבור שרת יחיד עם عقدת database אחת. Rocket.Chat מעביר הודעות בזמן אמת באמצעות MongoDB change streams, ו-change streams הם תכונה של replica-set בלבד — standalone mongod אינו יכול לפתוח אחד כזה. אין צורך במספר מכונות; מריצים container אחד של MongoDB שהופעל עם --replSet rs0 ומאתחלים set של חבר אחד באמצעות rs.initiate(). אם תדלגו על השלב הזה, ה-driver לעולם לא ימצא primary, ולכן Rocket.Chat ייכנס ללולמת restart עם MongoServerSelectionError: Server selection timed out ולא יסיים את תהליך ה-booting.

כמה RAM דרוש ל-Rocket.Chat המותקן באופן עצמאי?

תכננו ל-4 GB כמינימום מעשי, ול-8 GB עבור צוות עמוס. תהליך ה-Node של Rocket.Chat משתמש בערך של 1 עד 1.5 GB, ו-MongoDB תופס בערך מחצית מה-RAM הנותר עבור ה-WiredTiger cache שלו. לכן, במכונה של 2 GB נוצר התנגשות, ו-out-of-memory killer יסתיים את mongod תחת עומס אמיתי, מה שיציג Killed ב-logs וקוד יציאה 137. 2 GB מספיקים רק להערכת התוכנה עם מספר משתמשי בדיקה.

איך אני מעביר את Rocket.Chat מאחורי HTTPS?

הריצו reverse proxy על אותו VPS שיבצע TLS termination ויעביר את הבקשות ל-127.0.0.1:3000, והגדירו את ה-ROOT_URL של ה-container לכתובת ה-https:// הציבורית שלכם. ה-proxy חייב להעביר את ה-WebSocket upgrade headers, אחרת תהליך ה-login ייקפא. שימוש ב-Certbot עם nginx הוא ההגדרה הפשוטה ביותר לאפליקציה בודדת; Traefik הוא פתרון נקי יותר אם מריצים מספר containers מאחורי proxy אחד ורוצים ניהול תעודות אוטומטי.

איך אני מגבה Rocket.Chat המותקן באופן עצמאי?

בצעו database dump עקבי באמצעות mongodump במקום להעתיק את ה-volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. הארכיון הזה מכיל משתמשים, ערוצים, הודעות והגדרות, بالإضافة לקבצים שהועלו אם השארתם את האחסון ב-GridFS. העתיקו אותו מחוץ לשרת, הפכו את הגיבוי לאוטומטי מדי לילה באמצעות cron, ותרגלו mongorestore על מכונה זמנית כדי לוודא שהשחזור אכן עובד.

איך אני משדרג את Rocket.Chat מבלי לשבור את MongoDB?

שדרגו את Rocket.Chat גרסה ראשית אחת בכל פעם — התוכנה מריצה migrations בזמן ה-boot ואינה מאפשרת דילוג על גרסאות ראשיות — וקראו את ההערות של כל גרסה לפני עדכון ה-pinned image tag. בדקו אילו גרסאות MongoDB הגרסה המיועדת תומכת באמצעות curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions, וכאשר אתם מעבירים את MongoDB, עברו גרסה ראשית אחת בכל פעם והגדירו את setFeatureCompatibilityVersion באמצעות confirm: true לאחר כל שלב. תמיד בצעו mongodump תחילה.