1 28/10/2026 10 min

Su Ubuntu 20.04 in WSL2 Podman si installa senza problemi particolari, ma va capito subito un punto: WSL2 non è una VM Linux tradizionale e non ti dà automaticamente tutte le primitive che Podman sfrutta in un host completo. Il risultato pratico è semplice: per uso rootless, test di container, build e flussi di sviluppo locale, Podman funziona bene; per scenari più vicini a una macchina Linux “piena”, con systemd, networking avanzato e servizi persistenti, bisogna verificare prima il contesto e scegliere la configurazione giusta.

La strada più pulita su Ubuntu 20.04 in WSL2 è questa: aggiornare il sistema, installare Podman dai repository ufficiali di Ubuntu, verificare la compatibilità con il kernel WSL e poi testare un container minimale. Se qualcosa non torna, il problema di solito non è l’installazione in sé, ma il modo in cui WSL2 gestisce cgroups, networking e systemd. In altre parole: prima osservi, poi modifichi.

Quando Podman su WSL2 è una scelta sensata

Podman è una buona scelta se vuoi un runtime container daemonless, compatibile con molte abitudini di Docker ma meno dipendente da un servizio centrale sempre acceso. Su WSL2 è utile per sviluppo applicativo, test di immagini, esecuzione di servizi locali e sperimentazione con container rootless. Non è invece la scelta ideale se vuoi replicare in modo identico un host Linux server con tutte le sue caratteristiche di init, networking e persistenza.

Il punto critico è che WSL2, soprattutto su Ubuntu 20.04, può richiedere qualche accortezza in più rispetto a una distribuzione Linux installata nativamente. Se il tuo obiettivo è lavorare in locale con container e immagini OCI, il setup è perfettamente ragionevole. Se invece vuoi usare Podman come infrastruttura per servizi “always on”, conviene verificare prima se il tuo ambiente WSL supporta bene systemd e i requisiti di rete che ti servono.

Prerogative minime prima di installare

Prima di toccare i pacchetti, conviene confermare tre cose: che sei davvero su WSL2, che Ubuntu sia aggiornato e che il kernel Windows sottostante sia recente abbastanza da non creare problemi inutili. Questo riduce molto il classico scenario in cui Podman è installato correttamente ma poi fallisce al primo avvio di un container.

Controlli utili:

wsl.exe -l -v
uname -a
cat /etc/os-release

Nel primo comando devi vedere la distribuzione Ubuntu con versione 2. Nel secondo, il kernel Linux deve indicare chiaramente che stai lavorando dentro WSL. Nel terzo, verifica che la release sia effettivamente 20.04. Se uno di questi tre punti non torna, fermati: installare Podman in un contesto non coerente crea solo rumore diagnostico dopo.

Installazione di Podman su Ubuntu 20.04

Su Ubuntu 20.04 puoi partire dal repository ufficiale della distribuzione. In molti casi è la scelta migliore perché evita repository esterni non necessari e mantiene il sistema più lineare da mantenere. Prima aggiorna l’indice pacchetti e poi installa Podman insieme a qualche utile dipendenza per il networking e l’uso rootless.

sudo apt update
sudo apt install -y podman uidmap slirp4netns fuse-overlayfs

Questi pacchetti coprono la base operativa più comune. uidmap serve per la gestione degli UID/GID nei container rootless, slirp4netns aiuta con il networking in user space e fuse-overlayfs è spesso utile come storage driver in ambienti dove overlay nativo non è la scelta più semplice. Se uno di questi pacchetti non è disponibile o viene installato con una versione inattesa, conviene verificare i repository abilitati prima di procedere oltre.

Dopo l’installazione, controlla la versione di Podman e la presenza del binario:

podman --version
which podman

Il primo comando deve restituire una stringa del tipo podman version x.y.z. Il secondo deve mostrare un percorso come /usr/bin/podman. Se il binario non c’è, il problema è banale ma va chiarito subito: installazione non riuscita, repository errato o conflitto con altri pacchetti.

Verifica del funzionamento con un container minimale

La prova migliore non è un comando teorico, ma un container minimale che parte, scarica un’immagine nota e stampa un output prevedibile. Per iniziare, usa un’immagine piccola e affidabile come Alpine o BusyBox. L’obiettivo è vedere se Podman riesce a risolvere il registro, scaricare l’immagine, avviare il container e terminare correttamente.

podman run --rm docker.io/library/alpine:latest echo OK

Se tutto funziona, l’output atteso è semplicemente OK. Se invece ottieni un errore di rete, di storage o di autorizzazioni, hai già la prima indicazione sul layer da indagare. In WSL2 gli intoppi più comuni sono: DNS non coerente, limiti del networking di user space, oppure problemi di configurazione dello storage rootless.

Podman rootless: perché conviene in WSL2

Su WSL2, rootless è spesso il modo più pulito di lavorare. Riduce l’impatto sul sistema, evita di dipendere da privilegi elevati per ogni operazione e rende più semplice separare l’ambiente container dal resto della sessione Linux. In pratica, se non hai un bisogno preciso di eseguire Podman come root, conviene partire da qui.

Per verificare che l’utente sia correttamente configurato per il rootless, controlla i subuid e subgid:

grep "^$(whoami):" /etc/subuid /etc/subgid

Se i due file non contengono una riga per il tuo utente, Podman rootless può funzionare male o in modo incompleto. In molti casi il pacchetto uidmap sistema gran parte della base, ma se i mapping non sono presenti puoi aggiungerli con attenzione. Prima verifica il contenuto esistente, perché toccare questi file senza controllo può rompere altri setup locali. Il rollback, in caso di modifica manuale, è banale: ripristini la riga precedente dal backup del file.

Attivare systemd in WSL2 quando serve davvero

Molti flussi con Podman non richiedono systemd, ma alcuni sì: gestione di servizi persistenti, socket activation, integrazione con unità utente e certe automazioni. Su WSL2, il supporto a systemd non va dato per scontato; dipende dalla configurazione della tua installazione di WSL e dalla versione del componente Windows. Se ti serve, va verificato esplicitamente.

Il file da controllare è /etc/wsl.conf. Un esempio minimale è questo:

[boot]
systemd=true

Dopo la modifica devi riavviare la distribuzione WSL dall’host Windows. Il controllo pratico è semplice:

ps -p 1 -o comm=

Se il comando restituisce systemd, la feature è attiva. Se restituisce altro, systemd non è disponibile in quella sessione. In quel caso non forzare soluzioni improvvisate: decidi prima se il tuo uso di Podman richiede davvero systemd oppure no. Per molti scenari di sviluppo la risposta è no.

Problemi tipici su WSL2 e come leggerli in fretta

Quando Podman non parte, la tentazione è reinstallare tutto. Di solito è la strada sbagliata. Meglio classificare il guasto per layer e fare un test mirato. Su WSL2 i tre punti da controllare per primi sono rete, storage e privilegi utente.

1. Rete/DNS. Se il pull dell’immagine fallisce, prova una risoluzione semplice con un nome noto. La falsificazione più rapida è un test di rete verso il registry o una risoluzione DNS dall’interno della distro. Se il DNS è incoerente, Podman sembra rotto ma non lo è.

getent hosts docker.io

2. Storage. Se il container scarica ma non parte, o se l’errore parla di overlay, mount o permessi, il problema può essere il driver di storage. Verifica il backend in uso con:

podman info --debug | grep -iE 'graphDriverName|graphRoot|runRoot'

Qui non serve indovinare: vuoi vedere dove Podman salva i dati e quale driver usa. Se il driver non è quello atteso, puoi intervenire con una modifica minima alla configurazione utente, ma prima conviene capire il comportamento reale dell’ambiente.

3. Privilegi e mapping. Se l’errore riguarda user namespaces, UID o GID, controlla i mapping e la presenza dei pacchetti necessari. In un ambiente rootless, mancano spesso proprio i prerequisiti che altrove vengono dati per scontati.

Configurazione utile per un uso quotidiano

Una volta verificato che Podman parte, puoi rendere l’esperienza più comoda con alcune impostazioni di base. La prima riguarda gli alias di compatibilità, se vieni da Docker e vuoi mantenere abitudini operative simili. La seconda riguarda il registries.conf, utile se vuoi evitare di digitare sempre il nome completo dell’immagine.

Per esempio, puoi testare un container con nome corto solo se hai registri configurati correttamente. In caso contrario, usa sempre il riferimento esplicito al registry, come già visto con docker.io/library/alpine:latest. È meno comodo, ma evita ambiguità e fallimenti strani dovuti alla risoluzione dei repository.

Se vuoi mantenere le cose semplici, il principio operativo è questo: prima fai funzionare il percorso completo e verificabile, poi accorci il resto. In ambienti misti come WSL2, questa prudenza fa risparmiare tempo.

Gestione delle immagini e pulizia senza sorprese

Podman conserva immagini, container e volumi nel profilo dell’utente o nel contesto root che stai usando. Su WSL2, se fai prove frequenti, lo spazio può crescere in fretta. Conviene quindi controllare periodicamente cosa è presente e rimuovere solo ciò che sai di non usare più.

podman images
podman ps -a
podman volume ls

Questi tre comandi ti danno la fotografia del sistema. Se trovi artefatti vecchi, puoi eliminarli con attenzione, ma solo dopo aver verificato che non servano a una pipeline di build o a un test in corso. Il blast radius qui è il tuo spazio locale, ma il rollback esiste solo se hai ancora l’oggetto da ripristinare o un’immagine da ricreare.

Se devi usare Podman come sostituto pratico di Docker

Molti installano Podman su WSL2 perché vogliono un’esperienza simile a Docker senza portarsi dietro il daemon. È una motivazione legittima, ma va gestita bene. Podman non è un clone identico: comandi simili non significano comportamento identico in ogni dettaglio. Conviene quindi validare i flussi che usi davvero: pull, run, volume, build, networking, esposizione porte.

Per esempio, se il tuo uso principale è avviare un database locale e un’applicazione web, verifica subito che le porte siano raggiungibili dal lato Windows e che il container mantenga il comportamento atteso al riavvio della sessione WSL. Se invece lavori con build di immagini, controlla il tempo di build, la cache e il comportamento dei layer. In WSL2 questi aspetti contano più di una semplice installazione riuscita.

Sequenza operativa consigliata, senza giri inutili

Se vuoi un percorso lineare, usa questa sequenza:

  1. Verifica che la distro sia Ubuntu 20.04 su WSL2 con wsl.exe -l -v e cat /etc/os-release.
  2. Aggiorna i pacchetti con sudo apt update.
  3. Installa Podman e le dipendenze utili con sudo apt install -y podman uidmap slirp4netns fuse-overlayfs.
  4. Controlla la versione con podman --version.
  5. Fai un test reale con podman run --rm docker.io/library/alpine:latest echo OK.
  6. Se serve, abilita systemd in /etc/wsl.conf e verifica con ps -p 1 -o comm=.
  7. Solo dopo, ottimizza storage, rete e mapping utente in base agli errori osservati.

Questa sequenza riduce il rischio di inseguire sintomi secondari. È il modo più rapido per capire se il problema è nell’installazione, nel runtime o nel contesto WSL2. Se qualcosa si rompe, hai già un punto preciso da cui tornare indietro: la configurazione di sistema o i pacchetti appena aggiunti, non l’intero ambiente.

Quando fermarsi e chiudere il cerchio

Se il test con Alpine funziona, il resto del lavoro è soprattutto rifinitura. Se invece fallisce, non conviene andare a tentativi. Leggi il messaggio d’errore, identifica il layer e correggi solo quello. Su WSL2, il comportamento migliore non è “fare di più”, ma fare meno cose e verificarle meglio.

In pratica, Podman su Ubuntu 20.04 in WSL2 è una soluzione valida per sviluppo e test, a patto di accettare i limiti dell’ambiente. Se ti serve un host container con caratteristiche da server vero, meglio valutare un Linux nativo o una VM dedicata. Se invece ti serve un ambiente leggero, rapido e ripetibile per il lavoro quotidiano, questa combinazione è assolutamente sensata.