1 25/05/2026 10 min

Perché usare Snap per Docker su Ubuntu

Su Ubuntu, installare Docker con Snap ha un vantaggio immediato: la distribuzione, l’aggiornamento e l’isolamento del pacchetto sono gestiti in modo uniforme dal sistema Snap. In pratica, si riduce il lavoro iniziale e si ottiene un’installazione abbastanza lineare per ambienti di test, workstation e nodi poco complessi. Il punto da tenere chiaro è che Snap non cambia la natura di Docker: cambia solo il modo in cui il demone e i binari vengono impacchettati e aggiornati.

La scelta ha senso quando vuoi una messa in opera veloce e accetti il compromesso di un’integrazione meno “nativa” rispetto ai pacchetti ufficiali Docker o alla build da repository dedicato. Se l’obiettivo è un server di produzione con controllo fine delle versioni, dei plugin e del ciclo di patching, conviene valutare con attenzione. Se invece ti serve partire subito e avere una manutenzione semplice, Snap può andare bene, purché tu sappia dove guardare quando qualcosa non torna.

Verifica preliminare: stato del sistema e conflitti

Prima di installare, controlla che il sistema sia allineato e che non ci siano installazioni precedenti di Docker che possano creare conflitti. Il caso classico è avere già docker.io o il repository ufficiale Docker con binari e servizi che si sovrappongono al pacchetto Snap.

Usa questi controlli minimi:

lsb_release -a
snap version
systemctl status snapd
apt list --installed | grep -E '^docker|containerd'
which docker

Se snapd non è attivo, l’installazione Snap non può procedere correttamente. Se trovi un Docker già installato con APT, decidere di mescolare le due modalità è una cattiva idea: rischi che il client punti a un socket diverso o che i servizi si pestino i piedi. In quel caso conviene scegliere una sola strada e rimuovere l’altra prima di continuare.

Per capire cosa è già presente, puoi usare anche:

snap list | grep -i docker
systemctl list-unit-files | grep -E 'docker|containerd|snap.docker'

Installazione di Docker con Snap

L’installazione base è essenziale. Su Ubuntu recente basta un comando, ma il dettaglio importante è che il pacchetto Snap di Docker può esporre un comportamento leggermente diverso rispetto ai tutorial scritti per i pacchetti tradizionali. Per questo ha senso verificare subito versione, stato del servizio e percorso del socket.

sudo snap install docker
sudo snap services docker
sudo docker version

Dopo l’installazione, il demone viene gestito da Snap e i servizi correlati vengono avviati in automatico. Se il comando sudo docker version restituisce sia client sia server, l’installazione è andata a buon fine. Se il client risponde ma il server no, il problema non è il binario: è il demone, il socket o un conflitto di servizio.

Per vedere dove Snap ha collocato il pacchetto e quali revisioni sono attive:

snap info docker
snap list docker

Il vantaggio operativo di questi comandi è che ti dicono subito se stai lavorando sulla revisione giusta e se il pacchetto è aggiornato o bloccato su una release specifica. In ambienti sensibili, questa è già una prima forma di audit minimo.

Permessi, gruppo docker e accesso senza sudo

Per evitare di usare sempre sudo, il metodo classico è aggiungere l’utente al gruppo docker. Tecnicamente è comodo, ma va trattato con la stessa cautela di un accesso privilegiato: chi può parlare con il demone Docker ha di fatto un controllo molto ampio sul sistema host.

sudo adduser $USER docker
newgrp docker
id -nG

Il controllo corretto è verificare che il gruppo sia effettivamente presente nell’output di id -nG e che il comando docker ps funzioni senza elevazione. Se non vuoi ricaricare la sessione, puoi uscire e rientrare; in alternativa newgrp docker aggiorna il gruppo nella shell corrente.

Attenzione però al rischio operativo: il gruppo docker non è una semplice comodità di accesso, è una superficie d’attacco privilegiata. In un host multiutente o in una macchina condivisa, concederlo solo a chi serve davvero è una regola di base, non un dettaglio.

Verifica del daemon e del socket

Con Snap, il controllo del servizio passa sempre da snap services e dal classico ecosistema systemd, ma il nome del servizio non è sempre quello che ci si aspetta guardando i tutorial generici. Il primo controllo serio è capire se il demone è vivo e se il socket risponde.

sudo snap services docker
sudo systemctl status snap.docker.dockerd.service
ls -l /var/run/docker.sock
sudo docker info

Se docker info restituisce l’errore sul socket, il problema è quasi sempre uno di questi: il servizio non è partito, il socket non esiste, oppure stai puntando al demone sbagliato. Il file /var/run/docker.sock è la verifica immediata da fare perché ti dice se il canale di comunicazione standard è disponibile.

Nel caso in cui il servizio risulti inattivo, prova a riavviarlo e osserva l’esito:

sudo snap restart docker
sudo snap services docker
journalctl -u snap.docker.dockerd.service -n 50 --no-pager

Il log è la fonte più utile quando il demone non sale. Se vedi errori di storage, permessi o bind sul socket, hai già il primo indizio utile senza andare a tentoni.

Primo container: test rapido e lettura del risultato

Il test migliore non è “Docker parte”, ma “Docker esegue un container e lo termina correttamente”. Una prova minima e pulita è usare un’immagine piccola, verificare il download e controllare l’output del container.

sudo docker run --rm hello-world

Se l’output mostra il messaggio di benvenuto, il percorso base funziona: client, demone, rete e pull dell’immagine sono a posto. Se invece il comando resta bloccato o fallisce, distingui subito il punto di rottura: errore di rete, problema con il registry, storage locale o demone non disponibile.

Un test un po’ più realistico, utile per verificare porte e runtime, è questo:

sudo docker run -d --name webtest -p 8080:80 nginx:alpine
curl -I http://127.0.0.1:8080
sudo docker logs webtest
sudo docker rm -f webtest

Il controllo su curl -I ti dice se il port mapping funziona davvero. Il comando docker logs serve per escludere che il container sia partito ma l’applicazione interna sia già in errore. La rimozione finale con docker rm -f chiude il test e lascia l’host pulito.

Persistenza dei dati e volumi: non confondere container e storage

Uno degli errori più comuni è trattare il container come se fosse un server tradizionale. Il filesystem del container è effimero; se salvi dati dentro il layer scrivibile e poi ricrei il container, quei dati spariscono. Per questo, appena esci dal test di base, devi ragionare in termini di volumi.

sudo docker volume create appdata
sudo docker run -d --name dbtest -v appdata:/var/lib/mysql mariadb:11
sudo docker volume ls
sudo docker inspect appdata

Il controllo da fare è semplice: il volume deve esistere e deve essere montato dove ti aspetti. Se usi bind mount, verifica anche i permessi della directory host. Un errore di ownership su una cartella locale è spesso sufficiente a far fallire un database o un servizio che scrive log e file di stato.

Per un bind mount, la verifica minima è questa:

mkdir -p /srv/docker/testdata
sudo chown -R 1000:1000 /srv/docker/testdata
sudo docker run --rm -v /srv/docker/testdata:/data alpine sh -c 'echo ok > /data/prova.txt'
cat /srv/docker/testdata/prova.txt

Qui il punto non è il contenuto del file, ma il fatto che il container riesca a scrivere nel path host. Se fallisce, il problema è quasi sempre nei permessi o nel mapping UID/GID, non in Docker “in generale”.

Rete, porte e DNS dentro i container

La rete è il secondo posto dove si perde tempo. Docker crea una rete bridge di default, ma se la porta non risponde dall’host o dall’esterno, bisogna separare il problema di pubblicazione da quello dell’applicazione. Il test corretto è verificare il bind, poi la reachability, poi il DNS interno del container se serve.

sudo docker ps
sudo docker port webtest
ss -lntp | grep 8080
sudo docker exec webtest cat /etc/resolv.conf

Se la porta è pubblicata ma non raggiungibile, controlla firewall, policy di rete e binding su interfaccia corretta. Se invece il container non risolve i nomi, il problema può essere nella configurazione DNS del demone o in una rete personalizzata creata male. In quel caso è utile distinguere tra fallimento del runtime e fallimento dell’applicazione che dipende da DNS esterni.

Un test semplice per capire se il problema è di rete o di servizio è:

sudo docker run --rm alpine sh -c 'apk add --no-cache curl >/dev/null 2>&1; curl -I https://example.com'

Se questo fallisce, hai un problema di uscita verso Internet, proxy, DNS o policy del nodo. Se funziona, la rete base è sana e il problema va cercato nel container specifico o nel suo stack applicativo.

Aggiornamenti Snap e gestione della manutenzione

Uno dei vantaggi di Snap è l’aggiornamento centralizzato. Il rovescio della medaglia è che gli update possono arrivare in automatico secondo la policy del sistema. Questo è comodo su una macchina personale, meno su un host dove vuoi controllare il momento esatto del cambio di versione.

snap refresh --list
snap info docker
sudo snap refresh docker

Prima di aggiornare, conviene sapere quale revisione stai eseguendo e se esistono refresh in sospeso. Dopo l’aggiornamento, la verifica non è “il comando esiste ancora”, ma “i container e i volumi continuano a comportarsi come prima”. Su un host critico, pianifica sempre una finestra e osserva i log subito dopo il refresh.

Se vuoi ridurre il rischio operativo, tieni almeno una nota con la versione attiva e una procedura di ritorno. Snap conserva le revisioni, quindi il rollback è spesso più semplice di un downgrade manuale da pacchetto tradizionale, ma va comunque verificato sul campo e non dato per scontato.

Integrazione con systemd e avvio automatico

Su Ubuntu, il comportamento al boot dipende dal servizio Snap e dalla configurazione dei container. Docker può partire come demone, ma i container non ripartono automaticamente se non hai impostato la policy corretta. Questo è il classico punto in cui si confonde “Docker su è attivo” con “il servizio applicativo è operativo”.

sudo docker update --restart unless-stopped webtest
sudo docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' webtest
sudo systemctl is-enabled snapd

Per i servizi che devono essere sempre disponibili, il restart policy è parte della configurazione, non un optional. Verifica anche che il sistema abbia davvero il supporto necessario per avviare Snap all’accensione; se snapd non è abilitato, il resto della catena non regge.

Quando Snap non è la scelta giusta

Snap non è sbagliato in assoluto, ma non è sempre la scelta migliore. Se gestisci un host con esigenze precise su versioni, plugin, integrazioni con orchestratori o policy di hardening, il pacchetto Snap può introdurre variabili in più rispetto a un’installazione con repository ufficiale Docker o con la distribuzione del vendor. Questo non significa che non funzioni; significa che va scelto per il contesto giusto.

Segnali pratici che indicano di rivalutare la scelta: necessità di pinning stretto della versione, bisogno di debug approfondito del demone, policy aziendali che vietano refresh automatici, o dipendenza da percorsi e integrazioni non banali con storage e networking. In quei casi, l’installazione va progettata, non solo eseguita.

Checklist operativa finale

Alla fine dell’installazione, tieni questa sequenza come verifica minima:

  1. sudo snap services docker mostra il demone attivo.

  2. sudo docker version riporta client e server.

  3. sudo docker run --rm hello-world completa senza errori.

  4. sudo docker ps e sudo docker info non mostrano warning critici.

  5. Il gruppo docker è assegnato solo agli utenti che devono davvero amministrare il runtime.

Se uno di questi punti fallisce, il problema non va aggirato con tentativi casuali: va isolato per layer. Prima demone, poi socket, poi rete, poi storage, poi policy di accesso. È il modo più rapido per evitare di trasformare una semplice installazione in una sessione di troubleshooting lunga e poco pulita.

Un’ultima nota pratica: documenta sempre la modalità di installazione usata. Su un host dove convivono più amministratori, sapere che Docker arriva da Snap evita diagnosi sbagliate, comandi puntati al servizio errato e tempo perso a inseguire un problema che è solo di packaging.