Installare ntopng con Redis su AlmaLinux 9 usando Docker

Su AlmaLinux 9 la combinazione ntopng + Redis in Docker funziona bene se separi subito tre piani: persistenza, rete e permessi. Il punto non è “far partire due container”, ma evitare che al primo riavvio tu perda cache, interfacce o accesso al web UI. In pratica: Redis serve come backend leggero per stato e code, ntopng espone la UI e legge il traffico dalle interfacce host, quindi il container deve vedere la rete in modo coerente con ciò che vuoi monitorare.

Qui sotto trovi un’installazione ragionata, pensata per un host AlmaLinux 9 recente con Docker Engine e systemd. L’obiettivo è avere un setup ripetibile, con volumi persistenti, avvio automatico e una configurazione che si possa cambiare senza ricostruire ogni volta tutto da zero.

Scelta architetturale: due container, dati persistenti, rete semplice

La scelta più lineare è usare un container per Redis e uno per ntopng, collegati sulla stessa rete bridge Docker. Redis non deve essere esposto all’esterno: lo usa solo ntopng. ntopng invece espone la porta web, tipicamente 3000/TCP, e necessita di accesso ai dati di traffico del sistema host. Se vuoi osservare il traffico reale di una o più interfacce, la soluzione più robusta è usare host network per ntopng oppure concedergli accesso a /dev/bpf no, su Linux non esiste: qui il problema si risolve con --net=host e con i privilegi adeguati per la cattura.

Con Docker su Linux, ntopng spesso richiede anche --cap-add=NET_ADMIN e --cap-add=NET_RAW. Se l’immagine che usi è già preparata per il monitoraggio, può bastare il solo host network; in caso contrario, i capability extra evitano errori ambigui durante l’apertura delle interfacce.

Prerequisiti su AlmaLinux 9

Prima di tutto verifica che Docker sia installato e attivo. Se non lo è, il pacchetto da repository ufficiale Docker è la strada più pulita. Se hai già un runtime container diverso, non mischiare gli approcci senza motivo: per questo scenario Docker Engine basta e avanza.

Controlla anche che la macchina abbia spazio disco sufficiente per i volumi e per i log. ntopng e Redis non sono pesanti in assoluto, ma il punto critico sono i dati storici e il rumore dei log se il monitoraggio è molto attivo.

Verifica la base:

sudo systemctl status docker --no-pager

Atteso: active (running). Se non lo è, fermati qui e sistema il runtime prima di andare oltre.

Struttura delle directory sul host

Per non perdere tempo dopo il primo riavvio, crea subito directory dedicate. Un layout semplice e leggibile riduce gli errori quando devi fare troubleshooting o migrare il servizio su un altro host.

sudo mkdir -p /opt/ntopng/{redis,data,config,logs}

Se vuoi tenere separati file di configurazione e dati, questa divisione è sufficiente. Redis avrà il suo volume dedicato, ntopng userà un volume per i dati persistenti e un file di configurazione montato in sola lettura.

Permessi: evita di lasciare tutto world-writable. Se l’immagine gira con un utente non root, allinea ownership e UID solo dopo aver verificato quale utente usa il container. In assenza di documentazione precisa dell’immagine, la strada più sicura è partire con permessi conservativi e correggere solo il necessario dopo il primo avvio.

Docker Compose: Redis interno, ntopng esposto

Per un setup operativo conviene usare Compose. Ti permette di versionare il deployment, fare rollback del file e ricostruire il servizio senza ricordarti ogni flag a memoria. Qui sotto una base che puoi adattare all’immagine ntopng che stai usando. Se il tag dell’immagine cambia, verifica sempre la documentazione del maintainer perché nomi di variabili e path possono variare.

services:
  redis:
    image: redis:7-alpine
    container_name: ntopng-redis
    restart: unless-stopped
    command: ["redis-server", "--appendonly", "yes", "--save", "60", "1"]
    volumes:
      - /opt/ntopng/redis:/data
    networks:
      - ntopnet

  ntopng:
    image: ntop/ntopng:latest
    container_name: ntopng
    restart: unless-stopped
    network_mode: host
    depends_on:
      - redis
    cap_add:
      - NET_ADMIN
      - NET_RAW
    volumes:
      - /opt/ntopng/data:/var/lib/ntopng
      - /opt/ntopng/config:/etc/ntopng
      - /opt/ntopng/logs:/var/log/ntopng
    command:
      - /usr/bin/ntopng
      - -i
      - eth0
      - --redis
      - 127.0.0.1:6379
      - --http-port
      - "3000"

networks:
  ntopnet:
    driver: bridge

Nota pratica: nella configurazione sopra Redis resta sulla bridge interna, mentre ntopng usa la rete host per vedere l’interfaccia fisica del server. È una combinazione sensata perché Redis non ha bisogno di essere raggiungibile dall’esterno e ntopng sì, almeno sulla sua interfaccia web.

Se vuoi usare una porta diversa da 3000, cambiala subito qui e non dopo. In fase di test è più semplice tenere la default, perché molte guide, log e health check la assumono già.

Configurazione di ntopng: file dedicato e non solo command line

La command line va bene per il primo avvio, ma appena il setup cresce conviene spostare i parametri stabili in un file di configurazione. Così puoi versionare le opzioni e ridurre il rischio di dimenticare un flag importante al riavvio.

Un esempio minimale di file in /opt/ntopng/config/ntopng.conf:

-i=eth0
--redis=127.0.0.1:6379
--http-port=3000
--community
--disable-login

Attenzione su --disable-login: è un esempio da laboratorio, non una scelta da produzione. In un contesto reale vuoi proteggere la UI con credenziali robuste e, meglio ancora, limitarne l’esposizione a una rete di management o a un reverse proxy con controllo accessi.

Se usi un file di configurazione, montalo in sola lettura nel container. Il vantaggio è doppio: riduci modifiche accidentali e hai una traccia chiara di ciò che è stato cambiato.

Avvio del stack e verifica dei container

Portati nella directory del Compose e avvia il servizio:

cd /opt/ntopng
sudo docker compose up -d

Controlla subito lo stato dei container:

sudo docker compose ps

Atteso: entrambi Up. Se Redis è in esecuzione ma ntopng crasha in loop, il problema è quasi sempre in uno di questi punti: interfaccia sbagliata, permessi mancanti, porta già occupata, oppure path di configurazione errato.

Per leggere i log del servizio:

sudo docker logs -f ntopng
sudo docker logs -f ntopng-redis

Su ntopng cerca errori come impossibilità di aprire l’interfaccia, database non raggiungibile o failure nel caricamento del profilo. Su Redis, invece, gli errori seri sono rari: se non parte, spesso sono legati a filesystem, permessi del volume o parametri non supportati nell’immagine scelta.

Verifica funzionale dalla rete

Dal host, verifica che la porta web risponda:

curl -I http://127.0.0.1:3000

Atteso: una risposta HTTP valida, tipicamente 200, 302 o comunque una intestazione coerente con la UI in ascolto. Se ottieni connection refused, ntopng non è in ascolto o sta ascoltando su un’altra porta.

Verifica anche che la porta sia effettivamente aperta sul sistema:

sudo ss -lntp | grep ':3000'

Se non compare nulla, il problema non è il firewall: è il processo. Se compare ma non rispondi dal browser remoto, il problema passa a firewall o policy di rete.

Su AlmaLinux 9, se firewalld è attivo e vuoi accedere alla UI da fuori host, apri la porta in modo esplicito:

sudo firewall-cmd --permanent --add-port=3000/tcp
sudo firewall-cmd --reload

Questa è una modifica reversibile e a blast radius limitato: impatta solo l’esposizione della porta 3000. Se in seguito decidi di mettere ntopng dietro reverse proxy, puoi richiuderla.

Accesso alla UI e primo hardening

La UI iniziale di ntopng va trattata come un servizio di amministrazione, non come una pagina pubblica. Se la esponi su Internet senza controllo, stai regalando all’esterno un punto di osservazione molto sensibile sulla tua rete.

Le misure minime sono tre: password forte, accesso limitato per IP o VPN, e niente credenziali in chiaro dentro file condivisi. Se devi documentare l’accesso per il team, usa un password manager e ruota le credenziali quando cambia il perimetro di accesso.

Se vuoi limitare la visibilità della UI senza cambiare architettura, la scelta più semplice è un firewall con source restriction. Esempio concettuale: consenti 3000/TCP solo dalla subnet amministrativa, non da tutto il mondo.

Persistenza, backup e cosa non fidarsi a lasciare in container effimeri

Redis in questo scenario non è il database “di verità” dei tuoi dati storici, ma resta un componente che conviene rendere persistente. Il flag --appendonly yes riduce il rischio di perdita di stato in caso di stop improvviso. Per ntopng, invece, il volume dati è quello che ti evita di perdere configurazioni, preferenze e file di stato locale.

Per il backup, non fare snapshot ciechi dell’intero host se non serve. Separa almeno:

Così puoi ripristinare solo ciò che serve e non confondere il backup applicativo con quello del sistema operativo.

Troubleshooting rapido: i guasti più probabili

Se ntopng non parte, la prima domanda è sempre la stessa: vede l’interfaccia giusta? Un nome come eth0 in container non è garantito se non usi host network. Su host network normalmente il container vede le interfacce del sistema, ma se l’host usa nomi prevedibili come enp1s0 o ens18, devi impostare il nome corretto.

Se la UI risponde ma non mostra traffico, controlla che ntopng stia ascoltando sul link giusto e che il NIC selezionato abbia effettivamente passaggio di pacchetti. Su host virtualizzati, ad esempio, potresti vedere poco o nulla se il traffico non transita sulla scheda monitorata.

Se Redis è raggiungibile ma ntopng continua a restartare, guarda i log del container e verifica il parametro --redis. Un errore banale di host o porta genera sintomi poco chiari lato UI ma è immediato da vedere nei log.

sudo docker inspect ntopng --format '{{json .State}}' | jq

Questo ti dice se il processo sta uscendo per errore, se sta riavviandosi in loop e con quale exit code. È una verifica più utile del classico “non va” perché ti porta subito sul layer giusto.

Aggiornamenti e rollback senza sorprese

Per aggiornare ntopng o Redis, non cambiare tag alla cieca e non sovrascrivere il Compose senza copia. Salva sempre una versione precedente del file e annota il tag immagine usato. Il rollback più semplice è tornare al file Compose precedente e rilanciare docker compose up -d.

Se l’aggiornamento rompe la compatibilità con la configurazione, il rollback deve includere anche il file di configurazione. È il motivo per cui conviene tenere in un repository o in una directory versionata sia compose.yml sia ntopng.conf.

Prima di aggiornare in produzione, verifica sempre due cose: la sintassi della nuova immagine e la compatibilità dei parametri passati a ntopng. Un flag deprecato può far fallire il container anche se l’immagine è corretta.

Configurazione minima consigliata da portare in produzione

Se devi sintetizzare il setup in una baseline sensata, questa è la lista che non taglierei:

Questa impostazione non è “più elegante”: è semplicemente quella che ti fa perdere meno tempo quando qualcosa cambia nel tempo, che è la vera costante degli ambienti Linux in produzione.

Esempio di check finale operativo

Dopo l’avvio, esegui questa sequenza minima e non dare il lavoro per concluso finché tutti i punti non tornano:

sudo docker compose ps
sudo docker logs --tail=50 ntopng
curl -I http://127.0.0.1:3000
sudo ss -lntp | grep ':3000'
sudo firewall-cmd --list-ports

Se vuoi un esito pulito, devi vedere container Up, log senza errori ricorrenti, porta in ascolto e regola firewall coerente con la tua modalità di accesso. Se uno di questi punti non torna, non passare a tuning o dashboard: risolvi prima il livello infrastrutturale.

In sintesi pratica: ntopng con Redis su AlmaLinux 9 in Docker funziona bene quando tratti Redis come dipendenza interna, ntopng come servizio di osservabilità sensibile e la rete come parte della configurazione, non come dettaglio secondario. È il modo più semplice per avere un’installazione stabile, leggibile e recuperabile senza doverla ricostruire da zero al primo problema.