Come installare RabbitMQ su Ubuntu 22.04

Su Ubuntu 22.04, RabbitMQ si installa in modo affidabile partendo dai pacchetti ufficiali del progetto, non dai repository generici della distribuzione. La differenza conta: RabbitMQ dipende da una versione di Erlang compatibile, e se si forza il pacchetto sbagliato ci si ritrova con un servizio che parte male, si ferma subito o espone errori poco chiari nei log. In questa guida seguo un percorso pratico: preparazione del sistema, installazione del broker, avvio del servizio, verifica della console di amministrazione e alcune impostazioni minime per non lasciare il nodo troppo aperto.

Prerequisiti e criterio di installazione

RabbitMQ su Ubuntu 22.04 funziona bene come servizio systemd e, nella maggior parte dei casi, lo si installa su una macchina dedicata o su una VM che fa solo da broker. Prima di toccare i pacchetti, conviene chiarire due punti: la macchina deve avere connettività verso i repository ufficiali e bisogna usare una coppia Erlang/RabbitMQ coerente. Se l’obiettivo è un nodo singolo per sviluppo o per un ambiente piccolo, la procedura sotto è sufficiente. Se invece il nodo deve entrare in cluster, il discorso cambia e serve una progettazione diversa su cookie, naming e rete interna.

Mi aspetto un sistema Ubuntu 22.04 aggiornato, privilegi amministrativi e almeno una porta libera per AMQP e, se serve, per la management UI. I valori standard sono 5672 per AMQP e 15672 per l’interfaccia web di amministrazione. La porta 25672 viene usata internamente dal cluster e non va esposta inutilmente su Internet.

Aggiungere i repository ufficiali di RabbitMQ ed Erlang

Su Ubuntu 22.04 il modo più lineare è importare la chiave del repository e aggiungere i sorgenti ufficiali. In questo passaggio il rischio principale non è la distruzione dei dati, ma l’installazione di versioni incompatibili. Se qualcosa va storto, il rollback consiste nel rimuovere i repository aggiunti e reinstallare i pacchetti dalla sorgente corretta.

Prima verifica lo stato del sistema e aggiorna l’indice pacchetti:

sudo apt update
sudo apt -y upgrade

Installa gli strumenti necessari per gestire chiavi e repository:

sudo apt install -y curl gnupg apt-transport-https lsb-release ca-certificates

Importa la chiave del repository RabbitMQ ed Erlang in formato keyring, così eviti il vecchio approccio con apt-key, ormai deprecato:

sudo mkdir -p /usr/share/keyrings
curl -fsSL https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/rabbitmq.gpg
curl -fsSL https://packagecloud.io/rabbitmq/erlang/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/erlang.gpg

Aggiungi i repository. Se in futuro il progetto cambia distribuzione o percorso, il punto da controllare è il contenuto di /etc/apt/sources.list.d/.

echo "deb [signed-by=/usr/share/keyrings/erlang.gpg] https://packagecloud.io/rabbitmq/erlang/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/rabbitmq-erlang.list
echo "deb [signed-by=/usr/share/keyrings/rabbitmq.gpg] https://packagecloud.io/rabbitmq/rabbitmq-server/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/rabbitmq-server.list
sudo apt update

Se l’update fallisce, le cause più comuni sono DNS, proxy aziendale o una chiave non importata correttamente. Per falsificare rapidamente l’ipotesi, controlla che i file esistano e che l’URL risponda:

ls -l /etc/apt/sources.list.d/
curl -I https://packagecloud.io/rabbitmq/rabbitmq-server/ubuntu/dists/jammy/Release

Installare RabbitMQ e il runtime Erlang

Una volta aggiornati i repository, installa il broker e le dipendenze. Il pacchetto rabbitmq-server porta con sé il servizio systemd e, in genere, seleziona la versione Erlang compatibile dai repository aggiunti. Se il sistema ha già pacchetti Erlang installati da altre fonti, vale la pena controllare che non ci siano conflitti prima di procedere.

sudo apt install -y erlang-base erlang-crypto erlang-eldap erlang-inets erlang-mnesia erlang-os-mon erlang-public-key erlang-runtime-tools erlang-snmp erlang-ssl erlang-syntax-tools erlang-tools rabbitmq-server

Subito dopo l’installazione, verifica che il pacchetto abbia creato il servizio:

systemctl status rabbitmq-server --no-pager

Lo stato atteso è active (running). Se invece vedi failed o inactive, il primo posto da guardare è il journal del servizio:

journalctl -u rabbitmq-server -b --no-pager

In caso di errore al primo avvio, le ipotesi più probabili sono tre: incompatibilità Erlang/RabbitMQ, spazio disco insufficiente nella partizione che ospita /var/lib/rabbitmq, oppure un problema di hostname non risolvibile localmente. Per distinguerle in pochi minuti, controlla rispettivamente la versione installata, lo spazio libero e la risoluzione del nome host:

rabbitmqctl status df -h /var/lib/rabbitmq
hostname -f
getent hosts "$(hostname -f)"

Abilitare e verificare il servizio systemd

Su una macchina di produzione o su un nodo che deve ripartire dopo reboot, il servizio va abilitato esplicitamente. È una banalità solo in apparenza: capita spesso di trovare installazioni funzionanti ma non persistenti, perché il servizio è stato avviato a mano e non inserito nel boot sequence.

sudo systemctl enable rabbitmq-server
sudo systemctl start rabbitmq-server
sudo systemctl is-enabled rabbitmq-server
sudo systemctl is-active rabbitmq-server

Le risposte attese sono enabled e active. Se il servizio non resta su, evita di modificare subito la configurazione: prima controlla i log e lo stato del nodo.

Abilitare la console di amministrazione

La web UI di RabbitMQ non è obbligatoria, ma in pratica è molto utile per verificare code, connessioni, canali e permessi senza dover passare ogni volta dalla CLI. Il plugin da abilitare è rabbitmq_management. L’operazione è reversibile e non altera i messaggi già presenti nelle code.

sudo rabbitmq-plugins enable rabbitmq_management

Dopo l’abilitazione, la console dovrebbe rispondere su http://IP_DEL_SERVER:15672. Per un controllo rapido dal server stesso:

curl -I http://localhost:15672

Se la porta non risponde, verifica che il plugin sia effettivamente attivo:

sudo rabbitmq-plugins list -e | grep rabbitmq_management

In ambienti esposti alla rete, la management UI non andrebbe lasciata aperta a chiunque. Se la pubblichi, limita l’accesso con firewall, VPN o reverse proxy con autenticazione, altrimenti stai regalando un pannello di controllo del broker a chiunque raggiunga la porta.

Creare un utente amministrativo e rimuovere il guest remoto

Per default RabbitMQ crea l’utente guest, ma questo account è pensato per l’accesso locale. Lasciarlo esposto in rete è un errore classico. Il primo passo utile è creare un utente dedicato, assegnargli il ruolo di amministratore e poi disabilitare l’uso remoto di guest.

sudo rabbitmqctl add_user admin 'PASSWORD_FORTE'
sudo rabbitmqctl set_user_tags admin administrator
sudo rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"

Se il nodo è accessibile da più host, conviene evitare password deboli e preferire segreti gestiti fuori dalla shell, ad esempio tramite vault o file di provisioning protetti. Non lasciare la password in chiaro in cron, history o ticket.

Per impedire l’uso remoto di guest, il modo più semplice è configurare il broker affinché ascolti solo su localhost per quel profilo oppure, più frequentemente, non usare proprio quell’account. In molte installazioni il problema reale non è il demone, ma la combinazione tra credenziali di default e porta esposta su rete pubblica. Per falsificare il rischio, controlla se la porta 15672 è raggiungibile dall’esterno prima di pubblicare la UI.

Aprire solo le porte necessarie

Se il server è protetto da UFW, apri solo le porte realmente necessarie. Per un broker singolo con client esterni, in genere bastano AMQP e, se usata, la management UI. Non aprire 25672 verso Internet a meno che tu non stia configurando un cluster e sappia esattamente perché serve.

sudo ufw allow 5672/tcp
sudo ufw allow 15672/tcp
sudo ufw status verbose

Se il server è dietro security group o firewall esterno, la stessa logica va applicata lì. Il controllo finale non è il comando locale, ma la raggiungibilità reale dalla macchina client autorizzata.

Verifica funzionale del broker

Una installazione non è davvero pronta finché non hai verificato che il broker accetta connessioni e pubblica lo stato corretto. Il comando più utile, lato server, è rabbitmqctl status. Ti restituisce informazioni su versione, nodename, uptime, memoria, storage e listener attivi.

sudo rabbitmqctl status

Tra gli elementi da controllare ci sono:

• lo stato del nodo, che deve essere operativo;
• i listener su 5672 e, se attiva, 15672;
• la presenza del disco sotto soglia di allarme;
• l’assenza di errori ripetuti nel journal.

Se vuoi un test più concreto, puoi creare una coda temporanea dalla management UI oppure usare un client AMQP dedicato. In un ambiente di verifica, il semplice fatto che la UI mostri il nodo e che rabbitmqctl list_queues non restituisca errori è già un buon indicatore di salute.

sudo rabbitmqctl list_queues name messages consumers

File di configurazione principali

Su Ubuntu 22.04, la configurazione principale vive in /etc/rabbitmq/rabbitmq.conf. Se il file non esiste, puoi crearlo tu. Il formato è semplice, a chiave-valore. Per esempio, puoi impostare il nodo, limitare gli ascolti e definire il comportamento della UI. Ogni modifica va fatta con backup o diff, perché un errore di sintassi può impedire l’avvio del servizio.

sudo cp /etc/rabbitmq/rabbitmq.conf /etc/rabbitmq/rabbitmq.conf.bak 2>/dev/null || true
sudo nano /etc/rabbitmq/rabbitmq.conf

Un esempio minimo, adatto a un server singolo, potrebbe essere questo:

loopback_users.guest = true
listeners.tcp.default = 5672
management.tcp.port = 15672

Se usi questa configurazione, il guest resta limitato al loopback e la UI continua ad ascoltare sulla porta standard. Dopo ogni modifica, riavvia il servizio e controlla immediatamente i log:

sudo systemctl restart rabbitmq-server
journalctl -u rabbitmq-server -b --no-pager | tail -n 50

Il rollback, in caso di errore, è semplice: ripristina /etc/rabbitmq/rabbitmq.conf dalla copia di backup e riavvia il servizio. Il blast radius è limitato al broker, ma se il nodo serve applicazioni in produzione l’effetto lato utenti può essere immediato, quindi il riavvio va pianificato in finestra controllata.

Problemi tipici al primo avvio

Quando RabbitMQ non parte, i casi più frequenti sono prevedibili. Se il journal segnala che Erlang non è compatibile, la soluzione è riallineare i pacchetti e non forzare versioni casuali. Se il disco è pieno, libera spazio prima di riavviare. Se l’hostname non si risolve, correggi /etc/hosts o il DNS locale. Se la porta è occupata, individua il processo con ss -ltnp e rimuovi il conflitto solo dopo aver capito chi sta ascoltando.

sudo ss -ltnp | grep -E '(:5672|:15672)'
sudo journalctl -u rabbitmq-server -b --no-pager | grep -iE 'error|failed|panic|boot'

Un altro caso comune è il nodo che parte ma poi si mostra lento o instabile. In quel caso non si cambia subito il tuning: si guarda prima memoria, swap, I/O e numero di connessioni. La metrica utile, prima di qualsiasi ottimizzazione, è il rapporto tra messaggi in coda, consumer attivi e saturazione del disco. Se il broker sta accumulando backlog, il problema potrebbe stare nell’applicazione client e non nel server RabbitMQ.

Hardening minimo per un nodo esposto

Se il broker è raggiungibile dalla rete, il minimo sindacale è ridurre la superficie d’attacco. In pratica: niente account di default accessibili da fuori, management UI protetta, porte aperte solo dove servono, sistema aggiornato e log monitorati. Non è un hardening “avanzato”, ma evita gli errori grossolani che si vedono più spesso in produzione.

• aggiorna regolarmente il sistema con apt update && apt upgrade;
• limita l’accesso alle porte 5672 e 15672 ai soli host autorizzati;
• usa utenti separati per applicazioni diverse, con permessi sulla sola virtual host necessaria;
• monitora il journal e lo stato del servizio con alert sul riavvio o sui crash.

Se hai bisogno di cifrare il traffico AMQP, il passo successivo è configurare TLS con certificati validi e client che li usino correttamente. È un tema distinto dalla semplice installazione, ma su un broker esposto in rete pubblica andrebbe considerato presto, non dopo.

Verifica finale dopo reboot

La prova vera è il riavvio del server. Dopo il reboot, RabbitMQ deve tornare su da solo, la porta AMQP deve risultare in ascolto e la UI deve rispondere se abilitata. Se una di queste condizioni manca, non considerare conclusa l’installazione.

sudo reboot

Dopo il rientro:

systemctl is-active rabbitmq-server
ss -ltnp | grep -E '(:5672|:15672)'
curl -I http://localhost:15672

Se questi tre controlli passano, l’installazione è completa per un nodo singolo standard. Da qui in poi puoi costruire permessi, code, policy di retention e integrazione applicativa. L’unica assunzione fatta in questa guida è che tu stia lavorando su Ubuntu 22.04 pulito, con repository ufficiali disponibili e nessun altro servizio già in ascolto sulle porte standard di RabbitMQ.