התקנת Rocket.Chat עם Docker Compose על שרת VPS

מה אתם בונים

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

דרישות קדם, והחישוב האמיתי של זיכרון ה-RAM

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

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

התקנת מנוע Docker ותוסף Compose

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

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, התוסף לא הותקן ואתם צפויים להיתקל בכשלים לא מובנים בהמשך; תקנו זאת כאן.

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

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

צרו תיקיית עבודה וקובץ 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 שעל אותו שרת אמור להגיע אליה. קישור לכל הממשקים יחשוף דף התחברות בטקסט גלוי ישירות לאינטרנט הציבורי. MongoDB אינו מפורסם למארח כלל; הוא נגיש רק דרך הרשת הפנימית של Compose תחת השם mongodb, שהוא בדיוק שם המארח שבו משתמש ה-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.

קבעו תגיות גרסה ממשיות בשתי התמונות, 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 הוא מנוע הנתמך היחיד. בנוסף, הוא כולל דגל lts שמציין אם מדובר בגרסת long-term support שכדאי לקבע עבור שרת שאינכם רוצים לתחזק ללא הפסקה. לא כל פרויקט מפרסם image עם גרסה, ובמקרה כזה הקיבוע מתבצע במקור: אירוח עצמי של מעקב האימונים openGym פירושו לעבור ל־git tag מסוים ולבנות ממנו, במקום לעקוב אחר branch שמשתנה.

אתחול ה-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 }. בתוך שניות ספורות ה-node הבודד יבחר את עצמו כ-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, מחרוזת אקראית כמו a1b2c3d4e5f6. Rocket.Chat, שמתחבר מתוך ה-container שלו, אינו יכול לפתור את השם הזה, ולכן ה-driver של MongoDB נכשל ב-DNS ונכנס ללולאה אינסופית שמתעדת MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. תמיד בצעו אתחול עם שם ה-service המפורש שתואם ל-MONGO_URL שלכם.

עלייה ראשונה: ניטור תהליך ההפעלה

ברגע שהסט מוגדר כראשי (primary), האתחול הבא של Rocket.Chat יתחבר בצורה תקינה ויתחיל בהרצת המיגרציות של ההפעלה הראשונה. עקבו אחר הלוגים:

sudo docker compose logs -f rocketchat

השורה שעליכם לחפש היא באנר ההפעלה:

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

העלייה הראשונה איטית, שכן היישום מריץ מיגרציות של מסד הנתונים ובונה אינדקסים; המתינו דקה או שתיים לפני שתסיקו שמשהו אינו כשורה. אם הלוג חוזר על MongoServerSelectionError: Server selection timed out after 30000 ms עם תיאור טופולוגיה מסוג ReplicaSetNoPrimary, סימן שסט הרפליקציה לא אותחל; אם הוא חוזר על getaddrinfo ENOTFOUND עם hash אקראי, סימן שהוא אותחל עם שם מארח (host) שגוי. בשני המקרים, חזרו שלב אחד אחורה. ברגע שתראו את SERVER RUNNING, Rocket.Chat מאזין ב-127.0.0.1:3000, וזה הזמן להגדיר מולו שם מתחם אמיתי ו-TLS.

הגנה באמצעות TLS

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

התחילו עם בלוק שרת nginx ב-HTTP פשוט שמבצע proxy ליישום ומעביר את ה-upgrade headers. שמרו אותו כ-/etc/nginx/sites-available/rocketchat, צרו קישור סימבולי (symlink) ל-sites-enabled, ובצעו טעינה מחדש:

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

אשף ההגדרה הראשונית

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

רישום השרת מאפשר קבלת התראות Push לנייד דרך ה-gateway של Rocket.Chat וגישה ל-marketplace של התוספים, אך כרוך בקשר מול מערכת הניהול בענן של Rocket.Chat. מצב Standalone שומר על השרת פרטי לחלוטין וללא תלויות חיצוניות, אך התראות ה-Push ב-iOS וב-Android יפסיקו לעבוד, כיוון ש-Apple ו-Google אינן מאפשרות לאפליקציות בבנייה עצמית להחזיק בתעודות ה-Push; האפליקציות הרשמיות מנתבות את התעבורה דרך ה-gateway בענן. בחרו במצב Standalone אם הפרטיות היא המטרה העיקרית והמשתמשים שלכם עובדים דרך אפליקציית האינטרנט; בחרו ברישום אם התראות בנייד הן דרישה הכרחית. ניתן לשנות את ההגדרה הזו מאוחר יותר תחת תפריט ה-Admin.

אבטחו את המערכת לפני שאתם מזמינים משתמשים

Rocket.Chat מופץ כברירת מחדל עם הרשמה פתוחה, כאשר טופס ההרשמה מוגדר כ-Public, כך שכל מי שמגיע לכתובת ה-URL יכול ליצור חשבון. בשרת עם שם מתחם ציבורי, זוהי פרצה אבטחתית. עברו אל Admin → Settings → Accounts → Registration והגדירו את Registration Form ל-Disabled, כך שתוכלו ליצור חשבונות ידנית או באמצעות קישור הזמנה, או ל-Secret URL. בזמן שאתם שם, כבו את Allow Anonymous Read ואת Allow Anonymous Write, אלא אם כן אתם מעוניינים במפורש בערוץ ציבורי לקריאה בלבד. אם יצירת כל חשבון באופן ידני נראית לכם מייגעת, וזהו אינו השירות היחיד שהצוות שלכם מתחבר אליו, הגדירו את התחברות ה-OAuth של Rocket.Chat מול שרת Authentik SSO בניהול עצמי. כך, ניהול המשתמשים הנכנסים והיוצאים יתבצע פעם אחת במקום מרכזי, במקום לנהל זאת בכל יישום בנפרד.

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

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

כל הנתונים שלכם נמצאים בנפח האחסון mongodb_data. אל תעתיקו את הנפח ישירות בזמן שהמסד פעיל; בצעו dump עקבי באמצעות mongodump, והזרימו אותו לקובץ על המארח:

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

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

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

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

שדרוגים: קיבוע תגיות, קריאת הערות, והקפדה על מטריצת התאימות של MongoDB

שני כללים שומרים על תהליך שדרוג תקין. ראשית, שדרגו את Rocket.Chat גרסה ראשית אחת בכל פעם. המערכת מריצה מיגרציות של הסכימה בעת העלייה ומסרבת במכוון לדלג על גרסאות ראשיות; ניסיון לעבור מגרסה 6.x ישירות ל-8.x יסתיים בשגיאת מיגרציה במקום בהשחתת הנתונים שלכם. עדכנו את תגית ה-image לגרסה האחרונה של הגרסה הראשית הבאה, קראו את הערות השחרור עבור שינויים שעלולים לשבור תאימות, הריצו את docker compose up -d, ועקבו אחר הלוגים עד לסיום המיגרציה לפני שתמשיכו הלאה. שנית, הקפידו על מטריצת התאימות של MongoDB. כל שחרור של Rocket.Chat תומך בסט ספציפי של גרסאות MongoDB, והקישור curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions מפרט אילו מהן. כאשר אתם משדרגים את MongoDB, למשל מ-7.0 ל-8.0, בצעו זאת צעד אחד בכל פעם והגדירו את גרסת ה-feature-compatibility לאחר כל קפיצה. ב-MongoDB 8.0, פקודה זו דורשת confirm: true מפורש, אחרת היא תסרב לפעול ותציג הודעה המורה לכם להריץ אותה שוב עם דגל האישור:

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

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

מצבי כשל, עם מחרוזות מדויקות

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

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

מכולה ממשיכה לקרוס ו-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, לרוב מכולת Rocket.Chat קודמת שלא נעצרה בצורה נקייה, או יישום אחר. מצא אותו עם sudo ss -ltnp | grep :3000, עצור את התהליך או המכולה, או שנה את צד המארח במיפוי ל-127.0.0.1:3001:3000 ועדכן את ה-proxy_pass של ה-proxy שלך בהתאם.

FAQ

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

כן, גם עבור שרת בודד עם node אחד של מסד נתונים. Rocket.Chat מעביר הודעות בזמן אמת באמצעות change streams של MongoDB, ותכונה זו זמינה ב-replica set בלבד; מופע standalone של mongod אינו יכול לפתוח stream כזה. אין צורך במספר שרתים; ניתן להריץ מכולת MongoDB אחת שהופעלה עם --replSet rs0 ולאתחל קבוצה בעלת חבר אחד באמצעות rs.initiate(). דילוג על שלב זה יגרום לדרייבר לא למצוא primary, מה שיוביל את Rocket.Chat ללולאת אתחול עם MongoServerSelectionError: Server selection timed out ולכך שלעולם לא יסיים לעלות.

כמה 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 בלוגים עם קוד יציאה 137. נפח של 2 GB מספיק רק להערכת התוכנה עם מספר משתמשי בדיקה.

איך מציבים את Rocket.Chat מאחורי HTTPS?

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

איך מגבים Rocket.Chat באירוח עצמי?

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

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

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