Yazan Docker Compose ile Rocket.Chat Kurulumu
VPS üzerinde Docker Compose ile Rocket.Chat kurulumu yapın. MongoDB replica set gereksinimi, TLS yapılandırması ve yedekleme yöntemleri hakkında teknik rehber.
İnşa edilen yapı
Tamamen size ait özel bir ekip sohbeti: Docker Compose üzerinde kendi VPS'inizde çalışan, TLS ile şifrelenmiş ve tüm mesajların yedekleyebileceğiniz veya taşıyabileceğiniz bir MongoDB veritabanında tutulduğu Rocket.Chat. Rocket.Chat; kanallar, direkt mesajlar, thread yapısı, dosya paylaşımı, sesli ve görüntülü görüşme özelliklerine sahip, Slack ve Teams için olgun bir açık kaynak alternatifidir; tüm bunlar kiraladığınız ve kontrol ettiğiniz donanım üzerinde çalışır. Uygulama, dakikalar içinde ayağa kalkan tek bir container'dır. Olası hataların çoğu yanındaki veritabanından kaynaklanır; bu nedenle bu kılavuzun büyük bir kısmı MongoDB ve özellikle herkesi ilk seferinde şaşırtan bir gereksinim hakkındadır: Rocket.Chat, tek başına çalışan (standalone) bir MongoDB ile çalışmaz. "Set" yapısı tek bir düğümden (node) oluşsa bile bir replica set gereklidir.
Ön Koşullar ve kimsenin söylemediği RAM hesabı
Sunucu kapasitesini dürüstçe belirleyin. Küçük bir ekip için gerçekçi alt sınır 2 vCPU ve 4 GB RAM'dir. Rocket.Chat'in Node.js süreci tek başına yaklaşık 1 ile 1.5 GB arası RAM ister. MongoDB'nin WiredTiger önbelleği ise varsayılan olarak kalan RAM'in yaklaşık yarısını kullanır. 2 GB kapasiteli bir VPS üzerinde her iki süreç de açılışta çalışabilir, ancak gerçek trafik geldiğinde çakışırlar: MongoDB önbelleğini büyütür, Node heap alanını büyütür, çekirdek (kernel) sayfa (page) miktarını tüketir ve out-of-memory killer en büyük süreci, genellikle mongod'u sonlandırır. Konteyner Killed hatası verir, Docker konteyneri yeniden başlatır ve yük altında her birkaç dakikada bir çöken bir sohbet sunucusu elde edersiniz. 2 GB, iki kişilik testler için uygundur; ancak bir ekip sunucusu değildir. İşleme 4 GB ile başlayın; onlarca eşzamanlı kullanıcı, görüntülü görüşme veya artan bir yükleme geçmişi bekliyorsanız 8 GB ayırın.
Başlamadan önce şu üç bileşenin hazır olması gerekir: VPS'in genel IP adresine yönlendirilmiş bir A kaydı olan bir alan adı; Rocket.Chat'in gerçek zamanlı özellikleri ve mobil istemcileri için sabit bir hostname gereklidir, sadece IP yeterli değildir. Sunucu güvenlik duvarında ve sağlayıcınızın ağ güvenlik duvarında (çoğu panelde ayrı bir kontroldür) 80 ve 443 portları açık olmalıdır. Ve root veya sudo yetkisine sahip, yeni kurulmuş bir Ubuntu 24.04 KVM VPS. Bir sohbet sunucusunun çalıştırılacak ilk servis olup olmadığına karar veremediyseniz, 2026 yılında self-hosting yapmaya değer olanlar kılavuzu tüm ödünleşimleri (tradeoffs) açıklamaktadır.
Docker engine ve Compose plugin kurulumu
Ubuntu ile gelen docker.io paketini veya eski, bağımsız docker-compose Python binary dosyasını kullanmayın. Docker'ın kendi apt deposunu kullanın. Modern Compose, docker compose şeklinde çağrılan bir Docker plugin'idir; aradaki karakter boşluktur, tire değildir. Eski docker-compose v1 sürümünün desteği sona ermiştir; aşağıda belirtilen healthcheck ve bağımlılık sözdizimini hatalı işler.
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-pluginHer iki bileşenin de mevcut olduğunu doğrulayın:
sudo docker version
sudo docker compose versiondocker compose version komutunun Docker Compose version v2.x gibi bir çıktı vermesi gereken kontrol noktasıdır. Eğer docker: 'compose' is not a docker command hatası alınırsa, plugin kurulmamış demektir ve ileride karmaşık hatalarla karşılaşılacaktır; bu sorunu burada çözün.
Compose dosyası: Tek düğümlü replica set olarak MongoDB
Bu kısım sıkça hata yapılan bir bölümdür, bu yüzden dikkatlice okuyunuz. Rocket.Chat, yeni mesajları bağlı istemcilere gerçek zamanlı olarak iletmek için MongoDB change streams özelliğini kullanır; change streams özelliği yalnızca bir replica set üzerinde mevcuttur. Rocket.Chat'i düz bir standalone mongod sunucusuna yönlendirirseniz, bağlantı kurulur ancak change stream açılamadığı için uygulama sürekli yeniden başlatma döngüsüne (restart-loop) girer. Çözüm karmaşık değildir: Standart bir MongoDB konteyneri çalıştırılır, ancak konteyner --replSet ile başlatılır ve ardından tek üyeli bir set initialize edilir.
Çalışma dizini ve bir compose.yml oluşturun:
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:Buradaki bazı seçimler bilinçli yapılmıştır. Rocket.Chat portu 0.0.0.0 yerine 127.0.0.1:3000 üzerinde yayınlanır; uygulamanın kendisi TLS kullanmaz, bu nedenle uygulamaya yalnızca aynı makinedeki reverse proxy üzerinden erişilmelidir; tüm arayüzlere (interface) bağlamak, düz metin (plaintext) giriş sayfasını doğrudan internete açacaktır. MongoDB host makinesine hiç açılmamıştır; yalnızca Compose'un dahili ağı üzerinden mongodb ismiyle erişilebilir; bu isim aynı zamanda MONGO_URL tarafından kullanılan hostname değeridir. MONGO_URL, ?replicaSet=rs0 içerir; bu özellik kaldırılırsa sürücü (driver), sunucu bir replica set olsa bile onu standalone olarak kabul eder ve change streams yine hata verir. MONGO_OPLOG_URL, oplog verisinin bulunduğu local veritabanını işaret eder; modern Rocket.Chat sürümleri change streams tercih eder, ancak bu ayarın yapılması zararsızdır ve eski kod yollarının çalışmasını sağlar. depends_on, condition: service_healthy kullanır; bu sayede Compose, MongoDB'den bir ping yanıtı alana kadar Rocket.Chat'i başlatmaz; healthcheck bu işe yarar.
Her iki imaj için de gerçek versiyon etiketlerini sabitleyin — burada mongo:8.0 ve 8.5.1 gibi açık bir Rocket.Chat sürümü kullanın — ve asla :latest kullanmayın; bu etiket, denetimsiz bir docker pull işlemini kazara ve taşınamaz bir yükseltmeye dönüştürür. Sabitleme yapmadan önce güncel kararlı Rocket.Chat sürümünü ve desteklediği MongoDB versiyonlarını kontrol edin. Rocket.Chat, her sürüm için makine tarafından okunabilir bir bilgi belgesi yayınlar: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}', 8.5.1 sürümü için compatibleMongoVersions: ["8.0"] döndürür, dolayısıyla mongo:8.0 tek desteklenen motordur; ayrıca lts bayrağı, söz konusu sürümün sürekli bakım gerektirmeyen bir sunucu için sabitlenmeye değer bir uzun süreli destek (LTS) sürümü olup olmadığını belirtir.
Replica set'i başlatın
Stack'i başlatın:
sudo docker compose up -dRocket.Chat hemen çökmeye başlayacaktır ve Docker onu sürekli yeniden başlatacaktır; bu beklenen bir durumdur çünkü replica set henüz oluşturulmamıştır. Manuel olarak bir kez oluşturun:
sudo docker compose exec mongodb mongosh --eval 'rs.initiate({_id: "rs0", members: [{_id: 0, host: "mongodb:27017"}]})'Doğru sonuç { ok: 1 } olmalıdır. Birkaç saniye içinde tek düğüm kendisini primary olarak seçer; şu komutla onaylayın:
sudo docker compose exec mongodb mongosh --quiet --eval 'rs.status().members[0].stateStr'PRIMARY çıktısını görmeniz gerekir. Bu sayfadaki en önemli ayrıntı host: "mongodb:27017" argümanıdır. Eğer üye listesi olmadan yalın bir rs.initiate() çalıştırılırsa, MongoDB replica set'i konteynerin dahili hostname'i altında duyurur; bu, a1b2c3d4e5f6 gibi rastgele bir hash değeridir. Kendi konteynerinden bağlanan Rocket.Chat bu ismi çözümleyemez, bu nedenle MongoDB sürücüsü DNS hatası alır ve sürekli MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 loglarını basarak döngüye girer. İşlemi her zaman MONGO_URL ile eşleşen açık servis adı ile başlatın.
İlk açılış: süreci takip edin
Set primary konuma geldiğinde, Rocket.Chat'in bir sonraki yeniden başlatılması sorunsuz bir şekilde gerçekleşir ve ilk çalıştırma göçlerini (migrations) başlatır. Logları takip edin:
sudo docker compose logs -f rocketchatBeklenen satır başlangıç banner'ıdır:
+--------------------------------------------+
SERVER RUNNING
Rocket.Chat Version: 8.5.1
NodeJS Version: 22.22.3 - x64
+--------------------------------------------+İlk açılış yavaştır; uygulama veritabanı göçlerini gerçekleştirir ve indeksleri oluşturur, bu nedenle endişelenmeden önce bir veya iki dakika bekleyin. Eğer loglarda MongoServerSelectionError: Server selection timed out after 30000 ms ifadesi ReplicaSetNoPrimary tipinde bir topoloji açıklamasıyla tekrarlanıyorsa, replica set başlatılmamıştır; eğer rastgele bir hash üzerinde getaddrinfo ENOTFOUND tekrarlanıyorsa, yanlış host ile başlatılmıştır. Her iki durumda da bir önceki adıma dönün. SERVER RUNNING ifadesi görüldüğünde, Rocket.Chat 127.0.0.1:3000 üzerinde dinlemeye başlamıştır; artık gerçek bir hostname ve TLS yapılandırması ekleme zamanı gelmiştir.
TLS arkasına alın
Rocket.Chat'i asla düz HTTP üzerinden dış dünyaya açmayın. http:// üzerinden bir kez giriş yapmak, admin şifrenizi yol üzerindeki herhangi birine kaptırmanıza neden olur. TLS sonlandırmasını aynı makine üzerindeki bir reverse proxy ile gerçekleştirin ve trafiği 127.0.0.1:3000 adresine iletin. İki konu kritiktir: proxy, WebSocket upgrade header bilgilerini iletmelidir; çünkü Rocket.Chat gerçek zamanlı çalışır ve bu bilgiler olmadan işlevini yitirir. Ayrıca, container'ın ROOT_URL değeri, kullanıcıların yazdığı genel HTTPS adresiyle birebir eşleşmelidir.
Uygulamaya proxy yapan ve upgrade header bilgilerini ileten düz bir HTTP nginx server block ile başlayın. Bu bloğu /etc/nginx/sites-available/rocketchat olarak kaydedin, sites-enabled dizinine sembolik bağ (symlink) oluşturun ve yeniden yükleyin:
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;
}
}Şimdilik 80 portunda bırakın; listen 443 ssl; içeren ve sertifikası olmayan bir blok sudo nginx -t testinden bile geçemez. nginx'i yeniden yükleyin (sudo nginx -t && sudo systemctl reload nginx), ardından sertifikayı oluşturun. Ubuntu üzerindeki en temiz yöntem Certbot ve nginx ile Let's Encrypt TLS sertifikaları kullanmaktır: certbot --nginx yukarıdaki bloğu yerinde yeniden yazar; listen 443 ssl;, ssl_certificate satırlarını ve otomatik 80-to-443 yönlendirmesini ekler ve yenileme işlemini sizin yerinize planlar. Eğer tek bir proxy arkasında halihazırda birden fazla container çalıştırıyorsanız, Birçok Docker uygulaması için otomatik TLS ile Traefik daha düzenli bir seçenektir; rocketchat servisine router ve service etiketleri ekleyin; Traefik, nginx bloğuna ihtiyaç duymadan istekleri karşılar ve sertifikayı sizin yerinize yeniler. Her iki durumda da, compose.yml içindeki ROOT_URL değerini https://chat.example.com olarak ayarlayın ve değişikliğin container tarafından algılanması için sudo docker compose up -d komutunu tekrar çalıştırın. Sunucunun genel internet yerine sadece kendi ağınızdan erişilebilir olmasını istiyorsanız, önüne bir VPS üzerinde self-hosted WireGuard VPN kurun ve proxy'yi tünel adresine bağlayın.
İlk çalıştırma kurulum sihirbazı
https://chat.example.com adresine gidin ve Rocket.Chat sizi kısa bir sihirbaz aracılığıyla yönlendirsin. İlk adım admin account (yönetici hesabı) oluşturmaktır; gerçek isim, kullanıcı adı, e-posta ve güçlü bir şifre gereklidir. Bu, mevcut olan tek hesaptır, bu nedenle bilgilerini kaybetmeyin. Sonraki adım organisation and server info (organizasyon ve sunucu bilgileri) kısmıdır; isim, sektör, büyüklük, site adı ve varsayılan dil bilgilerini girin. Bu bilgiler sadece görsel amaçlıdır, doldurup devam edebilirsiniz. Ardından asıl önemli olan seçim gelir: çalışma alanını Rocket.Chat Cloud ile register this workspace (kaydetmek) veya standalone (bağımsız) olarak tutmak.
Kayıt işlemi, Rocket.Chat gateway ve eklenti pazaryeri üzerinden mobil push bildirimlerini etkinleştirir; ancak bu durum Rocket.Chat cloud ile bir kontrol düzlemi ilişkisi kurulmasına neden olur. Standalone kullanımı sunucuyu tamamen özel ve bağımlılıksız tutar, ancak iOS ve Android push bildirimleri çalışmayı durdurur. Bunun sebebi, Apple ve Google'ın kendi oluşturduğunuz bir uygulamanın push sertifikalarını tutmasına izin vermemesidir; resmi uygulamalar bulut gateway üzerinden yönlendirilir. Eğer önceliğiniz gizlilik ise ve kullanıcılarınız web uygulamasını kullanıyorsa standalone seçeneğini; mobil push bildirimleri zorunluysa kayıt seçeneğini tercih edin. Daha sonra Admin menüsü altından bu kararı değiştirebilirsiniz.
Davet etmeden önce erişimi kısıtlayın
Rocket.Chat varsayılan olarak open registration on ayarıyla gelir. Registration Form ayarı Public olarak yapılandırılmıştır; bu nedenle URL'yi bulan herkes hesap oluşturabilir. Bu durum, herkese açık bir hostname üzerinde güvenlik açığı oluşturur. Admin → Settings → Accounts → Registration menüsüne gidin ve Registration Form ayarını hesapların manuel olarak veya davet bağlantısıyla oluşturulması için Disabled veya Secret URL olarak değiştirin. Aynı bölümde, özel olarak herkese açık ve salt okunur bir kanal istemiyorsanız, Allow Anonymous Read ve Allow Anonymous Write seçeneklerini devre dışı bırakın.
Dosya yüklemelerinin nereye kaydedileceğini belirleyin. Varsayılan File Upload depolama birimi GridFS'dir; bu birim tüm resimleri ve ekleri MongoDB içinde saklar. Bu yöntem basittir ancak kullanıcılar ekran görüntüsü paylaştıkça veritabanının ve her bir mongodump dosyasının sınırsız şekilde büyümesine neden olur. Admin → Settings → File Upload menüsü altından depolama birimini yerel dosya sistemi (local filesystem) veya S3 uyumlu bir bucket olarak değiştirebilir ve makul bir maksimum dosya boyutu belirleyebilirsiniz. Küçük ekipler için GridFS uygundur; ancak zamanla yedekleme boyutlarının artacağını unutmayın.
mongodump ile yedekleme
Tüm verileriniz mongodb_data dizininde tutulur. Çalışan bir veritabanı altındayken dizini doğrudan kopyalamayın; mongodump kullanarak verileri ana makinedeki bir dosyaya aktararak tutarlı bir döküm alın:
sudo docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > rocketchat-$(date +%F).archive.gzBu tek gzipped arşivi tüm çalışma alanınızı içerir: kullanıcılar, kanallar, mesajlar, ayarlar ve eğer yüklemeler GridFS üzerinde bırakıldıysa dosyalar da dahildir. Yüklemeler dosya sistemi veya S3 üzerine taşındıysa, bu depolama alanını ayrıca yedekleyin. Yeni bir kurulum üzerine geri yükleme yapmak için önce replica set'i başlatın, ardından şu komutu çalıştırın:
sudo docker compose exec -T mongodb mongorestore --archive --gzip --drop < rocketchat-2026-07-15.archive.gzArşivi sunucudan dışarıya — nesne depolama, başka bir sunucu veya VPS çöktüğünde yedeğin de kaybolmayacağı herhangi bir yere — kopyalayın ve her gece cron ile döküm işlemini çalıştırın. Hiç geri yüklenmemiş bir yedek, gerçek bir yedek değil, sadece bir umuttur; ihtiyacınız olduğunda çalıştığından emin olmak için geçici bir VPS üzerinde geri yükleme pratiği yapın.
Upgrades: pin tags, read the notes, respect the Mongo matrix
Yükseltme işlemlerinin sorunsuz ilerlemesi için iki kural bulunmaktadır. Birincisi, Rocket.Chat sürümünü her seferinde yalnızca bir ana sürüm (major version) yükseltin. Yazılım, açılış sırasında şema migrasyonlarını çalıştırır ve doğrudan ana sürüm atlamayı reddeder; 6.x sürümünden doğrudan 8.x sürümüne geçmeye çalışmak, verilerin bozulması yerine bir migrasyon hatasıyla sonuçlanır. Image tag değerini bir sonraki ana sürümün en son sürümüyle güncelleyin, o sürümün notlarını (breaking changes için) okuyun, docker compose up -d komutunu çalıştırın ve bir sonraki adıma geçmeden önce loglarda migrasyonun tamamlandığını gözlemleyin. İkincisi, MongoDB destek matrisine uyun. Her Rocket.Chat sürümü belirli bir MongoDB sürüm setini destekler; hangisinin desteklendiğini curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions belirtir. MongoDB sürümünü güncellerken —örneğin 7.0'dan 8.0'a— her seferinde yalnızca bir ana sürüm ilerleyin ve her adımdan sonra feature-compatibility versiyonunu ayarlayın. MongoDB 8.0 üzerinde bu komut açık bir confirm: true gerektirir; aksi takdirde onay bayrağı (confirmation flag) ile yeniden çalıştırılması gerektiğini belirten bir hata mesajı verir:
sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'Her iki bileşenin her yükseltme işleminden önce mongodump alın. Güvenlik için tek yöntem budur.
Hata modları ve tam dize içerikleri
Rocket.Chat, docker compose up işleminden hemen sonra yeniden başlatma döngüsüne giriyor ve docker compose logs rocketchat bir MongoServerSelectionError ile doluyor. MongoDB çalışıyor ancak sürücü bir primary seçemiyor; hata dizesi yapılan hatayı belirtir. Topoloji tipi ReplicaSetNoPrimary olan bir Server selection timed out after 30000 ms, rs.initiate() komutunun çalıştırılmadığı anlamına gelir; set henüz yapılandırılmamıştır. Rastgele bir hash ile takip edilen getaddrinfo ENOTFOUND, işlemin açıkça host: "mongodb:27017" belirtilmeden başlatıldığını gösterir; bu durumda MongoDB, çözümlenemeyen bir konteyner ana bilgisayar adı yayınlar. sudo docker compose exec mongodb mongosh --eval 'rs.status()' ile teşhis koyun: eğer MongoServerError: no replset config has been received hatası alınıyorsa seti başlatın; eğer name değeri rastgele bir hash olan bir üye görülüyorsa, servis adını kullanarak yeniden başlatın.
Web arayüzü yükleniyor ancak giriş işlemi sonsuza kadar dönüyor ve tamamlanmıyor. Tarayıcı konsolunu açtığınızda WebSocket connection to 'wss://chat.example.com/websocket' failed hatasını göreceksiniz. Bu durum neredeyse her zaman bir ROOT_URL uyumsuzluğu veya upgrade header bilgilerini iletmeyen bir proxy kaynaklıdır. ROOT_URL değerinin, https:// dahil olmak üzere tam genel adres ile aynı olduğunu ve nginx location bloğunun Upgrade ve Connection "upgrade" değerlerini proxy_http_version 1.1 ile ayarladığını doğrulayın. Bu değerlerden birini değiştirin ve docker compose up -d komutunu tekrar çalıştırın.
Bir konteyner sürekli kapanıyor ve docker compose ps bunun Restarting olduğunu gösteriyor. docker compose logs satır ortasında kesiliyor ve sudo dmesg | tail, oom-killer kaynaklı Out of memory: Killed process 12345 (mongod) hatasını gösteriyor; çıkış kodu 137'dir. Sistemde RAM kalmamıştır. Kalıcı çözüm daha büyük bir VPS kullanmaktır; minimum 4 GB gereklidir. Geçici bir çözüm olarak swap ekleyin ve MongoDB önbelleğini command içerisindeki --wiredTigerCacheSizeGB 1 ile sınırlayın; ancak swap kullanımı, gerçek yük altında bir sonraki OOM hatasını sadece geciktirir:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfiledocker compose up, Error response from daemon: driver failed programming external connectivity ... bind: address already in use hatası veriyor. 3000 portu başka bir işlem tarafından kullanılıyor; bu genellikle düzgün kapanmamış önceki bir Rocket.Chat konteyneri veya başka bir uygulamadır. İşlemi sudo ss -ltnp | grep :3000 ile bulun, ilgili süreci veya konteyneri durdurun ya da eşleme tarafını 127.0.0.1:3001:3000 olarak değiştirip proxy'nizin proxy_pass ayarını buna göre güncelleyin.
FAQ
Rocket.Chat gerçekten bir MongoDB replica set yapısına ihtiyaç duyar mı?
Evet, tek bir veritabanı düğümü olan tek bir sunucu için bile gereklidir. Rocket.Chat, mesajları gerçek zamanlı olarak MongoDB change streams kullanarak iletir. Change streams özelliği yalnızca replica-set yapılarında mevcuttur; standalone bir mongod bu özelliği kullanamaz. Birden fazla makineye ihtiyacınız yoktur; --replSet rs0 ile başlatılmış tek bir MongoDB container'ı çalıştırabilir ve rs.initiate() ile tek üyeli bir set başlatabilirsiniz. Bu adım atlanırsa driver bir primary bulamaz; bu durumda Rocket.Chat, MongoServerSelectionError: Server selection timed out hatasıyla sürekli yeniden başlar ve açılış tamamlanamaz.
Kendi sunucunuzda barındırılan Rocket.Chat ne kadar RAM gerektirir?
Pratik minimum için 4 GB, yoğun bir ekip için ise 8 GB planlayın. Rocket.Chat'in Node süreci yaklaşık 1 ile 1.5 GB arası RAM kullanır. MongoDB ise kalan RAM'in yaklaşık yarısını WiredTiger cache için ayırır. 2 GB kapasiteli bir makinede bu iki süreç çakışır; gerçek bir yük altında out-of-memory killer mongod sürecini sonlandırır, loglarda Killed hatası ve 137 çıkış kodu görülür. 2 GB, yazılımı yalnızca birkaç test kullanıcısı ile değerlendirmek için yeterlidir.
Rocket.Chat'i HTTPS arkasına nasıl koyarım?
Aynı VPS üzerinde TLS sonlandırması yapan ve trafiği 127.0.0.1:3000 adresine ileten bir reverse proxy çalıştırın. Container'ın ROOT_URL ayarını halka açık https:// adresinize ayarlayın. Proxy, WebSocket upgrade header bilgilerini iletmelidir; aksi takdirde oturum açma işlemi askıda kalır. Nginx ile Certbot en basit tek uygulama kurulumudur; birden fazla container'ı tek bir proxy arkasında çalıştırıyorsanız ve otomatik sertifika yönetimi istiyorsanız Traefik daha temiz bir çözümdür.
Kendi sunucumdaki Rocket.Chat'i nasıl yedeklerim?
Volume kopyalamak yerine mongodump ile tutarlı bir veritabanı dökümü alın: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Bu arşiv; kullanıcıları, kanalları, mesajları ve ayarları içerir; eğer depolama GridFS üzerinde bırakıldıysa yüklenen dosyaları de içerir. Arşivi sunucudan başka bir yere kopyalayın, cron ile her gece otomatik hale getirin ve geri yüklemenin çalıştığından emin olmak için geçici bir makinede mongorestore denemesi yapın.
MongoDB'yi bozmadan Rocket.Chat nasıl yükseltilir?
Rocket.Chat'i her seferinde bir ana sürüm (major version) olacak şekilde yükseltin; yazılım açılışta migration işlemlerini çalıştırır ve ana sürümlerin atlanmasına izin vermez. Pinlenmiş image tag'ini değiştirmeden önce her sürümün notlarını okuyun. Hedef sürümün hangi MongoDB versiyonlarını desteklediğini curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions ile kontrol edin. MongoDB sürümünü değiştirirken her adımda bir ana sürüm ilerleyin ve her sıçramadan sonra confirm: true ile setFeatureCompatibilityVersion ayarını yapın. Her zaman önce bir mongodump alın.