Как да инсталирате и конфигурирате 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, за да избегнете постоянен дисков I/O от натиска върху кеша.

MongoDB срещу други NoSQL бази данни: Бързо сравнение

Стъпка 1: Актуализиране на системата

Винаги започвайте с напълно актуализирана система. Остарелите пакети въвеждат известни CVE уязвимости, които могат да бъдат експлоатирани преди дори да инсталирате вашия стек от приложения.

sudo apt update && sudo apt upgrade -y

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

sudo reboot

Свържете се отново чрез SSH след като сървърът се върне онлайн (обикновено 30–60 секунди).

Стъпка 2: Инсталиране на MongoDB от официалното хранилище

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

Добавяне на MongoDB GPG ключ и хранилище

Командата 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 (замества наследствения двоичен файл 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 с dedicated ресурси, настройте кеша на 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 — Релевантно, ако планирате да добавите членове на replica set по-късно. Предварителното оразмеряване на 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 са пряко свързани с основната инфраструктура. Разгледайте тези нива на разгръщане:

• Разработка и staging: Стандартен VPS с 2–4 GB RAM е достатъчен за непроизводствени натоварвания, тестване на схеми и интеграционни среди.
• Производствен единичен възел: VPS с 4–8 GB RAM, NVMe съхранение и dedicated CPU ядро обработва умерен производствен трафик за повечето уеб приложения.
• Производство с висока пропускателна способност: Dedicated сървър елиминира ефекта на шумния съсед, присъщ на виртуализираните среди. I/O моделите на WiredTiger се възползват значително от bare-metal NVMe масиви.
• 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)
• [ ] Автоматизирани ежедневни резервни копия с репликация извън сървъра
• [ ] Възстановяването от резервно копие е тествано — резервно копие, което никога не сте възстановявали, не е резервно копие

ЧЗВ

На кой порт по подразбиране слуша 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()