Come installare MongoDB su Ubuntu

Introduzione

MongoDB è uno dei database NoSQL open-source più popolari, ampiamente utilizzato per applicazioni che richiedono strutture dati flessibili, alta scalabilità e prestazioni rapide. Memorizza i dati in un formato orientato ai documenti utilizzando oggetti simili a JSON, il che lo rende ideale per carichi di lavoro moderni su web, mobile e analisi. Gli sviluppatori preferiscono MongoDB per il suo schema dinamico, lo sharding automatico e le funzionalità di replica integrate che supportano sia la scalabilità orizzontale sia l'alta disponibilità. Quando è combinato con la stabilità e la sicurezza di Ubuntu, MongoDB offre una solida base per eseguire applicazioni basate su database affidabili ed efficienti.

In questo articolo, spieghiamo come installare, configurare e mantenere MongoDB 8.2 su Ubuntu 24.04 LTS. Copriamo ogni passaggio essenziale, dalla preparazione del server e l'attivazione delle funzionalità di sicurezza all'ottimizzazione delle prestazioni, alla configurazione della replica e dei backup e alla risoluzione dei problemi comuni. Alla fine, avrete una distribuzione MongoDB pronta per la produzione, correttamente protetta, monitorata e ottimizzata per un uso a lungo termine. Che stiate configurando MongoDB per sviluppo, test o un ambiente di produzione completo, questa guida fornisce istruzioni dettagliate e best practice operative necessarie per gestirlo in modo efficace.

Prerequisiti

Per seguire questo tutorial, avrai bisogno di:

• Un server che esegue Ubuntu 24.04 LTS. Questo server dovrebbe avere un utente non root con privilegi amministrativi e UFW (Uncomplicated Firewall) installato e configurato. Consulta la nostra Guida all'Impostazione Iniziale del Server con Ubuntu per configurarlo.

Installare MongoDB dal repository ufficiale

Ubuntu 24.04 include una versione di MongoDB nei suoi repository di pacchetti predefiniti, ma di solito è obsoleta. Per i sistemi di produzione, dovresti sempre installare MongoDB direttamente dal repository ufficiale di MongoDB. Questo garantisce di ottenere l'ultima versione stabile (8.2 al momento della scrittura) insieme agli aggiornamenti di sicurezza e manutenzione tempestivi.

Aggiungiamo il repository MongoDB alle sorgenti APT del tuo sistema, importiamo la chiave GPG utilizzata per verificare i pacchetti, e poi installiamo il database.

1. Importa la chiave GPG di MongoDB

APT utilizza le chiavi GPG per verificare l'autenticità dei pacchetti. Senza queste, il tuo sistema non si fiderà del repository di MongoDB.

Esegui il seguente comando per importare la chiave pubblica per MongoDB 8.0:

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

Ecco cosa fa questo:

• curl -fsSL recupera silenziosamente la chiave GPG dai server ufficiali di MongoDB.
• --dearmor converte la chiave dal formato ASCII-armored in un formato di portachiavi binario compatibile con APT.
• L'output viene salvato in /usr/share/keyrings/mongodb-server-8.0.gpg, una posizione standard per le chiavi attendibili.

Se il comando viene completato senza errori, la chiave è stata aggiunta con successo.

2. Aggiungi il repository MongoDB

Successivamente, crea un nuovo file di lista dei repository che punti alla fonte ufficiale dei pacchetti di MongoDB per Ubuntu 24.04 ("Noble").

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-8.2.list

Ogni parte di questo comando ha uno scopo chiaro:

• deb indica ad APT che questo è un repository di pacchetti binari (a differenza di deb-src per il codice sorgente).
• arch=amd64,arm64 lo limita alle architetture a 64 bit Intel/AMD e ARM supportate da MongoDB.
• signed-by=... garantisce che APT utilizzi la chiave specifica di MongoDB (aggiunta sopra) per verificare i download.
• https://repo.mongodb.org/apt/ubuntu è l'URL base del repository APT ufficiale di MongoDB.
• noble/mongodb-org/8.2 specifica sia il nome in codice della distribuzione di Ubuntu (noble=Ubuntu 24.04) sia la versione di MongoDB (8.2).
• multiverse è la sezione dei componenti di Ubuntu per il software di terze parti.

3. Aggiorna l'indice dei pacchetti

Dopo aver aggiunto un nuovo repository, è necessario aggiornare l'elenco locale dei pacchetti disponibili del sistema in modo che APT riconosca la nuova fonte:

sudo apt update

APT scaricherà le ultime liste dei pacchetti e le verificherà utilizzando la chiave GPG. Se vedi MongoDB elencato tra i repository, la tua configurazione è corretta.

4. Installa MongoDB

Ora installa MongoDB e i suoi strumenti associati:

sudo apt install -y mongodb-org

Il flag -y conferma automaticamente le richieste di installazione.

Questo installerà un insieme di pacchetti correlati, tra cui:

• mongodb-org-server: Il demone del server MongoDB (mongod), responsabile dell'archiviazione dei dati e delle operazioni sul database.
• mongodb-org-mongos: Il router di sharding utilizzato nelle distribuzioni distribuite.
• mongodb-org-shell: Il client interattivo da riga di comando (mongosh) utilizzato per connettersi a MongoDB.
• mongodb-org-tools: Utility per il backup e il ripristino (mongodump, mongorestore, bsondump, ecc.).

Una volta installati, i file binari vengono collocati in /usr/bin/, e i file di configurazione si trovano in /etc/mongod.conf.

5. Verifica l'installazione

Puoi verificare che MongoDB 8.2 sia stato installato correttamente controllando la sua versione:

mongod --version

Dovresti vedere un output simile a:

db version v8.2.3
Build Info: {
    "version": "8.2.3",
    "gitVersion": "36f41c9c30a2f13f834d033ba03c3463c891fb01",
    "openSSLVersion": "OpenSSL 3.0.13 30 Jan 2024",
    "modules": [],
    "allocator": "tcmalloc-google",
    "environment": {
        "distmod": "ubuntu2404",
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

Se vedi questo, MongoDB è installato correttamente ed è pronto per essere avviato come servizio.

Avviare e gestire il servizio MongoDB

Quando installi MongoDB su Ubuntu, il pacchetto include automaticamente un unità di servizio systemd chiamata mongod.service. Questa integrazione permette a MongoDB di avviarsi, fermarsi e riavviarsi correttamente usando i comandi standard di gestione dei servizi di Ubuntu, proprio come Nginx, PostgreSQL o qualsiasi altro daemon principale.

Avvia il servizio MongoDB

Per impostazione predefinita, MongoDB non si avvia automaticamente dopo l'installazione. Per avviarlo manualmente, usa il seguente comando:

sudo systemctl start mongod

Se il comando viene eseguito senza errori, il servizio dovrebbe essere ora attivo. Puoi confermarlo con:

sudo systemctl status mongod

Esempio di output:

● mongod.service - MongoDB Database Server
     Loaded: loaded (/usr/lib/systemd/system/mongod.service; disabled; preset: enabled)
     Active: active (running) since Tue 2026-01-06 07:08:28 UTC; 5s ago
       Docs: https://docs.mongodb.org/manual
   Main PID: 12462 (mongod)
     Memory: 195.4M (peak: 277.1M)
        CPU: 739ms
     CGroup: /system.slice/mongod.service
             └─12462 /usr/bin/mongod --config /etc/mongod.conf

La riga “Active: active (running)” conferma che il database è attivo e funzionante.

Se invece vedi "failed" o "inactive", passa alla sezione Controllo dei log di MongoDB per la risoluzione dei problemi.

Abilita MongoDB per l'avvio con il sistema

La maggior parte dei sistemi di produzione richiede che il database si avvii automaticamente dopo un riavvio. Per consentire a MongoDB di avviarsi all'avvio, eseguire:

sudo systemctl enable mongod

Questo crea un collegamento simbolico in /etc/systemd/system/multi-user.target.wants/, indicando a systemd di avviare automaticamente il servizio ogni volta che il sistema entra in modalità multi-utente (la modalità operativa standard per i server).

Puoi confermare la modifica con:

systemctl is-enabled mongod

Output previsto:

enabled

Se vuoi mai disattivare l'avvio automatico (per manutenzione o test), usa:

sudo systemctl disable mongod

Verifica l'operazione MongoDB

Una volta che MongoDB è in esecuzione, è una buona idea verificare che stia rispondendo correttamente.

Esegui il comando seguente per connetterti al database e controllare lo stato della connessione:

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

Questo comando:

• Apre una sessione shell temporanea (mongosh è la nuova shell di MongoDB, che sostituisce il vecchio client mongo).
• Esegue il comando connectionStatus direttamente sull'istanza locale.
• Visualizza il risultato della connessione senza richiedere di rimanere nella shell.

Esempio di output:

{
  authInfo: { authenticatedUsers: [], authenticatedUserRoles: [] },
  uuid: UUID('be686f2a-9cb3-41c1-aad2-8849367de4e5'),
  ok: 1
}

Un valore di "ok": 1 conferma che il server funziona correttamente e accetta connessioni sulla porta 27017.

Gestire il ciclo di vita del servizio MongoDB

Una volta verificato che MongoDB è in esecuzione, è utile sapere come gestirlo in sicurezza nelle operazioni quotidiane.

Ecco i comandi principali:

sudo systemctl stop mongod

sudo systemctl start mongod

sudo systemctl restart mongod

sudo systemctl reload mongod

sudo systemctl disable mongod

sudo systemctl status mongod

Riavviare il servizio (restart) è particolarmente importante dopo aver modificato /etc/mongod.conf. Questo assicura che le modifiche alla configurazione vengano applicate.

Controllo dei log di MongoDB

Se MongoDB non si avvia o si comporta in modo inaspettato, il primo passo per la risoluzione dei problemi dovrebbe essere controllare i log.

I log di MongoDB si trovano in:

/var/log/mongodb/mongod.log

Puoi visualizzare le ultime 20 righe con:

sudo tail -n 20 /var/log/mongodb/mongod.log

I messaggi di log comuni includono:

• "In attesa di connessioni sulla porta 27017": MongoDB è stato avviato con successo ed è pronto.
• "Directory dei dati /var/lib/mongodb non trovata": Verifica che il percorso dei dati esista e abbia i permessi corretti.
• "Indirizzo già in uso": Un altro processo sta già utilizzando la porta 27017.
• "Permesso negato": Assicurati che l'utente MongoDB (mongodb) possieda le sue directory dei dati e dei log.

Puoi anche usare journalctl per visualizzare i log specifici dei servizi gestiti da systemd:

sudo journalctl -u mongod --since "5 minutes ago"

Testare MongoDB all'avvio del sistema

È buona pratica verificare che MongoDB si avvii automaticamente dopo un riavvio, specialmente prima di distribuire applicazioni.

Per riavviare, esegui:

sudo reboot

Dopo il riavvio del server, accedi di nuovo e controlla il servizio:

sudo systemctl status mongod

Se mostra “attivo (in esecuzione)”, la tua configurazione è corretta e persistente.

Comprendere le impostazioni di configurazione di MongoDB

Quando installi MongoDB, il suo comportamento è controllato da un unico file di configurazione situato in /etc/mongod.conf.

Questo file definisce come MongoDB funziona: tutto, da dove memorizza i dati, a come registra le attività, quali indirizzi IP ascolta e quali meccanismi di sicurezza sono attivi. Comprendere questo file è fondamentale, specialmente se prevedi di eseguire MongoDB in produzione. Le impostazioni in questo file sono equivalenti alle corrispondenti opzioni da riga di comando, ma l'uso di un file di configurazione rende la gestione del server più semplice, soprattutto per implementazioni più grandi o automatizzate.

Panoramica del file di configurazione

Il file di configurazione di MongoDB utilizza la sintassi YAML, che è sensibile all'indentazione. Ciò significa che è necessario usare gli spazi (non le tabulazioni) durante la modifica, poiché anche uno spazio fuori posto può compromettere la configurazione.

Puoi visualizzare il contenuto attuale del file con:

sudo cat /etc/mongod.conf

Il file predefinito appare più o meno così:

# mongod.conf

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Analizziamo questo passo per passo.

La sezione storage

Questa sezione definisce dove MongoDB memorizza i suoi dati e come gestisce il journaling (che garantisce la durabilità dei dati).

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

• dbPath: Questa è la directory in cui MongoDB memorizza i suoi database, collezioni e indici. Per default, punta a /var/lib/mongodb. Se cambi questo percorso, assicurati che la directory esista e sia di proprietà dell'utente mongodb:

  sudo mkdir -p /data/mongodb
  
  sudo chown -R mongodb:mongodb /data/mongodb

• journal.enabled: Quando impostato su true, MongoDB mantiene un file di journal che aiuta a recuperare da crash o spegnimenti imprevisti. La journalizzazione scrive le modifiche in un log separato prima di aggiornarle nei file di dati, prevenendo la corruzione. Mantenerlo sempre abilitato nei sistemi di produzione.

La sezione systemLog

Questo controlla come e dove MongoDB scrive i suoi log.

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

• destination: Specifica dove vengono scritti i log. Il valore predefinito file scrive i log in un file; puoi cambiarlo in syslog se desideri che i log di MongoDB siano integrati con i log del sistema.
• logAppend: Quando true, MongoDB aggiunge nuove voci di log al file esistente invece di sovrascriverlo al riavvio.
• path: Il percorso assoluto del file di registro.

Puoi visualizzare i log direttamente con:

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

Se i tuoi log diventano troppo grandi, valuta l'opzione di abilitare la rotazione dei log con uno strumento come logrotate o di configurare i log di sistema per ruotare automaticamente.

La sezione net

Questa sezione definisce come MongoDB ascolta le connessioni di rete in arrivo.

net:
  port: 27017
  bindIp: 127.0.0.1

• port: La porta predefinita di MongoDB è 27017. Puoi cambiarla se stai eseguendo più servizi di database sullo stesso host.
• bindIp: Questo controlla su quali interfacce di rete MongoDB ascolta.

Per impostazione predefinita, è limitato a 127.0.0.1 (l'indirizzo di loopback locale), il che significa che vengono accettate solo connessioni locali. Questo è un comportamento predefinito di sicurezza critico che impedisce l'accesso remoto finché non lo permetti esplicitamente.

Se prevedi di connetterti da un'altra macchina (ad esempio, un server web o un'applicazione remota), puoi modificarlo come segue:

bindIp: 127.0.0.1,192.168.1.100

Oppure, per ascoltare su tutte le interfacce (usare con cautela in produzione):

bindIp: 0.0.0.0

La sezione security

MongoDB viene installato con l'autenticazione disabilitata per impostazione predefinita. Chiunque possa connettersi al database può leggere o modificare i dati. Questo va bene per i test, ma rappresenta una minaccia per la sicurezza in qualsiasi sistema reale. Per abilitare l'autenticazione basata sugli utenti, aggiungi la seguente sezione:

security:
  authorization: enabled

Una volta abilitato, MongoDB richiederà agli utenti di autenticarsi con un nome utente e una password prima di eseguire operazioni.

Altre impostazioni opzionali in questa sezione includono:

• keyFile: Utilizzato per i set di repliche per autenticarsi tra i nodi del cluster.
• javascriptEnabled: Abilita o disabilita l'esecuzione di JavaScript lato server (si consiglia di mantenere disabilitato a meno che non sia necessario).

La sezione processManagement

Questa sezione controlla come MongoDB gestisce il management dei processi e le informazioni di runtime.

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Questo è principalmente a scopo informativo; garantisce che MongoDB abbia accesso ai dati sul fuso orario per la conversione dei timestamp. In implementazioni avanzate, è anche possibile abilitare qui il forking (per l'esecuzione in background) se MongoDB viene avviato manualmente senza systemd.

Le Sezioni replication e sharding (Opzionali)

Non vedrai queste sezioni in un'installazione nuova, ma vengono utilizzate in configurazioni multi-nodo o distribuite.

Esempio per abilitare un set di repliche:

replication:
  replSetName: "rs0"

Questo indica a MongoDB di avviarsi come parte di un set di replica chiamato rs0. Successivamente, inizializzeresti e aggiungeresti membri dall'interno della shell di MongoDB.

Per lo sharding:

sharding:
  clusterRole: "shardsvr"

Questo definisce il ruolo del nodo in un cluster shardato.

La sezione setParameter

Questa sezione facoltativa ti consente di sovrascrivere i parametri di runtime che regolano il comportamento di MongoDB.

Esempio :

setParameter:
  enableLocalhostAuthBypass: false

Impostare questo su false garantisce che anche le connessioni locali richiedano l'autenticazione. Altri parametri possono controllare i timeout delle query, il comportamento del cursore o la registrazione diagnostica.

Fare e applicare modifiche

Ogni volta che modifichi /etc/mongod.conf, devi riavviare MongoDB affinché le modifiche abbiano effetto:

sudo systemctl restart mongod

Quindi verifica che il servizio sia in esecuzione:

sudo systemctl status mongod

Se MongoDB non riesce a riavviarsi, controlla la presenza di errori di sintassi (gli errori di indentazione in YAML sono comuni) o verifica i log:

sudo tail -n 20 /var/log/mongodb/mongod.log

Esempio: Una configurazione sicura e pronta per la produzione

Ecco un esempio di un mongod.conf pulito e orientato alla produzione per Ubuntu 24.04:

# mongod.conf — Example production configuration

storage:
  dbPath: /data/mongodb
  journal:
    enabled: true
  engine: wiredTiger

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.10

security:
  authorization: enabled
  javascriptEnabled: false

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

replication:
  replSetName: "rs0"

setParameter:
  enableLocalhostAuthBypass: false

Questa configurazione:

• Abilita l'autenticazione
• Utilizza WiredTiger (il motore di archiviazione predefinito)
• Si collega solo a interfacce fidate specifiche
• Prepara l'istanza per l'inizializzazione del set di replica
• Registra tutte le operazioni in un file di log dedicato

Proteggere MongoDB

La flessibilità di MongoDB lo rende potente, ma significa anche che una configurazione insicura può facilmente portare all'esposizione dei dati. Nei primi tempi di MongoDB, molti server erano lasciati aperti a Internet senza autenticazione, permettendo agli aggressori di elencare, modificare o persino cancellare database semplicemente collegandosi alla porta 27017.

Oggi, MongoDB viene fornito con impostazioni predefinite più sicure, ma spetta ancora a te far rispettare l'autenticazione, le restrizioni di rete e la crittografia.

Abilitazione dell'autenticazione

Per impostazione predefinita, MongoDB si avvia con l'autenticazione disabilitata. Ciò significa che chiunque possa connettersi al database può eseguire comandi amministrativi, eliminare collezioni o modificare i dati senza restrizioni. Per prevenire questo, MongoDB utilizza un sistema di Controllo degli Accessi Basato sui Ruoli (RBAC) che devi abilitare esplicitamente.

1. Apri il file di configurazione di MongoDB:

   sudo nano /etc/mongod.conf

2. Individua la sezione security o creane una se non esiste:

   security:
     authorization: enabled

3. Salva ed esci (Ctrl+O, poi Ctrl+X).

4. Riavvia MongoDB affinché la modifica abbia effetto:

   sudo systemctl restart mongod

MongoDB fornisce un temporaneo bypass dell'autenticazione in localhost su un'installazione fresca in modo che possa essere creato il primo utente amministrativo. Questo bypass viene disattivato automaticamente una volta che esiste un utente amministratore o se vengono attivate determinate impostazioni di sicurezza (come keyFile o clusterAuthMode).

Ciò significa che puoi creare in sicurezza il tuo primo utente amministratore prima che inizi l'applicazione completa delle regole.

Creazione del primo utente amministrativo

L'utente amministratore è la base del sistema di autenticazione di MongoDB. Ha il permesso di creare altri utenti, definire ruoli e concedere l'accesso a database specifici.

Per creare questo account:

1. Avvia una shell MongoDB locale:

   mongosh

2. Passa al database admin, che memorizza le credenziali degli utenti e le definizioni dei ruoli:

   use admin

3. Crea l'utente con il seguente comando:

   db.createUser({
     user: "admin",
     pwd: "StrongPasswordHere",
     roles: [
       { role: "userAdminAnyDatabase", db: "admin" },
       "readWriteAnyDatabase"
     ]
   })

   Scomponiamolo:

   • userAdminAnyDatabase consente a questo utente di creare, modificare e rimuovere utenti in tutti i database.
   • readWriteAnyDatabase concede permessi di lettura e scrittura a livello globale. (Puoi omettere questo per un utente amministratore più restrittivo, se desideri.)

   Questo comando scrive un nuovo documento nella collezione system.users di MongoDB all'interno del database admin. Puoi verificarlo elencando gli utenti successivamente:

   show users

4. Esci dalla shell:

   exit

5. Riconnettiti come utente admin per confermare che l'autenticazione sia ora attivata:

   mongosh -u admin -p --authenticationDatabase admin

Una volta autenticato, puoi eseguire comandi amministrativi come:

show dbs

Se MongoDB richiede una password e concede l'accesso solo dopo l'autenticazione, RBAC sta funzionando correttamente.

Creazione di utenti basati su ruoli per le applicazioni

In produzione, la tua applicazione non dovrebbe mai utilizzare l'account amministratore. Invece, crea utenti dedicati per ogni applicazione, ognuno con solo i permessi di cui ha bisogno.

Ad esempio, per creare un utente per un'applicazione web che gestisce i dati in un database specifico:

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

• readWrite consente all'applicazione di eseguire tutte le operazioni CRUD standard (inserire, interrogare, aggiornare, eliminare) solo su questo database.
• Non può creare altri utenti, modificare le raccolte di sistema o accedere ad altri database.

Puoi elencare tutti gli utenti di un database con:

show users

Limitare l'accesso alla rete

Anche con l'autenticazione abilitata, è pericoloso esporre MongoDB a Internet aperto. Scanner automatizzati cercano regolarmente porte aperte (in particolare 27017, la porta predefinita di MongoDB) e tentano attacchi a forza bruta o di sfruttare istanze mal configurate.

Per impostazione predefinita, MongoDB ascolta solo su 127.0.0.1, l'interfaccia locale. Se le tue applicazioni e il server MongoDB condividono lo stesso host, non è necessario modificare nulla. Tuttavia, se la tua applicazione si connette da remoto, dovrai aggiungere esplicitamente alla whitelist indirizzi IP specifici.

1. Modifica il file di configurazione:

   sudo nano /etc/mongod.conf

2. Individua la sezione net e aggiornala:

   net:
     port: 27017
     bindIp: 127.0.0.1,192.168.10.50

   Sostituisci 192.168.10.50 con l’indirizzo IP del tuo server applicativo fidato. Questo assicura che MongoDB accetti connessioni solo da localhost e da quell’host remoto specifico.

3. Riavvia il servizio per applicare le modifiche:

   sudo systemctl restart mongod

4. Conferma i collegamenti attivi:

   sudo ss -tulpn | grep mongod

Dovresti vedere MongoDB in ascolto sia su 127.0.0.1:27017 sia sull'IP da te specificato.

Configurazione del firewall di Ubuntu (UFW)

Anche se MongoDB ascolta solo su determinate interfacce, è buona pratica rafforzare la sicurezza della rete a livello del sistema operativo.

UFW di Ubuntu offre un modo semplice per controllare le connessioni in entrata e in uscita.

1. Verifica che UFW sia installato e attivo:

   sudo ufw status

   Se risulta inattivo, attivalo:

   sudo ufw enable

2. Consenti connessioni a MongoDB solo da IP affidabili. Ad esempio, se l’IP del server della tua applicazione è 192.168.10.50:

   sudo ufw allow from 192.168.10.50 to any port 27017

3. Controlla che la regola sia stata aggiunta:

   sudo ufw status numbered

   Dovresti vedere una voce che consente la porta 27017 dalla sorgente specificata.

4. Facoltativamente, nega esplicitamente tutto il traffico verso MongoDB:

   sudo ufw deny 27017/tcp

Questa combinazione, bindIp nella configurazione di MongoDB e regole UFW selettive, garantisce che solo i sistemi conosciuti possano accedere al tuo database, anche se altri processi tentano di esporlo.

Abilitare la crittografia TLS/SSL

Finora, hai garantito che solo utenti e IP affidabili possano accedere a MongoDB. Il passo successivo è proteggere i dati in transito.

Quando un client si connette a MongoDB, tutti i dati (comprese le credenziali di autenticazione e le query) vengono trasmessi come testo normale per impostazione predefinita. TLS cifra questi dati, impedendo intercettazioni o manomissioni.

Genera o Ottieni un Certificato

In produzione, utilizza un certificato di un'Autorità di Certificazione (CA) affidabile. Per test o distribuzioni interne, puoi generare un certificato auto-firmato:

sudo mkdir -p /etc/ssl/mongodb

sudo openssl req -newkey rsa:4096 -new -x509 -days 365 -nodes -out /etc/ssl/mongodb/mongodb.crt -keyout /etc/ssl/mongodb/mongodb.key -subj "/CN=$(hostname)"

Questo crea:

• mongodb.crt: il certificato pubblico
• mongodb.key: la chiave privata

Combinali in un unico file PEM (richiesto da MongoDB):

sudo cat /etc/ssl/mongodb/mongodb.key /etc/ssl/mongodb/mongodb.crt | sudo tee /etc/ssl/mongodb/mongodb.pem

sudo chmod 600 /etc/ssl/mongodb/mongodb.pem

sudo chown mongodb:mongodb /etc/ssl/mongodb/mongodb.pem

Questi permessi garantiscono che solo l'utente mongodb possa accedere al file chiave.

Aggiorna il file di configurazione

Modifica /etc/mongod.conf e individua la sezione net. Aggiungi un nuovo blocco tls al di sotto:

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

• mode: requireTLS significa che MongoDB rifiuterà qualsiasi connessione non crittografata.
• certificateKeyFile specifica il percorso del file PEM combinato.

Riavvia MongoDB per applicare la modifica:

sudo systemctl restart mongod

Connetti utilizzando TLS

Quando ci si connette con mongosh, è ora necessario specificare l'opzione --tls:

mongosh --tls --host 192.168.10.50 -u admin -p --authenticationDatabase admin

Se la connessione riesce e appare il prompt, la tua configurazione TLS funziona correttamente.

Puoi verificare la crittografia esaminando la connessione con OpenSSL:

openssl s_client -connect 192.168.10.50:27017

L'output dovrebbe mostrare la catena dei certificati e i dettagli della crittografia, per esempio:

SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

Questo conferma che il tuo server MongoDB sta ora cifrando il traffico end-to-end.

Verifica del tuo assetto di sicurezza

Una volta configurato tutto, vale la pena ricontrollare la tua impostazione.

1. Verifica che MongoDB sia collegato solo agli IP consentiti:

   sudo ss -tulpn | grep mongod

   Dovresti vedere le connessioni limitate a 127.0.0.1 e solo ai tuoi IP di fiducia.

2. Assicurati che l'autenticazione sia obbligatoria. Prova a connetterti senza credenziali:

   mongosh

   Dovresti ricevere un errore di autenticazione.

3. Verifica che TLS sia richiesto. Prova a connetterti senza --tls:

   mongosh --host 192.168.10.50 -u admin -p --authenticationDatabase admin

   Se la connessione fallisce con un messaggio riguardante i requisiti TLS, la tua crittografia è correttamente applicata.

4. Esamina i parametri di sicurezza interni di MongoDB:

   mongosh -u admin -p --authenticationDatabase admin --eval "db.runCommand({ getParameter: 1, tlsMode: 1 })"

   Se tlsMode restituisce "requireTLS", la crittografia è confermata attiva.

Con l'autenticazione, il controllo degli accessi, le restrizioni di rete e TLS configurati, la tua istanza MongoDB è ora protetta contro i vettori di attacco più comuni.

Migliori Pratiche Operative

Una volta che MongoDB è installato e sicuro, la prossima grande priorità è mantenerlo efficacemente. Anche il database più accuratamente configurato può diventare inaffidabile senza una manutenzione regolare. Operazioni di routine come backup, monitoraggio e aggiornamenti di sistema garantiscono che MongoDB rimanga performante, stabile e recuperabile nel tempo.

Eseguire il backup dei dati di MongoDB

Una strategia di backup ben pianificata è fondamentale per qualsiasi database di produzione. I backup consentono di recuperare rapidamente da guasti hardware, bug del software o cancellazioni accidentali. MongoDB supporta sia i backup logici sia quelli fisici, ciascuno adatto a diversi scenari.

Backup logici con mongodump

Un backup logico cattura il contenuto del database in formato BSON utilizzando l'utility mongodump. Questo approccio è portatile, leggibile dall'uomo e facile da automatizzare.

Per creare un backup completo di tutti i database, esegui:

mongodump --out /backups/mongodb/$(date +%F)

Questo comando crea una directory denominata con la data corrente sotto /backups/mongodb/ e vi memorizza tutti i dump BSON.

Se l'autenticazione è abilitata, usa una stringa di connessione URI che includa le credenziali:

mongodump --uri="mongodb://admin:YourPassword@localhost:27017/admin" --out /backups/mongodb/$(date +%F)

Puoi anche eseguire il backup di un database specifico:

mongodump --db=myappdb --out /backups/mongodb/$(date +%F)

Per ripristinare da un backup logico, usa mongorestore:

mongorestore /backups/mongodb/2026-01-05/

O ripristina un singolo database:

mongorestore --db=myappdb /backups/mongodb/2026-01-05/myappdb

I backup logici sono flessibili e facili da automatizzare, ma possono richiedere più tempo per completarsi su dataset molto grandi.

Backup fisici (istantanee del file system)

I backup fisici catturano i file del database direttamente dal volume di archiviazione. Questo metodo è più veloce e più efficiente in termini di spazio per database di grandi dimensioni, ma richiede snapshot coerenti per evitare corruzioni.

Se usi il journaling (che è abilitato di default), puoi eseguire snapshot del volume mentre MongoDB è in esecuzione. WiredTiger supporta snapshot coerenti in caso di crash mentre MongoDB è in esecuzione, purché il journaling sia abilitato. Per snapshot completamente coerenti con l'applicazione, è consigliato ma non necessario fermare MongoDB:

sudo systemctl stop mongod

Esegui uno snapshot utilizzando il tuo provider cloud o il sistema di archiviazione e riavvia il servizio:

sudo systemctl start mongod

Archivia gli snapshot in un sito remoto o in una regione separata ogni volta che è possibile. Questo protegge dagli arresti dei centri dati o dalle cancellazioni locali accidentali.

Monitoraggio della salute di MongoDB

Il monitoraggio è fondamentale per prevenire problemi prima che impattino gli utenti. MongoDB offre strumenti da riga di comando integrati, oltre al supporto per sistemi di monitoraggio esterni.

Utilizzo degli strumenti integrati

Lo strumento mongostat mostra le metriche del database in tempo reale, come le operazioni al secondo, l'utilizzo della memoria e le connessioni attive. Eseguilo come segue:

mongostat --uri "mongodb://admin@localhost:27017/?authSource=admin"

Questo produce una tabella in tempo reale che mostra inserimenti, interrogazioni, aggiornamenti ed eliminazioni. Ogni colonna rappresenta un indicatore chiave di performance, come il rapporto tra pagine di memoria sporche o il numero di connessioni attive.

L'utilità mongotop si concentra su quanto tempo MongoDB impiega per leggere e scrivere per ogni raccolta. Per eseguirla ogni due secondi, utilizza:

mongotop 2

Questo è utile per identificare le raccolte che subiscono un intenso I/O.

Utilizzo di strumenti di monitoraggio esterni

Per una visibilità e un allerta persistenti, puoi integrare MongoDB con sistemi esterni come:

• Monitoraggio di MongoDB Atlas, anche per cluster auto-ospitati.
• Prometheus e Grafana, utilizzando il MongoDB Exporter per dashboard a serie temporali.
• Percona Monitoring and Management (PMM), una completa suite di monitoraggio open-source.
• Strumenti generali di sistema come Netdata, Zabbix o Datadog.

Le metriche importanti da monitorare includono:

• Utilizzo della memoria e tasso di successo della cache
• Latenza e throughput I/O del disco
• Conteggio delle connessioni e lunghezza della coda
• Latenza delle operazioni (tempi di inserimento, aggiornamento, interrogazione)
• Ritardo replica (se si utilizza un set di repliche)

Gestione dello spazio su disco e della crescita dello storage

I database MongoDB si espandono dinamicamente man mano che crescono documenti e indici. Se l'utilizzo del disco non viene controllato, il database potrebbe esaurire lo spazio, causando blocchi o arresti improvvisi.

Verifica dell'utilizzo del disco

Controlla l'uso corrente del filesystem con:

df -h /var/lib/mongodb

Questo mostra lo spazio disponibile e utilizzato per la directory dei dati di MongoDB.

Puoi anche controllare l'utilizzo della memoria e della cache direttamente tramite MongoDB:

mongosh --eval "db.serverStatus().wiredTiger.cache"

Il valore bytes currently in the cache indica quanta RAM sta utilizzando il motore di archiviazione WiredTiger.

Impostazione degli avvisi sull'utilizzo del disco

Per rimanere proattivi, imposta avvisi o controlli di monitoraggio che ti notifichino quando l'utilizzo del disco supera l'85%. Ad esempio, un semplice script potrebbe essere programmato per essere eseguito periodicamente:

df -h | awk '$5 > 85 {print $0}'

Puoi integrare questo nei timer di systemd o negli strumenti di monitoraggio per l'automazione.

Gestione dei vecchi dati e dei registri

Collezioni e file di log grandi o inutilizzati possono consumare spazio significativo nel tempo. Per gestire i log, configura la rotazione in /etc/logrotate.d/mongodb (come mostrato più avanti in questa sezione) o pulisci manualmente:

sudo journalctl --vacuum-time=7d

sudo rm -f /var/log/mongodb/*.gz

Per i dati delle applicazioni, considera di utilizzare gli indici TTL (time-to-live) per le raccolte che memorizzano dati temporanei o sensibili al tempo:

db.sessionLogs.createIndex({ "createdAt": 1 }, { expireAfterSeconds: 604800 })

Questo elimina automaticamente i documenti più vecchi di sette giorni.

Eseguire aggiornamenti sicuri

Aggiornare MongoDB richiede una pianificazione accurata, specialmente quando si passa tra versioni principali. Il seguente processo minimizza i tempi di inattività e garantisce la compatibilità.

Controlla la versione attuale

Conferma la versione installata:

mongod --version

Esegui il backup prima dell'aggiornamento

Crea sempre un backup completo prima dell'aggiornamento:

mongodump --out /backups/mongodb/pre-upgrade-$(date +%F)

Aggiorna il repository dei pacchetti e aggiorna

Se in precedenza hai bloccato i pacchetti di MongoDB per impedire aggiornamenti automatici, rimuovi i blocchi:

echo "mongodb-org install" | sudo dpkg --set-selections

Quindi aggiorna la lista dei pacchetti e aggiorna MongoDB:

sudo apt update

sudo apt install -y mongodb-org

MongoDB conserva i tuoi file di configurazione e dati durante gli aggiornamenti, ma un backup garantisce che tu possa tornare indietro se qualcosa va storto.

Convalida l'aggiornamento

Dopo l'aggiornamento:

1. Verifica lo stato del servizio:

   sudo systemctl status mongod

2. Controlla i registri recenti per avvisi o note sulla migrazione:

   sudo tail -n 30 /var/log/mongodb/mongod.log

3. Conferma la nuova versione:

   mongosh --eval "db.version()"

Automatizzare la Manutenzione Ordinaria

La manutenzione manuale funziona per ambienti piccoli, ma l'automazione garantisce coerenza. Puoi programmare backup ricorrenti, rotazioni dei log o controlli di monitoraggio utilizzando cron o systemd timers.

Pianifica backup automatici

Modifica il crontab di root:

sudo crontab -e

Aggiungi la seguente riga per eseguire il backup della tua istanza di MongoDB ogni notte alle 2:00:

0 2 * * * mongodump --out /backups/mongodb/$(date +\%F)

Questo crea una cartella di backup con data ogni giorno.

Configura la rotazione dei log

Per evitare che i file di log occupino spazio su disco, crea un file di configurazione per la rotazione dei log:

sudo nano /etc/logrotate.d/mongodb

Aggiungi il seguente contenuto:

/var/log/mongodb/mongod.log {
    weekly
    rotate 5
    compress
    delaycompress
    missingok
    notifempty
    create 640 mongodb adm
    postrotate
        systemctl reload mongod > /dev/null 2>&1 || true
    endscript
}

Questa configurazione conserva cinque settimane di log, comprime i file più vecchi e ricarica MongoDB dopo la rotazione.

Mantenere l'orologio di sistema accurato

Le funzionalità di journaling e replica di MongoDB si basano su timestamp accurati. Se l'orologio di sistema perde precisione, potrebbero verificarsi ritardi nella replica o corruzione del journal dopo un crash.

Ubuntu 24.04 utilizza systemd-timesyncd per impostazione predefinita, ma puoi anche usare chrony per una sincronizzazione dell'orologio più precisa:

sudo apt install chrony -y

sudo systemctl enable --now chrony

Puoi verificare la sincronizzazione con:

timedatectl status

Se NTP synchronized mostra yes, l'orologio del sistema è sincronizzato.

Controllo della salute di MongoDB in tempo reale

MongoDB fornisce il comando serverStatus per una diagnostica completa in tempo reale. Puoi interrogarlo direttamente dalla shell:

mongosh --eval "db.serverStatus()"

Questo restituisce un oggetto JSON dettagliato contenente metriche come:

• Consumo di memoria
• Utilizzo della cache
• Numero di connessioni
• Attraversamento operativo
• Stato della replicazione

Puoi estrarre campi specifici per controlli mirati. Ad esempio, per visualizzare le statistiche di connessione:

mongosh --eval "db.serverStatus().connections"

Questo consente di ottenere rapidamente informazioni sul fatto che il sistema stia riscontrando saturazione della connessione o vincoli di risorse.

Prepararsi per l'alta disponibilità

Le implementazioni di MongoDB su un singolo nodo funzionano bene per lo sviluppo o per applicazioni a bassa criticità. Per gli ambienti di produzione, dovresti implementare i replica set. I replica set offrono ridondanza e failover automatico, garantendo la disponibilità anche se un nodo dovesse guastarsi.

In una configurazione tipica:

• Un nodo agisce come il principale, gestendo tutte le scritture e la maggior parte delle letture.
• Uno o più nodi secondari replicano i dati in tempo reale.
• Se il nodo primario va offline, uno dei nodi secondari diventa automaticamente il nuovo primario.

I set di repliche semplificano anche le operazioni di manutenzione come backup e scalabilità. È possibile delegare i backup o le query analitiche ai nodi secondari senza influire sulle prestazioni del nodo primario.

La tua istanza di MongoDB è ora completamente operativa e correttamente mantenuta.

Scalabilità e Ottimizzazione delle Prestazioni

MongoDB è progettato per scalare orizzontalmente, il che significa che puoi aumentare la capacità e le prestazioni aggiungendo più server piuttosto che fare affidamento esclusivamente su una singola macchina più potente. Man mano che il tuo dataset cresce o la tua applicazione inizia a gestire più query contemporanee, la scalabilità garantisce che MongoDB continui a funzionare in modo affidabile ed efficiente.

Ci sono due modi principali per scalare MongoDB:

1. Replica set, che aumentano l'affidabilità e le prestazioni di lettura attraverso la ridondanza.
2. Sharding, che distribuisce i dati su più server per gestire insiemi di dati più grandi e carichi di scrittura.

Comprendere i Replica Set

Un replica set è un gruppo di server MongoDB che mantengono copie identiche dei tuoi dati. I replica set garantiscono un'alta disponibilità e proteggono da guasti hardware o di rete. Se il nodo primario si guasta, uno dei nodi secondari subentra automaticamente, garantendo un tempo di inattività minimo.

Un set di repliche standard consiste in:

• Un nodo primario che gestisce tutte le operazioni di scrittura.
• Due o più nodi secondari che replicano i dati dal nodo primario.
• Nodi arbitri opzionali che partecipano alle elezioni ma non memorizzano dati.

Per i sistemi di produzione, MongoDB raccomanda almeno tre membri in un set di repliche.

Configurazione di un Replica Set

Per creare un set di repliche, sono necessari almeno due o tre server (fisici o virtuali). Ogni nodo dovrebbe avere MongoDB installato e configurato.

1. Su ogni nodo, apri il file di configurazione /etc/mongod.conf e aggiungi la sezione di replica:

   replication:
     replSetName: "rs0"

2. Riavvia MongoDB su ogni server:

   sudo systemctl restart mongod

3. Sulla nodo primario, connettiti a MongoDB e inizializza il set di repliche:

   mongosh

   Poi esegui:

   rs.initiate({
     _id: "rs0",
     members: [
       { _id: 0, host: "mongodb1.example.com:27017" },
       { _id: 1, host: "mongodb2.example.com:27017" },
       { _id: 2, host: "mongodb3.example.com:27017" }
     ]
   })

4. Verifica lo stato:

   rs.status()

   L'output dovrebbe mostrare un primario e due secondari con il loro stato etichettato come «PRIMARY» e «SECONDARY».

Vantaggi dei Replica Set

I set di repliche offrono diversi vantaggi importanti:

• Alta disponibilità: Il failover automatico garantisce il funzionamento continuo se il nodo primario va offline.
• Ridondanza dei dati: Ogni nodo mantiene una copia completa dei dati.
• Scalabilità in lettura: I nodi secondari possono gestire le operazioni di lettura, riducendo il carico sul nodo primario.
• Flessibilità nella manutenzione: È possibile eseguire backup o aggiornamenti di sistema sui nodi secondari senza influire sulla disponibilità.

Comprendere lo Sharding

Lo sharding è la strategia di MongoDB per la scalabilità orizzontale. Quando un dataset diventa troppo grande per essere memorizzato o elaborato efficacemente da un singolo server, MongoDB può suddividerlo in parti più piccole distribuite su più server chiamati shard.

Ogni frammento contiene un sottoinsieme dei dati e il cluster si comporta collettivamente come un unico database logico.

Componenti di un cluster sharded

Un tipico cluster sharded di MongoDB include:

• Shards: I nodi che contengono i dati, spesso distribuiti come set di repliche per la ridondanza.
• Server di configurazione: Memorizzano i metadati e la configurazione del cluster, inclusa la distribuzione dei chunk.
• Router Mongos: Instrada le query dei client allo shard corretto in base alla chiave di sharding.

Scegliere una chiave di shard

La chiave di shard determina come MongoDB distribuisce i dati tra gli shard. Una chiave di shard scelta male può portare a una distribuzione dei dati non uniforme (nota come data skew) o a punti caldi.

Le buone chiavi di shard solitamente hanno:

• Alta cardinalità (molti valori unici).
• Anche i modelli di accesso ai dati.
• Un modello di query prevedibile che include la chiave di shard nella maggior parte delle query.

Esempio di abilitazione dello sharding per un database:

sh.enableSharding("salesdb")
sh.shardCollection("salesdb.orders", { "customer_id": 1 })

Questo comando abilita lo sharding sul database salesdb e sharda la collezione orders utilizzando il campo customer_id.

Quando usare lo sharding

Dovresti considerare lo sharding quando:

• Il database si avvicina o supera i limiti della capacità di archiviazione di un singolo server.
• La velocità di scrittura sta costantemente saturando la CPU o l'I/O del disco.
• Il set di lavoro non entra più nella RAM, causando frequenti scambi di pagina.
• Ti aspetti una crescita esponenziale nel tuo set di dati.

Lo sharding aggiunge complessità architettonica, quindi è meglio introdurlo solo quando necessario.

Ottimizzare WiredTiger per le prestazioni

MongoDB utilizza il motore di archiviazione WiredTiger per impostazione predefinita. È ottimizzato per l'hardware moderno e utilizza compressione, caching e I/O multi-thread. Comprendere come WiredTiger gestisce la memoria e l'I/O su disco aiuta a migliorare le prestazioni.

Utilizzo della memoria

WiredTiger utilizza in genere circa il 50% della RAM disponibile per la sua cache, con MongoDB che regola dinamicamente questo valore in base alla memoria del sistema.

Puoi regolare questo nel file di configurazione:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

Questo è utile se il tuo sistema esegue altri servizi ad alto utilizzo di memoria insieme a MongoDB. Per i server dedicati a MongoDB, di solito è meglio lasciare l'impostazione predefinita della cache.

Puoi visualizzare l'utilizzo attuale della cache eseguendo:

mongosh --eval "db.serverStatus().wiredTiger.cache"

Compressione

WiredTiger supporta la compressione di dati e indici per ridurre l'uso del disco. Per impostazione predefinita, utilizza la compressione Snappy, che bilancia prestazioni ed efficienza dello spazio. È possibile passare a zlib (per una migliore compressione) o a zstd (per configurazioni più recenti) se si dà priorità al risparmio di spazio sul disco rispetto alla velocità.

Esempio di configurazione:

storage:
  wiredTiger:
    collectionConfig:
      blockCompressor: zstd

Scrittura del diario e durata

La registrazione garantisce che le operazioni di scrittura siano durature, anche in caso di interruzione di corrente. Puoi regolare il parametro commitIntervalMs per controllare la frequenza delle scritture nel journal:

storage:
  journal:
    commitIntervalMs: 100

Intervalli più bassi migliorano la durata, ma possono ridurre leggermente le prestazioni di scrittura.

Trigger di Monitoraggio e Scala

È importante riconoscere quando scalare la propria distribuzione di MongoDB. Monitorare metriche come il carico della CPU, l'utilizzo della memoria e i tempi di attesa I/O aiuterà a determinare quando è il momento di aggiungere maggiore capacità.

Fattori Comuni che Scatenano la Scala

• Utilizzo della CPU costantemente superiore all'80%.
• La latenza I/O del disco supera le soglie accettabili (ad esempio, più di 10 ms).
• Utilizzo della RAM vicino al massimo per periodi prolungati.
• Crescita rapida della dimensione del set di lavoro.
• Aumento del ritardo di replica tra i nodi.

Quando compaiono questi indicatori, considera di aggiungere più secondari (per le letture) o shard (per carichi pesanti di scrittura).

Scalabilità verticale vs. orizzontale

Scalabilità verticale consiste nell'aggiungere più risorse (CPU, RAM, dischi più veloci) ai server esistenti. È più semplice da gestire ma limitata dalla capacità dell'hardware.

Scalabilità orizzontale implica l'aggiunta di nuovi server per distribuire il carico di lavoro. Questo è il punto forte di MongoDB, in quanto scala quasi linearmente se progettato correttamente.

Migrazione a MongoDB gestito

Man mano che il tuo sistema cresce, gestire un cluster self-hosted può diventare complesso. A questo punto, migrare a un servizio MongoDB gestito, come MongoDB Atlas, può ridurre significativamente il carico operativo.

Le piattaforme gestite si occupano di backup automatici, patching, monitoraggio, scalabilità e crittografia. Tuttavia, possono comportare costi aggiuntivi e una flessibilità leggermente inferiore rispetto alle configurazioni autogestite.

<$> Raccomandazione: Rimanete autonomi fino a quando il vostro team non affronta problemi operativi costanti come colli di bottiglia delle prestazioni, complessità nella gestione del cluster o requisiti di conformità che le piattaforme gestite affrontano in modo più efficiente. <$>

Confronto: MongoDB Autogestito vs Gestito

MongoDB può essere distribuito in due modi principali:

1. Autogestito, dove installi, configuri e gestisci il database da solo (come spiegato in questa guida).
2. Gestito, dove un fornitore terzo ospita e gestisce MongoDB per te come servizio.

Ogni approccio ha vantaggi e compromessi distinti. La scelta giusta dipende dalla tua competenza tecnica, dalle caratteristiche del carico di lavoro, dalle esigenze di conformità e dalle priorità operative.

Esaminiamo queste due opzioni in profondità.

MongoDB auto-ospitato

Quando ospiti MongoDB autonomamente, lo installi direttamente sulla tua infrastruttura, che si tratti di un server fisico, di una macchina virtuale o di un'istanza cloud come un Droplet di Linux-Console.net. Controlli ogni aspetto dell'ambiente, dall'installazione agli aggiornamenti e al monitoraggio.

Vantaggi del self-hosting

1. Controllo e Flessibilità Totali: Hai piena autorità sulle impostazioni di configurazione, sui sistemi di file, sulla rete e sull’ottimizzazione delle prestazioni. Puoi modificare il file mongod.conf, scegliere i percorsi di archiviazione e applicare politiche di sicurezza o di backup personalizzate che si adattino agli standard della tua organizzazione.
2. Efficienza dei costi per piccole implementazioni: Per carichi di lavoro piccoli o medi, l'auto-ospitazione può essere più economica rispetto all'utilizzo di un servizio gestito. Paghi solo per le risorse di calcolo e di archiviazione sottostanti, anziché per un ulteriore livello di gestione.
3. Policy di Sicurezza Personalizzate: È possibile integrare MongoDB con VPN interne, firewall o reti private, garantendo la piena conformità ai requisiti di sicurezza locali o specifici del settore. Alcune organizzazioni richiedono l'installazione on-premises a causa della residenza dei dati o di vincoli normativi, rendendo l'hosting autonomo l'unica opzione praticabile.
4. Ottimizzazione delle prestazioni: Poiché controlli l'hardware, puoi perfezionare i parametri del sistema come i scheduler I/O, le dimensioni della cache e gli algoritmi di compressione. Puoi anche collocare MongoDB insieme ai servizi correlati per minimizzare la latenza di rete.

Sfide dell'auto-ospitazione

• Sovraccarico Operativo: Sei responsabile della gestione di tutto; dall'installazione di aggiornamenti e patch alla gestione dei guasti e dell'ottimizzazione delle prestazioni. Questo richiede personale dedicato con competenze nell'amministrazione di database e nella gestione dei sistemi Linux.
• Complessità di Scalabilità: Scalare un cluster MongoDB auto-ospitato significa provisionare nuovi server, riequilibrare i dati, aggiornare le configurazioni e mantenere manualmente le topologie di replica o sharding. Queste attività possono essere soggette a errori senza automazione.
• Backup e Ripristino di Emergenza: Devi progettare, testare e mantenere i tuoi processi di backup, ripristino e archiviazione offsite. Sebbene gli strumenti di MongoDB (mongodump, mongorestore e snapshot dei volumi) lo rendano possibile, richiede una pianificazione operativa rigorosa.
• Monitoraggio e Avvisi: MongoDB self-hosted richiede di configurare sistemi di monitoraggio e avvisi utilizzando strumenti come Prometheus, Grafana o Percona PMM. Senza una visibilità continua, guasti o colli di bottiglia nelle prestazioni potrebbero passare inosservati fino a causare tempi di inattività.

In sintesi, MongoDB auto-ospitato offre flessibilità, indipendenza e costi inferiori su piccola scala, ma richiede un impegno significativo per la manutenzione continua.

Servizi MongoDB Gestiti

Un servizio MongoDB gestito ospita il database per tuo conto, gestendo automaticamente tutta l'infrastruttura, gli aggiornamenti, la scalabilità e le patch di sicurezza. Questi servizi eliminano gran parte del carico amministrativo pur offrendo alta disponibilità e scalabilità globale.

Vantaggi di MongoDB gestito

1. Sforzo Operativo Minimo: Il fornitore del servizio gestisce automaticamente il provisioning del database, i backup, gli aggiornamenti e il failover. Puoi distribuire nuovi cluster con pochi clic o chiamate API, riducendo significativamente il carico amministrativo.
2. Scaling Automatico: I servizi gestiti possono regolare dinamicamente le risorse di calcolo e archiviazione man mano che il tuo set di dati cresce. Ad esempio, MongoDB Atlas supporta lo sharding automatico e lo scaling verticale senza tempi di inattività.
3. Monitoraggio e Avvisi Integrati: Le piattaforme gestite includono dashboard per l'utilizzo della CPU, le prestazioni del disco, le statistiche di connessione e la latenza delle query. È possibile impostare soglie di avviso per i parametri critici senza dover utilizzare strumenti di monitoraggio separati.
4. Alta disponibilità di default: La maggior parte dei servizi gestiti distribuisce cluster con tre o più nodi replica set in diverse zone di disponibilità. Questo garantisce failover automatico e alta continuità operativa con una configurazione minima.
5. Sicurezza e Conformità: Le piattaforme MongoDB gestite offrono crittografia integrata, accesso basato sui ruoli, isolamento della rete (VPC peering) e integrazione con provider di identità. Sono inoltre certificate secondo standard come SOC 2, GDPR, HIPAA e ISO 27001, semplificando così le verifiche di conformità.
6. Distribuzione Globale: MongoDB Atlas e servizi simili supportano cluster multi-regione. I dati possono essere replicati geograficamente vicino ai tuoi utenti, migliorando la latenza per applicazioni distribuite.

Limitazioni dei Servizi Gestiti

1. Costo Maggiore su Larga Scala: I servizi gestiti applicano un costo aggiuntivo per l'automazione e la comodità. Con l'aumento del volume dei dati e del traffico, i costi mensili possono superare le spese per eseguire istanze self-hosted, soprattutto per grandi set di dati archiviati su SSD.
2. Personalizzazione Limitata: Gli ambienti gestiti limitano l'accesso alle opzioni di configurazione a basso livello. Non è possibile modificare le impostazioni a livello di filesystem, la configurazione della cache o i parametri del sistema operativo sottostante.
3. Blocco del fornitore: Ogni fornitore ha API e configurazioni di distribuzione uniche, rendendo difficile migrare tra i servizi in seguito.
4. Dipendenza dalla Rete: I database gestiti si basano sulla connettività di rete esterna. Se la tua applicazione viene eseguita in un ambiente locale, la connessione sicura a un servizio gestito può introdurre latenza o dipendenza dai tunnel VPN.

In sintesi, i servizi gestiti di MongoDB riducono drasticamente il carico amministrativo e migliorano l'affidabilità, ma a costo di minore flessibilità e spese ricorrenti più elevate.

Tabella di confronto delle caratteristiche

Scegliere il modello di distribuzione giusto

La decisione tra MongoDB self-hosted e gestito dipende principalmente dalle priorità, risorse e vincoli della tua organizzazione. Considera i seguenti scenari:

• Scegli MongoDB self-hosted se:

  • Hai bisogno del pieno controllo sull'infrastruttura e sui dati.
  • Il tuo carico di lavoro è moderato e prevedibile.
  • Hai competenze interne nell'amministrazione di Linux e MongoDB.
  • Le leggi sulla conformità o sulla residenza dei dati richiedono l'archiviazione locale.

• Scegli MongoDB gestito se:

  • Preferisci concentrarti sullo sviluppo di applicazioni piuttosto che sull'infrastruttura.
  • Hai bisogno di scalabilità automatica e alta disponibilità con una configurazione minima.
  • Al tuo team mancano amministratori di database dedicati.
  • Hai bisogno di cluster distribuiti a livello globale o di certificazioni di conformità (SOC 2, HIPAA, GDPR).

Risoluzione dei problemi e manutenzione

Anche con la configurazione e il monitoraggio più attenti, possono sorgere problemi in un'installazione di MongoDB. Questi possono includere prestazioni lente, avvii falliti, ritardi nella replica o esaurimento dello spazio su disco. La chiave per mantenere un ambiente MongoDB stabile è avere un approccio strutturato alla diagnosi dei problemi e all'applicazione di routine di manutenzione preventiva.

Verifica dello stato del servizio MongoDB

Il primo passo nella risoluzione dei problemi di MongoDB è verificare se il servizio del database funziona correttamente.

Puoi controllare lo stato attuale con il seguente comando:

sudo systemctl status mongod

Se MongoDB è in esecuzione, dovresti vedere un output che include:

Active: active (running)

Main PID: 3564 (mongod)

Se il servizio è inattivo, fallito o morto, riavvialo:

sudo systemctl restart mongod

Dopo il riavvio, controlla di nuovo il suo stato. Se fallisce immediatamente, procedi a controllare il file di log per errori specifici.

Revisione dei log di MongoDB

I log sono la fonte più diretta di informazioni diagnostiche. MongoDB registra tutti gli eventi principali, gli avvertimenti e gli errori nel suo file di log principale, situato in:

/var/log/mongodb/mongod.log

Per visualizzare le voci più recenti, esegui:

sudo tail -n 30 /var/log/mongodb/mongod.log

Se MongoDB non riesce ad avviarsi, di solito vedrai uno dei seguenti errori:

• Permesso negato: Proprietà o permessi errati su /var/lib/mongodb o /var/log/mongodb. Controlla i permessi e correggili:

  sudo chown -R mongodb:mongodb /var/lib/mongodb /var/log/mongodb

• Directory dei dati non trovata: Assicurati che /var/lib/mongodb esista e corrisponda al percorso definito in /etc/mongod.conf.

• Indirizzo già in uso: Un altro processo sta utilizzando la porta 27017. Identificalo con:

  sudo lsof -i :27017

  e interrompere o riconfigurare il servizio in conflitto.

• File di dati corrotti: Questo può accadere se MongoDB è stato chiuso bruscamente. In tali casi, il journal dovrebbe recuperare automaticamente i dati al riavvio. Se ciò non avviene, potrebbe essere necessario ripristinare da un backup.

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

Diagnosticare problemi di connessione

I problemi di connessione sono un altro inconveniente frequente. Quando i client non riescono a raggiungere MongoDB, di solito si tratta di un problema di rete, di autenticazione o di configurazione.

Verificare che MongoDB stia ascoltando sulle interfacce corrette

Esegui :

sudo ss -tulpn | grep mongod

L'output dovrebbe mostrare MongoDB collegato a 127.0.0.1 (per connessioni locali) e a qualsiasi IP esterno configurato. Se MongoDB non ascolta sull'IP previsto, verifica il campo bindIp in /etc/mongod.conf:

net:
  bindIp: 127.0.0.1,192.168.10.50

Riavvia MongoDB dopo aver modificato:

sudo systemctl restart mongod

Verifica le regole del firewall

Se le connessioni remote falliscono, verifica che il tuo firewall permetta il traffico sulla porta 27017:

sudo ufw status

In caso contrario, consenti connessioni da IP specifici:

sudo ufw allow from 192.168.10.50 to any port 27017

Testare la connettività con Telnet o Ping

Dal sistema client, verifica se la porta è raggiungibile:

telnet mongodb-server-ip 27017

o

nc -vz mongodb-server-ip 27017

Se la connessione riesce, il problema è probabilmente legato all'autenticazione o ai privilegi dell'utente.

Risoluzione dei problemi di autenticazione

I problemi di autenticazione si verificano spesso dopo aver attivato il controllo degli accessi o modificato le credenziali utente.

Conferma che l'autenticazione è abilitata

Connettiti localmente e verifica:

mongosh --eval "db.runCommand({ getParameter: 1, authenticationMechanisms: 1 })"

Se l'output include "SCRAM-SHA-256", l'autenticazione è attiva.

Verifica le credenziali di accesso

Prova a connetterti usando l'account admin:

mongosh -u admin -p --authenticationDatabase admin

Se ciò fallisce, connettiti localmente senza autenticazione (possibile solo dal localhost quando non esistono utenti) e ricrea l'account amministratore:

use admin

db.createUser({
  user: "admin",
  pwd: "NewStrongPassword",
  roles: ["userAdminAnyDatabase", "readWriteAnyDatabase"]
})

Verifica il contesto del database

Ogni utente MongoDB è definito all'interno di un database specifico. Se ti autentichi con il database sbagliato, l'autenticazione fallirà. Ad esempio, se l'utente è stato creato nel database admin, devi autenticarti esplicitamente contro di esso:

mongosh -u admin -p --authenticationDatabase admin

Risoluzione dei problemi di prestazioni

Il degrado delle prestazioni può derivare da un elevato utilizzo della memoria, lentezza delle operazioni di I/O su disco, query non ottimizzate o connessioni concorrenti eccessive. MongoDB include diversi strumenti diagnostici per identificare questi problemi.

Controlla l'utilizzo delle risorse

Usa i comandi Linux per controllare i parametri a livello di sistema:

top

vmstat 2

iostat -x 2

Controlla l'elevato utilizzo della CPU da parte di mongod o una latenza del disco superiore a 10 millisecondi.

Monitorare le operazioni del database

Esegui :

mongostat 2

Questo mostra metriche in tempo reale, inclusi inserimenti, query, aggiornamenti ed eliminazioni al secondo.

Se alcune operazioni sembrano lente, utilizza il profiler di MongoDB per identificare le query che impiegano più tempo.

Abilita il profiling delle query

Puoi abilitare temporaneamente il profiler per registrare le query lente:

use myappdb

db.setProfilingLevel(1, { slowms: 100 })

Questa registra qualsiasi query che impiega più di 100 millisecondi.

Revisiona i risultati:

db.system.profile.find().sort({ ts: -1 }).limit(5).pretty()

Analizzare l'efficienza dell'indice

Le query inefficienti spesso derivano da indici mancanti. Per vedere se MongoDB sta utilizzando correttamente gli indici, anteponi explain() alla tua query:

db.orders.find({ customer_id: 12345 }).explain("executionStats")

Se executionStages.stage mostra "COLLSCAN", MongoDB sta effettuando una scansione completa della raccolta. Puoi creare un indice per migliorare le prestazioni:

db.orders.createIndex({ customer_id: 1 })

Riparazione di database corrotti

La corruzione dei dati è rara, ma può verificarsi a causa di interruzioni di corrente o errori del disco. Se MongoDB si rifiuta di avviarsi e i log mostrano corruzione nei file di WiredTiger, segui questi passaggi:

1. Ferma MongoDB:

   sudo systemctl stop mongod

2. Eseguire il backup della directory dei dati corrente:

   sudo cp -r /var/lib/mongodb /var/lib/mongodb-corrupt-backup

3. Prova un'operazione di riparazione:

   sudo -u mongodb mongod --repair --config /etc/mongod.conf

4. Riavvia MongoDB:

   sudo systemctl start mongod

Se la riparazione fallisce, ripristina i dati dal tuo backup più recente.

Compiti di manutenzione di routine

La manutenzione preventiva riduce notevolmente il rischio di guasti imprevisti.

Ruota i registri regolarmente

Assicurati che la tua politica di rotazione dei log sia attiva. MongoDB supporta sia la rotazione interna dei log (logRotate) sia la rotazione esterna tramite logrotate quando logAppend è abilitato. Puoi avviarla manualmente se i log crescono rapidamente:

sudo logrotate -f /etc/logrotate.d/mongodb

Collezioni compatte

Le collezioni possono diventare frammentate dopo molti inserimenti e cancellazioni. compact può recuperare spazio, ma è un'operazione bloccante e dovrebbe essere usata raramente in produzione. WiredTiger gestisce automaticamente la maggior parte della frammentazione, quindi la compattazione di solito non è necessaria.

Nota che questa operazione blocca il database, quindi eseguila durante i periodi di bassa attività.

Convalida collezioni

Eseguire controlli periodici sull'integrità dei dati:

db.runCommand({ validate: "collection_name" })

Questo verifica che gli indici e i documenti siano coerenti.

Monitora l'utilizzo di disco e memoria

Usa avvisi automatici per segnalare quando l'utilizzo del disco supera l'85% o l'utilizzo della memoria diventa critico. Strumenti di monitoraggio come Prometheus, Percona PMM o MongoDB Atlas Monitor possono tracciare queste metriche nel tempo.

Applicare gli aggiornamenti di sistema in sicurezza

Quando si aggiorna MongoDB o il sistema Ubuntu sottostante, seguire sempre un processo strutturato:

1. Fai prima il backup dei tuoi dati.

2. Interrompere il servizio MongoDB prima degli aggiornamenti del kernel o delle librerie:

   sudo systemctl stop mongod

3. Applica aggiornamenti:

   sudo apt update && sudo apt upgrade -y

4. Riavvia il servizio e conferma che funzioni correttamente:

   sudo systemctl start mongod
   
   sudo systemctl status mongod

Strumenti per la manutenzione proattiva

Diversi strumenti semplificano la manutenzione continua e i controlli di salute:

• MongoDB Compass: Un'interfaccia grafica per esplorare visivamente i dati e le metriche di rendimento.
• Atlas CLI: Per gestire cluster, utenti e backup su MongoDB Atlas.
• Script Mongosh: Gli script personalizzati possono automatizzare i controlli della salute o generare rapporti giornalieri sul numero di connessioni e sull'utilizzo del disco.
• Playbook di Ansible: Automatizza le installazioni, la convalida della configurazione e la pianificazione dei backup.

Test di Recupero dai Disastri

L'ultimo passo nella pianificazione della manutenzione è testare le procedure di recupero. Un backup è utile solo se si ripristina correttamente.

Almeno una volta ogni trimestre:

1. Ripristina il tuo ultimo backup su un server di staging.
2. Verifica che gli indici, gli utenti e i permessi vengano caricati correttamente.
3. Misura il tempo di ripristino per garantire che soddisfi i tuoi obiettivi di tempo di recupero (RTO).
4. Documenta il processo in modo che qualsiasi amministratore possa eseguirlo in caso di emergenza.

Lista di Controllo per la Manutenzione a Lungo Termine

Seguendo queste pratiche di risoluzione dei problemi e manutenzione, puoi mantenere un'installazione di MongoDB sana su Ubuntu che rimanga performante, sicura e resiliente nel tempo. Un monitoraggio e una manutenzione costanti sono molto meno costosi rispetto al recupero da un'interruzione o da un evento di perdita di dati.

Domande frequenti

1. Perché MongoDB non è disponibile nei repository predefiniti di Ubuntu?

MongoDB è stato rimosso dai repository predefiniti di Ubuntu dopo la versione 18.04 a causa di cambiamenti di licenza. La MongoDB Server Side Public License (SSPL) non è riconosciuta come open-source dai progetti Debian e Ubuntu. Di conseguenza, Canonical non distribuisce più MongoDB nei suoi repository ufficiali e gli utenti devono installarlo dal repository APT di MongoDB.

2. Come faccio a disinstallare completamente MongoDB?

Per disinstallare MongoDB e rimuovere tutti i file associati, esegui i seguenti comandi:

sudo systemctl stop mongod

sudo apt purge -y mongodb-org*

sudo rm -rf /var/lib/mongodb

sudo rm -rf /var/log/mongodb

sudo rm -f /etc/apt/sources.list.d/mongodb-org-*.list

sudo apt autoremove -y

Questo arresta il servizio MongoDB, rimuove tutti i pacchetti correlati, elimina le directory dei dati e dei log e pulisce la voce del repository.

3. Come posso verificare se MongoDB è in esecuzione?

Puoi controllare lo stato del servizio MongoDB usando:

sudo systemctl status mongod

Se MongoDB è in esecuzione, vedrai una riga che indica “Attivo: attivo (in esecuzione)”. In alternativa, puoi confermare la connettività eseguendo:

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

Se il comando restituisce "ok": 1, MongoDB è attivo e accetta connessioni.

4. MongoDB può funzionare su un piccolo VPS?

Sì, MongoDB può funzionare su un piccolo VPS, ma con delle limitazioni. Per carichi di lavoro di sviluppo o test di base, un server con 2 core CPU, 2 GB di RAM e 10-20 GB di storage SSD è sufficiente.

Tuttavia, per l'uso in produzione, MongoDB offre le migliori prestazioni su sistemi con almeno 4 core CPU, 8 GB di RAM e unità SSD o NVMe ad alta velocità. Gli ambienti con poca memoria potrebbero richiedere la regolazione della dimensione della cache di WiredTiger per evitare eccessivi swap.

5. Perché MongoDB non si avvia dopo aver eseguito un'operazione di riparazione?

MongoDB potrebbe non avviarsi dopo una riparazione se il processo di riparazione è stato eseguito come root, il che modifica la proprietà dei file di dati in /var/lib/mongodb a root:root. Poiché il servizio mongod viene eseguito come utente mongodb, non avrà il permesso di leggere o scrivere questi file. Per risolvere questo problema, assicurati di eseguire il comando di riparazione come utente mongodb o di ripristinare successivamente la proprietà corretta:

sudo chown -R mongodb:mongodb /var/lib/mongodb

6. Come posso capire se MongoDB sta ascoltando sulle interfacce di rete corrette?

Puoi verificare i listener attivi di MongoDB usando:

sudo ss -tulpn | grep mongod

Questo mostra gli indirizzi IP e le porte a cui MongoDB è collegato. Se non vedi l'IP previsto (ad esempio, l'IP del server della tua applicazione), controlla il valore bindIp in /etc/mongod.conf e riavvia il servizio.

7. Dovrei modificare la dimensione predefinita della cache WiredTiger di MongoDB?

Nella maggior parte dei casi, no. WiredTiger utilizza automaticamente circa il 50% della RAM di sistema e regola dinamicamente l'uso della cache in base alla memoria disponibile. Modificate le impostazioni cacheSizeGB solo se MongoDB condivide il server con altre applicazioni che richiedono molta memoria. I server dedicati a MongoDB dovrebbero generalmente mantenere il comportamento predefinito.

8. Perché i miei log di MongoDB stanno diventando così grandi?

MongoDB scrive continuamente i dati operativi nel suo file di log in /var/log/mongodb/mongod.log. Senza la rotazione dei log, questo file può diventare molto grande. Assicurati di avere la rotazione dei log configurata utilizzando logrotate, come descritto nella sezione di manutenzione della guida, in modo che i log più vecchi vengano compressi o eliminati automaticamente.

9. Quando dovrei considerare di aggiungere altri nodi al mio set di repliche?

Dovresti espandere il tuo replica set quando noti un aumento costante del traffico di lettura, frequenti elezioni dei nodi, ritardi nella replica o quando hai bisogno di una maggiore disponibilità su più zone o regioni. Aggiungere nodi secondari distribuisce il carico di lettura e migliora la tolleranza ai guasti, soprattutto negli ambienti di produzione.

10. Come posso confermare che TLS è correttamente abilitato sul mio server MongoDB?

Dopo aver configurato TLS in /etc/mongod.conf, connettiti utilizzando:

mongosh --tls --host <server-ip> -u admin -p --authenticationDatabase admin

Se la connessione ha successo, esegui:

openssl s_client -connect <server-ip>:27017

Un handshake TLS valido e dettagli come Protocol: TLSv1.3 confermano che la crittografia è attiva.

Conclusione

Gestire MongoDB in modo efficace non riguarda solo l'installazione e la configurazione; riguarda il mantenimento di un equilibrio tra prestazioni, sicurezza e affidabilità nel tempo. Ora hai un sistema MongoDB completamente operativo che può supportare carichi di lavoro in produzione, scalare in base alla domanda e riprendersi da guasti imprevisti.

Applicando i principi e le migliori pratiche illustrati in questa guida, dal monitoraggio quotidiano alla pianificazione della capacità a lungo termine, è possibile gestire MongoDB con sicurezza in qualsiasi ambiente. Che continui a gestirlo autonomamente o che tu decida di migrare a un servizio gestito come MongoDB Atlas, la tua comprensione del funzionamento interno di MongoDB ti garantirà di mantenere sempre il controllo dei tuoi dati.

Per saperne di più sui database, dai un'occhiata ai seguenti tutorial:

• Quali sono i diversi tipi di database? Spiegati con casi d'uso e architetture
• SQLite vs MySQL vs PostgreSQL: Un confronto tra sistemi di gestione di database relazionali
• Come installare Node.js su Ubuntu
• Come iniziare con il MERN Stack

Grazie per aver imparato con la community di Linux-Console.net.