Rocket.Chat на Ubuntu 24.04: пошаговая установка

MAATRIX

Если команда переросла Telegram-чаты и хочет собственный мессенджер без утечки переписки на чужие серверы, Rocket.Chat — один из немногих self-hosted вариантов, где из коробки есть видеозвонки, интеграции с внешними сервисами и приличный мобильный клиент. В отличие от Mattermost, у Rocket.Chat более гибкая система каналов и встроенный Jitsi для звонков, но и требований к серверу чуть больше. Ниже — рабочая установка на Ubuntu 24.04 через Docker Compose, с MongoDB, обратным прокси и HTTPS, без пропущенных шагов.

Что понадобится и почему именно Docker Compose

Rocket.Chat можно ставить через официальный snap-пакет или собирать вручную из исходников на Node.js, но оба пути на практике доставляют больше хлопот, чем экономят времени. Snap тянет за собой отдельную версию MongoDB, которую неудобно бэкапить и обновлять отдельно от остальной инфраструктуры. Ручная сборка требует конкретных версий Node.js, которые со временем расходятся с тем, что ждёт актуальный Rocket.Chat, и это постоянный источник поломок при апдейтах.

Docker Compose снимает эту головную боль: и приложение, и база данных — версионируемые образы, апгрейд — это смена тега в файле и docker compose up -d, откат — обратная операция. Плюс всё описано в одном файле, который удобно хранить в git и переносить на другой сервер.

Что понадобится по железу:

MongoDB под нагрузкой любит RAM для кеша страниц — на 2 ГБ сервер будет работать, но с заметными подтормаживаниями при активной команде из 30+ человек. Если предполагаете рост, лучше сразу смотреть на конфигурацию с 4 ГБ и выше.

Подготовка сервера и установка Docker

Подключаемся по SSH к свежей Ubuntu 24.04 и обновляем систему:

apt update && apt upgrade -y
apt install -y ca-certificates curl gnupg

Ставим Docker Engine и плагин Compose из официального репозитория Docker — версия из репозитория Ubuntu заметно старее:

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
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" | \
  tee /etc/apt/sources.list.d/docker.list > /dev/null

apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Проверяем, что всё встало:

docker --version
docker compose version

Заодно закройте лишние порты в файрволе — снаружи должны смотреть только SSH и 80/443, остальное (Rocket.Chat, MongoDB) останется во внутренней docker-сети. Если ещё не настраивали защиту, у нас есть отдельный разбор настройки UFW на Ubuntu 24.04 — стоит сделать это до того, как сервис откроется в интернет.

Структура проекта и docker-compose.yml

Создаём рабочую директорию и файл для переменных:

mkdir -p /opt/rocketchat && cd /opt/rocketchat

Файл docker-compose.yml:

services:
  rocketchat:
    image: registry.rocket.chat/rocketchat/rocket.chat:6.13.0
    restart: unless-stopped
    volumes:
      - ./uploads:/app/uploads
    environment:
      - MONGO_URL=mongodb://mongo:27017/rocketchat?replicaSet=rs0
      - MONGO_OPLOG_URL=mongodb://mongo:27017/local?replicaSet=rs0
      - ROOT_URL=https://chat.example.com
      - PORT=3000
      - DEPLOY_METHOD=docker
    depends_on:
      - mongo
    expose:
      - "3000"

  mongo:
    image: mongo:6.0
    restart: unless-stopped
    volumes:
      - ./data/db:/data/db
    command: mongod --oplogSize 128 --replSet rs0
    expose:
      - "27017"

  mongo-init-replica:
    image: mongo:6.0
    restart: "no"
    depends_on:
      - mongo
    command: >
      bash -c "sleep 5 && mongosh mongo/rocketchat --eval \"
      rs.initiate({
        _id: 'rs0',
        members: [ { _id: 0, host: 'mongo:27017' } ]
      })\""

Важный нюанс, о который спотыкаются почти все: Rocket.Chat требует MongoDB в режиме replica set, даже если реплика одна-единственная — это нужно для oplog-механизма realtime-обновлений (сообщения появляются в чате без перезагрузки страницы). Сервис mongo-init-replica запускает инициализацию один раз и завершается — это нормально, при docker compose ps он будет в статусе Exited(0), и это не ошибка.

Замените chat.example.com в ROOT_URL на свой домен — это критично: Rocket.Chat сверяет заголовки запросов с этим значением, и если оно не совпадает с реальным адресом, вы получите редиректы в никуда или ошибки WebSocket-соединения при попытке открыть чат.

Поднимаем стек:

docker compose up -d
docker compose logs -f rocketchat

Первый старт занимает 1-3 минуты — Rocket.Chat инициализирует базу и накатывает миграции. Ждите строку SERVER RUNNING в логах, после этого сервис доступен на 127.0.0.1:3000 изнутри сервера.

Обратный прокси Nginx и HTTPS

Rocket.Chat активно использует WebSocket для realtime-обмена сообщениями, поэтому конфиг Nginx должен явно прокидывать заголовки Upgrade/Connection — без этого чат будет работать в режиме постоянных перезагрузок вместо живого обновления.

Ставим Nginx и Certbot:

apt install -y nginx certbot python3-certbot-nginx

Конфиг /etc/nginx/sites-available/rocketchat:

server {
    listen 80;
    server_name chat.example.com;

    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-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

Активируем и получаем сертификат:

ln -s /etc/nginx/sites-available/rocketchat /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

certbot --nginx -d chat.example.com

Certbot сам допишет блок listen 443 ssl и настроит редирект с 80 на 443. Если вы уже используете этот сервер под несколько сайтов и хотите разобраться, чем certbot отличается от альтернатив, у нас есть сравнение certbot и acme.sh. Общий принцип настройки Nginx как reverse-proxy для других сервисов на сервере расписан подробнее в статье про Nginx как обратный прокси на VPS — пригодится, если планируете разместить рядом ещё какие-то приложения.

Таймауты proxy_read_timeout/proxy_send_timeout увеличены до 300 секунд не случайно — долгоживущее WebSocket-соединение иначе будет рваться дефолтными 60 секундами Nginx, и пользователи будут видеть периодические разрывы связи в интерфейсе.

Первый запуск и настройка администратора

Открываем https://chat.example.com в браузере. Rocket.Chat покажет мастер первоначальной настройки:

1. Регистрация учётной записи администратора (email, логин, пароль).
2. Информация об организации — название рабочего пространства, часовой пояс, размер команды. Эти данные ни на что критично не влияют, их всегда можно поменять в админке.
3. Предложение подключить облачную учётную запись Rocket.Chat Cloud (для push-уведомлений на мобильные и маркетплейса приложений). Это опционально — если хотите полностью автономную установку без внешних зависимостей, можно пропустить, но тогда push-уведомления на смартфоны работать не будут, только в браузере и на десктопе.

После мастера попадаете в админ-панель (Administration → Workspace). Первым делом стоит зайти в Administration → General и проверить:

• Site URL — должен совпадать с ROOT_URL из docker-compose.yml.
• Language — интерфейс можно переключить на русский по умолчанию для всех новых пользователей в Administration → Accounts → Default User Preferences.

Создать первый канал можно прямо из главного экрана — кнопка + рядом с поиском, или через админку для служебных каналов вроде #general, который создаётся автоматически.

Видеозвонки, файлы и почтовые уведомления

Видеозвонки в Rocket.Chat работают через встроенный Jitsi-модуль по умолчанию — отдельно ничего разворачивать не нужно, достаточно включить их в Administration → Video Conference. Для self-hosted инсталляций рекомендуется указать собственный Jitsi-сервер, если ожидается много одновременных звонков — публичный meet.jit.si у Rocket.Chat используется по умолчанию и может быть нестабилен под нагрузкой извне.

Загрузка файлов по умолчанию хранится на файловой системе — том ./uploads, который мы примонтировали в docker-compose.yml. Для продакшн-инсталляции с большим объёмом вложений разумнее переключить хранилище на S3-совместимый объектный бакет (Administration → File Upload → Storage Type → AmazonS3), чтобы не упереться в диск сервера и упростить бэкапы — файлы тогда живут отдельно от сервера приложения.

Почтовые уведомления и восстановление пароля требуют настроенного SMTP — без него новые пользователи не смогут завершить регистрацию по email-приглашению. Указывается в Administration → Email → SMTP:

Host: smtp.example.com
Port: 587
Username: notifications@example.com
Password: ваш пароль
Use SSL: включено (для порта 587 — STARTTLS)

Если своего почтового сервера нет, подойдёт любой транзакционный SMTP-провайдер — для внутреннего корпоративного мессенджера хватит минимального тарифа, трафик на уведомления обычно небольшой.

Бэкапы и обновление

Так как всё состояние живёт в MongoDB и на файловой системе (./data/db и ./uploads), бэкап сводится к копированию этих двух директорий плюс дампу базы штатными средствами Mongo:

docker compose exec mongo mongodump --archive=/data/db/backup-$(date +%F).gz --gzip --db rocketchat

Для регулярного автоматического бэкапа удобнее вынести это в отдельный cron-скрипт и копировать архивы за пределы сервера — на объектное хранилище или другой сервер. Если у вас уже есть отлаженный процесс резервного копирования на сервере, логику можно переиспользовать — общие принципы разобраны в материале про бэкапы через BorgBackup, это применимо и к директориям Rocket.Chat.

Обновление — смена тега образа и пересоздание контейнера:

# в docker-compose.yml меняем тег на нужную версию, например 6.14.0
docker compose pull rocketchat
docker compose up -d rocketchat
docker compose logs -f rocketchat

Перед крупным обновлением (смена мажорной версии) всегда смотрите changelog на официальном GitHub Rocket.Chat — иногда там требуются дополнительные шаги миграции базы, и всегда снимайте свежий дамп MongoDB перед апдейтом, чтобы был путь отката.

Частые вопросы