Det här sätter du upp
MongoDB är en dokumentdatabas: den sparar JSON-liknande dokument i stället för rader i tabeller, och många appar är byggda för den. Den här guiden sätter upp MongoDB Community Server som din egen databasserver, ungefär som en hanterad tjänst: en inloggning per app som bara kan använda sin egen databas, TLS för varje anslutning, en cache anpassad efter servern, åtkomst bara från servern själv och via WireGuard, och nattliga säkerhetskopior.
MongoDB utvecklas av MongoDB, Inc., ett företag i USA. Servern är inte öppen källkod. Sedan oktober 2018 omfattas den av Server Side Public License (SSPL) version 1, som MongoDB har skrivit och som Open Source Initiative inte har godkänt. Du får köra den för dina egna appar, även kommersiella, och ändra den. Erbjuder du MongoDB i sig som en tjänst åt andra kräver SSPL att du publicerar källkoden till allt du använder för att driva tjänsten, även din programvara för administration, övervakning och säkerhetskopiering. Passar inte det läser du licensen först, eller använder FerretDB, som är öppen källkod under Apache 2.0. Drivrutinerna, mongosh och databasverktygen omfattas av licensen Apache 2.0.
mongosh, MongoDB:s skal, skickar användningsstatistik till MongoDB som standard. Steg 4 stänger av det.
Här körs MongoDB från mongo, Dockers officiella avbild, som Docker bygger från MongoDB:s egna paket, i Podman under en egen användare som heter mongodb. Den ligger inte bakom Caddy: en databas är ingen webbplats, och bara dina appar ska nå den.
Varje steg nedan har körts på en nyinstallerad Melonslab VC-P Alloy (2 vCPU, 8 GB) med Debian 13:
- MongoDB 9.0.2 startade som en replica set med en medlem, och tog bara emot anslutningar med TLS och lösenord. En klient utan TLS, en klient som inte litade på certifikatet och ett fel lösenord nekades.
- Appens inloggning kunde läsa, skriva och skapa index i sin egen databas, men inte läsa en annan databas, skapa användare eller stänga av servern.
- En testapp på en annan maskin i WireGuard-nätet anslöt till
10.8.0.1med Python och skrev och läste dokument. Från internet fick porten inget svar. - 100 000 dokument lästes in, och transaktioner, change streams, aggregeringar, joins och textsökning fungerade.
- En nattlig dump återställdes två gånger: en databas under ett nytt namn, och allt, inloggningarna inräknade, till en tom volym.
- En uppgradering från MongoDB 8.0 till 9.0, med stegen i steg 11, gick igenom i en separat testcontainer. Serverns certifikat förnyades, och allt startade igen av sig självt efter en omstart av servern.
Efter en omstart, med testdatan inläst, använde hela servern 650 MB minne, och 710 MB efter frågor mot de 100 000 dokumenten, varav MongoDB använde 190 MB. Cachen tar mer allteftersom den fylls med din data, upp till de 3 GB som ställs in i steg 4.
Innan du börjar
Du behöver:
- en server uppsatt som i Podman-guiden, med ufw påslaget som i säkerhetsguiden;
- WireGuard på servern med tunneladressen
10.8.0.1, och varje appserver tillagd som en enhet, som i Lägg till fler enheter. På en appserver skickarAllowedIPs = 10.8.0.1/32bara databasens trafik genom tunneln.
Körs din app på en annan server hos Melonslab läser du först Anslut två servrar: två servrar i samma nät kan inte nå varandra direkt. Ingen DNS-post behövs: apparna ansluter till tunneladressen.
Exemplen använder 203.0.113.10 för databasserverns publika adress, 10.8.0.2 för appservern i tunneln, och appdb och appuser för appens databas och inloggning. Byt ut dem mot dina egna genomgående.
1. Skapa användaren
Som root:
useradd -m -s /bin/bash mongodb
loginctl enable-linger mongodb
machinectl shell mongodb@
Allt fram till steg 6 körs som mongodb.
2. Skapa ett certifikat
Apparna kontrollerar med ett certifikat att de pratar med din databas. En publik certifikatutfärdare som Let's Encrypt utfärdar bara certifikat för publika namn, och apparna når databasen på en privat adress. Därför gör du en egen liten certifikatutfärdare och ger dess certifikat till dina appar:
mkdir -p ~/tls && cd ~/tls
umask 077
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc -days 3650 -subj "/CN=MongoDB CA" -keyout ca.key -out ca.crt
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc -subj /CN=mongodb -keyout server.key -out server.csr
echo "subjectAltName=DNS:localhost,IP:127.0.0.1,IP:10.8.0.1" > server.ext
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -days 825 -extfile server.ext -out server.crt
chmod 644 ca.crt
cd
ca.crtär certifikatutfärdarens eget certifikat. Det är inte hemligt: dina appar får en kopia.ca.keysignerar certifikat som dina appar kommer att lita på. Förvara den säkert. Du kan också flytta den från servern och ta tillbaka den när serverns certifikat ska förnyas.server.crtochserver.keyär databasens certifikat, giltigt förlocalhost,127.0.0.1och tunneladressen10.8.0.1i 825 dagar. Steg 11 visar hur du förnyar det.
3. Skapa hemligheterna
cat ~/tls/server.crt ~/tls/server.key | podman secret create mongodb-tls -
openssl rand -base64 756 | podman secret create mongodb-keyfile -
for u in admin appuser; do openssl rand -hex 24 | tr -d '\n' | podman secret create mongodb-$u-password -; done
mongodb-tlsär certifikatet och dess nyckel i en fil, så som MongoDB vill ha dem.mongodb-keyfileär en gemensam nyckel som medlemmarna i en replica set känner igen varandra med. Med en enda medlem används den inte till mycket, men MongoDB kör ingen replica set med inloggningar utan den.- Sista raden gör lösenorden till din egen inloggning,
admin, och appens,appuser.
Podman lagrar dem, inte filerna nedan.
4. Definiera containern
MongoDB:s skal skickar användningsstatistik till MongoDB som standard. En liten inställningsfil, som containern kommer att använda, stänger av det för gott:
printf 'mongosh:\n forceDisableTelemetry: true\n' > ~/mongosh.conf
chmod 644 ~/mongosh.conf
mkdir -p ~/.config/containers/systemd
Skapa ~/.config/containers/systemd/mongodb.container:
[Unit]
Description=MongoDB
[Container]
ContainerName=mongodb
Image=docker.io/library/mongo:9.0
Volume=mongodb-data:/data/db
# Reachable on this server and over WireGuard only, never on the public address
PublishPort=127.0.0.1:27017:27017
PublishPort=10.8.0.1:27017:27017
Environment=MONGO_INITDB_ROOT_USERNAME=admin MONGO_INITDB_ROOT_PASSWORD_FILE=/run/secrets/mongodb-admin-password
Secret=mongodb-admin-password
Secret=mongodb-keyfile,uid=999,gid=999,mode=0400
Secret=mongodb-tls,uid=999,gid=999,mode=0400
Volume=%h/tls/ca.crt:/etc/mongodb/ca.crt:ro
Volume=%h/mongosh.conf:/etc/mongosh.conf:ro
# A one-member replica set, TLS for every connection, and a 3 GB cache for 8 GB of memory
Exec=--replSet rs0 --keyFile /run/secrets/mongodb-keyfile --tlsMode requireTLS --tlsCertificateKeyFile /run/secrets/mongodb-tls --tlsCAFile /etc/mongodb/ca.crt --tlsAllowConnectionsWithoutCertificates --wiredTigerCacheSizeGB 3
AutoUpdate=registry
[Service]
Restart=always
[Install]
WantedBy=default.target
Vad inställningarna gör:
MONGO_INITDB_ROOT_USERNAMEoch lösenordsfilen får avbilden att skapa inloggningenadmin, med alla rättigheter, första gången den startar. Utan inloggning låter MongoDB vem som helst som når den göra vad som helst.--replSet rs0gör MongoDB till en replica set med en medlem. Transaktioner och change streams fungerar bara i en replica set, och många appar behöver dem. En replica set för också en logg över varje ändring, oploggen, som gör säkerhetskopiorna i steg 10 konsekventa.--tlsMode requireTLSnekar varje anslutning utan TLS, även på servern själv.--tlsAllowConnectionsWithoutCertificatesbetyder att klienter visar vilka de är med ett lösenord, inte med ett eget certifikat.--wiredTigerCacheSizeGB 3är MongoDB:s egen cache. Steg 6 förklarar storleken.uid=999låter MongoDB, som körs som användare 999 i sin container, läsa sin nyckel och sitt certifikat, ochmode=0400stänger ute alla andra.AutoUpdate=registryuppdaterar MongoDB inom 9.0 (steg 11).
Starta den:
systemctl --user daemon-reload
systemctl --user start mongodb
systemctl --user enable --now podman-auto-update.timer
Första starten laddar ner omkring 1,1 GB, och MongoDB tar några sekunder på sig att skapa sin första inloggning. Den är klar när det här skriver ut 1:
podman logs mongodb 2>&1 | grep -c 'init process complete'
5. Starta replica set och skapa appens inloggning
Lägg till ett alias för MongoDB:s skal, mongosh, som kör det i containern:
echo "alias mongosh='podman exec -it mongodb mongosh --tls --tlsCAFile /etc/mongodb/ca.crt'" >> ~/.bashrc
source ~/.bashrc
Starta replica set. Hemligheterna går till mongosh på dess indata, så de syns inte i listan över processer:
printf 'db.getSiblingDB("admin").auth("admin", "%s"); rs.initiate({_id: "rs0", members: [{_id: 0, host: "localhost:27017"}]})\n' \
"$(podman secret inspect --showsecret --format '{{.SecretData}}' mongodb-admin-password)" |
podman exec -i mongodb mongosh --quiet --tls --tlsCAFile /etc/mongodb/ca.crt
Svaret slutar med ok: 1. Medlemmens namn är localhost:27017, det enda namnet som stämmer inne i containern genom omstarter och uppdateringar. Klienter utanför ansluter direkt till den med directConnection=true (steg 9).
Skapa sedan appens inloggning, med rätt att läsa och skriva i sin egen databas och ingenting annat:
printf 'db.getSiblingDB("admin").auth("admin", "%s"); db.getSiblingDB("appdb").createUser({user: "appuser", pwd: "%s", roles: [{role: "readWrite", db: "appdb"}]})\n' \
"$(podman secret inspect --showsecret --format '{{.SecretData}}' mongodb-admin-password)" \
"$(podman secret inspect --showsecret --format '{{.SecretData}}' mongodb-appuser-password)" |
podman exec -i mongodb mongosh --quiet --tls --tlsCAFile /etc/mongodb/ca.crt
readWrite låter appen skapa samlingar och index i appdb, vilket dess migreringar behöver. Resten kontrollerade vi med appuser:
read other db -> not authorized on shop to execute command { find: "orders", ...
createUser -> not authorized on appdb to execute command { createUser: "x", ...
shutdown -> not authorized on admin to execute command { shutdown: 1, ...
För en till app skapar du en hemlighet för dess lösenord som i steg 3, och upprepar kommandot med createUser med appens eget namn, databas och hemlighet. För att logga in själv:
mongosh -u admin
Det frågar efter lösenordet, som podman secret inspect --showsecret --format '{{.SecretData}}' mongodb-admin-password visar. Prompten rs0 [direct: primary] test> betyder att replica set är igång. exit tar dig ut.
6. Anpassa den efter servern
Gå tillbaka till root med exit.
Cachen. MongoDB håller datan den använder i sin egen cache, WiredTigers. Som standard tar den halva minnet minus 1 GB, omkring 3,4 GB här, men den kan inte veta vad mer servern kör. --wiredTigerCacheSizeGB 3 från steg 4 bestämmer storleken. Resten går till anslutningar, omkring 1 MB var, till andra program och till systemets filcache, som MongoDB också använder: dess datafiler är komprimerade, och filcachen håller dem så. På en server som bara kör MongoDB kan du höja den till 3,5. db.serverStatus().wiredTiger.cache["maximum bytes configured"] i mongosh visar värdet som gäller.
Stora sidor. MongoDB 8.0 och senare fungerar bäst med kärnans transparent huge pages påslagna, och säger det vid varje start med två varningar om /sys/kernel/mm/transparent_hugepage. Debian har dem redan påslagna, och två inställningar återstår. Skapa /etc/tmpfiles.d/mongodb-thp.conf:
# Transparent huge pages as MongoDB 8.0 and later recommend
w /sys/kernel/mm/transparent_hugepage/defrag - - - - defer+madvise
w /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none - - - - 0
Använd den direkt:
systemd-tmpfiles --create /etc/tmpfiles.d/mongodb-thp.conf
cat /sys/kernel/mm/transparent_hugepage/defrag
always defer [defer+madvise] madvise never
MongoDB kontrollerar inställningarna när den startar, så starta om den en gång, med systemctl --user restart mongodb som mongodb. systemd använder filen igen vid varje uppstart, innan MongoDB startar. Efter en omstart av servern startade vår MongoDB utan varningar. Den skriver fortfarande i loggen att den rekommenderar filsystemet XFS. Debian använder ext4, vilket fungerar.
7. Släpp in dina appservrar
MongoDB lyssnar på tunneladressen 10.8.0.1, som bara finns när WireGuard är igång. Startar MongoDB först vid uppstart misslyckas den med Cannot assign requested address. Låt program lyssna på en adress innan den finns:
echo "net.ipv4.ip_nonlocal_bind = 1" > /etc/sysctl.d/60-nonlocal-bind.conf
sysctl --system
Öppna sedan port 27017 bara i tunneln:
ufw allow in on wg0 to any port 27017 proto tcp
ss -tlnp | grep 27017
LISTEN 0 128 10.8.0.1:27017 0.0.0.0:* users:(("pasta.avx2",pid=1161,fd=7))
LISTEN 0 128 127.0.0.1:27017 0.0.0.0:* users:(("pasta.avx2",pid=1161,fd=6))
Bara tunneladressen och 127.0.0.1: ingenting lyssnar på den publika adressen.
8. Kontrollera vad andra ser
Från en dator som inte är med i tunneln provar du den publika adressen:
nc -vz -w 10 203.0.113.10 27017
nc: connect to 203.0.113.10 port 27017 (tcp) timed out: Operation now in progress
Ingenting lyssnar där, och ufw kastar försöket utan att svara. Där MongoDB lyssnar tar den bara emot TLS och lösenord. Vi provade med mongosh på servern utan TLS, utan certifikatutfärdaren och med fel lösenord:
MongoServerSelectionError: connection <monitor> to 127.0.0.1:27017 closed
MongoNetworkError: self-signed certificate in certificate chain
MongoServerError: Authentication failed.
9. Anslut från en app
Kopiera ~/tls/ca.crt från databasservern till appservern, här till /opt/notes/ca.crt. Appens anslutningssträng är:
mongodb://appuser:PASSWORD@10.8.0.1:27017/appdb?tls=true&tlsCAFile=/opt/notes/ca.crt&directConnection=true
appdbär databasen som appen loggar in mot och använder som standard. MongoDB skapar den första gången appen skriver till den.directConnection=truegör att drivrutinen bara pratar med10.8.0.1. Utan den frågar drivrutinen replica set efter medlemmarna, fårlocalhost:27017och provar det på appservern i stället. I vårt test misslyckades det medCould not reach any servers in [('localhost', 27017)].- Lösenorden från steg 3 är hexadecimala. Ett eget lösenord med tecken som
@,:eller/måste procentkodas i strängen.
Ett exempel i Python, med PyMongo, MongoDB:s egen drivrutin för Python. På appservern, med Debian 13:
apt install -y python3-pymongo
Skapa /opt/notes/notes.py:
import datetime
import os
from pymongo import MongoClient
client = MongoClient(os.environ["MONGODB_URI"])
notes = client.get_default_database().notes
notes.insert_one({"text": "Hello from the app", "at": datetime.datetime.now(datetime.UTC)})
for note in notes.find().sort("at", -1).limit(3):
print(note["text"])
print(notes.count_documents({}), "notes in total")
MONGODB_URI='mongodb://appuser:PASSWORD@10.8.0.1:27017/appdb?tls=true&tlsCAFile=/opt/notes/ca.crt&directConnection=true' python3 /opt/notes/notes.py
Hello from the app
1 notes in total
Samma kod körs oförändrad mot FerretDB. Det är bara anslutningssträngen som skiljer. I en riktig app förvarar du strängen bland appens egna hemligheter, inte i koden.
Vi körde också en uppsättning tester mot 100 000 dokument, samma som i FerretDB-guiden. I MongoDB 9.0 fungerade alla, även transaktioner och change streams, utom $where: MongoDB 9.0 nekar JavaScript i frågor som standard, med $where is not allowed in this context.
10. Säkerhetskopiera
mongodump skriver varje databas, inloggningarna inräknade, medan MongoDB fortsätter att arbeta. Med --oplog sparar den också ändringarna som görs medan den körs, så att dumpen är en kopia av ett enda ögonblick. Som mongodb skapar du ~/bin/mongodb-backup:
mkdir -p ~/bin ~/.config/systemd/user
#!/bin/sh
# Dump every database with mongodump, and keep 14 days
set -e
umask 077
dir=$HOME/backup
day=$(date +%F)
mkdir -p "$dir"
podman exec mongodb sh -c '
printf "password: %s\n" "$(cat /run/secrets/mongodb-admin-password)" |
mongodump --quiet --config=/dev/stdin --oplog --gzip --archive \
--uri="mongodb://admin@localhost:27017/?authSource=admin&tls=true&tlsCAFile=/etc/mongodb/ca.crt&directConnection=true"
' > "$dir/mongodump-$day.gz"
find "$dir" -type f -mtime +13 -delete
Lösenordet når mongodump på dess indata, inte på dess kommandorad, och dumpen kommer ut på dess utdata, rakt in i filen. Kör det varje natt med en tjänst och en timer. Skapa ~/.config/systemd/user/mongodb-backup.service:
[Unit]
Description=Back up MongoDB
[Service]
Type=oneshot
ExecStart=%h/bin/mongodb-backup
Och ~/.config/systemd/user/mongodb-backup.timer:
[Unit]
Description=Back up MongoDB every night
[Timer]
OnCalendar=*-*-* 02:30
Persistent=true
[Install]
WantedBy=timers.target
Slå på den, och kör den en gång direkt:
chmod 755 ~/bin/mongodb-backup
systemctl --user daemon-reload
systemctl --user enable --now mongodb-backup.timer
systemctl --user start mongodb-backup.service
ls -l ~/backup
-rw------- 1 mongodb mongodb 2615655 Oct 14 02:13 mongodump-2026-10-14.gz
För våra 100 000 testdokument tog det 2 sekunder. Kopiera ~/backup från servern varje natt, till exempel med restic, och håll den privat: den innehåller all din data och inloggningarnas lösenordshashar.
Testa en återställning. Återställ en databas under ett nytt namn, bredvid den riktiga:
podman exec -i mongodb mongorestore \
--uri="mongodb://admin:ADMIN_PASSWORD@localhost:27017/?authSource=admin&tls=true&tlsCAFile=/etc/mongodb/ca.crt&directConnection=true" \
--gzip --archive --nsInclude='appdb.*' --nsFrom='appdb.*' --nsTo='appdb_restore.*' \
< ~/backup/mongodump-2026-10-14.gz
125010 document(s) restored successfully. 0 document(s) failed to restore.
Vår appdb_restore hade lika många dokument i varje samling som appdb, och samma index. Ta bort den med db.getSiblingDB("appdb_restore").dropDatabase() i mongosh. Administratörens lösenord står på kommandoraden här, så kör det när ingen annan är inloggad på servern.
Återställ allt, till exempel på en ny server, med samma hemligheter. Börja med en tom volym, starta replica set som i steg 5, och återställ hela dumpen:
systemctl --user stop mongodb
podman volume rm mongodb-data
systemctl --user start mongodb
När podman logs mongodb 2>&1 | grep -c 'init process complete' skriver ut 1 igen kör du kommandot med rs.initiate från steg 5, och sedan:
podman exec -i mongodb mongorestore \
--uri="mongodb://admin:ADMIN_PASSWORD@localhost:27017/?authSource=admin&tls=true&tlsCAFile=/etc/mongodb/ca.crt&directConnection=true" \
--gzip --archive --oplogReplay < ~/backup/mongodump-2026-10-14.gz
Vår kom tillbaka med alla dokument och index, och appuser kunde logga in med sitt gamla lösenord. Utelämna --drop här: med den tog mongorestore bort inloggningen admin, som den själv använde, halvvägs igenom, och misslyckades med requires authentication.
11. Uppdatera
Inom 9.0, till exempel från 9.0.2 till 9.0.3, letar podman auto-update en gång om dagen efter en ny avbild och startar om MongoDB när det finns en. En omstart tar några sekunder, och apparna tappar sina anslutningar en kort stund. 9.0.2 var den senaste när vi testade, så vi har inte sett någon sådan uppdatering. För att uppdatera direkt, som mongodb:
podman auto-update
En ny huvudversion ändrar hur datan lagras, och MongoDB uppgraderar bara från versionen före: från 9.0 till nästa, inte förbi den. Vi testade stegen från 8.0 till 9.0. Ta först en säkerhetskopia:
systemctl --user start mongodb-backup.service
Byt taggen i mongodb.container till den nya versionen, och starta om:
systemctl --user daemon-reload
systemctl --user restart mongodb
Den nya versionen startar i kompatibilitetsläge, med den gamla versionens featureCompatibilityVersion, så att du fortfarande kan gå tillbaka. När dina appar fungerar slår du om, i mongosh som admin, med det nya versionsnumret:
db.adminCommand({setFeatureCompatibilityVersion: "9.0", confirm: true})
I vårt test, från 8.0.34 till 9.0.2, fanns all data kvar före och efter omslaget. Läs MongoDB:s uppgraderingsanvisningar för versionen först: de listar vad som ändras och vad du måste göra innan.
Förnya certifikatet innan det går ut, om ungefär två år. openssl x509 -enddate -noout -in ~/tls/server.crt visar datumet. Gör ett nytt med samma utfärdare, så att apparna inte behöver ändras:
cd ~/tls
umask 077
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc -subj /CN=mongodb -keyout server.key -out server.csr
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -days 825 -extfile server.ext -out server.crt
cat server.crt server.key | podman secret create --replace mongodb-tls -
systemctl --user restart mongodb
Vi testade det en gång: appen anslöt igen med sin gamla ca.crt.
Felsökning
MongoDB startar inte efter en omstart, och loggen visar Failed to bind port 27017 (Cannot assign requested address). Den startade före WireGuard. Lägg till inställningen från steg 7, och kör sedan systemctl --user reset-failed och systemctl --user start mongodb som mongodb.
Could not reach any servers in [('localhost', 27017)]. Appen ansluter som till en replica set och letar efter localhost på sin egen server. Lägg till directConnection=true i anslutningssträngen.
MongoServerSelectionError: connection <monitor> to ... closed. Klienten anslöt utan TLS. Lägg till tls=true och tlsCAFile i anslutningssträngen.
self-signed certificate in certificate chain. Klienten litar inte på certifikatet. Kontrollera att tlsCAFile pekar på kopian av ca.crt.
Authentication failed. för appens inloggning. Appen loggar in mot en annan databas än den där inloggningen skapades. Inloggningen hör till appdb, så anslutningssträngen måste sluta på /appdb eller ha authSource=appdb.
not authorized on ... to execute command. Inloggningen har inga rättigheter där. En appinloggning har bara readWrite i sin egen databas. Ge den mer med db.getSiblingDB("appdb").grantRolesToUser("appuser", [...]) som admin, om den verkligen behöver det.
Varningar om /sys/kernel/mm/transparent_hugepage när MongoDB startar. Filen från steg 6 saknas, eller MongoDB startade innan den användes: starta om MongoDB.
En appserver väntar och får timeout. Kontrollera med wg show att WireGuard är igång på båda sidor, och med ufw status att regeln från steg 7 finns.