Як встановити та налаштувати 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

Створення користувачів з обмеженим доступом для застосунків

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

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)
• [ ] Адміністративного користувача створено за допомогою 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()