1 05/11/2026 11 min

Su Alpine Linux la prima cosa da chiarire è che MongoDB non si installa sempre con la stessa semplicità che si ha su distribuzioni glibc-based. Il punto non è solo il pacchetto, ma la compatibilità binaria, il supporto della versione scelta e il modo in cui vuoi esporre il database: locale, su rete privata o dietro un’applicazione che gira nella stessa macchina.

Se l’obiettivo è mettere in piedi un server MongoDB stabile e mantenibile, conviene procedere con metodo: verificare prima che la versione disponibile nel repository di Alpine sia quella adatta al tuo caso, poi predisporre storage e permessi, infine attivare autenticazione e bind address corretti. Saltare questi passaggi di solito porta a servizi che partono ma non sono davvero usabili in produzione.

Compatibilità su Alpine Linux: il punto da controllare prima di tutto

Alpine usa musl invece di glibc. Questo dettaglio conta molto quando si parla di MongoDB, perché non tutte le build upstream o i pacchetti terzi si comportano allo stesso modo. Prima di installare, conviene verificare cosa offre il repository della tua release e se il pacchetto è davvero quello che ti serve.

Il controllo minimo è questo:

cat /etc/alpine-release
apk update
apk search -v mongodb
apk policy mongodb

Se il pacchetto non è presente, o se la versione è troppo vecchia per il tuo progetto, hai tre strade: usare il pacchetto disponibile nei repository ufficiali, impiegare un container, oppure valutare una distribuzione diversa per il nodo database. Su Alpine, la scelta più prudente per un server esposto è partire dal repository ufficiale e non improvvisare binari presi altrove.

Installazione del pacchetto MongoDB

Se il pacchetto è disponibile, l’installazione base è lineare. Prima però conviene aggiornare gli indici e controllare che non ci siano dipendenze insolute. In un ambiente minimale come Alpine, questo evita di scoprire problemi solo quando il servizio prova ad avviarsi.

apk update
apk add mongodb

Dopo l’installazione, verifica che il binario sia presente e che la directory dati esista o possa essere creata dal servizio:

which mongod
mongod --version
ls -ld /var/lib/mongodb /var/log/mongodb

Se il pacchetto installa solo i binari ma non crea le directory, non è un errore: su Alpine è frequente dover predisporre manualmente i percorsi di lavoro. In quel caso conviene creare directory dedicate, con owner coerente con l’utente del servizio.

Preparare utente, directory dati e permessi

Un database non va mai lasciato con permessi generici. Anche su una macchina piccola, il minimo è separare dati e log, assegnare i permessi al solo utente del servizio e verificare che il filesystem scelto regga il carico previsto. Se il disco è lento o quasi pieno, MongoDB degrada molto prima di altri servizi meno sensibili alle I/O operations.

Controlla prima se l’utente esiste già:

getent passwd mongodb
getent group mongodb

Se non c’è, la creazione dipende dal pacchetto e dalla policy locale. In molti casi il pacchetto crea già l’account; in caso contrario va creato esplicitamente. Poi prepara le directory:

install -d -o mongodb -g mongodb /var/lib/mongodb
install -d -o mongodb -g mongodb /var/log/mongodb

Se usi un mount separato per i dati, controlla anche il tipo di filesystem e lo spazio disponibile prima di procedere. I due controlli più utili sono:

df -h /var/lib/mongodb
mount | grep /var/lib/mongodb

Qui il criterio pratico è semplice: se lo storage è condiviso con altre applicazioni e non hai margine di crescita, il database diventa il primo candidato a saturazione. Su un server serio, meglio dare a MongoDB un volume dedicato o comunque una partizione con capienza prevedibile.

Configurazione di base con file dedicato

La configurazione va trattata come un file di servizio vero e proprio, non come un elenco di opzioni sparse. Su Alpine, il percorso può variare in base al pacchetto, ma il concetto resta lo stesso: definire storage, log, rete e sicurezza in un file leggibile e versionabile.

Un esempio tipico, da adattare al percorso effettivo usato dal pacchetto, è questo:

systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true
storage: dbPath: /var/lib/mongodb
net: port: 27017 bindIp: 127.0.0.1
processManagement: timeZoneInfo: /usr/share/zoneinfo

Se il database deve essere raggiungibile solo localmente, lascia bindIp su 127.0.0.1. È la scelta più sicura per iniziare. Se invece devi accettare connessioni da un’app su un altro host, cambia solo dopo aver definito firewall, autenticazione e limitazione degli IP. Esporre MongoDB in rete senza autenticazione è un errore classico che si paga subito.

Prima di riavviare il servizio, fai sempre una copia del file originale. Se qualcosa va storto, il rollback deve essere banale:

cp /etc/mongodb.conf /etc/mongodb.conf.bak

Il nome del file può cambiare: verifica il percorso reale con il pacchetto installato, ad esempio tramite apk info -L mongodb o leggendo i file installati dal pacchetto. Questo è uno di quei casi in cui il percorso corretto conta più della teoria.

Avvio del servizio con OpenRC

Alpine usa OpenRC, quindi l’attivazione del servizio non passa da systemd. Se il pacchetto fornisce uno script di init, il flusso normale è abilitare il servizio e avviarlo. Se non lo fornisce, devi creare uno script locale coerente con il tuo setup. In entrambi i casi, la verifica va fatta subito dopo l’avvio.

rc-update add mongodb default
rc-service mongodb start
rc-service mongodb status

Se il servizio non parte, la prima cosa da leggere è il log. Niente tentativi a vuoto: il log dice quasi sempre se il problema è un path errato, un permesso sbagliato, un file di configurazione non valido o una porta già occupata.

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

Se non hai ancora un file di log, l’errore potrebbe essere a monte: servizio che non trova la configurazione, directory dati non accessibile o opzione non supportata dalla build disponibile. In quel caso, l’obiettivo non è “forzare” l’avvio, ma capire quale precondizione manca.

Verifica funzionale dopo l’avvio

Una volta che il servizio è su, il test minimo non è “il processo esiste”, ma “il database risponde e accetta la connessione nel modo previsto”. Il test più semplice è interrogare la porta e, se disponibile, eseguire un controllo con il client MongoDB.

ss -ltnp | grep 27017

Se il bind è locale, ti aspetti di vedere la porta in ascolto su 127.0.0.1:27017. Se hai configurato accesso remoto, la verifica deve mostrare l’indirizzo corretto sulla scheda di rete desiderata. Se non compare nulla, il servizio non è partito davvero o è fallito subito dopo l’avvio.

Quando il client è disponibile, un controllo elementare è questo:

mongosh --eval 'db.runCommand({ ping: 1 })'

Se mongosh non è presente nel pacchetto, non è necessariamente un problema del server. Vuol dire solo che il client va installato a parte, oppure che devi verificare il servizio con altri strumenti. In assenza del client, il controllo di socket e log resta comunque sufficiente per il primo sanity check.

Esporre MongoDB in rete solo quando serve davvero

Il database non dovrebbe essere esposto su Internet. Se devi renderlo raggiungibile da un’altra macchina, la soluzione corretta è una rete privata, un firewall restrittivo e autenticazione attiva. Il bind su 0.0.0.0 va considerato una scelta temporanea o comunque da accompagnare a regole molto precise.

Un approccio prudente prevede:

  • bind solo sugli IP necessari;
  • firewall che accetta la porta 27017 solo dagli host autorizzati;
  • autenticazione attiva con utenti separati per applicazione e amministrazione;
  • backup periodici e test di restore.

    • Il controllo firewall dipende dallo strumento usato sul nodo, ma il principio è sempre lo stesso: se la porta è aperta, deve esserlo solo per i client che servono davvero. In caso contrario, il rischio operativo non vale il beneficio.

    Abilitare autenticazione e creare un utente amministrativo

    Una volta verificato che il servizio funziona in locale, il passo successivo è chiudere il database con autenticazione. Senza questo passaggio, chiunque riesca a raggiungere la porta può leggere o modificare dati a seconda della configurazione di rete. È una delle prime cose da sistemare prima di usare il server per qualcosa di serio.

    La sequenza operativa tipica è:

  • abilitare l’opzione di authorization nel file di configurazione;
  • riavviare il servizio;
  • creare un utente amministrativo locale;
  • verificare che l’accesso anonimo non sia più possibile.

    • Un esempio di configurazione, se supportato dalla versione installata, è:

    security: authorization: enabled

    Dopo il riavvio, crea l’utente amministrativo da una sessione locale. Se hai già accesso al server, questo è il momento giusto per evitare di fare la procedura da remoto con una finestra di rischio inutile.

    mongosh
use admin
db.createUser({ user: "admin", pwd: passwordPrompt(), roles: [ { role: "root", db: "admin" } ]
})

    Se la shell non è disponibile, la creazione dell’utente va fatta con il client corretto del pacchetto installato o da un nodo che abbia il tool. Il punto importante non è il nome del comando, ma il risultato: un account amministrativo con password forte e senza esposizione in chiaro nella history della shell.

    Backup e ripristino: la parte che non si improvvisa

    Installare il database è solo metà lavoro. L’altra metà è sapere come salvarlo e ripristinarlo. Su un server piccolo, il backup minimo può essere un dump logico; su installazioni più serie, servono snapshot coerenti o una strategia più articolata. La scelta dipende da volume dati, RPO e RTO, non da preferenze personali.

    Per un controllo base, puoi usare un dump logico della singola istanza:

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

    Il restore va sempre testato su una macchina non produttiva o in un ambiente isolato. Un backup non testato è solo un file occupato su disco. Se usi dump logici, conserva anche la versione del server e dei client usati, perché il ripristino può dipendere dalla compatibilità tra release.

    Problemi tipici su Alpine e come leggerli in fretta

    Su Alpine i problemi più frequenti non sono misteriosi: quasi sempre riguardano path, permessi, compatibilità del pacchetto o configurazione troppo aggressiva per la build installata. Il metodo giusto è sempre lo stesso: leggere log, controllare il servizio, verificare il bind e confermare che il filesystem sia sano.

    Se il servizio fallisce subito, guarda prima questi tre punti:

  • Path errato: il file di configurazione punta a una directory inesistente o non scrivibile. Verifica con ls -ld /var/lib/mongodb /var/log/mongodb.
  • Permessi insufficienti: l’utente del servizio non può aprire il database o scrivere il log. Verifica owner e mode delle directory.
  • Opzione non supportata: la versione del pacchetto non riconosce un parametro della config. Verifica il log di avvio e confronta le opzioni con la documentazione della versione installata.

    • Quando qualcosa non torna, la prima correzione deve essere minima e reversibile. Cambia un solo parametro, riavvia, osserva il log, poi passa al successivo. È il modo più rapido per evitare di confondere un errore di configurazione con una catena di errori secondari.

    Hardening essenziale prima di andare in produzione

    Se il server MongoDB deve restare acceso a lungo, ci sono alcune misure che vale la pena mettere subito in ordine. Non sono optional: riducono il rischio operativo e rendono più semplice la gestione quotidiana.

  • Autenticazione attiva e utenti separati per ruoli diversi.
  • Bind ristretto agli IP necessari, non su tutte le interfacce senza motivo.
  • Firewall con porta 27017 aperta solo agli host autorizzati.
  • Backup verificati con almeno un restore di test.
  • Monitoraggio di spazio disco, RAM, latenza I/O e errori nei log.

    • Se hai un sistema di monitoraggio, vale la pena agganciare almeno questi segnali: spazio libero sulla partizione dati, crescita del file di log, numero di connessioni e tempi di risposta delle query più importanti. Non serve strumentazione sofisticata per accorgersi in tempo di un problema di saturazione disco o di un degrado improvviso.

    Checklist finale di installazione

    Prima di considerare conclusa l’installazione, verifica questi punti in sequenza:

  • Il pacchetto è installato e il binario risponde con mongod --version.
  • Le directory dati e log esistono e sono di proprietà dell’utente corretto.
  • Il servizio parte con rc-service mongodb start e resta attivo.
  • La porta ascolta solo sugli IP previsti.
  • L’autenticazione è abilitata prima di aprire il database ad altri host.
  • Esiste almeno un backup testato, non solo creato.

    • Se uno di questi punti manca, non sei ancora in una condizione solida. Il vero obiettivo non è “avere MongoDB installato”, ma avere un servizio che parte, resta su, protegge i dati e si ripristina senza sorprese. Su Alpine si può fare bene, ma solo se si accetta di controllare più dettagli rispetto a una distribuzione più tradizionale.

    Assunzione: i percorsi di configurazione e i nomi esatti del pacchetto possono variare leggermente in base alla release di Alpine e al repository abilitato; verifica sempre con apk info -L mongodb e con i log del servizio prima di applicare modifiche permanenti.