가이드

작성자 Matt Connor 2026-07-15 · 업데이트됨 2026-07-24

Docker Compose로 Rocket.Chat 직접 구축하기

Q: Rocket.Chat에 HTTPS를 어떻게 적용하나요?

동일한 VPS에서 TLS를 종료하고 127.0.0.1:3000로 전달하는 reverse proxy를 실행하십시오. 그리고 컨테이너의 ROOT_URL를 공개 https:// 주소로 설정하십시오. 프록시는 WebSocket upgrade 헤더를 반드시 전달해야 합니다. 그렇지 않으면 로그인이 멈춥니다. nginx와 함께 Certbot을 사용하는 것이 가장 간단한 단일 앱 설정 방식입니다. 하나의 프록시 뒤에서 여러 컨테이너를 실행하고 자동 인증서 관리를 원한다면 Traefik이 더 효율적입니다.

Q: self-hosted Rocket.Chat을 어떻게 백업하나요?

볼륨을 복사하는 대신 mongodump를 사용하여 일관된 데이터베이스 덤프를 생성하십시오: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. 이 아카이브에는 사용자, 채널, 메시지, 설정이 포함됩니다. 저장소를 GridFS로 설정했다면 업로드된 파일도 포함됩니다. 아카이브를 서버 외부로 복사하고 cron을 사용하여 매일 밤 자동으로 실행되도록 설정하십시오. 복구가 실제로 작동하는지 확인하기 위해 테스트용 서버에서 mongorestore를 연습하십시오.

Docker Compose를 이용해 VPS에 Rocket.Chat을 설치하는 방법을 설명합니다. 단일 노드 MongoDB replica set 설정과 TLS 적용, 백업 방법 및 2GB RAM 환경에서 발생하는 OOM 오류 해결법을 상세히 다룹니다.

구축 목표

사용자가 직접 소유하는 프라이빗 팀 채팅 서비스를 구축합니다. Docker Compose를 사용하여 VPS에서 Rocket.Chat을 실행하며, TLS를 적용합니다. 모든 메시지는 백업 및 이동이 가능한 MongoDB 데이터베이스에 저장됩니다. Rocket.Chat은 Slack이나 Teams를 대체할 수 있는 성숙한 오픈 소스 솔루션입니다. 채널, 다이렉트 메시지, 스레드, 파일 공유, 음성 및 영상 통화 기능을 제공하며, 모든 데이터는 사용자가 임대하고 제어하는 하드웨어에서 구동됩니다. 애플리케이션은 단일 컨테이너로 구성되어 몇 분 내에 실행됩니다. 실제 오류가 발생하는 대부분의 지점은 데이터베이스와 관련되어 있습니다. 따라서 이 가이드는 MongoDB에 집중하며, 특히 처음 접하는 사용자가 당황할 수 있는 요구 사항을 다룹니다. Rocket.Chat은 단독(standalone) MongoDB로는 실행되지 않습니다. 단일 노드 구성이라 할지라도 반드시 replica set이 필요합니다.

Prerequisites, and the RAM math nobody tells you

서버 사양을 정할 때 현실적으로 고려하십시오. 소규모 팀을 위한 최소 사양은 2 vCPU 및 4 GB RAM입니다. Rocket.Chat의 Node.js 프로세스는 단독으로 약 1~1.5 GB를 사용하며, MongoDB의 WiredTiger 캐시는 기본적으로 남은 RAM의 약 절반을 점유합니다. 2 GB VPS에서는 부팅 직후에는 두 프로세스가 실행되지만, 실제 트래픽이 발생하면 충돌이 일어납니다. MongoDB는 캐시를 늘리고 Node는 heap을 늘리며, 커널은 페이지 부족 상태에 빠집니다. 이때 out-of-memory killer가 가장 큰 프로세스를 종료하며, 대개 mongod이 대상이 됩니다. 컨테이너는 Killed를 출력하고 Docker는 이를 재시작합니다. 결과적으로 부하를 견뎌야 할 채팅 서버가 몇 분마다 중단됩니다. 2 GB는 두 명 정도의 인원이 테스트하기에는 적합하지만, 팀용 서버로는 부족합니다. 4 GB로 시작하십시오. 수십 명의 동시 접속자, 영상 통화, 또는 증가하는 업로드 기록이 예상된다면 8 GB를 할당하십시오.

시작하기 전에 다음 세 가지 사항이 준비되어야 합니다. VPS의 공인 IP를 가리키는 A record가 설정된 도메인 이름이 필요합니다. Rocket.Chat의 실시간 기능과 모바일 클라이언트는 IP 주소가 아닌 안정적인 hostname을 사용해야 합니다. 서버 방화벽과 제공업체의 네트워크 방화벽(대부분의 제어판에서 별도로 관리됨) 모두에서 80 및 443 포트가 개방되어 있어야 합니다. 마지막으로 root 또는 sudo 권한을 가진 신규 Ubuntu 24.04 KVM VPS가 필요합니다. 채팅 서버를 첫 서비스로 운영할지 고민 중이라면, 2026년에 자체 호스팅할 가치가 있는 서비스 가이드에서 트레이드오프를 확인하십시오.

Docker engine 및 Compose plugin 설치

Ubuntu에서 제공하는 docker.io 패키지나 오래된 standalone docker-compose Python 바이너리를 사용하지 마십시오. Docker 자체 apt repository를 사용해야 합니다. 최신 Compose는 Docker plugin이며, docker compose와 같이 하이픈 대신 공백을 사용하여 실행합니다. 이전 버전인 docker-compose v1은 지원이 종료되었으며, 아래의 healthcheck 및 dependency 구문을 올바르게 처리하지 못합니다.

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

두 구성 요소가 모두 설치되었는지 확인하십시오:

sudo docker version
sudo docker compose version

docker compose version 실행 시 Docker Compose version v2.x와 같은 결과가 출력되어야 합니다. 만약 docker: 'compose' is not a docker command 오류가 발생하면 plugin이 설치되지 않은 것입니다. 이 경우 나중에 복잡한 오류가 발생할 수 있으므로 여기서 문제를 해결하십시오.

The compose file: MongoDB as a single-node replica set

이 부분은 오류가 자주 발생하므로 주의해서 읽으십시오. Rocket.Chat은 연결된 클라이언트에 새 메시지를 실시간으로 전송하기 위해 MongoDB change streams를 사용합니다. change streams는 replica set에서만 사용할 수 있습니다. Rocket.Chat을 일반 standalone mongod로 설정하면, 연결은 되지만 change stream을 열 수 없어 무한 재시작 루프에 빠집니다. 해결 방법은 간단합니다. 일반적인 MongoDB 컨테이너를 실행하되, --replSet 옵션으로 시작한 후 1개의 멤버로 구성된 set을 초기화하면 됩니다.

작업 디렉토리를 생성하고 compose.yml를 만듭니다:

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

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

volumes:
  mongodb_data:
  mongodb_config:

여기에는 의도적인 설정이 포함되어 있습니다. Rocket.Chat 포트는 0.0.0.0이 아니라 127.0.0.1:3000에 게시됩니다. 앱 자체에는 TLS가 없으므로 동일한 호스트의 reverse proxy만 접근해야 합니다. 모든 인터페이스에 바인딩하면 평문 로그인 페이지가 공용 인터넷에 그대로 노출됩니다. MongoDB는 호스트에 전혀 공개되지 않습니다. Compose의 내부 네트워크를 통해서만 mongodb이라는 이름으로 접근할 수 있으며, 이는 MONGO_URL이 사용하는 호스트 이름과 동일합니다. MONGO_URL에는 ?replicaSet=rs0이 포함됩니다. 이 옵션이 없으면 드라이버는 서버가 replica set임에도 불구하고 standalone으로 취급하며, change streams는 여전히 작동하지 않습니다. MONGO_OPLOG_URL은 oplog가 있는 local 데이터베이스를 가리킵니다. 최신 Rocket.Chat은 change streams를 선호하지만, 이 설정을 추가해도 무방하며 이전 코드 경로와의 호환성을 유지합니다. depends_on은 condition: service_healthy를 사용합니다. 따라서 Compose는 MongoDB가 ping에 응답할 때까지 기다린 후 Rocket.Chat을 시작합니다. 이것이 healthcheck의 역할입니다.

두 이미지 모두에 실제 버전 태그를 고정하십시오. 여기서는 mongo:8.0과 8.5.1 같은 명시적인 Rocket.Chat 릴리스를 사용해야 합니다. :latest은 절대 사용하지 마십시오. 이 태그를 사용하면 자동화된 docker pull이 의도치 않은, 마이그레이션 불가능한 업그레이드로 이어집니다. 버전을 고정하기 전에 현재 안정적인 Rocket.Chat 릴리스와 지원되는 MongoDB 버전을 확인하십시오. Rocket.Chat은 릴리스마다 기계 판독이 가능한 정보 문서를 게시합니다. curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}'은 8.5.1에 대해 compatibleMongoVersions: ["8.0"]을 반환하므로, mongo:8.0만이 유일하게 지원되는 엔진입니다. 또한 lts 플래그를 통해 해당 릴리스가 지속적인 관리가 필요 없는 서버를 위한 long-term-support 빌드인지 확인할 수 있습니다.

replica set 초기화

스택을 실행합니다:

sudo docker compose up -d

Rocket.Chat이 즉시 충돌하며 Docker가 이를 계속 재시작할 것입니다. 이는 replica set이 아직 존재하지 않으므로 발생하는 정상적인 현상입니다. 수동으로 한 번 생성하십시오:

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

정상적인 결과는 { ok: 1 }입니다. 몇 초 이내에 단일 노드가 스스로를 primary로 선출합니다. 다음 명령어로 확인하십시오:

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

PRIMARY 결과가 나타나야 합니다. 이 페이지에서 가장 중요한 세부 사항은 host: "mongodb:27017" 인자입니다. 멤버 목록 없이 rs.initiate()를 실행하면, MongoDB는 컨테이너의 내부 호스트 이름인 a1b2c3d4e5f6와 같은 임의의 해시값으로 replica set을 광고합니다. 자신의 컨테이너에서 접속하는 Rocket.Chat은 해당 이름을 해석할 수 없습니다. 따라서 MongoDB 드라이버는 DNS 해석에 실패하며 MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 로그를 남기며 무한 루프에 빠집니다. 항상 MONGO_URL와 일치하는 명시적인 서비스 이름을 사용하여 초기화하십시오.

First boot: watch it come up

Set이 primary가 되면, Rocket.Chat를 재시작합니다. 이 과정에서 연결이 정상적으로 이루어지며 첫 실행을 위한 migrations가 시작됩니다. 다음 로그를 확인하십시오:

sudo docker compose logs -f rocketchat

대기해야 하는 로그 라인은 startup banner입니다:

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

First boot 단계는 시간이 오래 걸립니다. 애플리케이션이 database migrations를 수행하고 indexes를 생성하기 때문입니다. 1~2분 정도 여유를 가지고 기다리십시오. 만약 로그에 topology description이 ReplicaSetNoPrimary인 MongoServerSelectionError: Server selection timed out after 30000 ms이 반복된다면, replica set이 시작되지 않은 것입니다. 만약 무작위 hash와 함께 getaddrinfo ENOTFOUND이 반복된다면, 잘못된 host로 시작된 것입니다. 두 경우 모두 이전 단계로 돌아가십시오. SERVER RUNNING가 나타나면 Rocket.Chat가 127.0.0.1:3000에서 대기 중인 상태입니다. 이제 실제 hostname과 TLS를 설정하십시오.

TLS 적용하기

Rocket.Chat을 일반 HTTP로 노출하지 마십시오. http://를 통해 로그인하면 경로상의 모든 사용자에게 관리자 비밀번호를 전달하게 됩니다. 동일한 서버의 reverse proxy에서 TLS를 종료하고 127.0.0.1:3000로 전달하십시오. 두 가지 사항이 중요합니다. 첫째, Rocket.Chat은 실시간 통신을 사용하므로 proxy가 WebSocket upgrade headers를 전달해야 합니다. 전달하지 않으면 기능이 작동하지 않습니다. 둘째, container의 ROOT_URL는 사용자가 입력하는 공용 HTTPS 주소와 정확히 일치해야 합니다.

앱으로 프록시를 수행하고 upgrade headers를 전달하는 일반 HTTP nginx server block으로 시작하십시오. 파일을 /etc/nginx/sites-available/rocketchat로 저장하고 sites-enabled에 symlink를 생성한 뒤 다음을 실행하십시오:

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;가 포함되지 않은 block은 sudo nginx -t를 통과할 수 없습니다. nginx를 재로드(sudo nginx -t && sudo systemctl reload nginx)한 다음 인증서를 발급하십시오. Ubuntu에서 가장 권장되는 방법은 Certbot과 nginx를 이용한 Let's Encrypt TLS 인증서 설치입니다. certbot --nginx를 실행하면 위 block을 직접 수정하여 listen 443 ssl;, ssl_certificate 라인, 그리고 80에서 443으로의 자동 리다이렉트를 추가하며 갱신 일정을 자동으로 설정합니다. 하나의 proxy 뒤에 여러 container를 운영 중이라면 여러 Docker 앱을 위한 Traefik 자동 TLS가 더 효율적인 옵션입니다. rocketchat 서비스에 router 및 service label을 추가하면 Traefik이 nginx block 없이도 인증서를 요청하고 갱신합니다. 어떤 방식을 선택하든 compose.yml의 ROOT_URL를 https://chat.example.com로 설정한 후 sudo docker compose up -d를 다시 실행하여 container가 변경 사항을 반영하도록 하십시오. 서버를 공용 인터넷이 아닌 내부 네트워크에서만 접속 가능하게 하려면 VPS에 self-hosted WireGuard VPN 구축하기를 사용하여 proxy를 tunnel 주소에 바인딩하십시오.

첫 실행 설정 마법사

https://chat.example.com로 이동하면 Rocket.Chat의 짧은 설정 마법사가 시작됩니다. 먼저 admin account를 설정해야 합니다. 실명, username, email, 그리고 강력한 password를 입력하십시오. 이 계정이 유일한 관리자 계정이므로 정보를 분실하지 않도록 주의하십시오. 다음은 organisation and server info 설정 단계입니다. name, industry, size, site name, default language를 입력하십시오. 이는 외관 설정이므로 입력 후 다음 단계로 진행하면 됩니다. 마지막으로 중요한 선택 단계가 있습니다. Rocket.Chat Cloud에 register this workspace를 하거나, standalone 상태를 유지하는 것입니다.

Registration을 하면 Rocket.Chat의 gateway를 통해 모바일 push notification과 add-on marketplace를 사용할 수 있습니다. 대신 Rocket.Chat cloud와 control-plane 관계가 형성됩니다. Standalone 방식은 서버를 완전히 프라이빗하게 유지하고 의존성을 없애지만, iOS 및 Android push notification 기능이 중단됩니다. Apple과 Google은 자체 제작된 앱이 push certificate를 보유하는 것을 허용하지 않기 때문입니다. 공식 앱은 cloud gateway를 통해 통신합니다. 프라이버시가 가장 중요하고 사용자가 웹 앱을 주로 사용한다면 standalone을 선택하십시오. 모바일 push 기능이 필수적이라면 registration을 선택하십시오. 설정은 나중에 Admin 메뉴에서 변경할 수 있습니다.

사용자를 초대하기 전에 보안을 설정하십시오

Rocket.Chat은 기본적으로 open registration on 상태로 배포됩니다. 즉, Registration Form이 Public로 설정되어 있어 URL을 아는 누구나 계정을 생성할 수 있습니다. 공개 호스트네임에서는 보안에 취약합니다. Admin → Settings → Accounts → Registration으로 이동하여 Registration Form을 수동 계정 생성 또는 초대 링크 방식인 Disabled 또는 Secret URL로 설정하십시오. 또한, 공개 읽기 전용 채널이 필요한 경우가 아니라면 Allow Anonymous Read와 Allow Anonymous Write를 비활성화하십시오.

파일 업로드 저장 위치도 결정해야 합니다. 기본 File Upload 저장소는 GridFS이며, 모든 이미지와 첨부 파일을 MongoDB 내부에 저장합니다. 이 방식은 간단하지만, 사용자가 스크린샷을 계속 붙여넣으면 데이터베이스와 모든 mongodump의 크기가 무한히 커집니다. Admin → Settings → File Upload에서 저장소를 local filesystem 또는 S3-compatible bucket으로 변경할 수 있으며, 적절한 최대 파일 크기를 설정할 수 있습니다. 소규모 팀에게는 GridFS가 적합하지만, 시간이 지날수록 백업 파일의 크기가 커진다는 점을 유의하십시오.

mongodump을 이용한 백업

모든 데이터는 mongodb_data 볼륨에 저장됩니다. 데이터베이스가 실행 중인 상태에서 볼륨을 단순히 복사하지 마십시오. mongodump을 사용하여 호스트의 파일로 스트리밍된 일관된 덤프를 생성해야 합니다.

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

생성된 gzipped 아카이브 하나에 전체 작업 공간이 포함됩니다. 사용자, 채널, 메시지, 설정이 포함되며, GridFS에 업로드 파일을 남겨두었다면 파일도 포함됩니다. 업로드 파일을 filesystem 또는 S3로 이동했다면 해당 저장소를 별도로 백업하십시오. 새로운 스택에 복원하려면 먼저 replica set을 초기화한 다음 다음을 수행하십시오.

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

아카이브를 서버 외부로 복사하십시오. object storage, 다른 서버 등 VPS가 손상되어도 백업이 함께 유실되지 않는 곳이어야 합니다. 그리고 cron을 통해 매일 밤 덤프를 실행하십시오. 복원해 본 적 없는 백업은 백업이 아니라 희망 사항일 뿐입니다. 실제 상황이 닥치기 전에 테스트용 VPS에서 복원 연습을 수행하여 정상 작동 여부를 확인하십시오.

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

업그레이드 과정을 안정적으로 유지하기 위한 두 가지 규칙이 있습니다. 첫째, Rocket.Chat를 한 번에 하나의 메이저 버전씩만 업그레이드하십시오. Rocket.Chat은 부팅 시 schema migration을 실행하며, 메이저 버전 간의 직접적인 점프를 허용하지 않습니다. 예를 들어 6.x에서 8.x로 바로 업그레이드하려고 하면 데이터 손상을 방지하기 위해 migration error를 발생시키며 중단됩니다. 이미지 tag를 다음 메이저 버전의 최신 release로 변경하고, 해당 release notes에서 breaking changes를 확인하십시오. 그 다음 docker compose up -d를 실행하고, 로그에서 migration이 완료된 것을 확인한 후 다음 단계로 진행하십시오. 둘째, MongoDB support matrix를 준수하십시오. 각 Rocket.Chat release는 특정 MongoDB 버전들을 지원하며, curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions에서 이를 확인할 수 있습니다. MongoDB를 7.0에서 8.0으로 업그레이드하는 경우, 한 번에 하나의 메이저 버전씩 단계적으로 진행하고 각 단계마다 feature-compatibility version을 설정하십시오. MongoDB 8.0에서는 해당 명령에 명시적인 confirm: true이 필요합니다. 그렇지 않으면 확인 flag를 사용하여 다시 실행하라는 메시지와 함께 실행이 거부됩니다.

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

두 구성 요소 모두 업그레이드하기 전에 반드시 mongodump를 수행하십시오. 이것이 유일한 보험입니다.

Failure modes, with the exact strings

docker compose up 직후에 Rocket.Chat이 재시작 루프에 빠지며, docker compose logs rocketchat가 MongoServerSelectionError로 가득 찹니다. MongoDB는 실행 중이지만 드라이버가 primary를 선택할 수 없는 상태입니다. 정확한 문자열을 통해 오류 원인을 확인할 수 있습니다. topology type이 ReplicaSetNoPrimary인 Server selection timed out after 30000 ms은 rs.initiate()을 실행하지 않았음을 의미합니다. 즉, set에 설정이 아직 없습니다. getaddrinfo ENOTFOUND 뒤에 임의의 hash가 나타나면 host: "mongodb:27017" 없이 초기화를 시작한 것입니다. 이 경우 MongoDB가 해결할 수 없는 container hostname을 광고합니다. sudo docker compose exec mongodb mongosh --eval 'rs.status()'으로 진단하십시오. MongoServerError: no replset config has been received 오류가 발생하면 set을 초기화하십시오. name이 임의의 hash인 멤버가 표시되면 service name을 사용하여 재초기화하십시오.

Web UI는 로드되지만 로그인을 시도하면 무한 로딩이 발생하며 완료되지 않습니다. 브라우저 콘솔을 열면 WebSocket connection to 'wss://chat.example.com/websocket' failed가 표시됩니다. 이는 대부분 ROOT_URL 불일치 또는 proxy가 upgrade headers를 전달하지 않기 때문에 발생합니다. ROOT_URL이 https://을 포함한 정확한 public address와 일치하는지 확인하십시오. 또한 nginx location block에서 Upgrade와 Connection "upgrade"을 proxy_http_version 1.1으로 설정했는지 확인하십시오. 설정을 변경한 후 docker compose up -d를 다시 실행하십시오.

Container가 계속 종료되며 docker compose ps에 Restarting이 표시됩니다. docker compose logs이 중간에 끊기고 sudo dmesg | tail에 oom-killer로 인한 Out of memory: Killed process 12345 (mongod)이 표시됩니다. exit code는 137입니다. 시스템의 RAM이 부족한 상태입니다. 근본적인 해결책은 더 큰 VPS를 사용하는 것입니다. 최소 4 GB가 필요합니다. 임시 방편으로 swap을 추가하고 command 내의 --wiredTigerCacheSizeGB 1으로 MongoDB의 cache를 제한하십시오. 하지만 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 container이거나 다른 앱입니다. sudo ss -ltnp | grep :3000로 해당 프로세스를 찾은 뒤, 해당 process 또는 container를 중지하십시오. 또는 host 측 매핑을 127.0.0.1:3001:3000으로 변경하고 proxy의 proxy_pass를 이에 맞춰 업데이트하십시오.

FAQ

Rocket.Chat에 MongoDB replica set이 반드시 필요한가요?

네, 데이터베이스 노드가 하나인 단일 서버에서도 필요합니다. Rocket.Chat은 MongoDB change streams를 사용하여 메시지를 실시간으로 전달합니다. change streams는 replica-set 전용 기능이며, standalone mongod는 이 기능을 사용할 수 없습니다. 여러 대의 머신이 필요한 것은 아닙니다. --replSet rs0로 시작된 하나의 MongoDB 컨테이너를 실행하고 rs.initiate()를 사용하여 1-member set을 초기화하면 됩니다. 이 단계를 건너뛰면 드라이버가 primary를 찾지 못합니다. 이 경우 Rocket.Chat은 MongoServerSelectionError: Server selection timed out 오류와 함께 재시작 루프에 빠지며 부팅이 완료되지 않습니다.

self-hosted Rocket.Chat에 필요한 RAM 용량은 얼마인가요?

실질적인 최소 사양은 4 GB, 사용자가 많은 팀은 8 GB를 권장합니다. Rocket.Chat의 Node 프로세스는 약 1~1.5 GB를 사용합니다. MongoDB는 남은 RAM의 약 절반을 WiredTiger cache 용도로 점유합니다. 따라서 2 GB 사양의 서버에서는 두 프로세스가 충돌합니다. 실제 부하가 발생하면 out-of-memory killer가 mongod를 종료시키며, 로그에는 Killed이 기록되고 종료 코드는 137이 발생합니다. 2 GB는 테스트용 사용자 몇 명을 대상으로 소프트웨어를 평가하는 용도로만 충분합니다.

Rocket.Chat에 HTTPS를 어떻게 적용하나요?

동일한 VPS에서 TLS를 종료하고 127.0.0.1:3000로 전달하는 reverse proxy를 실행하십시오. 그리고 컨테이너의 ROOT_URL를 공개 https:// 주소로 설정하십시오. 프록시는 WebSocket upgrade 헤더를 반드시 전달해야 합니다. 그렇지 않으면 로그인이 멈춥니다. nginx와 함께 Certbot을 사용하는 것이 가장 간단한 단일 앱 설정 방식입니다. 하나의 프록시 뒤에서 여러 컨테이너를 실행하고 자동 인증서 관리를 원한다면 Traefik이 더 효율적입니다.

self-hosted Rocket.Chat을 어떻게 백업하나요?

볼륨을 복사하는 대신 mongodump를 사용하여 일관된 데이터베이스 덤프를 생성하십시오: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. 이 아카이브에는 사용자, 채널, 메시지, 설정이 포함됩니다. 저장소를 GridFS로 설정했다면 업로드된 파일도 포함됩니다. 아카이브를 서버 외부로 복사하고 cron을 사용하여 매일 밤 자동으로 실행되도록 설정하십시오. 복구가 실제로 작동하는지 확인하기 위해 테스트용 서버에서 mongorestore를 연습하십시오.

MongoDB를 손상시키지 않고 Rocket.Chat을 업그레이드하는 방법은 무엇인가요?

Rocket.Chat은 한 번에 하나의 major 버전씩 업그레이드하십시오. Rocket.Chat은 부팅 시 마이그레이션을 실행하며 major 버전을 건너뛰는 것을 허용하지 않습니다. 핀(pinned)된 image tag를 변경하기 전에 각 릴리스의 노트를 읽으십시오. curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions를 사용하여 대상 릴리스가 지원하는 MongoDB 버전을 확인하십시오. MongoDB를 업그레이드할 때는 한 번에 하나의 major 버전씩 이동해야 하며, 각 단계마다 confirm: true를 사용하여 setFeatureCompatibilityVersion를 설정하십시오. 작업을 수행하기 전에 항상 mongodump를 수행하십시오.

#rocket-chat#docker #docker-compose#mongodb#self-hosting #tls