Installare Docker Desktop su Ubuntu 24.04 LTS passo dopo passo

Docker Desktop su Ubuntu 24.04 LTS: cosa cambia davvero

Su Ubuntu 24.04 LTS Docker Desktop si può installare, ma non va confuso con il pacchetto docker-ce usato sui server. Qui parliamo di un prodotto desktop con interfaccia grafica, integrazione con WSL no ovviamente, ma con una VM interna, supporto per container, immagini, compose e Kubernetes locale. La scelta ha senso se lavori da workstation Linux e vuoi un ambiente coerente con Mac e Windows, soprattutto quando devi testare stack misti o fare debugging con GUI e volumi condivisi.

La prima decisione tecnica è semplice: se ti serve solo il motore container per automazione o server, usa Docker Engine nativo. Se ti serve il desktop ufficiale con UI, estensioni e funzioni aggiuntive, Docker Desktop è il prodotto giusto. Su Ubuntu 24.04 LTS il punto delicato non è tanto l’installazione in sé, quanto la gestione di dipendenze, permessi, integrazione con il gruppo docker e possibili conflitti con installazioni precedenti.

Prerequisiti e controlli prima di installare

Prima di scaricare il pacchetto conviene verificare che la macchina sia allineata con la release e che non ci siano residui di installazioni vecchie. L’errore classico è avere già Docker Engine, plugin compose, containerd o snapshot di configurazioni che poi confondono l’avvio del Desktop.

1. Verifica la versione del sistema operativo con lsb_release -a oppure con cat /etc/os-release. L’atteso è Ubuntu 24.04 LTS.
2. Controlla l’architettura con uname -m. Su una workstation moderna ti aspetti x86_64 o aarch64 se sei su ARM compatibile.
3. Controlla spazio libero con df -h. Per un uso reale conviene avere margine su / e sulla home, perché immagini e volumi crescono in fretta.
4. Se Docker è già presente, fai una fotografia con docker version, docker compose version e dpkg -l | grep -E 'docker|containerd'.

Se emergono pacchetti già installati, non partire alla cieca. Il modo corretto è capire se stai facendo una sostituzione, una coesistenza o una migrazione. In particolare, Docker Desktop può convivere con Docker Engine, ma la convivenza spesso crea confusione operativa: due socket, due contesti, due modi diversi di avviare i container.

Scaricare il pacchetto corretto senza introdurre ambiguità

Il metodo più pulito è scaricare il pacchetto .deb ufficiale dal sito del vendor e installarlo localmente. Per Ubuntu 24.04 LTS, in genere la build per Debian/Ubuntu è quella giusta. Se stai lavorando in un contesto aziendale, conviene verificare checksum e policy di download prima di distribuire il file.

1. Scarica il pacchetto dal canale ufficiale e salvalo, per esempio, in /tmp.
2. Se disponibile, confronta l’hash pubblicato con sha256sum.
3. Evita repository terzi o pacchetti ricompattati: qui il rischio non è teorico, perché il Desktop installa componenti privilegiati e modifica integrazioni di sistema.

Un esempio di flusso minimale da terminale è questo:

cd /tmp
curl -LO https://desktop.docker.com/linux/main/amd64/docker-desktop-amd64.deb
sha256sum docker-desktop-amd64.deb

Se sei su ARM, il nome del file cambia. Il controllo più importante non è il nome in sé ma la corrispondenza tra architettura del pacchetto e macchina reale. Un mismatch qui si vede subito: dpkg rifiuta il pacchetto oppure il sistema non avvia correttamente i componenti.

Installazione con dpkg e dipendenze mancanti

Su Ubuntu il percorso più lineare è usare dpkg per installare il pacchetto e poi correggere eventuali dipendenze con apt. Questo è il classico caso in cui il primo comando può segnalare errori non fatali: non è una fallita installazione completa, spesso è solo un problema di librerie richieste dal pacchetto.

1. Installa il pacchetto con sudo dpkg -i docker-desktop-*.deb.
2. Se dpkg segnala dipendenze mancanti, risolvile con sudo apt -f install.
3. Rilancia l’installazione solo se il sistema lo richiede esplicitamente, altrimenti verifica direttamente lo stato del pacchetto.

sudo dpkg -i /tmp/docker-desktop-amd64.deb
sudo apt -f install

Durante questa fase è normale che vengano creati servizi systemd, file di integrazione desktop e componenti per l’avvio automatico. Il punto da tenere sotto controllo è che l’installazione non deve lasciare il sistema in uno stato parziale. Se dpkg fallisce, leggi l’errore testuale prima di riprovare: spesso indica esattamente quale libreria o pacchetto manca.

Avvio iniziale e verifica del servizio

Dopo l’installazione, Docker Desktop va avviato una prima volta dall’interfaccia grafica o dal menu applicazioni. Su Linux il primo avvio può richiedere qualche secondo in più perché il software prepara il backend, inizializza la VM interna e crea i contesti utente.

1. Avvia Docker Desktop dal menu applicazioni oppure con il launcher del desktop environment.
2. Verifica che l’icona mostri stato attivo e che la dashboard sia accessibile.
3. Da terminale, controlla che il client veda il motore con docker version e docker info.

Se il comando docker info restituisce errore di connessione al socket, il problema non è necessariamente nell’applicazione: può essere un permesso utente, un servizio non partito o un conflitto con l’installazione precedente. In questi casi la diagnostica utile è immediata:

systemctl --user status docker-desktop

e, se serve, anche il controllo dei log utente:

journalctl --user -u docker-desktop -b

Il risultato atteso è un servizio in stato active (running) o comunque senza errori ripetuti. Se vedi crash loop, il primo sospetto non è il container che stai cercando di eseguire, ma il desktop engine stesso.

Permessi, gruppo docker e accesso senza sudo

Molti problemi “strani” dopo l’installazione sono in realtà banalissimi problemi di permessi. L’utente che usa Docker Desktop deve poter interagire con il socket e con i componenti del backend senza dover forzare sudo in modo continuo. Su una workstation ben configurata, l’applicazione gestisce il proprio contesto utente, ma vale comunque la pena verificare il gruppo docker se usi anche il motore classico.

1. Controlla i gruppi dell’utente con groups.
2. Se serve l’accesso al socket del motore classico, aggiungi l’utente al gruppo con sudo usermod -aG docker $USER.
3. Esci e rientra nella sessione grafica per applicare la modifica.

Il comando precedente non è distruttivo, ma ha un effetto concreto sulla sessione. Se lo fai, verifica dopo il login che groups mostri il gruppo docker. Se non compare, non inseguire bug immaginari: il problema è quasi sempre che la sessione non è stata riaperta.

Conflitto con Docker Engine già installato

Qui sta il punto che crea più rumore nelle workstation Linux. Docker Desktop e Docker Engine possono coesistere, ma non devi dare per scontato che siano equivalenti. Il Desktop usa il proprio contesto e la propria orchestrazione interna; il motore nativo usa il servizio classico di sistema. Se li mescoli senza criterio, il risultato è che un container sembra partire in un posto e non nell’altro, oppure che il client punta al daemon sbagliato.

Per capire a quale motore sei collegato, usa questi controlli:

docker context ls
docker context show
docker info | grep -E 'Context|Server Version|Docker Root Dir'

Se il contesto attivo non è quello atteso, correggilo esplicitamente. Non affidarti alla memoria operativa: in ambienti con più test installati la variabile d’ambiente o il contesto Docker cambia facilmente.

1. Elenca i contesti con docker context ls.
2. Se serve, imposta quello corretto con docker context use desktop-linux oppure il contesto disponibile nella tua installazione.
3. Riesegui docker info e controlla che il server risponda dal backend corretto.

Se invece vuoi usare solo Docker Engine nativo e non Docker Desktop, allora la strada è diversa: disinstalli il Desktop e tieni il motore di sistema. Non fare il contrario a metà, perché la coesistenza non aggiunge valore se il tuo obiettivo è solo servire container in locale.

Test funzionale con container effimero

La verifica vera non è “si apre la finestra”, ma “riesco a eseguire un container e a vedere output coerente”. Il test più semplice resta quello con hello-world, perché riduce le variabili al minimo.

docker run --rm hello-world

Il risultato corretto è un messaggio di benvenuto e l’uscita del container con codice zero. Se invece il comando resta bloccato, oppure segnala pull fallito, allora devi distinguere tra problema di rete, problema di registry, problema di DNS locale o problema del backend Docker.

Un test leggermente più utile per una workstation è un container con porta pubblicata:

docker run --rm -p 8080:80 nginx:alpine

In un secondo terminale apri http://localhost:8080. Se la pagina risponde, hai validato rete, port mapping e backend. Se non risponde, il debug deve seguire il layer: porta occupata, firewall locale, backend non attivo, contesto errato.

Integrazione con Compose e flusso quotidiano

Per uso reale, Docker Desktop serve spesso come ambiente di lavoro per stack composti. Qui il punto è verificare che docker compose funzioni come previsto e che i volumi persistano dove ti aspetti. La differenza tra un ambiente “apre i container” e uno usabile davvero sta tutta nella ripetibilità del compose file.

Un test utile è un file minimale che espone una porta e monta un volume locale. Per esempio:

services:
  web:
    image: nginx:alpine
    ports:
      -