Yazan Matt Connor
Docker Compose ile Rocket.Chat Kurulumu ve Yapılandırması
Docker Compose kullanarak Rocket.Chat kurulumunu VPS üzerinde tamamlayın. MongoDB replica set gereksinimi, TLS yapılandırması ve yedekleme süreçleri dahil tüm kritik adımlar.
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 her mesajı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. Ancak bu tek güvenilir seçenek değildir; hala seçim aşamasındaysanız, Mattermost, Rocket.Chat, Synapse ve Zulip karşılaştırması başlıklı yazı, bu platformları daha sonra sorun yaratabilecek RAM kullanımı, veritabanı, mobil bildirimler, SSO ve yükseltme süreçleri gibi konularda kıyaslamaktadır. Uygulama, dakikalar içinde ayağa kalkan tek bir container'dan oluşur. Ters giden her şey yanındaki veritabanında saklanır; bu nedenle rehberin büyük bir kısmı MongoDB'ye ve özellikle ilk kez kurulum yapan herkesi ş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) oluşsa 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 (toplam RAM eksi 1 GB) değerinin %50'si veya 0.256 GB değerlerinden büyük olanı kullanır. Bu varsayılan ayar, mongod'in makineyi tek başına kullandığını varsayar: Toplam RAM üzerinden hesaplanır ve Node'un halihazırda kullandığı miktarı dikkate almaz. Bu nedenle 4 GB'lık bir makinede 1.5 GB, 2 GB'lık bir makinede ise yaklaşık 0.5 GB önbellek ayırır; bu miktar Node'un heap alanı, mongod'nın önbellek dışındaki bellek kullanımı ve işletim sistemi gereksinimlerinin üzerine eklenir. 2 GB'lık bir VPS üzerinde bu iki servis açılışta çalışır ancak gerçek trafik geldiği anda çakışırlar: MongoDB önbelleğini büyütür, Node heap alanını genişletir, çekirdek bellek sayfalarını tüketir ve "out-of-memory killer" mekanizması en büyük süreci, yani genellikle mongod'yi 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 ancak sürekli bağlantısı kopan bir sohbet sunucunuz olur. 2 GB, iki kişiyle denemeler 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. Sunucunun üzerinde çalışacak diğer servisleri de hesaba katın: Aynı VPS üzerine bir Notion tarzı AFFiNE çalışma alanı kurmak, aynı bellek sayfaları için rekabet eden dört konteyner daha ekler; dolayısıyla bu servislerin RAM ihtiyacı Rocket.Chat'in payından değil, onun üzerine eklenmelidir.
Başlamadan önce üç şeyi hazır bulundurmanız gerekir. VPS'in genel IP adresine yönlendirilmiş bir A kaydı içeren bir alan adı; Rocket.Chat'in gerçek zamanlı özellikleri ve mobil istemcileri, çıplak bir IP adresi değil, kararlı bir ana makine adı 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ı. Son olarak, root veya sudo yetkisine sahip temiz bir Ubuntu 24.04 KVM VPS. Eğer bir sohbet sunucusunun çalıştırılacak ilk servis olup olmadığına henüz karar vermediyseniz, 2026 yılında nelerin self-host edilmeye değer olduğuna dair rehber bu konudaki avantaj ve dezavantajları özetlemektedir.
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ü ömrünü tamamlamıştır ve aşağıda yer alan sağlık kontrolü (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 bir sürüm satırı yazdırması, kontrol edilmesi gereken asıl noktadır. Güncel sürümler Docker Compose version v5.x çıktısını verir (2026-10-10 itibarıyla en son sürüm 2 Ekim 2026 tarihinde yayınlanan v5.6.0 idi); daha eski bir kurulum hala v2.x çıktısı verebilir ve Docker her ikisini de destekler. Docker, Compose v5'i işlevsel olarak v2 ile aynı olarak tanımlar; eski v2 ve v3 compose dosya formatlarıyla karışıklığı önlemek için v5 olarak numaralandırılmıştır, bu nedenle bu kılavuz için her ikisi de uygundur. Eğer docker: 'compose' is not a docker command hatası alırsanız, eklenti kurulmamıştır ve ileride kafa karıştırıcı hatalarla karşılaşacaksınız; bu sorunu burada çözün.
Compose dosyası: Tek düğümlü replica set olarak MongoDB
İnsanların hata yaptığı kısım burasıdır, bu yüzden dikkatli okuyun. Rocket.Chat, yeni mesajları bağlı istemcilere gerçek zamanlı olarak iletmek için MongoDB change stream özelliğini kullanır ve change stream yalnızca bir replica set üzerinde kullanılabilir. Rocket.Chat'i standart bir 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ırsınız ancak bunu --replSet parametresiyle başlatıp ardından tek üyeli bir set olarak başlatırsınız.
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 birkaç tercih 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 yoktur, bu nedenle ona yalnızca aynı sunucudaki reverse proxy erişmelidir; 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ı ile aynı olan mongodb ismiyle erişilebilir durumdadır. MONGO_URL, seti açıkça adlandıran ?replicaSet=rs0 değerini taşır; MongoDB, sürücüler arasında tutarlı bir davranış için bunun ayarlanmasını önerir. Bunu boş bırakmak tek başına bir şeyi bozmaz: directConnection varsayılan olarak false değerini alır, bu nedenle set, Rocket.Chat'in çözümleyebileceği bir ana bilgisayar adıyla başlatıldığı sürece sürücü replica set'i keşfeder ve işlemleri primary düğüme gönderir; bir sonraki bölüm bununla ilgilenmektedir. MONGO_OPLOG_URL, oplog'un bulunduğu local veritabanını işaret eder; modern Rocket.Chat change stream kullanmayı tercih eder ancak bunu ayarlamak zararsızdır ve eski kod yollarının düzgün çalışmasını sağlar. depends_on, condition: service_healthy kullanır; bu sayede Compose, Rocket.Chat'i başlatmadan önce MongoDB'nin bir ping yanıtı vermesini bekler; healthcheck'in amacı budur.
Her iki imaj için de mongo:8.0 ve 8.5.1 gibi belirli bir Rocket.Chat sürümü gibi gerçek sürüm etiketlerini sabitleyin ve asla, gözetimsiz bir docker pull işlemini kazara gerçekleşen ve geri alınamaz bir yükseltmeye dönüştüren :latest etiketini kullanmayın. Sabitleme yapmadan önce güncel kararlı Rocket.Chat sürümünü ve desteklediği MongoDB sürümlerini 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, bu nedenle mongo:8.0 desteklenen tek motordur; ayrıca, söz konusu sürümün sürekli başında durmak istemediğiniz bir sunucu için sabitlemeye değer bir uzun vadeli destek (LTS) sürümü olup olmadığını belirten bir lts bayrağı da bulunur. Her proje sürümlü bir imaj yayınlamaz; bu durumda sabitleme işlemi kaynağa taşınır: openGym antrenman takipçisini kendi sunucunuzda barındırma rehberinde olduğu gibi, hareketli bir dalı takip etmek yerine belirli bir git etiketini çekip oradan derleme yapmak gerekir.
Replica set kurulumu
Yığını ayağa kaldırın:
sudo docker compose up -dReplica 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 rocketchatBeklemeniz 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 kurulum sihirbazı
https://chat.example.com adresine gidin; Rocket.Chat sizi kısa bir kurulum sihirbazına yönlendirecektir. İlk adım yönetici hesabı oluşturmaktır; gerçek ad, kullanıcı adı, e-posta adresi ve güçlü bir parola girin. Bu, sistemdeki tek hesap olacağı için bilgileri kaybetmemeye dikkat edin. Ardından kuruluş ve sunucu bilgileri kısmında isim, sektör, ölçek, site adı ve varsayılan dil bilgilerini girin; bunlar kozmetik ayarlardır, doldurup devam edebilirsiniz. Sonrasında ise asıl önemli olan seçim gelir: çalışma alanını Rocket.Chat Cloud ile kaydettirmek veya bağımsız (standalone) tutmak.
Kaydettirme işlemi, Rocket.Chat ağ geçidi üzerinden mobil anlık bildirimleri ve eklenti marketini etkinleştirir; ancak bu durum, Rocket.Chat bulut altyapısı ile bir kontrol düzlemi ilişkisi kurulmasına neden olur. Ayrıca ağ geçidi üzerinden gönderilen bildirimler, çalışma alanınızın aylık limitinden düşülür. Bağımsız mod ise sunucuyu tamamen gizli ve bağımlılıklardan arınmış tutar; ancak resmi iOS ve Android uygulamaları anlık bildirim almayı durdurur. Rocket.Chat belgelerine göre bu uygulamalar yalnızca bulut ağ geçidi ile çalışır ve ağ geçidi, kayıtsız bir çalışma alanında çalışmaz. Bunun çözümü, mobil uygulamanın kendi beyaz etiketli (white-labeled) sürümünü oluşturmaktır: Push ayarlarından ağ geçidini kapatın, kendi APNs sertifikalarınızı ve Firebase Cloud Messaging kimlik bilgilerinizi girin ve kullanıcılarınızın resmi uygulama yerine kendi uygulamanızı yüklemesini sağlayın. Gizlilik önceliğinizse ve kullanıcılarınız web uygulamasını kullanıyorsa ya da kendi mobil uygulamanızı dağıtmaya hazırsanız bağımsız modu seçin; resmi uygulamalarda anlık bildirim almanız şartsa kaydettirme seçeneğini tercih edin. Bu tercihi daha sonra 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 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ı demektir. Admin → Settings → Accounts → Registration yolunu izleyin ve Registration Form ayarını Disabled olarak değiştirin; böylece hesapları el ile veya davet bağlantısı ile oluşturabilir ya da Secret URL seçeneğini kullanabilirsiniz. Oradayken, özellikle herkese açık, salt okunur bir kanal istemiyorsanız Allow Anonymous Read ve Allow Anonymous Write seçeneklerini kapatın. Her hesabı el ile oluşturmak zahmetli geliyorsa ve bu, ekibinizin giriş yaptığı tek servis değilse, Rocket.Chat'in OAuth girişini kendi kendine barındırılan bir Authentik SSO sunucusuna yönlendirin; böylece yeni katılanlar ve ayrılanlar uygulama uygulama değil, tek bir merkezden yönetilir.
Yüklemelerin nereye gideceğine de karar verin. Varsayılan File Upload depolama alanı, her görseli ve eki doğrudan MongoDB içinde saklayan GridFS'tir. 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ız bir şekilde büyümesi anlamına gelir. Admin → Settings → File Upload altından depolama alanını yerel dosya sistemine veya S3 uyumlu bir bucket'a geçirebilir ve makul bir maksimum dosya boyutu belirleyebilirsiniz. Ekibiniz ara sıra paylaşılan ekran görüntüleri yerine tüm fotoğraf arşivlerini paylaşıyorsa, bunlar sohbet veritabanı yerine özel bir fotoğraf sunucusunda tutulmalıdır; PhotoPrism ve Immich karşılaştırması yazısı, her birinin RAM maliyetini ve ihtiyaç duyduğu yedekleme komutlarını değerlendirir. 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.gzBu 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.gzArş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 ve Mongo matrisine uyun
Yükseltmeleri sorunsuz hale getiren iki kural vardır. Birincisi, Rocket.Chat'i her seferinde bir ana sürüm yükseltin. Yazılım, açılış sırasında şema migrasyonlarını çalıştırır ve Rocket.Chat yükseltme belgeleri, ana sürümler arasında her zaman sırayla güncelleme yapılmasını önerir; ana sürümleri atlamanın ciddi uyumluluk sorunlarına yol açabileceği konusunda uyarır. Yazılımın sizi durduracağına güvenmeyin: belgelerinde 6.x sürümünden doğrudan 8.x sürümüne geçişin güvenli bir şekilde reddedileceğine dair bir garanti yoktur ve yarıda kalan bir migrasyon, kilitli kalmasına neden olur ve manuel onarım gerektirir. Görüntü etiketini bir sonraki ana sürümün en güncel sürümüne yükseltin, o sürümün notlarını bozucu değişiklikler açısından okuyun, docker compose up -d komutunu çalıştırın ve bir sonrakine geçmeden önce logların migrasyonu tamamladığını izleyin. İ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 hangileri olduğunu söyler. MongoDB'yi ö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 onay bayrağı ile yeniden çalıştırmanızı söyleyen bir mesajla işlemi reddeder:
sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'Her iki bileşenin her yükseltmesinden önce bir mongodump alın. Tüm sigorta poliçeniz budur.
Hata modları ve kesin dizeler
Rocket.Chat, docker compose up sonrasında sürekli yeniden başlatılıyor ve docker compose logs rocketchat bir MongoServerSelectionError ile doluyor. MongoDB çalışıyor ancak sürücü birincil düğümü seçemiyor; hata mesajındaki kesin dize, yapılan hatayı belirtir. ReplicaSetNoPrimary topoloji türüne sahip Server selection timed out after 30000 ms, rs.initiate() komutunu hiç çalıştırmadığınız ve kümenin henüz bir yapılandırmaya sahip olmadığı anlamına gelir. Rastgele bir hash değerini takip eden getaddrinfo ENOTFOUND, kümenin açık host: "mongodb:27017" parametresi olmadan başlatıldığını gösterir; bu durumda MongoDB, çözümlenemeyen bir container ana bilgisayar adını duyurmuştur. 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ş 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 uyuşmazlığından 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ğini ve nginx location bloğunuzun Upgrade ve Connection "upgrade" ayarlarını proxy_http_version 1.1 ile yapılandırdığını doğrulayın. Herhangi bir değişiklik yaparsanız docker compose up -d komutunu tekrar çalıştırın.
Bir container sürekli duruyor ve docker compose ps üzerinde Restarting hatası görünüyor. docker compose logs satır ortasında kesiliyor ve sudo dmesg | tail üzerinde oom-killer kaynaklı Out of memory: Killed process 12345 (mongod) mesajı görünüyor; çıkış kodu 137'dir. Sunucunun RAM kapasitesi dolmuştur. Kalıcı çözüm daha yüksek kapasiteli bir VPS kullanmaktır, minimum 4 GB önerilir. Geçici bir çözüm olarak swap alanı ekleyin ve MongoDB önbelleğini command dosyasında --wiredTigerCacheSizeGB ile sınırlayın. Bu değeri varsayılanın üzerine değil altına ayarlayın; örneğin 4 GB bir sunucuda 1 (varsayılan 1.5) veya 2 GB bir sunucuda 0.3 (varsayılan yaklaşık 0.5) kullanın. Ancak swap kullanımı, gerçek yük altında bir sonraki OOM durumunu sadece geciktirir:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfiledocker compose up komutu Error response from daemon: driver failed programming external connectivity ... bind: address already in use hatası veriyor. 3000 numaralı port halihazırda başka bir süreç tarafından kullanılıyor. Bu genellikle düzgün durdurulamamış eski bir Rocket.Chat container'ı veya başka bir uygulamadır. sudo ss -ltnp | grep :3000 ile süreci bulun, ilgili işlemi veya container'ı durdurun ya da eşleme tarafındaki ana bilgisayar portunu 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 gerektiriyor mu?
Evet, tek bir veritabanı düğümüne sahip tek bir sunucu için bile 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 üzerinde ç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ırıp rs.initiate() ile tek üyeli bir set başlatmanız yeterlidir. Bu adımı atlarsanız sürücü hiçbir zaman bir primary düğüm bulamaz, bu yüzden 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 planlayın. Rocket.Chat'in Node süreci yaklaşık 1 ila 1,5 GB kullanır ve MongoDB'nin varsayılan WiredTiger önbelleği, sunucuda başka hiçbir şey çalışmıyormuş gibi (toplam RAM eksi 1 GB) değerinin yarısı kadar boyutlandırılır. 2 GB'lık bir sunucuda bu önbellek, Node'un heap alanı ve mongod'in kendi ek yükü çakışır; bu durumda 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ı sadece birkaç test kullanıcısıyla değerlendirmek için yeterlidir.
Rocket.Chat'i HTTPS arkasına nasıl alırım?
Aynı VPS üzerinde TLS termination işlemini yapan ve trafiği 127.0.0.1:3000 adresine ileten bir reverse proxy ç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 depolamayı GridFS üzerinde bıraktıysanız yüklenen dosyaları içerir. Arşivi sunucudan dışarı kopyalayın, cron ile her gece otomatikleştirin ve geri yüklemenin 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 migration işlemlerini çalıştırır ve belgeleri, ana sürümleri atlamanın ciddi uyumluluk sorunlarına yol açabileceği konusunda uyarır. 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 adımda bir ana sürüm ilerleyin, ardından confirm: true ile setFeatureCompatibilityVersion ayarını yapın. Her zaman önce bir mongodump alın.