Il 29 settembre 2026 Microsoft ha reso generalmente disponibili i #container #WSL, portando su #Windows la possibilità di eseguire container #Linux nativi senza installare #Docker Desktop. La funzionalità arriva con wslc.exe, un nuovo strumento a riga di comando integrato direttamente nel Windows Subsystem for Linux (WSL 3.0.1), e segna un passo importante per chi lavora quotidianamente con container su macchine Windows: sviluppatori .NET, team #DevOps e sistemisti che gestiscono ambienti ibridi.

In questo articolo vediamo cosa cambia rispetto a Docker Desktop, come installare e usare wslc, quali sono i controlli enterprise disponibili tramite #Intune e #Defender for Endpoint, e quali limiti bisogna conoscere prima di adottarlo in produzione.

Perché WSL containers e non “solo” Docker DesktopFino ad oggi, eseguire container Linux su Windows significava quasi sempre installare Docker Desktop, che a sua volta si appoggia su una VM WSL2 per fornire il kernel Linux. Con i container WSL, Microsoft sposta il motore dei container direttamente dentro l’infrastruttura WSL, eliminando uno strato intermedio: niente demone Docker separato da gestire, niente licenza Docker Desktop da considerare per le aziende con più di 250 dipendenti o oltre 10 milioni di dollari di fatturato (requisito che per molte realtà italiane ha reso Docker Desktop un costo da giustificare).

Il risultato dichiarato da Microsoft è un accesso ai file Windows fino a 2 volte più veloce rispetto alle soluzioni basate su virtiofs tradizionale, grazie a un nuovo modello di rete chiamato internamente “Consommé mode”, che instrada il traffico della VM attraverso un processo Windows eseguito con i permessi dell’utente della sessione, migliorando la compatibilità con VPN aziendali e firewall perimetrali — uno scenario molto comune nelle reti enterprise italiane dove Docker Desktop spesso va in conflitto con client VPN come Cisco AnyConnect o Fortinet.

Installazione e primi comandiNon serve installare nulla di separato: wslc.exe è incluso a partire da WSL 3.0.1. Basta aggiornare WSL dal prompt dei comandi o da PowerShell:

wsl --update
wsl --versionIl comando wsl --version deve riportare almeno la 3.x (oppure 2.9.3+ per chi è rimasto sul canale di anteprima). Fatto questo, si può avviare subito un primo container di prova:

wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"Per un caso d’uso più realistico, ecco come avviare un web server Nginx in background con il port forwarding verso l’host Windows:

wslc run -it --rm -d -p 8080:80 --name web nginx
curl localhost:8080La gestione del ciclo di vita dei container ricalca la sintassi Docker, cosa che rende la curva di apprendimento quasi nulla per chi già conosce Docker CLI:

wslc container ps
wslc container stop web
wslc container restart web
wslc container cp web:/var/log/nginx/access.log .
wslc system info
wslc eventsCon la GA sono arrivati anche comandi per la gestione della rete, utili quando si orchestrano più container che devono comunicare tra loro:

wslc network create mynet
wslc network connect mynet web
wslc network disconnect mynet webPer le immagini, sono supportati i flag più comuni per operazioni di pull/push ed ispezione:

wslc pull --all-tags myregistry/myimage
wslc image list --all --digests
wslc image inspect --size myregistry/myimageArchitettura: cosa succede sotto il cofanoDal punto di vista architetturale, Microsoft ha separato le responsabilità in due processi distinti:

wslservice.exe crea la macchina virtuale WSL ma non ne mantiene la proprietà operativa dei container;

wslcsession.exe, eseguito a livello utente, gestisce effettivamente i container, il mounting dei volumi e il binding delle porte.

Questa separazione mantiene isolate le operazioni privilegiate dal resto, un dettaglio che conta per chi deve valutare la postura di sicurezza dell’ambiente. Ogni sessione utente ha il proprio disco virtuale dedicato, salvato in %AppData%\Local\wslc\sessions, che contiene immagini, container, reti e volumi di quella sessione. I path Windows vengono montati tramite virtiofs, mentre i filesystem nativi Linux usano volumi basati su VHD per prestazioni migliori.

Supporto GPU e integrazione .NETPer chi sviluppa su Windows con carichi di lavoro che richiedono accelerazione hardware (training di modelli, inferenza locale, elaborazione video), l’accesso alla GPU è esposto tramite il nuovo pacchetto NuGet Microsoft.WSL.Containers, che oltre alla GPU espone anche stdin/stdout, mount di file e configurazione di rete direttamente da codice C#. È un’ottima notizia per i team .NET che vogliono orchestrare container Linux senza uscire dal proprio stack di sviluppo abituale, magari dentro una pipeline di test o un tool interno scritto in C#.

Da notare che il supporto per la projection C++/WinRT è ancora in anteprima e soggetto a breaking change, mentre l’API per sviluppatori C# risulta più stabile e pronta per un uso quotidiano.

Controlli enterprise: Intune e Defender for EndpointPer i reparti IT che devono governare l’adozione di questa tecnologia in azienda, Microsoft ha introdotto due leve di controllo tramite Intune:

Allow WSL containers access: un interruttore on/off per abilitare o disabilitare completamente la funzionalità sui dispositivi gestiti;

WSL containers registry allow list: permette di restringere il pull delle immagini solo ai registry approvati, un controllo fondamentale per evitare che gli utenti scarichino immagini da fonti non verificate.

Sul fronte della sicurezza runtime, il plugin WSL di Microsoft Defender for Endpoint è stato esteso per coprire anche i container, mostrando attività di processo, file e rete collegate all’host Windows. È importante sottolineare che si tratta di visibilità e capacità di indagine, non di un meccanismo di enforcement in tempo reale: Defender segnala e documenta, ma la prevenzione attiva resta affidata alle policy Intune.

I limiti da conoscere prima di migrarePrima di sostituire Docker Desktop in produzione, vale la pena considerare alcuni limiti ancora presenti alla GA:

Nessun supporto Compose: è la funzionalità più richiesta dalla community e il lavoro è iniziato, ma Microsoft non ha ancora comunicato una data di rilascio. Chi ha workflow multi-servizio basati su docker compose up dovrà continuare a usare strumenti alternativi o avviare manualmente i singoli container;

Compatibilità “quasi” totale: test di terze parti riportano buona compatibilità con i comandi Docker esistenti, ma non totale — vale la pena testare gli script di automazione esistenti prima di un rollout su larga scala;

API C++/WinRT instabile: chi sviluppa tooling nativo in C++ dovrà aspettarsi possibili breaking change nelle prossime release.

Conclusione: chi dovrebbe provarlo subitoPer sviluppatori singoli e piccoli team che non dipendono da Docker Compose, i container WSL rappresentano già oggi un’alternativa solida, gratuita e integrata nativamente in Windows, con un vantaggio prestazionale concreto sull’I/O dei file. Per i team che si affidano a Compose nei workflow quotidiani, conviene affiancare wslc agli strumenti attuali e monitorare l’evoluzione del supporto. Per i reparti IT enterprise, il consiglio è di testare i controlli di governance (Intune e Defender) in un gruppo pilota prima di abilitare la funzionalità su larga scala, verificando in particolare il comportamento con le VPN aziendali e i registry Docker privati già in uso.

Fonte: 4sysops.com e WindowsForum

Per anni Docker è stato il default indiscusso quando si parlava di container su Linux. Ma l’architettura basata su un daemon centrale che gira come root ha sempre lasciato sul tavolo un problema di superficie d’attacco: se qualcuno compromette dockerd, ha di fatto accesso root all’intero host. Podman nasce proprio per chiudere questo gap, offrendo un motore container daemonless, compatibile con le immagini OCI e con la CLI Docker, che si integra in modo molto più nativo con systemd e con il modello di permessi di Linux.

Vediamo come installarlo, come si differenzia realmente da Docker oltre gli slogan, e come portarlo in produzione con systemd e le Quadlet, che sono probabilmente la ragione migliore per prenderlo sul serio.

Cos’è Podman, in praticaPodman (da Pod Manager) è un motore container open source senza demone centrale. Ogni container gira come processo figlio dell’utente che lo ha avviato, non come figlio di un servizio di sistema con privilegi elevati. Questo significa che è possibile eseguire container completamente rootless, senza mai invocare sudo, riducendo drasticamente cosa un container compromesso può effettivamente toccare sull’host.

Sotto il cofano Podman usa gli stessi runtime OCI di Docker e parla lo stesso formato immagine, quindi la stragrande maggioranza dei comandi Docker funziona invariata sostituendo semplicemente il nome del binario (o creando un alias docker=podman, oppure installando il pacchetto podman-docker che fa da shim trasparente).

Un concetto che Docker non ha nativamente è quello di pod: gruppi di uno o più container che condividono rete e storage, concettualmente vicini ai pod di Kubernetes. Comodo quando si vogliono far girare insieme più container che devono comunicare come se fossero sulla stessa macchina.

Installazione# Debian/Ubuntu (Debian 11+, Ubuntu 20.10+)
sudo apt-get update
sudo apt-get -y install podman

Fedora/CentOS/RHEL 8+

sudo dnf -y install podman

openSUSE

sudo zypper install podman

Arch/Manjaro

sudo pacman -S podmanVerifica dell’installazione:

podman --version
podman info
podman run hello-worldSe l’ultimo comando restituisce il messaggio di benvenuto di Podman, l’installazione è a posto.

Uso quotidiano: i comandi non cambiano quasi nullaShell interattiva dentro un container Ubuntu:

podman run -it ubuntu bashServizio in background, con Nginx esposto sulla porta 8080 dell’host:

podman run -d --name web -p 8080:80 nginx
podman psIl resto della CLI ricalca Docker praticamente 1:1: podman pull, podman images, podman stop/start, podman rm/rmi. Dietro le quinte, podman build è in realtà un wrapper attorno a Buildah, mentre lo spostamento di immagini tra registry passa per Skopeo: strumenti separati che Podman orchestra per te, senza che serva conoscerli nel dettaglio per l’uso base.

Dove Docker e Podman divergono davveroLa compatibilità è alta ma non totale, e i problemi emergono quasi sempre dal modello rootless. Il caso più comune sono i bind mount: poiché i container rootless usano user namespace e mapping subuid/subgid, una directory montata dall’host non sempre ha la proprietà che il container si aspetta. Su sistemi con SELinux attivo serve anche il suffisso :z o :Z per far ri-etichettare correttamente i file:

podman run -v /host/path:/container/path:Z myimage:z minuscolo condivide il volume tra più container, :Z maiuscolo lo rende privato per un singolo container. Se serve far coincidere esattamente la proprietà con quella dell’host, l’opzione --uidmap permette un controllo fine, oppure si può far girare il container in modalità rootful per replicare il comportamento di Docker.

Altri attriti da conoscere prima di migrare: l’accesso GPU da container rootless è limitato (NVIDIA richiede nvidia-container-toolkit e setup CDI, con i container da ricreare a ogni aggiornamento driver), e i Docker secrets insieme ad alcune configurazioni di rete non hanno una corrispondenza 1:1. Niente di bloccante, ma va testato prima di assumere che la migrazione sia un semplice “find and replace”.

Container come servizi systemd: le QuadletQuesto è probabilmente il motivo migliore per scegliere Podman in un contesto server. Invece di lasciare un demone in background a gestire lo stato dei container, si delega tutto a systemd, che diventa responsabile di avvio, riavvio e supervisione, esattamente come per qualsiasi altro servizio di sistema.

Il meccanismo si chiama Quadlet: un file dichiarativo con estensione .container che Podman traduce automaticamente in una unit systemd. Per un servizio utente rootless, il file va in ~/.config/containers/systemd/. Esempio minimo per Nginx:

[Container]
ContainerName=web
Image=docker.io/library/nginx:latest
PublishPort=8080:80

[Install]
WantedBy=default.targetAttivazione:

systemctl --user daemon-reload
systemctl --user start webDa questo momento il container è gestito da systemd come un servizio qualsiasi: si riavvia in caso di crash, si integra con i log di journald, si può abilitare al boot. Aggiungendo l’etichetta AutoUpdate=registry a un container, inoltre, podman auto-update può controllare periodicamente nuove versioni dell’immagine e riavviare il servizio in automatico, senza bisogno di Watchtower o strumenti equivalenti.

Migrare da Docker ComposeChi ha un’infrastruttura basata su Compose ha due strade percorribili. La prima è continuare a usare Compose così com’è: il binario standalone docker compose può puntare al socket di Podman senza toccare i file docker-compose.yml esistenti:

systemctl --user enable --now podman.socketLa seconda è convertire i file Compose in Quadlet, così che sia systemd a gestire tutto nativamente. Scrivere le unit a mano è tedioso, quindi conviene usare podlet, un tool che legge un docker-compose.yml e genera i file Quadlet corrispondenti. C’è una curva di apprendimento, ma è comunque più veloce che partire da zero.

Docker resta rilevanteNonostante i vantaggi di Podman, Docker non sta scomparendo. L’ecosistema attorno a Docker (Compose, Swarm, e tutta la tooling che si integra con esso, inclusi molti sistemi CI/CD già configurati per il socket Docker) resta enorme, e non tutte le piattaforme gestiscono bene le peculiarità rootless di Podman. Se un team è già standardizzato su Docker, spesso ha più senso restare sull’esistente piuttosto che affrontare una migrazione per un guadagno marginale.

Dove Podman convince davvero è quando si parte da zero: setup più sicuro per default, nessun demone da tenere sotto controllo, integrazione diretta con systemd per la gestione del ciclo di vita dei servizi.

ConclusionePodman è un motore container completo, compatibile con Docker, che funziona senza demone e senza bisogno di privilegi root. Per l’uso quotidiano è quasi un drop-in replacement: si installa dal repository della distribuzione, si usano gli stessi comandi (o si crea l’alias docker=podman), e si ottengono benefici di sicurezza concreti senza dover reimparare nulla. I limiti di compatibilità, soprattutto su bind mount, GPU e secrets, vanno conosciuti e testati prima di una migrazione in produzione, ma per chi sta impostando nuovi ambienti containerizzati su Linux, specialmente se pensa di gestirli con systemd e Quadlet, vale decisamente la pena valutarlo.

Fonte originale: Hayden James, “Docker Alternative: Podman on Linux”, LinuxBlog.io.