Come installare Docker CE su Ubuntu 22.04 LTS

Repository ufficiale Docker su Ubuntu 22.04

Su Ubuntu 22.04 LTS la strada pulita è usare il repository ufficiale di Docker, non i pacchetti del repository base. La differenza non è cosmetica: con il canale ufficiale ottieni versioni aggiornate, pacchetti separati per engine, CLI, containerd e plugin, oltre a una gestione più prevedibile degli aggiornamenti. Se il server espone servizi in produzione, questa è la scelta sensata: meno sorprese, meno drift tra ambienti, più controllo sul ciclo di update.

Prima di toccare il sistema, conviene allineare il quadro: stato atteso = una macchina Ubuntu 22.04 con accesso sudo, rete funzionante e nessun Docker installato in modo conflittuale; stato osservato = pacchetti eventualmente presenti da installazioni precedenti, repo terzi o versioni residue di container runtime. Se manca un dettaglio, il punto da chiudere è semplice: verificare i pacchetti installati e la presenza dei repository già configurati.

1. Verifica preliminare e pulizia di eventuali conflitti

Il primo controllo è capire se il sistema ha già componenti Docker o container runtime installati. Non è un passaggio teorico: su host “vissuti” capita spesso di trovare mix tra pacchetti Ubuntu, vecchie installazioni manuali e repository esterni. Se lasci tutto lì e procedi, il rischio è una installazione apparentemente riuscita ma con binari e servizi incoerenti.

Esegui questi controlli:

dpkg -l | egrep 'docker|containerd|runc' || true
apt-cache policy docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Se il primo comando non restituisce nulla, bene: parti da una base pulita. Se invece trovi pacchetti già presenti, non rimuoverli a caso su un server in uso. Prima identifica cosa li consuma e se esistono container attivi:

docker ps -a 2>/dev/null || true
systemctl status docker --no-pager 2>/dev/null || true

In caso di conflitto evidente, la correzione minima e reversibile è annotare lo stato attuale, fare un backup della configurazione se esiste, e solo dopo procedere alla rimozione dei pacchetti in eccesso. Qui il blast radius è medio: agisci sul runtime locale, ma puoi fermare container in esecuzione. Rollback: reinstallare i pacchetti precedenti o ripristinare la configurazione salvata.

2. Prerequisiti di sistema e chiavi del repository

Il repository Docker richiede i pacchetti base per HTTPS, gestione chiavi e repository APT. Su Ubuntu 22.04 la sequenza standard è breve e non ha effetti collaterali rilevanti oltre all’installazione di pacchetti utili al sistema. Questo è il punto in cui si evita l’errore classico: aggiungere il repository senza avere i prerequisiti, poi inseguire errori di firma o fetch falliti.

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

Ora crea la directory per le chiavi GPG e importa la chiave del repository Docker in formato dearmored, che è il metodo raccomandato nei sistemi moderni con APT. Questo evita l’uso di keyring legacy sparsi in posizioni deprecate.

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

Se il download della chiave fallisce, il problema non è Docker ma la connettività o un filtro in uscita. Verifica rapidamente con:

curl -I https://download.docker.com/linux/ubuntu/gpg

Atteso: risposta HTTP 200 o comunque una connessione valida. Se ottieni timeout o blocchi TLS, chiudi prima il problema di rete o proxy. Non ha senso proseguire con APT se il canale verso il repository è già rotto.

3. Aggiunta del repository Docker CE

Con la chiave pronta, configura il repository ufficiale per la release corrente. Su Ubuntu 22.04 il nome in codice è jammy. L’uso di `lsb_release -cs` riduce errori di digitazione e rende il comando riutilizzabile anche su host identici ma non necessariamente clonati in modo perfetto.

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

Subito dopo aggiorna l’indice dei pacchetti e controlla che APT veda il repository corretto, non quello generico di Ubuntu:

sudo apt update
apt-cache policy docker-ce | sed -n '1,20p'

Il risultato atteso è che docker-ce abbia candidate version disponibili dal dominio `download.docker.com`. Se vedi solo repository Ubuntu o nessuna candidate, il file in `/etc/apt/sources.list.d/docker.list` è sbagliato o la chiave non è stata letta correttamente. In quel caso la verifica più rapida è leggere il file:

cat /etc/apt/sources.list.d/docker.list
ls -l /etc/apt/keyrings/docker.gpg

4. Installazione di Docker CE, CLI e plugin utili

A questo punto puoi installare i componenti principali. Docker CE è il motore, `docker-ce-cli` è il client, `containerd.io` è il runtime di base, mentre i plugin `docker-buildx-plugin` e `docker-compose-plugin` coprono build avanzate e Compose v2. In pratica, installare solo il motore è una scelta monca: poi ti ritrovi a inseguire plugin mancanti quando devi fare build o gestire stack multi-container.

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Dopo l’installazione, controlla stato e versione. Qui non basta vedere il pacchetto installato: devi verificare che il servizio sia attivo e che il client parli con il daemon.

sudo systemctl status docker --no-pager
docker version
sudo docker version

Atteso: `dockerd` attivo e le versioni di client e server allineate o comunque compatibili. Se `docker version` senza sudo fallisce ma con sudo funziona, non è un guasto: è solo un problema di permessi sull’endpoint socket. Lo risolvi nella fase successiva.

5. Abilitare il servizio e gestire i permessi dell’utente

Per impostazione predefinita, il daemon parte con il sistema e ascolta sul socket Unix `/var/run/docker.sock`. Se vuoi usare Docker come utente normale senza anteporre `sudo` a ogni comando, devi aggiungere l’utente al gruppo `docker`. È comodo, ma va trattato come una scelta con implicazioni di sicurezza: chi può parlare con il socket Docker ha di fatto privilegi molto elevati sul sistema host.

Prima abilita il servizio al boot e avvialo subito:

sudo systemctl enable --now docker

Poi, se serve, aggiungi il tuo utente al gruppo dedicato:

sudo usermod -aG docker $USER

La modifica al gruppo richiede logout/login oppure una nuova sessione shell per diventare effettiva. Per verificare senza ambiguità:

id -nG
ls -l /var/run/docker.sock

Atteso: il gruppo `docker` compare nell’elenco dell’utente e il socket è di proprietà `root:docker`. Se vuoi limitare l’esposizione, lascia l’uso via `sudo` e non aggiungere utenti al gruppo. Questo è spesso il comportamento più prudente su host condivisi o bastion.

6. Test funzionale con un container minimale

Un’installazione non è davvero valida finché non lanci un container e verifichi il percorso completo: pull dell’immagine, creazione del container, avvio e output. Il test classico è `hello-world`, che è piccolo, chiaro e immediato da interpretare.

docker run --rm hello-world

Se tutto è a posto, vedrai un messaggio che conferma che Docker ha scaricato l’immagine e avviato il container. Questo è il punto di controllo più utile perché mette in evidenza problemi di rete, DNS, storage locale o daemon non operativo.

Se il pull fallisce, i casi da considerare sono pochi: DNS non risolve, firewall o proxy bloccano l’uscita, oppure il daemon non riesce a raggiungere Docker Hub. Per distinguere rapidamente, separa il problema di rete da quello del runtime:

getent hosts registry-1.docker.io
curl -I https://registry-1.docker.io/v2/
sudo journalctl -u docker -n 50 --no-pager

Atteso: risoluzione DNS corretta, risposta HTTP almeno coerente con il servizio registry, e nei log niente errori ripetitivi di connessione. Se invece il container parte ma poi fallisce in modo strano, controlla spazio disco e memoria disponibili: su host piccoli è facile che il problema non sia Docker ma la pressione generale del sistema.

7. Verifiche operative dopo l’installazione

Una volta installato Docker CE, il controllo non si ferma al test base. In ambiente reale ti interessano almeno tre aspetti: il servizio deve ripartire dopo un reboot, i container devono poter essere gestiti senza errori di permessi, e la macchina non deve mostrare segnali di saturazione lato storage o memoria dopo i primi avvii.

Controlli utili:

systemctl is-enabled docker
systemctl is-active docker
docker info | egrep 'Server Version|Storage Driver|Cgroup Driver|Docker Root Dir'

Il parametro `Docker Root Dir` merita attenzione perché indica dove Docker conserva immagini, layer e volumi. Su Ubuntu standard è spesso `/var/lib/docker`. Se il filesystem di root è piccolo, conviene anticipare il problema e spostare la directory dati su un volume più capiente, ma questa è già una decisione di design e non un passaggio obbligatorio dell’installazione base.

Per osservare eventuali errori iniziali del daemon, il log più utile è quello di systemd:

sudo journalctl -u docker --since "1 hour ago" --no-pager

Se trovi warning su overlay2, iptables o cgroup, non ignorarli: spesso sono segnali di configurazione del kernel o di conflitti con altri componenti di networking. In quel caso la correzione va fatta sul sistema, non su Docker in sé.

8. Aggiornamenti, rollback e igiene del repository

Il vantaggio del repository ufficiale è che gli aggiornamenti sono lineari, ma vanno comunque gestiti con disciplina. Su host di produzione non aggiornare “alla cieca”: prima leggi cosa sta per cambiare, poi pianifica una finestra e tieni pronto un rollback ragionato.

Per vedere le versioni disponibili:

apt list --upgradable | grep -E '^docker|containerd'
apt-cache policy docker-ce docker-ce-cli containerd.io

Se vuoi congelare una versione specifica, puoi usare il pinning di APT o bloccare i pacchetti. È utile quando hai validato una combinazione nota e non vuoi che un upgrade automatico cambi comportamento del runtime senza test.

sudo apt-mark hold docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Rollback tipico, se un aggiornamento rompe qualcosa: ripristinare la versione precedente dei pacchetti, riavviare il servizio e verificare che i container tornino nello stato atteso. Prima di farlo, però, controlla i log e identifica se il problema è davvero nel motore o in un container specifico. Non sempre il colpevole è Docker.

Se devi rimuovere il repository ufficiale, elimina il file in `/etc/apt/sources.list.d/docker.list` e poi aggiorna APT. Questo non rimuove i pacchetti già installati, ma evita che il sistema continui a proporre upgrade da un canale che non vuoi più usare.

sudo rm -f /etc/apt/sources.list.d/docker.list
sudo apt update

9. Note pratiche su sicurezza e gestione operativa

Installare Docker non significa aprire automaticamente una superficie d’attacco enorme, ma alcune scelte operative contano. Il gruppo `docker` equivale a un accesso molto potente al sistema, quindi va assegnato solo a utenti fidati. Il socket non va esposto su rete se non hai un motivo preciso e un modello di autenticazione adeguato. I secret non vanno messi in chiaro nei file Compose o nelle variabili di shell persistenti senza un meccanismo di rotazione e redazione.

Se il server è esposto a internet, cura anche il livello host: aggiornamenti regolari, firewall coerente con le porte realmente usate, e auditing minimo dei container in esecuzione. Un’installazione corretta oggi può diventare fragile domani se lasci crescere immagini vecchie, volumi non controllati e container orfani.

In sintesi operativa, la sequenza giusta su Ubuntu 22.04 è: prerequisiti, chiave, repository, installazione, verifica del daemon, test con un container minimale, poi eventuale tuning dei permessi. Se salti i controlli iniziali, spesso finisci a inseguire sintomi invece di risolvere la causa.