Come installare RethinkDB Server su Ubuntu 20.04 LTS

Repository ufficiale e prerequisiti su Ubuntu 20.04

Su Ubuntu 20.04 LTS la via più lineare per installare RethinkDB Server è usare il repository del vendor, perché il pacchetto nel repository standard può non essere aggiornato o non essere presente. Prima di toccare il sistema, conviene verificare che la macchina sia in ordine: aggiornamenti base, accesso sudo e spazio disco sufficiente per dati e log.

RethinkDB espone di default tre superfici distinte: la porta dati del database, la dashboard web e l’API amministrativa. In un contesto reale questo vuol dire che non basta “installare il pacchetto”: va ragionato anche il perimetro di rete, soprattutto se il nodo è raggiungibile da Internet o da una VLAN condivisa.

Prima di procedere, aggiorna l’indice dei pacchetti e installa i prerequisiti minimi per la gestione del repository. I comandi sotto non sono distruttivi e sono adatti a un server appena provisionato.

sudo apt update
sudo apt install -y curl gnupg ca-certificates lsb-release

Se il sistema è in produzione o comunque già usato da altri servizi, fai prima un controllo rapido su spazio e memoria. RethinkDB non è pesante in fase di installazione, ma la parte dati può crescere in fretta se il carico applicativo è poco disciplinato.

df -h
free -h

Aggiungere la chiave e il repository di RethinkDB

La parte delicata è il repository. Qui l’obiettivo non è “far partire apt”, ma farlo in modo verificabile. La chiave GPG deve essere importata e il repository deve puntare alla release corretta per Ubuntu 20.04, cioè focal. Se in futuro il vendor cambiasse endpoint o naming del repository, il sintomo tipico sarebbe un errore di firma o un pacchetto non trovato.

Usa il metodo con keyring separato, che è più pulito del vecchio approccio con apt-key. In questo modo riduci rumore nei warning di sicurezza e mantieni il controllo sulla provenienza del pacchetto.

curl -fsSL https://download.rethinkdb.com/apt/pubkey.gpg | sudo gpg --dearmor -o /usr/share/keyrings/rethinkdb.gpg

echo "deb [signed-by=/usr/share/keyrings/rethinkdb.gpg] https://download.rethinkdb.com/apt focal main" | sudo tee /etc/apt/sources.list.d/rethinkdb.list

sudo apt update

Dopo l’update, il controllo da fare non è solo l’assenza di errori: devi vedere che il repository venga letto correttamente. Se apt update segnala problemi di firma, DNS o TLS, fermati lì. Non ha senso installare nulla finché non hai chiuso la parte di trust chain.

Se il repository non fosse disponibile o il vendor cambiasse URL, il punto di chiusura è semplice: verifica la pagina ufficiale del pacchetto, poi confronta il percorso della chiave e il nome della distro supportata. Non andare a tentativi con repository di terze parti non verificati.

Installazione del pacchetto server

Una volta che il repository è pronto, l’installazione è diretta. Il pacchetto principale è rethinkdb e porta con sé il binario server, i file di servizio e la documentazione minima. In genere non serve compilare nulla, e questo è un vantaggio operativo rispetto a software che richiedono build locali.

sudo apt install -y rethinkdb

Terminata l’installazione, verifica che il binario sia presente e che il pacchetto abbia effettivamente registrato il servizio systemd. Questo evita il classico errore da “installato ma non avviabile” causato da repository incompleti o da installazioni parziali.

rethinkdb --version
systemctl status rethinkdb --no-pager

Un output sano mostra la versione del server e un’unità systemd presente, anche se non ancora avviata. Se il servizio non esiste, il primo controllo è sul pacchetto installato: dpkg -l | grep rethinkdb. Se il pacchetto c’è ma il servizio no, è probabile un problema di packaging o un repository sbagliato.

Avvio iniziale e struttura dei dati

RethinkDB può partire con una configurazione molto semplice, ma in pratica conviene decidere subito dove mettere i dati e dove tenere i log. Il default può andare bene per un test, non per un server che deve restare leggibile dopo tre mesi di esercizio.

La scelta minima ragionevole è separare il path dati dal resto del filesystem, idealmente su volume dedicato o almeno su partizione con spazio monitorato. Se lasci tutto su root, il giorno in cui il disco si riempie non hai più margine né per il database né per il sistema.

Prima di avviare il servizio, crea una directory dedicata e assegna i permessi corretti. Se stai lavorando con l’utente di sistema predefinito del pacchetto, non forzare ownership strane: usa il proprietario previsto dal servizio.

sudo mkdir -p /var/lib/rethinkdb
sudo mkdir -p /var/log/rethinkdb
sudo chown -R rethinkdb:rethinkdb /var/lib/rethinkdb /var/log/rethinkdb

Se l’utente di servizio non esiste con quel nome, il controllo da fare è immediato: getent passwd rethinkdb. In alcune varianti di packaging il nome può differire; in quel caso devi allinearti al file unit di systemd e non inventare ownership a caso.

Configurazione del servizio systemd

Il modo più pulito di gestire RethinkDB su Ubuntu è tramite systemd, con un file di configurazione esplicito. Il vantaggio è duplice: hai un avvio controllato e puoi leggere lo stato del servizio con strumenti standard. Per un server esposto a più utenti o applicazioni, questa tracciabilità vale più di un lancio manuale da shell.

Se il pacchetto non crea già una configurazione adatta al tuo caso, puoi intervenire sul file di unit o su un drop-in. La regola pratica è non editare a mano ciò che il package manager può sovrascrivere; meglio un override dedicato. Qui sotto c’è un esempio minimo di configurazione del demone con path dati e log separati.

sudo systemctl edit rethinkdb

Nel drop-in inserisci qualcosa di simile, adattando i parametri al tuo scenario. L’idea è rendere esplicito il path del data directory e limitare le superfici di ascolto se il nodo non deve essere pubblico.

[Service]
ExecStart=
ExecStart=/usr/bin/rethinkdb serve --data-dir /var/lib/rethinkdb --log-file /var/log/rethinkdb/rethinkdb.log --bind all

Dopo il salvataggio, ricarica systemd e avvia il servizio. Il punto da osservare non è solo “active (running)”, ma anche eventuali warning in journal. Se il servizio parte ma poi si ferma, il journal è la prima fonte utile, non il browser.

sudo systemctl daemon-reload
sudo systemctl enable --now rethinkdb
sudo systemctl status rethinkdb --no-pager
sudo journalctl -u rethinkdb -n 50 --no-pager

Un avvio corretto mostra il processo in esecuzione e nessun errore di binding o di permessi. Se vedi “permission denied” su data dir o log, il problema è quasi sempre ownership o AppArmor. Se invece il processo esce subito, cerca nella riga di comando usata da systemd: spesso c’è un parametro errato o una directory inesistente.

Verifica porte, dashboard e API amministrativa

Una volta avviato il server, il controllo successivo è di rete. RethinkDB usa porte distinte e questo è utile perché ti consente di esporre solo ciò che serve. In un ambiente serio non lasci la dashboard aperta al mondo senza filtro: la dashboard non è un giocattolo, è una superficie di gestione.

Verifica che il processo stia ascoltando sulle porte previste e che il browser possa raggiungere l’interfaccia web solo dai segmenti autorizzati. La verifica locale è rapida con ss e curl.

ss -lntp | grep rethinkdb
curl -I http://127.0.0.1:8080

Se il servizio è configurato correttamente, dovresti vedere almeno la porta della dashboard in ascolto e una risposta HTTP coerente. Un curl -I con 200 o 302 sulla porta web è un buon segnale; un timeout o connection refused indica che il demone non è in ascolto o che un firewall locale sta bloccando.

Per il controllo più pratico, apri la dashboard solo da un host di amministrazione e non dalla rete utente. Se devi pubblicarla dietro reverse proxy, fallo con autenticazione e restrizioni IP a monte. Non affidarti alla sola oscurità della porta.

Primo database, test operativo e modello d’uso

Installare il server non basta: serve un test che dimostri che il nodo accetta connessioni e scrive dati. Il modo più semplice è creare un database di prova e verificare che compaia nella dashboard o tramite client. Questo passaggio è importante perché separa il “servizio vivo” dal “servizio utile”.

Se hai già un client RethinkDB disponibile, puoi effettuare una connessione locale. In alternativa la dashboard offre una visibilità immediata sullo stato del nodo, ma non sostituisce un test di scrittura. La regola è semplice: nessun servizio va considerato valido finché non ha superato almeno una operazione CRUD minima.

Un esempio di test con shell o client applicativo dipende dal linguaggio che userai in produzione. Qui il punto non è imporre uno stack, ma verificare che il server sia pronto a sostenere il tuo pattern di accesso reale. Se l’applicazione userà connessioni persistenti, controlla anche eventuali limiti del firewall e del reverse proxy, perché una sessione che cade ogni pochi secondi genera sintomi falsamente “database”.

Firewall, esposizione servizi e riduzione della superficie d’attacco

Dal punto di vista operativo, RethinkDB va trattato come un servizio sensibile. La dashboard web, la porta dati e l’eventuale porta di clustering non dovrebbero essere esposte indiscriminatamente. La configurazione corretta dipende dal tuo scenario, ma la logica non cambia: il meno possibile, solo ai nodi che devono parlare tra loro.

Se usi ufw, puoi aprire solo la porta necessaria dal segmento amministrativo. In ambienti con firewall perimetrale o security group cloud, la stessa logica va applicata lì. Non duplicare aperture “temporanee” che poi restano per mesi.

sudo ufw allow from 10.0.0.0/24 to any port 8080 proto tcp
sudo ufw status verbose

Se il nodo è in cloud, il controllo equivalente va fatto anche su security group o regole di rete del provider. Il punto da verificare è che la dashboard sia raggiungibile solo da IP amministrativi e che la porta dati sia limitata ai peer applicativi o di cluster.

Controlli di salute dopo l’installazione

Dopo l’installazione, il controllo sano non è “la pagina si apre”, ma una combinazione di stato servizio, ascolto porte, log puliti e assenza di saturazione. Questa è la differenza tra una demo e un nodo mantenibile.

La check list minima che uso in pratica è questa: servizio attivo, porta aperta, log senza errori ripetuti, disco non saturo e memoria coerente con il carico atteso. Se uno di questi punti è fuori posto, il problema va chiuso prima di dichiarare il server pronto.

systemctl is-active rethinkdb
ss -lntp | grep rethinkdb
journalctl -u rethinkdb --since "10 min ago" --no-pager
watch -n 2 'df -h /var/lib/rethinkdb'

Se il log mostra warning sul filesystem o su permessi, correggi subito il layout prima di caricare dati reali. Se il disco cresce senza controllo già nei primi test, è meglio fermarsi e rivedere il data path piuttosto che inseguire un problema di spazio tra una settimana.

Nota pratica sul backup e sul ripristino

Un’installazione corretta deve includere almeno una strategia di backup. Per un database non basta sapere dove stanno i file: devi sapere come fermare il servizio in modo pulito, copiare i dati e ripartire senza corrompere nulla. Se non hai ancora una procedura testata, il backup è solo una speranza con un nome più professionale.

La forma minima di protezione è snapshot del volume o backup coerente del data directory con servizio fermato. Se il sistema è in produzione, il metodo va scelto in base alla finestra di manutenzione e al RPO richiesto. In ogni caso, prima di fidarti di un restore, fai almeno un test di ripartenza su una macchina separata.

sudo systemctl stop rethinkdb
sudo tar -czf /root/rethinkdb-backup-$(date +%F).tar.gz /var/lib/rethinkdb /var/log/rethinkdb
sudo systemctl start rethinkdb

Questo esempio è volutamente semplice e va usato solo se il carico lo consente e se hai accettato il rischio operativo di una fermata breve. In ambienti più seri conviene usare snapshot storage o procedure di replica, non archivi tar improvvisati.

Quando qualcosa non torna: sintomi tipici e lettura rapida

Se l’installazione sembra andata a buon fine ma il servizio non sale, i colpevoli abituali sono quattro: repository sbagliato, permessi errati, porta occupata o data directory mancante. Il pattern di diagnosi è sempre lo stesso: prima guardi journalctl, poi il binding di rete, poi lo stato del filesystem.

Se la dashboard non risponde ma il servizio è attivo, non saltare subito alla conclusione che “il database è rotto”. Più spesso il problema è una regola firewall, un bind su localhost o un proxy configurato male. La differenza si vede in pochi minuti con ss e curl.

Se invece il nodo parte ma i dati non persistono, controlla il path indicato in avvio. Un errore di data directory può sembrare innocuo all’inizio e diventare evidente solo dopo il primo riavvio. È proprio per questo che il test di restart è parte della validazione, non un extra opzionale.

Procedura sintetica da riusare in ambienti nuovi

1. Aggiorna il sistema e installa i prerequisiti con apt update e apt install curl gnupg ca-certificates lsb-release.
2. Importa la chiave GPG in /usr/share/keyrings/rethinkdb.gpg e aggiungi il repository focal in /etc/apt/sources.list.d/rethinkdb.list.
3. Installa il pacchetto con apt install rethinkdb e verifica la versione con rethinkdb --version.
4. Prepara /var/lib/rethinkdb e /var/log/rethinkdb con ownership coerente.
5. Avvia il servizio con systemd e controlla systemctl status rethinkdb e journalctl -u rethinkdb.
6. Verifica ascolto porte e dashboard con ss -lntp e curl -I http://127.0.0.1:8080.
7. Limita l’esposizione di rete con firewall e, se serve, reverse proxy o accesso da subnet amministrativa.

Questa sequenza è abbastanza corta da stare in una runbook interna e abbastanza robusta da ridurre i classici errori di installazione. Se devi adattarla a una macchina già usata, la vera variabile non è il pacchetto: sono i vincoli di storage, rete e policy locali.

In sintesi, installare RethinkDB Server su Ubuntu 20.04 LTS è semplice solo sulla carta. In pratica la qualità del risultato dipende da tre cose: repository verificato, servizio controllato da systemd e perimetro di rete ristretto. Se questi tre punti sono in ordine, il resto diventa manutenzione ordinaria.