Как установить и настроить MongoDB на VPS (полное руководство)

MongoDB — это документно-ориентированная NoSQL база данных, которая хранит записи в виде BSON (Binary JSON) документов, обеспечивая схемонезависимое моделирование данных с горизонтальной масштабируемостью через нативное шардирование. В отличие от реляционных баз данных, MongoDB не требует заранее определённой схемы таблиц, что делает её доминирующим выбором для приложений с развивающимися структурами данных, высокой пропускной способностью записи или иерархическими связями данных.

Это руководство описывает производственное развёртывание MongoDB на Linux VPS — включая установку из официального репозитория, усиление аутентификации, контроль сетевого доступа, настройку TLS, оптимизацию производительности и автоматизацию резервного копирования. Каждый шаг предполагает, что вы работаете в реальной серверной среде, где безопасность и надёжность не подлежат обсуждению.

Предварительные требования

Перед началом убедитесь в следующем:

• VPS под управлением Ubuntu 20.04 LTS или Ubuntu 22.04 LTS (команды идентичны для обеих версий)
• Доступ с правами root или sudo через SSH
• Минимум 2 GB RAM (рекомендуется 4 GB для производственных нагрузок)
• Не менее 20 GB свободного дискового пространства на быстром томе хранилища
• UFW или iptables для управления брандмауэром
• Базовые знания командной строки Linux

> Примечание об архитектуре: Движок хранилища WiredTiger в MongoDB использует внутренний кэш по умолчанию размером 50% от (RAM – 1 GB). На VPS с 2 GB это даёт примерно 512 MB кэша. Для нагрузок с интенсивным чтением выделите не менее 4 GB RAM, чтобы избежать постоянных дисковых операций ввода-вывода из-за нехватки кэша.

MongoDB против других NoSQL баз данных: краткое сравнение

Шаг 1: Обновление системы

Всегда начинайте с полностью обновлённой системы. Устаревшие пакеты содержат известные CVE, которые могут быть использованы ещё до установки вашего стека приложений.

sudo apt update && sudo apt upgrade -y

После применения обновлений ядра или libc перезагрузитесь для активации нового ядра:

sudo reboot

Повторно подключитесь через SSH после того, как сервер снова станет доступен (обычно через 30–60 секунд).

Шаг 2: Установка MongoDB из официального репозитория

Репозитории apt по умолчанию в Ubuntu содержат устаревшую версию MongoDB, переупакованную сообществом, в которой отсутствуют последние патчи безопасности и улучшения движка. Всегда устанавливайте из официального репозитория MongoDB.

Добавление GPG-ключа и репозитория MongoDB

Команда apt-key устарела в Ubuntu 22.04. Используйте рекомендуемый метод keyring, который работает как на 20.04, так и на 22.04:

curl -fsSL https://www.mongodb.org/static/pgp/server-7.0.asc | 
  sudo gpg --dearmor -o /usr/share/keyrings/mongodb-server-7.0.gpg

Добавьте запись официального репозитория:

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] 
  https://repo.mongodb.org/apt/ubuntu $(lsb_release -cs)/mongodb-org/7.0 multiverse" | 
  sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list

> Примечание о версии: Замените 7.0 на нужный релиз (например, 6.0), если вам требуется конкретная версия для совместимости с приложением. MongoDB 7.0 является текущим релизом с долгосрочной поддержкой по состоянию на 2024 год.

Установка пакетов MongoDB

sudo apt update
sudo apt install -y mongodb-org

Устанавливаются следующие компоненты:

mongod — основной демон базы данных
mongos — маршрутизатор шардирования (используется в развёртываниях с шардированным кластером)
mongosh — современная оболочка MongoDB Shell (заменяет устаревший бинарный файл mongo)
mongodb-database-tools — включает mongodump, mongorestore, mongoexport и mongoimport

Фиксация установленной версии

Предотвратите непреднамеренные обновления, которые могут нарушить совместимость приложений:

echo "mongodb-org hold" | sudo dpkg --set-selections
echo "mongodb-org-database hold" | sudo dpkg --set-selections
echo "mongodb-org-server hold" | sudo dpkg --set-selections
echo "mongosh hold" | sudo dpkg --set-selections
echo "mongodb-org-mongos hold" | sudo dpkg --set-selections
echo "mongodb-org-tools hold" | sudo dpkg --set-selections

Шаг 3: Настройка системных предварительных требований

MongoDB работает наилучшим образом, когда определённые параметры ядра и файловой системы настроены до запуска демона.

Установка ulimit для открытых файлов

MongoDB требует высокого лимита файловых дескрипторов. Создайте переопределение systemd:

sudo mkdir -p /etc/systemd/system/mongod.service.d
sudo tee /etc/systemd/system/mongod.service.d/limits.conf > /dev/null <<EOF
[Service]
LimitFNOFILE=64000
LimitNPROC=64000
EOF

Отключение Transparent Huge Pages (THP)

THP вызывает значительные скачки задержки в MongoDB. Отключите его постоянно:

sudo tee /etc/systemd/system/disable-thp.service > /dev/null <<EOF
[Unit]
Description=Disable Transparent Huge Pages (THP)
DefaultDependencies=no
After=sysinit.target local-fs.target
Before=mongod.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never | tee /sys/kernel/mm/transparent_hugepage/enabled > /dev/null'
ExecStart=/bin/sh -c 'echo never | tee /sys/kernel/mm/transparent_hugepage/defrag > /dev/null'

[Install]
WantedBy=basic.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now disable-thp

Проверьте, что настройка вступила в силу:

cat /sys/kernel/mm/transparent_hugepage/enabled

В выводе должно отображаться [never] как активное значение.

Шаг 4: Запуск и включение MongoDB

sudo systemctl daemon-reload
sudo systemctl start mongod
sudo systemctl enable mongod

Убедитесь, что демон запущен:

sudo systemctl status mongod

Найдите Active: active (running) в выводе. Если служба не запускается, немедленно проверьте журнал:

sudo tail -50 /var/log/mongodb/mongod.log

Распространённые причины сбоев при запуске:

• Порт 27017 уже занят — другой процесс привязан к порту; определите его с помощью sudo ss -tlnp | grep 27017
• Права доступа к каталогу данных — пользователь mongod должен владеть /var/lib/mongodb; исправьте с помощью sudo chown -R mongodb:mongodb /var/lib/mongodb
• THP всё ещё включён — движок WiredTiger записывает предупреждение и может снизить производительность

Шаг 5: Защита MongoDB — аутентификация и авторизация

Это наиболее критичный раздел. Незащищённые экземпляры MongoDB, доступные из интернета, стали причиной тысяч утечек данных. Установка по умолчанию не имеет аутентификации, то есть любой, кто может достичь порта 27017, имеет полный доступ на чтение/запись ко всем базам данных.

Создание административного пользователя

Подключитесь к локальной оболочке MongoDB (аутентификация не требуется до её включения):

mongosh

В оболочке переключитесь на базу данных admin и создайте суперпользователя:

use admin

db.createUser({
  user: "adminuser",
  pwd: passwordPrompt(),
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" },
    { role: "dbAdminAnyDatabase", db: "admin" },
    { role: "clusterAdmin", db: "admin" }
  ]
})

Использование passwordPrompt() вместо строки с открытым текстом предотвращает появление пароля в истории оболочки. Введите пароль при появлении запроса, затем выйдите:

exit

Включение аутентификации в mongod.conf

Откройте файл конфигурации MongoDB:

sudo nano /etc/mongod.conf

Найдите раздел security (он будет закомментирован) и включите авторизацию:

security:
  authorization: enabled

Сохраните и выйдите (Ctrl+X, затем Y, затем Enter), после чего перезапустите демон:

sudo systemctl restart mongod

Проверка применения аутентификации

Попробуйте подключиться без аутентификации — теперь это должно завершиться ошибкой:

mongosh --eval "db.adminCommand({ listDatabases: 1 })"

Вы должны получить ошибку Unauthorized. Теперь выполните правильную аутентификацию:

mongosh -u adminuser -p --authenticationDatabase admin

Создание пользователей с ограниченным доступом для приложений

Никогда не используйте суперпользователя admin для подключений приложений. Создайте пользователя с минимальными привилегиями для каждой базы данных приложения:

use myappdb

db.createUser({
  user: "appuser",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "myappdb" }
  ]
})

Шаг 6: Настройка привязки сети и правил брандмауэра

Ограничение или расширение bindIp

По умолчанию mongod.conf привязывается только к 127.0.0.1. Это правильная настройка, если ваше приложение работает на том же VPS. Если вам нужен удалённый доступ (например, с сервера приложений на отдельном хосте), отредактируйте /etc/mongod.conf:

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.5

Замените 10.0.0.5 на конкретный приватный IP вашего сервера приложений. Никогда не устанавливайте bindIp: 0.0.0.0 на публичном интерфейсе без правила брандмауэра, ограничивающего доступ известными IP-адресами. Привязка ко всем интерфейсам без брандмауэра является основной причиной инцидентов с утечкой данных MongoDB.

Перезапустите после изменений:

sudo systemctl restart mongod

Настройка правил брандмауэра UFW

Если требуется удалённый доступ, разрешите его только с конкретного доверенного IP:

sudo ufw allow from 10.0.0.5 to any port 27017 proto tcp
sudo ufw enable
sudo ufw status verbose

Заблокируйте весь остальной внешний доступ к порту 27017:

sudo ufw deny 27017

UFW обрабатывает правила по порядку — конкретное правило allow from выше широкого правила deny имеет приоритет для доверенного IP.

Шаг 7: Включение TLS/SSL для зашифрованных соединений

Для любого развёртывания, где трафик MongoDB пересекает сеть — даже частную LAN — шифрование TLS обязательно. Без него учётные данные и данные передаются в открытом виде.

Создайте самоподписанный сертификат для тестирования (используйте сертификат, подписанный CA, в производственной среде — рассмотрите возможность использования SSL-сертификата для вашего домена):

sudo mkdir -p /etc/mongodb/ssl
sudo openssl req -newkey rsa:4096 -nodes -keyout /etc/mongodb/ssl/mongodb.key 
  -x509 -days 365 -out /etc/mongodb/ssl/mongodb.crt 
  -subj "/CN=your-vps-hostname"
sudo cat /etc/mongodb/ssl/mongodb.crt /etc/mongodb/ssl/mongodb.key | 
  sudo tee /etc/mongodb/ssl/mongodb.pem > /dev/null
sudo chown -R mongodb:mongodb /etc/mongodb/ssl
sudo chmod 600 /etc/mongodb/ssl/mongodb.pem

Добавьте конфигурацию TLS в /etc/mongod.conf:

net:
  port: 27017
  bindIp: 127.0.0.1
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongodb/ssl/mongodb.pem

Перезапустите MongoDB и подключитесь с TLS:

sudo systemctl restart mongod
mongosh --tls --tlsCertificateKeyFile /etc/mongodb/ssl/mongodb.pem 
  --tlsAllowInvalidCertificates -u adminuser -p --authenticationDatabase admin

Флаг --tlsAllowInvalidCertificates допустим только для самоподписанных сертификатов в среде разработки. Удалите его при использовании сертификата, подписанного CA.

Шаг 8: Оптимизация производительности в mongod.conf

Для производственного развёртывания на VPS с выделенными ресурсами настройте кэш WiredTiger и параметры журналирования. Откройте /etc/mongod.conf и добавьте или измените следующее:

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
      cacheSizeGB: 1.5

operationProfiling:
  slowOpThresholdMs: 100
  mode: slowOp

replication:
  oplogSizeMB: 1024

Объяснение ключевых параметров настройки:

• cacheSizeGB — Установите примерно 50% доступной RAM минус 1 GB. На VPS с 4 GB используйте 1.5. На VPS с 8 GB используйте 3.5.
• slowOpThresholdMs — Запросы, превышающие этот порог (в миллисекундах), записываются в профилировщик. Снижение этого значения помогает выявлять неиндексированные запросы на ранних этапах.
• oplogSizeMB — Актуально, если вы планируете добавить членов набора реплик позже. Предварительное задание размера oplog позволяет избежать задержки репликации при высоких нагрузках на запись.

Примените изменения:

sudo systemctl restart mongod

Шаг 9: Резервное копирование и восстановление с помощью mongodump

Ручное резервное копирование

mongodump 
  --uri="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin" 
  --out /var/backups/mongodb/$(date +%Y-%m-%d)

Ручное восстановление

mongorestore 
  --uri="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin" 
  /var/backups/mongodb/2024-06-15

Автоматизация резервного копирования с помощью Cron

Создайте специальный скрипт резервного копирования:

sudo tee /usr/local/bin/mongodb-backup.sh > /dev/null <<'EOF'
#!/bin/bash
BACKUP_DIR="/var/backups/mongodb"
TIMESTAMP=$(date +%Y-%m-%d_%H-%M-%S)
MONGO_URI="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin"
RETENTION_DAYS=7

mkdir -p "${BACKUP_DIR}/${TIMESTAMP}"
mongodump --uri="${MONGO_URI}" --out="${BACKUP_DIR}/${TIMESTAMP}"
find "${BACKUP_DIR}" -maxdepth 1 -type d -mtime +${RETENTION_DAYS} -exec rm -rf {} ;
EOF

sudo chmod +x /usr/local/bin/mongodb-backup.sh

Запланируйте его запуск ежедневно в 2:00:

(crontab -l 2>/dev/null; echo "0 2 * * * /usr/local/bin/mongodb-backup.sh >> /var/log/mongodb-backup.log 2>&1") | crontab -

> Рекомендация для производственной среды: Храните резервные копии за пределами сервера. Хранение резервных копий на том же VPS, что и база данных, не обеспечивает защиты от сбоя диска или компрометации сервера. Используйте rsync, rclone или S3-совместимое объектное хранилище для репликации резервных копий в удалённое место.

Шаг 10: Мониторинг состояния MongoDB

Встроенные команды мониторинга

Внутри mongosh запустите статистику сервера:

db.serverStatus()
db.stats()
db.currentOp()

Использование mongostat и mongotop

Из оболочки отслеживайте счётчики операций в реальном времени:

mongostat --uri="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin"

Отслеживайте время чтения/записи по коллекциям:

mongotop --uri="mongodb://adminuser:yourpassword@127.0.0.1:27017/?authSource=admin"

Ключевые метрики для наблюдения

Выбор подходящего хостинга для MongoDB

Производительность и надёжность вашего экземпляра MongoDB напрямую зависят от базовой инфраструктуры. Рассмотрите следующие уровни развёртывания:

• Разработка и тестирование: Стандартный VPS с 2–4 GB RAM достаточен для непроизводственных нагрузок, тестирования схем и сред интеграции.
• Производственный одиночный узел: VPS с 4–8 GB RAM, NVMe-хранилищем и выделенным ядром CPU справляется с умеренным производственным трафиком для большинства веб-приложений.
• Высокопроизводительная производственная среда: Выделенный сервер устраняет эффект «шумного соседа», присущий виртуализированным средам. Паттерны ввода-вывода WiredTiger значительно выигрывают от NVMe-массивов на bare-metal.
• Нагрузки ML/аналитики: Если вы запускаете MongoDB совместно с конвейерами данных, аналитикой с интенсивной агрегацией или векторным поиском, GPU-хостинг может ускорить задачи последующей обработки.

Для развёртываний, требующих графического интерфейса управления, VPS с cPanel предоставляет привычную среду для команд, менее знакомых с администрированием через CLI, хотя прямое редактирование mongod.conf по-прежнему необходимо для расширенной настройки.

Матрица решений для развёртывания

Используйте этот контрольный список перед запуском в производство:

• [ ] MongoDB установлена из официального репозитория, версия зафиксирована
• [ ] Служба mongod включена и подтверждено состояние active (running)
• [ ] Transparent Huge Pages отключены и проверены
• [ ] ulimit для файловых дескрипторов установлен на 64000 или выше
• [ ] Аутентификация включена в mongod.conf (authorization: enabled)
• [ ] Пользователь admin создан с помощью passwordPrompt() — никаких паролей в открытом виде в истории оболочки
• [ ] Пользователи для конкретных приложений созданы с ролями минимальных привилегий
• [ ] bindIp ограничен только localhost или конкретными доверенными IP
• [ ] Правила UFW настроены — порт 27017 заблокирован из публичного интернета
• [ ] TLS включён с действующим сертификатом
• [ ] Кэш WiredTiger настроен на 50% от (RAM – 1 GB)
• [ ] Профилирование медленных запросов включено (slowOpThresholdMs: 100)
• [ ] Автоматическое ежедневное резервное копирование с репликацией за пределы сервера
• [ ] Восстановление из резервной копии протестировано — резервная копия, которую вы никогда не восстанавливали, не является резервной копией

FAQ

На каком порту MongoDB прослушивает соединения по умолчанию, и стоит ли его менять?

MongoDB прослушивает TCP-порт 27017 по умолчанию. Изменение его на нестандартный порт добавляет незначительную неочевидность, но не является заменой аутентификации и правил брандмауэра. Если вы его измените, обновите net.port в /etc/mongod.conf и скорректируйте все правила UFW и строки подключения соответствующим образом.

Почему MongoDB использует так много RAM даже при небольшом наборе данных?

WiredTiger предварительно выделяет внутренний кэш по формуле max(50% of (RAM - 1 GB), 256 MB). Это сделано намеренно — хранение рабочих данных в памяти устраняет обращения к диску. Если потребление RAM вызывает беспокойство на небольшом VPS, явно установите cacheSizeGB в /etc/mongod.conf на меньшее значение.

Можно ли запустить MongoDB на общем хостинге?

Нет. MongoDB требует постоянного фонового демона (mongod), прямого доступа к файловой системе для своего каталога данных и возможности привязки к сетевому порту. Ничего из этого недоступно на виртуальном веб-хостинге. VPS является минимально необходимой средой.

В чём разница между mongodump и снимком файловой системы для резервного копирования?

mongodump выполняет логическое резервное копирование — он читает документы через интерфейс запросов MongoDB и экспортирует их в виде BSON-файлов. Он переносим и работает между версиями, но медленнее и не может гарантировать согласованность на определённый момент времени на живом экземпляре с высокой нагрузкой на запись без --oplog. Снимок файловой системы (LVM, ZFS или снимок облачного блочного хранилища) захватывает необработанные файлы данных в согласованный момент времени и значительно быстрее для больших наборов данных, но требует, чтобы движок хранилища находился в согласованном состоянии.

Как проверить, какая версия MongoDB установлена?

Выполните следующую команду в терминале:

mongod --version

Или изнутри mongosh:

db.version()