Differenze tra Docker installato via apt e via snap

Installare Docker con apt o con snap non cambia solo il comando iniziale: cambia il modo in cui il demone viene aggiornato, dove finiscono i file, come si integra con il sistema e quanto è lineare il troubleshooting. In ambienti server questa differenza conta più della comodità del primo avvio. Se devi gestire container in produzione, la domanda vera non è “quale installa più in fretta?”, ma “quale si comporta in modo più prevedibile nel tempo?”.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

La differenza pratica: pacchetto di sistema contro pacchetto confinato

Con apt installi Docker come software del sistema, gestito dal package manager della distribuzione. I binari, i servizi, le dipendenze e le configurazioni seguono la logica classica di Linux server: file in posizioni note, aggiornamenti controllati, integrazione diretta con systemd e con il resto dello stack. Con snap installi invece una distribuzione impacchettata dal formato Snap, con mount dedicati, revisioni del pacchetto, aggiornamenti automatici e un certo grado di isolamento dal filesystem host.

Questo si traduce in tre conseguenze immediate. Primo: i percorsi cambiano. Secondo: il ciclo di aggiornamento cambia. Terzo: il comportamento operativo non è identico, soprattutto quando tocchi storage, permessi, socket, plugin e integrazioni con altri servizi. In altre parole, due installazioni che espongono lo stesso comando docker non sono intercambiabili in senso amministrativo.

Installazione via apt: prevedibilità e controllo

Il percorso classico su Debian, Ubuntu e derivate è quello dei repository ufficiali Docker o dei repository della distribuzione, quando disponibili. Il vantaggio non è estetico: è operativo. Hai una catena di installazione comprensibile, aggiornamenti integrati con la gestione del sistema e meno sorprese quando devi fare hardening, audit o automazione.

Un’installazione tipica via repository ufficiale mantiene separati i componenti principali: docker-ce, docker-ce-cli, containerd.io e, se serve, plugin e pacchetti accessori. Questo aiuta quando vuoi fissare versioni, fare pinning o testare una release specifica in staging prima di portarla in produzione.

Esempio di installazione su Ubuntu/Debian con repository Docker:

sudo apt update
sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo \"$VERSION_CODENAME\") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

La parte utile qui viene dopo l’installazione è altrettanto importante: puoi verificare subito il servizio, il socket e la versione senza ambiguità.

systemctl status docker --no-pager
docker version
docker info

Se qualcosa non torna, sai dove guardare: /lib/systemd/system/docker.service, /etc/docker/daemon.json, i log di journalctl -u docker e la configurazione del socket /var/run/docker.sock. Questa trasparenza è il motivo per cui, su server, apt resta la scelta più lineare nella maggior parte dei casi.

Installazione via snap: comodità, ma con un modello diverso

Con Snap il pacchetto Docker arriva come applicazione confezionata e revisionata dal sistema Snap. L’idea è semplice: installi in fretta, aggiorni automaticamente e riduci la dipendenza dal layout tradizionale della distribuzione. Su desktop o in ambienti di test questa semplicità può essere comoda. In server, però, il quadro cambia perché Snap introduce un livello di astrazione in più.

Il demone, i mount e i dati non si comportano come in un’installazione classica. I file vivono sotto /var/snap/docker e il comando può essere esposto come /snap/bin/docker. Anche il servizio viene gestito da unità Snap, con logica di aggiornamento e restart propria del sistema di packaging.

Installazione tipica:

sudo snap install docker

Verifiche immediate:

snap list docker
snap services docker
/snap/bin/docker version

Il punto critico non è il comando in sé, ma il fatto che Snap può nascondere parte dell’impianto tradizionale dietro il proprio meccanismo di confinamento e aggiornamento. Questo è accettabile quando vuoi un sistema più autosufficiente, meno quando devi integrare Docker con backup, agent, monitoraggio, policy di sicurezza e procedure operative già esistenti.

Differenze che contano davvero in produzione

La prima differenza concreta è la gestione degli aggiornamenti. Con apt sei tu, o il tuo sistema di automation, a decidere quando aggiornare. Con Snap gli aggiornamenti sono tendenzialmente automatici e più frequenti. Questo può essere un vantaggio per la rapidità di patching, ma diventa un rischio se hai bisogno di finestre di manutenzione precise o se vuoi validare ogni salto di versione in staging.

La seconda differenza è il layout del filesystem. In una installazione via apt trovi i file dove te li aspetti: configurazioni in /etc, unità systemd in percorsi standard, dati in /var/lib/docker salvo override. Con Snap, invece, il pacchetto vive nel suo perimetro, e questo può complicare script, backup, agent di sicurezza e strumenti che assumono un percorso standard.

La terza differenza riguarda l’integrazione con il resto del sistema. Molti ambienti usano Docker insieme a systemd, log collector, exporter Prometheus, reverse proxy, CNI, storage locale o remoto, e policy di accesso al socket Docker. Con il pacchetto apt l’integrazione è più naturale; con Snap puoi farla, ma devi verificare ogni passaggio con più attenzione.

La quarta differenza è il comportamento sotto troubleshooting. Se il servizio non parte, con apt hai una traiettoria abbastanza standard: unità systemd, journald, configurazione del daemon, permessi sul socket, spazio disco, cgroup, kernel. Con Snap aggiungi un ulteriore livello: stato del pacchetto Snap, revisioni, mount del confinamento, path specifici e possibili interazioni con il sistema di aggiornamento Snap stesso.

Path, servizi e file: dove cercare nei due casi

Qui conviene essere molto concreti. Se installi via apt, i punti di controllo più comuni sono:

/etc/docker/daemon.json
/lib/systemd/system/docker.service
/var/lib/docker
/var/run/docker.sock

Se installi via Snap, i riferimenti diventano in genere:

/var/snap/docker/common/
/var/snap/docker/current/
/snap/docker/current/
/snap/bin/docker

Questa differenza è cruciale quando scrivi playbook Ansible, script di backup, check di monitoraggio o procedure di recovery. Un controllo che cerca /etc/docker/daemon.json non ti dice nulla su una installazione Snap; un controllo che assume /var/lib/docker può perdere il dato reale se la piattaforma è stata impacchettata diversamente. Il risultato non è teorico: è il classico bug da “funziona sul server A, non sul server B”.

Permessi e accesso al socket: stesso sintomo, cause diverse

Molti problemi apparentemente banali nascono dal socket Docker. Se un utente non appartiene al gruppo giusto, il comando fallisce con un errore di permesso. In installazione classica, il gruppo è di solito docker e il socket è /var/run/docker.sock. Verifica con:

ls -l /var/run/docker.sock
getent group docker
groups <utente>

Con Snap la logica può essere più articolata perché il pacchetto e il relativo servizio seguono il modello del sistema Snap. Se i comandi sembrano installati ma non rispondono come previsto, controlla prima snap services docker e poi la disponibilità effettiva del binario in /snap/bin. Non dare per scontato che il gruppo o il path siano identici a una installazione via apt.

Un test semplice che chiarisce subito la situazione è questo:

which docker
readlink -f $(which docker)
docker context ls

Se which docker punta a /snap/bin/docker, sei nel mondo Snap. Se punta a /usr/bin/docker, sei nel mondo apt o comunque nel layout classico. Questo dettaglio evita ore di debug inutile quando hai più host con installazioni miste.

Aggiornamenti, rollback e finestra di rischio

Su un server, l’aggiornamento di Docker non va trattato come un dettaglio. Docker non è solo un binario: è il punto di controllo di container, reti, volumi e in molti casi di stack applicativi interi. Se aggiorni male, il problema può propagarsi a servizi web, database containerizzati, job schedulati e pipeline CI.

Con apt il rollback è più prevedibile: puoi bloccare versioni, usare repository mirati, rimettere una release precedente e allineare il change management al ciclo di manutenzione. Con Snap hai revisioni e canali, ma il rollback dipende dal modello Snap e dalla disponibilità della revisione precedente. È fattibile, ma non è la stessa esperienza operativa di un pacchetto deb standard.

Se devi ridurre il rischio, il criterio è semplice: preferisci un meccanismo di rilascio che puoi congelare, osservare e revertire con precisione. In produzione questo pesa più della rapidità di installazione iniziale.

Compatibilità con Compose, plugin e tooling esterno

Oggi molti ambienti non usano solo il motore Docker, ma anche docker compose, plugin CLI, driver di logging, exporter, scanner, agent di backup e automazioni che parlano con il socket. Qui la differenza tra apt e Snap si vede bene: i plugin e il posizionamento dei file seguono logiche diverse e possono richiedere attenzione extra nella documentazione interna.

Verifica sempre che il binario usato dalle pipeline sia quello atteso:

docker compose version
docker buildx version
docker info | grep -E 'Docker Root Dir|Server Version'

Se una pipeline CI o uno script di provisioning assume un certo layout, l’installazione Snap può introdurre una divergenza silenziosa. Il problema non si manifesta sempre subito: a volte emerge solo quando un job cerca un path, una socket o una directory di stato. Per questo, nei server condivisi o nelle macchine di automazione, la coerenza della distribuzione conta più della semplicità del primo setup.

Quando scegliere apt e quando scegliere snap

La scelta non è ideologica. È operativa.

1. Usa apt se il nodo è server di produzione, se vuoi controllo sulle versioni, se fai automazione con Ansible o script, se devi integrare backup e monitoraggio in modo prevedibile.
2. Usa Snap se ti serve installazione rapida, ambiente omogeneo su sistemi che già adottano Snap, oppure se stai testando e vuoi ridurre la manutenzione manuale del pacchetto.
3. Evita di mescolare i due approcci sullo stesso host a meno che tu non abbia una ragione precisa e una documentazione interna chiara. Due installazioni concorrenti di Docker sono una delle forme più banali di confusione operativa.

In pratica, su un host che ospita workload reali, la raccomandazione più robusta resta apt con repository ufficiale Docker e versioni tenute sotto controllo. Snap ha senso in contesti dove il trade-off favorisce la semplicità di distribuzione rispetto al controllo fine. Ma appena entri nel territorio di SLO, audit, change window e rollback, il formato classico torna a essere più adatto.

Checklist di verifica dopo l’installazione

Indipendentemente dal metodo scelto, una verifica minima evita sorprese successive:

1. Controlla il binario effettivo con which docker e readlink -f $(which docker).
2. Controlla il servizio con systemctl status docker oppure snap services docker.
3. Controlla la versione con docker version e la root dei dati con docker info.
4. Controlla il socket con ls -l /var/run/docker.sock e i gruppi utente con groups.
5. Controlla il percorso dei dati e della configurazione prima di scrivere backup o automazioni.

Se uno di questi punti non torna, non forzare la diagnosi. Prima identifica il packaging reale, poi adatta la procedura. È un risparmio di tempo immediato e riduce gli errori che in produzione si pagano con un ticket in più e un rollback in ritardo.

Conclusione operativa: stesso nome, comportamento diverso

Dire che Docker installato via apt e via Snap “fa la stessa cosa” è vero solo a livello superficiale. Appena entri nel dettaglio di aggiornamenti, path, servizio, troubleshooting e integrazione con l’ecosistema del server, le differenze diventano concrete. In un ambiente Linux amministrato bene, la scelta del packaging è parte dell’architettura operativa, non un dettaglio di installazione.

Se vuoi una linea guida asciutta: apt per controllo e produzione, Snap per comodità e contesti meno rigidi. Poi, come sempre, conta il vincolo reale del tuo ambiente: versione della distro, policy di update, automazione già presente e tolleranza al cambiamento. Quello che non cambia è la necessità di sapere esattamente dove sono binari, dati, log e servizi prima di toccare un host.