Jak zainstalować i skonfigurować MongoDB na VPS (Kompletny przewodnik)

MongoDB to zorientowana dokumentowo baza danych NoSQL, która przechowuje rekordy jako dokumenty BSON (Binary JSON), umożliwiając modelowanie danych bez schematu z poziomą skalowalnością poprzez natywny sharding. W przeciwieństwie do relacyjnych baz danych, MongoDB nie wymaga predefiniowanego schematu tabel, co czyni ją dominującym wyborem dla aplikacji z ewoluującymi strukturami danych, wysoką przepustowością zapisu lub hierarchicznymi relacjami danych.

Ten przewodnik przeprowadza przez wdrożenie MongoDB klasy produkcyjnej na Linux VPS — obejmując instalację z oficjalnego repozytorium, wzmocnienie uwierzytelniania, kontrolę dostępu sieciowego, konfigurację TLS, dostrajanie wydajności i automatyzację kopii zapasowych. Każdy krok zakłada, że pracujesz w rzeczywistym środowisku serwerowym, gdzie bezpieczeństwo i niezawodność są niezbędne.

Wymagania wstępne

Przed kontynuowaniem potwierdź następujące kwestie:

• VPS z Ubuntu 20.04 LTS lub Ubuntu 22.04 LTS (polecenia są identyczne dla obu)
• Dostęp użytkownika root lub z uprawnieniami sudo przez SSH
• Minimum 2 GB RAM (4 GB zalecane dla obciążeń produkcyjnych)
• Co najmniej 20 GB dostępnego miejsca na dysku na szybkim woluminie pamięci masowej
• UFW lub iptables dostępne do zarządzania zaporą sieciową
• Podstawowa znajomość wiersza poleceń Linux

> Uwaga dotycząca architektury: Silnik pamięci masowej WiredTiger MongoDB używa domyślnej wewnętrznej pamięci podręcznej wynoszącej 50% (RAM – 1 GB). Na VPS z 2 GB daje to około 512 MB pamięci podręcznej. W przypadku obciążeń z intensywnym odczytem, zapewnij co najmniej 4 GB RAM, aby uniknąć ciągłego I/O dysku spowodowanego presją pamięci podręcznej.

MongoDB vs. inne bazy danych NoSQL: szybkie porównanie

Krok 1: Aktualizacja systemu

Zawsze zaczynaj od w pełni zaktualizowanego systemu. Przestarzałe pakiety wprowadzają znane CVE, które mogą być wykorzystane zanim jeszcze zainstalujesz swój stos aplikacji.

sudo apt update && sudo apt upgrade -y

Po zastosowaniu aktualizacji jądra lub libc, uruchom ponownie, aby aktywować nowe jądro:

sudo reboot

Połącz się ponownie przez SSH po powrocie serwera online (zazwyczaj 30–60 sekund).

Krok 2: Instalacja MongoDB z oficjalnego repozytorium

Domyślne repozytoria apt Ubuntu zawierają przestarzałą, przepakowaną przez społeczność wersję MongoDB, której brakuje najnowszych poprawek bezpieczeństwa i ulepszeń silnika. Zawsze instaluj z oficjalnego repozytorium MongoDB.

Dodaj klucz GPG MongoDB i repozytorium

Polecenie apt-key jest przestarzałe w Ubuntu 22.04. Użyj zalecanej metody keyring, która działa zarówno na 20.04, jak i 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

Dodaj wpis oficjalnego repozytorium:

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

> Uwaga dotycząca wersji: Zastąp 7.0 docelową wersją (np. 6.0), jeśli potrzebujesz konkretnej wersji dla zgodności aplikacji. MongoDB 7.0 to aktualne wydanie Long-Term Support od 2024 roku.

Zainstaluj pakiety MongoDB

sudo apt update
sudo apt install -y mongodb-org

Instaluje to następujące komponenty:

mongod — główny demon bazy danych
mongos — router shardingu (używany w wdrożeniach klastra shardowanego)
mongosh — nowoczesna powłoka MongoDB Shell (zastępuje starszy plik binarny mongo)
mongodb-database-tools — zawiera mongodump, mongorestore, mongoexport i mongoimport

Przypnij zainstalowaną wersję

Zapobiegaj niezamierzonym aktualizacjom, które mogłyby zepsuć zgodność aplikacji:

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

Krok 3: Konfiguracja wymagań wstępnych na poziomie systemu

MongoDB działa najlepiej, gdy pewne parametry jądra i systemu plików są dostrojone przed uruchomieniem demona.

Ustaw ulimit dla otwartych plików

MongoDB wymaga wysokiego limitu deskryptorów plików. Utwórz nadpisanie 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

Wyłącz Transparent Huge Pages (THP)

THP powoduje znaczące skoki opóźnień w MongoDB. Wyłącz je trwale:

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

Sprawdź, czy ustawienie zostało zastosowane:

cat /sys/kernel/mm/transparent_hugepage/enabled

Wynik powinien pokazywać [never] jako aktywną wartość.

Krok 4: Uruchom i włącz MongoDB

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

Potwierdź, że demon działa:

sudo systemctl status mongod

Szukaj Active: active (running) w wynikach. Jeśli usługa nie uruchomi się, natychmiast sprawdź dziennik:

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

Typowe błędy uruchamiania obejmują:

• Port 27017 jest już używany — inny proces jest powiązany z portem; zidentyfikuj go za pomocą sudo ss -tlnp | grep 27017
• Uprawnienia katalogu danych — użytkownik mongod musi być właścicielem /var/lib/mongodb; napraw za pomocą sudo chown -R mongodb:mongodb /var/lib/mongodb
• THP nadal włączone — silnik WiredTiger rejestruje ostrzeżenie i może obniżyć wydajność

Krok 5: Zabezpieczenie MongoDB — uwierzytelnianie i autoryzacja

To jest najbardziej krytyczna sekcja. Niezabezpieczone instancje MongoDB wystawione na internet były odpowiedzialne za tysiące naruszeń danych. Domyślna instalacja nie ma żadnego uwierzytelniania, co oznacza, że każdy, kto może dotrzeć do portu 27017, ma pełny dostęp do odczytu/zapisu każdej bazy danych.

Utwórz użytkownika administracyjnego

Połącz się z lokalną powłoką MongoDB (uwierzytelnianie nie jest wymagane przed jego włączeniem):

mongosh

Wewnątrz powłoki przełącz się na bazę danych admin i utwórz superużytkownika:

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" }
  ]
})

Użycie passwordPrompt() zamiast ciągu tekstowego zapobiega pojawieniu się hasła w historii powłoki. Wpisz hasło po wyświetleniu monitu, a następnie wyjdź:

exit

Włącz uwierzytelnianie w mongod.conf

Otwórz plik konfiguracyjny MongoDB:

sudo nano /etc/mongod.conf

Znajdź sekcję security (będzie zakomentowana) i włącz autoryzację:

security:
  authorization: enabled

Zapisz i wyjdź (Ctrl+X, następnie Y, następnie Enter), a następnie uruchom ponownie demona:

sudo systemctl restart mongod

Sprawdź, czy uwierzytelnianie jest wymuszane

Spróbuj połączyć się bez uwierzytelniania — powinno to teraz zakończyć się niepowodzeniem:

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

Powinieneś otrzymać błąd Unauthorized. Teraz uwierzytelnij się prawidłowo:

mongosh -u adminuser -p --authenticationDatabase admin

Utwórz użytkowników o zakresie aplikacji

Nigdy nie używaj superużytkownika administratora do połączeń aplikacji. Utwórz użytkownika z minimalnymi uprawnieniami dla każdej bazy danych aplikacji:

use myappdb

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

Krok 6: Konfiguracja powiązania sieciowego i reguł zapory sieciowej

Ogranicz lub rozszerz bindIp

Domyślnie mongod.conf wiąże się tylko z 127.0.0.1. Jest to prawidłowe ustawienie, jeśli Twoja aplikacja działa na tym samym VPS. Jeśli potrzebujesz zdalnego dostępu (np. z serwera aplikacji na osobnym hoście), edytuj /etc/mongod.conf:

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.5

Zastąp 10.0.0.5 konkretnym prywatnym IP Twojego serwera aplikacji. Nigdy nie ustawiaj bindIp: 0.0.0.0 na interfejsie publicznym bez reguły zapory sieciowej ograniczającej dostęp do znanych adresów IP. Powiązanie ze wszystkimi interfejsami bez zapory sieciowej jest główną przyczyną incydentów ujawnienia danych MongoDB.

Uruchom ponownie po zmianach:

sudo systemctl restart mongod

Konfiguracja reguł zapory sieciowej UFW

Jeśli wymagany jest zdalny dostęp, zezwól tylko na konkretny zaufany adres IP:

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

Zablokuj cały inny zewnętrzny dostęp do portu 27017:

sudo ufw deny 27017

UFW przetwarza reguły w kolejności — konkretna reguła allow from powyżej szerokiej reguły deny ma pierwszeństwo dla zaufanego adresu IP.

Krok 7: Włącz TLS/SSL dla szyfrowanych połączeń

W przypadku każdego wdrożenia, gdzie ruch MongoDB przekracza sieć — nawet prywatną sieć LAN — szyfrowanie TLS jest obowiązkowe. Bez niego dane uwierzytelniające i dane są przesyłane w postaci zwykłego tekstu.

Wygeneruj certyfikat z podpisem własnym do testów (użyj certyfikatu podpisanego przez CA w produkcji — rozważ połączenie tego z certyfikatem SSL dla swojej domeny):

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

Dodaj konfigurację TLS do /etc/mongod.conf:

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

Uruchom ponownie MongoDB i połącz się z TLS:

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

Flaga --tlsAllowInvalidCertificates jest akceptowalna tylko dla certyfikatów z podpisem własnym w środowisku deweloperskim. Usuń ją podczas używania certyfikatu podpisanego przez CA.

Krok 8: Dostrajanie wydajności w mongod.conf

W przypadku wdrożenia produkcyjnego na VPS z dedykowanymi zasobami, dostosuj ustawienia pamięci podręcznej WiredTiger i journalingu. Otwórz /etc/mongod.conf i dodaj lub zmodyfikuj następujące elementy:

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

operationProfiling:
  slowOpThresholdMs: 100
  mode: slowOp

replication:
  oplogSizeMB: 1024

Wyjaśnienie kluczowych parametrów dostrajania:

• cacheSizeGB — Ustaw to na około 50% dostępnego RAM minus 1 GB. Na VPS z 4 GB użyj 1.5. Na VPS z 8 GB użyj 3.5.
• slowOpThresholdMs — Zapytania przekraczające ten próg (w milisekundach) są rejestrowane w profilerze. Obniżenie tego pomaga wcześnie identyfikować zapytania bez indeksów.
• oplogSizeMB — Istotne, jeśli planujesz później dodać członków zestawu replik. Wstępne określenie rozmiaru oplog pozwala uniknąć opóźnień replikacji przy obciążeniach z intensywnym zapisem.

Zastosuj zmiany:

sudo systemctl restart mongod

Krok 9: Kopia zapasowa i przywracanie za pomocą mongodump

Ręczna kopia zapasowa

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

Ręczne przywracanie

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

Automatyzacja kopii zapasowych za pomocą Cron

Utwórz dedykowany skrypt kopii zapasowej:

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

Zaplanuj jego uruchamianie codziennie o 2:00 w nocy:

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

> Uwaga dotycząca produkcji: Przechowuj kopie zapasowe poza serwerem. Przechowywanie kopii zapasowych na tym samym VPS co baza danych nie zapewnia ochrony przed awarią dysku lub kompromitacją serwera. Użyj rsync, rclone lub magazynu obiektów kompatybilnego z S3, aby replikować kopie zapasowe do zdalnej lokalizacji.

Krok 10: Monitorowanie stanu MongoDB

Wbudowane polecenia monitorowania

Wewnątrz mongosh uruchom statystyki serwera:

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

Użyj mongostat i mongotop

Z powłoki monitoruj liczniki operacji w czasie rzeczywistym:

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

Monitoruj czas odczytu/zapisu dla każdej kolekcji:

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

Kluczowe metryki do obserwowania

Wybór odpowiedniego hostingu dla MongoDB

Wydajność i niezawodność Twojej instancji MongoDB są bezpośrednio powiązane z podstawową infrastrukturą. Rozważ te poziomy wdrożenia:

• Środowisko deweloperskie i staging: Standardowy VPS z 2–4 GB RAM jest wystarczający dla obciążeń nieprodukcyjnych, testowania schematu i środowisk integracyjnych.
• Produkcja na jednym węźle: VPS z 4–8 GB RAM, pamięcią masową NVMe i dedykowanym rdzeniem CPU obsługuje umiarkowany ruch produkcyjny dla większości aplikacji webowych.
• Produkcja o wysokiej przepustowości: Serwer dedykowany eliminuje efekt hałaśliwego sąsiada charakterystyczny dla środowisk zwirtualizowanych. Wzorce I/O WiredTiger znacznie korzystają z macierzy NVMe na bare-metal.
• Obciążenia ML/analityczne: Jeśli uruchamiasz MongoDB obok potoków danych, analityki z intensywną agregacją lub wyszukiwania wektorowego, hosting GPU może przyspieszyć zadania przetwarzania downstream.

W przypadku wdrożeń wymagających graficznego interfejsu zarządzania, VPS z cPanel zapewnia znajome środowisko dla zespołów mniej komfortowych z czystą administracją CLI, choć bezpośrednia edycja mongod.conf pozostaje niezbędna dla zaawansowanej konfiguracji.

Macierz decyzji wdrożeniowych

Użyj tej listy kontrolnej przed uruchomieniem produkcyjnym:

• [ ] MongoDB zainstalowane z oficjalnego repozytorium, wersja przypięta
• [ ] Usługa mongod włączona i potwierdzona jako active (running)
• [ ] Transparent Huge Pages wyłączone i zweryfikowane
• [ ] ulimit dla deskryptorów plików ustawione na 64000 lub wyżej
• [ ] Uwierzytelnianie włączone w mongod.conf (authorization: enabled)
• [ ] Użytkownik administratora utworzony za pomocą passwordPrompt() — brak haseł w postaci zwykłego tekstu w historii powłoki
• [ ] Użytkownicy specyficzni dla aplikacji utworzeni z rolami o minimalnych uprawnieniach
• [ ] bindIp ograniczony do localhost lub konkretnych zaufanych adresów IP
• [ ] Reguły UFW na miejscu — port 27017 zablokowany z publicznego internetu
• [ ] TLS włączone z ważnym certyfikatem
• [ ] Pamięć podręczna WiredTiger ustawiona na 50% (RAM – 1 GB)
• [ ] Profilowanie wolnych zapytań włączone (slowOpThresholdMs: 100)
• [ ] Zautomatyzowane codzienne kopie zapasowe z replikacją poza serwerem
• [ ] Przywracanie kopii zapasowej przetestowane — kopia zapasowa, której nigdy nie przywróciłeś, nie jest kopią zapasową

FAQ

Na jakim domyślnym porcie nasłuchuje MongoDB i czy należy go zmienić?

MongoDB domyślnie nasłuchuje na porcie TCP 27017. Zmiana go na niestandardowy port dodaje niewielką obscurity, ale nie zastępuje uwierzytelniania i reguł zapory sieciowej. Jeśli go zmienisz, zaktualizuj net.port w /etc/mongod.conf i odpowiednio dostosuj wszystkie reguły UFW i ciągi połączeń.

Dlaczego MongoDB używa tak dużo RAM nawet przy małym zestawie danych?

WiredTiger wstępnie przydziela swoją wewnętrzną pamięć podręczną na podstawie formuły max(50% of (RAM - 1 GB), 256 MB). Jest to zamierzone — przechowywanie roboczych danych w pamięci eliminuje odczyty z dysku. Jeśli zużycie RAM jest problemem na małym VPS, jawnie ustaw cacheSizeGB w /etc/mongod.conf na niższą wartość.

Czy mogę uruchomić MongoDB na hostingu współdzielonym?

Nie. MongoDB wymaga trwałego demona działającego w tle (mongod), bezpośredniego dostępu do systemu plików swojego katalogu danych oraz możliwości powiązania z portem sieciowym. Żadna z tych możliwości nie jest dostępna na hostingu współdzielonym. VPS to minimalne wykonalne środowisko.

Jaka jest różnica między mongodump a migawką systemu plików dla kopii zapasowych?

mongodump wykonuje logiczną kopię zapasową — odczytuje dokumenty przez interfejs zapytań MongoDB i eksportuje je jako pliki BSON. Jest przenośna i działa między wersjami, ale jest wolniejsza i nie może zagwarantować spójności w danym momencie na działającej instancji z intensywnym zapisem bez --oplog. Migawka systemu plików (LVM, ZFS lub migawka blokowej pamięci masowej w chmurze) przechwytuje surowe pliki danych w spójnym momencie i jest znacznie szybsza dla dużych zestawów danych, ale wymaga, aby silnik pamięci masowej był w spójnym stanie.

Jak sprawdzić, która wersja MongoDB jest zainstalowana?

Uruchom następujące polecenie z terminala:

mongod --version

Lub z wnętrza mongosh:

db.version()