Docker Compose ile Rocket.Chat Kurulumu ve Yapılandırması

Ne inşa ediyorsunuz

Tamamen size ait olan özel bir ekip sohbeti: Docker Compose altında kendi VPS'nizde çalışan, TLS ile sonlandırılan ve tüm mesajların yedekleyip taşıyabileceğiniz bir MongoDB veritabanında tutulduğu Rocket.Chat. Rocket.Chat; kanallar, doğrudan mesajlar, iş parçacıkları, dosya paylaşımı ile sesli ve görüntülü görüşme özelliklerine sahip, kiraladığınız ve kontrol ettiğiniz donanım üzerinde çalışan, Slack ve Teams'in olgun bir açık kaynak alternatifidir. Uygulama, dakikalar içinde ayağa kalkan tek bir container'dan oluşur. Ters giden her şey yanındaki veritabanında yaşanır; bu nedenle rehberin büyük bir kısmı MongoDB'ye ve özellikle herkesi ilk seferinde şaşırtan o tek gereksinime odaklanır: Rocket.Chat, bağımsız (standalone) bir MongoDB üzerinde çalışmaz. Bu "küme" tek bir düğümden (node) ibaret olsa bile bir replica set gerektirir.

Ön gereksinimler ve kimsenin bahsetmediği RAM hesabı

Sunucu boyutunu gerçekçi bir şekilde 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 ila 1,5 GB RAM tüketir; MongoDB'nin WiredTiger önbelleği ise varsayılan olarak kalan RAM'in yaklaşık yarısını talep eder. 2 GB'lık bir VPS üzerinde bu ikili açılışta çalışır ancak gerçek trafik geldiği anda çakışırlar: MongoDB önbelleğini büyütür, Node yığınını (heap) genişletir, çekirdek bellek sayfalarını tüketir ve out-of-memory killer genellikle en büyük süreci, yani mongod'ü sonlandırır. Konteyner Killed çıktısını verir, Docker onu yeniden başlatır ve sonuçta yük altında kolayca çalışması gereken bir sohbet sunucusu sürekli kesintiye uğrar. 2 GB, iki kişiyle deneme yapmak için yeterlidir; ancak bir ekip sunucusu değildir. 4 GB ile başlayın; düzinelerce eşzamanlı kullanıcı, görüntülü görüşme veya büyüyen bir yükleme geçmişi bekliyorsanız 8 GB RAM sağlayın.

Başlamadan önce üç şeyi hazır bulundurmanız gerekir. VPS'in genel IP adresine işaret eden bir A kaydına sahip bir alan adı; Rocket.Chat'in gerçek zamanlı özellikleri ve mobil istemcileri ham bir IP adresi değil, kararlı bir ana makine adı (hostname) gerektirir. Hem sunucu güvenlik duvarında hem de çoğu panelde ayrı bir kontrol mekanizması olan sağlayıcınızın ağ güvenlik duvarında 80 ve 443 numaralı portların açık olması gerekir. Ayrıca root veya sudo yetkilerine sahip temiz bir Ubuntu 24.04 KVM VPS gereklidir. Eğer bir sohbet sunucusunun çalıştırılacak ilk servis olup olmadığına henüz karar vermediyseniz, 2026 yılında self-host etmeye değer servisler rehberi bu konudaki avantaj ve dezavantajları ortaya koymaktadır.

Docker motorunu ve Compose eklentisini kurun

Ubuntu'nun sunduğu docker.io paketini veya eski, bağımsız docker-compose Python ikili dosyasını değil, Docker'ın kendi apt deposunu kullanın. Modern Compose, docker compose şeklinde, tire işareti olmadan boşlukla çağrılan bir Docker eklentisidir. Eski docker-compose v1 sürümünün kullanım ömrü dolmuştur; aşağıdaki sağlık kontrolü 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-plugin

Her iki bileşenin de mevcut olduğunu doğrulayın:

sudo docker version
sudo docker compose version

docker compose version komutunun Docker Compose version v2.x benzeri bir çıktı vermesi, kontrolün başarılı olduğu anlamına gelir. Eğer docker: 'compose' is not a docker command hatası alırsanız, eklenti kurulmamış demektir; bu durum ileride karmaşık hatalara yol açacağı için sorunu burada giderin.

Compose dosyası: Tek düğümlü replica set olarak MongoDB

Bu kısım genellikle yanlış anlaşıldığı için dikkatle incelenmelidir. Rocket.Chat, yeni mesajları bağlı istemcilere gerçek zamanlı iletmek için MongoDB change streams özelliğini kullanır ve bu özellik yalnızca bir replica set üzerinde kullanılabilir. Rocket.Chat'i standart bir tekil mongod örneğine yönlendirirseniz bağlantı kurulur ancak change stream açılamadığı için uygulama sürekli yeniden başlatma döngüsüne girer. Çözüm karmaşık değildir: tek bir standart MongoDB container çalıştırılır, ancak --replSet bayrağı ile başlatılır ve ardından tek üyeli bir set olarak başlatılır.

Bir ç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ı tercihler bilinçli olarak yapılmıştır. Rocket.Chat portu 0.0.0.0 yerine 127.0.0.1:3000 adresine yayınlanmıştır; uygulamanın kendisinde TLS bulunmadığından, yalnızca aynı sunucudaki reverse proxy ona erişebilmelidir. Tüm arayüzlere bağlamak, düz metin bir giriş sayfasını doğrudan genel internete açmak anlamına gelir. MongoDB ise ana makineye hiç yayınlanmamıştır; yalnızca Compose'un dahili ağı üzerinden, MONGO_URL tarafından kullanılan ana bilgisayar adı olan mongodb ismiyle erişilebilir. MONGO_URL, ?replicaSet=rs0 değerini taşır; bu parametre çıkarılırsa, replica set olmasına rağmen sürücü sunucuyu tekil olarak algılar ve change stream işlemleri başarısız olur. MONGO_OPLOG_URL, oplog'un bulunduğu local veritabanını işaret eder; modern Rocket.Chat change stream kullanmayı tercih etse de, bu ayarın yapılması zararsızdır ve eski kod yollarının düzgün çalışmasını sağlar. depends_on, condition: service_healthy kullanır; böylece Compose, Rocket.Chat'i başlatmadan önce MongoDB'nin bir ping yanıtı vermesini bekler; healthcheck'in amacı budur.

Her iki image için de gerçek sürüm tag’leri sabitleyin: burada mongo:8.0 ve 8.5.1 gibi açık bir Rocket.Chat release kullanın. Denetimsiz bir docker pull işlemini yanlışlıkla yapılan ve migration işlemi gerçekleştirilemeyen bir upgrade’e dönüştüren :latest seçeneğini hiçbir zaman kullanmayın. Sürümü sabitlemeden önce mevcut stable Rocket.Chat release’ini ve desteklediği MongoDB sürümlerini kontrol edin. Rocket.Chat her release için makine tarafından okunabilen bir bilgi belgesi yayımlar: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}', 8.5.1 için compatibleMongoVersions: ["8.0"] değerini döndürür. Bu nedenle desteklenen tek engine mongo:8.0 değeridir. Ayrıca bu release’in, sürekli bakım gerektirmeyen bir server için sabitlenmeye uygun long-term-support build olup olmadığını belirten bir lts flag’i de bulunur. Her proje versioned image yayımlamaz. Bu durumda sabitleme source üzerinde yapılır: openGym workout tracker’ı self-host etme için değişken bir branch’i takip etmek yerine belirli bir git tag checkout edilmeli ve bu kaynaktan build alınmalıdır.

Replica set kurulumu

Yığını ayağa kaldırın:

sudo docker compose up -d

Replica set henüz mevcut olmadığı için Rocket.Chat hemen çökecek ve Docker servisi sürekli yeniden başlatacaktır; bu beklenen bir durumdur. Replica set'i 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 } şeklindedir. Birkaç saniye içinde tek düğüm kendini birincil (primary) olarak seçecektir; durumu şu komutla doğrulayı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 detay host: "mongodb:27017" argümanıdır. Eğer üye listesi belirtmeden sadece rs.initiate() komutunu çalıştırırsanız, MongoDB replica set'i container'ın dahili ana bilgisayar adı olan a1b2c3d4e5f6 gibi rastgele bir hash değeriyle duyurur. Kendi container'ı içinden bağlanan Rocket.Chat bu ismi çözümleyemez, bu nedenle MongoDB sürücüsü DNS hatası verir ve sürekli MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 günlüğünü yazarak döngüye girer. Başlatma işlemini her zaman MONGO_URL değerinizle eşleşen açık servis adını kullanarak gerçekleştirin.

İlk başlatma: sistemin ayağa kalkışını izleme

Set birincil duruma geldiğinde, Rocket.Chat bir sonraki yeniden başlatmada sorunsuz bağlanır ve ilk çalıştırma migrasyonlarını başlatır. Günlük kayıtlarını izleyin:

sudo docker compose logs -f rocketchat

Beklemeniz gereken satır, başlangıç başlığıdır:

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

İlk başlatma yavaştır; uygulama veritabanı migrasyonlarını çalıştırır ve indeksleri oluşturur, bu nedenle endişelenmeden önce bir veya iki dakika bekleyin. Eğer günlük kaydı sürekli olarak MongoServerSelectionError: Server selection timed out after 30000 ms ifadesini ve ReplicaSetNoPrimary tipinde bir topoloji açıklamasını tekrarlıyorsa, replica set başlatılmamış demektir; eğer rastgele bir hash üzerinde getaddrinfo ENOTFOUND ifadesini tekrarlıyorsa, yanlış ana makine (host) ile başlatılmıştır. Her iki durumda da bir önceki adıma geri dönün. SERVER RUNNING ifadesini gördüğünüzde, Rocket.Chat 127.0.0.1:3000 üzerinde dinleme yapıyor demektir; artık önüne gerçek bir ana makine adı ve TLS ekleme zamanı gelmiştir.

TLS arkasına alın

Rocket.Chat uygulamasını asla şifrelenmemiş HTTP üzerinden dış dünyaya açmayın. http:// üzerinden bir kez giriş yaptığınızda, yönetici parolanızı ağ yolundaki herkese teslim etmiş olursunuz. TLS termination işlemini aynı sunucu üzerindeki bir reverse proxy katmanında yapın ve trafiği 127.0.0.1:3000 adresine yönlendirin. İki nokta kritiktir: Proxy, WebSocket yükseltme başlıklarını (upgrade headers) iletmelidir; çünkü Rocket.Chat gerçek zamanlı çalışır ve bu başlıklar olmadan bağlantı kopar. Ayrıca container içindeki ROOT_URL değeri, kullanıcıların tarayıcıya yazdığı genel HTTPS adresiyle tam olarak eşleşmelidir.

İşe, uygulamaya proxy yapan ve yükseltme başlıklarını ileten standart bir HTTP nginx sunucu bloğu ile başlayın. Dosyayı /etc/nginx/sites-available/rocketchat olarak kaydedin, sites-enabled dizinine sembolik bağ (symlink) oluşturun ve yapılandırmayı 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 numaralı portta bırakın; listen 443 ssl; içermeyen ve sertifikası olmayan bir blok sudo nginx -t testini geçemez. Nginx servisini yeniden yükleyin (sudo nginx -t && sudo systemctl reload nginx) ve ardından sertifikayı oluşturun. Ubuntu üzerinde en temiz yöntem Certbot ve nginx ile Let's Encrypt TLS sertifikaları kullanmaktır: certbot --nginx komutu yukarıdaki bloğu yerinde düzenleyerek listen 443 ssl; ayarını, ssl_certificate satırlarını ve 80'den 443'e otomatik yönlendirmeyi ekler; ayrıca sertifika yenileme işlemini sizin yerinize planlar. Eğer halihazırda tek bir proxy arkasında 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 etiketlerini eklediğinizde Traefik, herhangi bir nginx bloğuna ihtiyaç duymadan sertifikayı talep eder ve yeniler. Hangi yöntemi seçerseniz seçin, compose.yml dosyasında ROOT_URL değerini https://chat.example.com olarak ayarlayın ve container'ın değişikliği algılaması için sudo docker compose up -d komutunu tekrar çalıştırın. Sunucuya genel internet üzerinden değil de yalnızca kendi ağınızdan erişilmesini istiyorsanız, sunucunun önüne 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; Rocket.Chat sizi kısa bir kurulum sihirbazına yönlendirecektir. İlk adımda yönetici hesabı için gerçek bir isim, kullanıcı adı, e-posta adresi ve güçlü bir parola belirleyin; bu, sistemde mevcut olan tek hesap olduğundan erişim bilgilerini kaybetmeyin. Ardından kuruluş ve sunucu bilgileri kısmında isim, sektör, ölçek, site adı ve varsayılan dil bilgilerini girin; bunlar kozmetik bilgilerdir, doldurup devam edebilirsiniz. Sonrasında ise asıl önemli olan seçime gelin: çalışma alanını Rocket.Chat Cloud ile kaydedin veya bağımsız (standalone) olarak bırakın.

Kayıt işlemi, Rocket.Chat ağ geçidi üzerinden mobil anlık bildirimleri ve eklenti marketini etkinleştirir; bunun karşılığında Rocket.Chat bulut altyapısı ile bir kontrol düzlemi bağlantısı kurulur. Bağımsız mod ise sunucuyu tamamen gizli ve bağımlılıklardan arınmış tutar; ancak iOS ve Android anlık bildirimleri çalışmayı durdurur. Apple ve Google, kendi derlediğiniz uygulamaların anlık bildirim sertifikalarını tutmasına izin vermediğinden, resmi uygulamalar bulut ağ geçidi üzerinden yönlendirilir. Gizlilik temel önceliğinizse ve kullanıcılarınız web uygulamasını kullanıyorsa bağımsız modu seçin; mobil bildirimler vazgeçilmezse kayıt işlemini tercih edin. Bu tercihi daha sonra Yönetim (Admin) paneli altından değiştirebilirsiniz.

Kimseye izin vermeden önce güvenliği sağlayın

Rocket.Chat, varsayılan olarak açık kayıt özelliğiyle gelir; Kayıt Formu (Registration Form) Public olarak ayarlanmıştır, bu nedenle URL'yi bulan herkes bir hesap oluşturabilir. Halka açık bir ana makine adında bu, açık bir kapı anlamına gelir. Admin → Settings → Accounts → Registration yolunu izleyin ve Registration Form ayarını Disabled olarak değiştirin; böylece hesapları manuel olarak veya davet bağlantısı ile oluşturabilirsiniz ya da Secret URL seçeneğini kullanın. Buradayken, özel olarak herkese açık salt okunur bir kanal istemiyorsanız Allow Anonymous Read ve Allow Anonymous Write seçeneklerini kapatın. Her hesabı manuel olarak oluşturmak zahmetli geliyorsa ve ekibinizin giriş yaptığı tek servis bu değilse, Rocket.Chat'in OAuth girişini kendi kendine barındırılan bir Authentik SSO sunucusuna yönlendirin; böylece sisteme katılanlar ve ayrılanlar her uygulama için ayrı ayrı değil, tek bir merkezden yönetilmiş olur.

Yüklemelerin nereye gideceğine de karar verin. Varsayılan File Upload depolama alanı GridFS'tir; bu, her görseli ve eki doğrudan MongoDB içinde saklar. Bu basit bir yöntemdir ancak veritabanınızın ve aldığınız her mongodump yedeğinin, kullanıcılar ekran görüntüsü paylaştıkça sınırsızca büyümesi anlamına gelir. Admin → Settings → File Upload altında depolamayı yerel dosya sistemine veya S3 uyumlu bir bucket'a geçirebilir ve makul bir maksimum dosya boyutu belirleyebilirsiniz. Küçük bir ekip için GridFS uygundur; sadece yedeklerinizin zamanla ağırlaşacağını göz önünde bulundurun.

mongodump ile yedekleme

Tüm verileriniz mongodb_data birimi içerisinde yer alır. Çalışan bir veritabanının altındaki birimi doğrudan kopyalamayın; bunun yerine mongodump kullanarak tutarlı bir döküm alın ve bunu ana makinedeki bir dosyaya aktarın:

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

Bu tekil gzipped arşiv tüm çalışma alanınızı içerir: kullanıcılar, kanallar, mesajlar, ayarlar ve eğer yüklemeleri GridFS üzerinde bıraktıysanız dosyalarınız. Yüklemeleri dosya sistemine veya S3'e taşıdıysanız, bu depolama alanını ayrıca yedekleyin. Geri yükleme yapmak için önce replica set kurulumunu gerçekleştirin, ardından yeni bir yığın üzerinde şu komutu çalıştırın:

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

Arşivi sunucunun dışına, nesne depolama alanına, başka bir sunucuya veya VPS'in çökmesi durumunda yedeğin kaybolmayacağı herhangi bir yere kopyalayın ve döküm işlemini cron ile her gece çalışacak şekilde ayarlayın. Daha önce hiç geri yüklemediğiniz bir yedek, yedek değil sadece bir temennidir; ihtiyacınız olduğunda çalıştığından emin olmak için geri yükleme işlemini tek kullanımlık bir VPS üzerinde mutlaka deneyin.

Yükseltmeler: etiketleri sabitleyin, notları okuyun, Mongo matrisine uyun

Yükseltmeleri sorunsuz hale getiren iki kural vardır. Birincisi, Rocket.Chat sürümünü her seferinde bir ana sürüm yükseltin. Uygulama, açılış sırasında şema migrasyonlarını çalıştırır ve ana sürümler arasında doğrudan geçişe izin vermez; 6.x sürümünden doğrudan 8.x sürümüne geçmeye çalışırsanız, verilerinizi bozmak yerine bir migrasyon hatası vererek durur. Görüntü etiketini bir sonraki ana sürümün en güncel sürümüne yükseltin, o sürüme ait sürüm notlarını olası değişiklikler için okuyun, docker compose up -d komutunu çalıştırın ve bir sonraki adıma geçmeden önce logların migrasyonu tamamladığından emin olun. İkincisi, MongoDB destek matrisine uyun. Her Rocket.Chat sürümü belirli bir MongoDB sürüm kümesini destekler ve curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions size hangilerinin desteklendiğini gösterir. MongoDB sürümünü örneğin 7.0'dan 8.0'a yükseltirken, her seferinde bir ana sürüm ilerleyin ve her adımdan sonra özellik uyumluluk sürümünü (feature-compatibility version) ayarlayın. MongoDB 8.0 üzerinde bu komut açık bir confirm: true gerektirir, aksi takdirde komut, onay bayrağı ile yeniden çalıştırılmasını belirten bir hata mesajı vererek reddeder:

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

Her iki bileşenin yükseltmesinden önce bir mongodump alın. Tüm sigorta politikanız budur.

Hata modları ve kesin dizeler

Rocket.Chat, docker compose up sonrasında yeniden başlatma döngüsüne giriyor ve docker compose logs rocketchat bir MongoServerSelectionError ile doluyor. MongoDB çalışıyor ancak sürücü birincil (primary) düğümü seçemiyor; hata mesajındaki kesin dize, yaptığınız hatayı size söyler. Server selection timed out after 30000 ms ve ardından gelen ReplicaSetNoPrimary topoloji tipi, rs.initiate() komutunu hiç çalıştırmadığınızı, yani kümenin henüz bir yapılandırmaya sahip olmadığını gösterir. getaddrinfo ENOTFOUND ve ardından gelen rastgele bir hash değeri, küme başlatma işlemini açık bir host: "mongodb:27017" belirtmeden yaptığınızı, bu nedenle MongoDB'nin çözümlenemeyen bir container ana bilgisayar adını (hostname) duyurduğunu gösterir. sudo docker compose exec mongodb mongosh --eval 'rs.status()' ile teşhis edin: Eğer MongoServerError: no replset config has been received hatası veriyorsa kümeyi başlatın; eğer name değeri rastgele bir hash olan bir üye gösteriyorsa, servis adını kullanarak yeniden başlatın.

Web arayüzü yükleniyor ancak giriş yapma ekranı sürekli 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ğundan veya upgrade başlıklarını iletmeyen bir proxy'den kaynaklanır. ROOT_URL değerinin, https:// dahil olmak üzere tam genel adresle eşleştiğinden ve nginx location bloğunuzun Upgrade ve Connection "upgrade" ayarlarını proxy_http_version 1.1 ile yaptığından emin olun. Herhangi birini değiştirirseniz docker compose up -d komutunu yeniden çalıştırın.

Bir container sürekli kapanıyor ve docker compose ps üzerinde Restarting olduğu görülüyor. docker compose logs satır ortasında kesiliyor ve sudo dmesg | tail üzerinde oom-killer kaynaklı Out of memory: Killed process 12345 (mongod) hatası görünüyor; çıkış kodu 137'dir. Sunucunun RAM'i tükenmiştir. Asıl çözüm daha yüksek kapasiteli bir VPS kullanmaktır, minimum 4 GB önerilir. Geçici bir çözüm olarak swap alanı ekleyebilir ve MongoDB'nin önbelleğini command dosyasında --wiredTigerCacheSizeGB 1 ile sınırlayabilirsiniz, ancak swap kullanımı gerçek yük altında bir sonraki OOM (Out of Memory) durumunu sadece geciktirir:

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 hatasıyla başarısız oluyor. 3000 numaralı portu halihazırda başka bir süreç kullanıyor; bu genellikle düzgün bir şekilde durdurulmamış önceki bir Rocket.Chat container'ı veya başka bir uygulamadır. sudo ss -ltnp | grep :3000 ile bunu bulun, ilgili süreci veya container'ı durdurun ya da eşleme (mapping) kısmındaki ana bilgisayar tarafını 127.0.0.1:3001:3000 olarak değiştirin ve 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üne sahip tek bir sunucu için bile bu gereklidir. Rocket.Chat, mesajları gerçek zamanlı olarak iletmek için MongoDB change stream özelliğini kullanır ve change stream yalnızca replica set yapılarında çalışan bir özelliktir; bağımsız (standalone) bir mongod bu özelliği açamaz. Birden fazla makineye ihtiyacınız yoktur; --replSet rs0 ile başlatılan tek bir MongoDB container çalıştırabilir ve rs.initiate() ile tek üyeli bir set başlatabilirsiniz. Bu adımı atlarsanız sürücü hiçbir zaman bir primary düğüm bulamaz, bu nedenle Rocket.Chat MongoServerSelectionError: Server selection timed out hatasıyla sürekli yeniden başlar ve önyükleme işlemini asla tamamlayamaz.

Self-hosted Rocket.Chat ne kadar RAM'e ihtiyaç duyar?

Pratik bir minimum olarak 4 GB, yoğun bir ekip için ise 8 GB RAM planlayın. Rocket.Chat'in Node süreci yaklaşık 1 ila 1.5 GB kullanır ve MongoDB, WiredTiger önbelleği için kalan RAM'in kabaca yarısını talep eder; bu nedenle 2 GB'lık bir sunucuda bu iki süreç çakışır ve out-of-memory killer, gerçek bir yük altında 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ıyla değerlendirmek için yeterlidir.

Rocket.Chat'i HTTPS arkasına nasıl alabilirim?

TLS termination işlemini yapan ve trafiği 127.0.0.1:3000 adresine yönlendiren bir reverse proxy'yi aynı VPS üzerinde çalıştırın ve container'ın ROOT_URL değerini genel https:// adresinize ayarlayın. Proxy, WebSocket upgrade başlıklarını iletmelidir, aksi takdirde giriş işlemi askıda kalır. Nginx ile Certbot, tek uygulamalı kurulumlar için en basit yöntemdir; eğer bir proxy arkasında birden fazla container çalıştırıyorsanız ve otomatik sertifika yönetimi istiyorsanız Traefik daha temiz bir çözümdür.

Self-hosted Rocket.Chat yedeğini nasıl alırım?

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ı, ayarları ve depolama alanı olarak GridFS kullanıyorsanız yüklenen dosyaları içerir. Arşivi sunucudan dışarı kopyalayın, cron ile her gece otomatikleştirin ve geri yükleme işleminin gerçekten çalıştığından emin olmak için geçici bir sunucuda mongorestore provası yapın.

MongoDB'yi bozmadan Rocket.Chat'i nasıl yükseltirim?

Rocket.Chat'i her seferinde bir ana sürüm (major version) olacak şekilde yükseltin; uygulama önyükleme sırasında migrasyonları çalıştırır ve ana sürümleri atlamayı reddeder. Sabitlenmiş image etiketini yükseltmeden önce her sürümün notlarını okuyun. Hedef sürümünüzün hangi MongoDB sürümlerini desteklediğini curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions ile kontrol edin ve MongoDB'yi yükseltirken her seferinde bir ana sürüm ilerleyin, her adımdan sonra confirm: true ile setFeatureCompatibilityVersion ayarını yapın. Her zaman önce bir mongodump alın.