Windows 11 può ora creare, eseguire e amministrare container Linux direttamente tramite WSL (Windows Subsystem for Linux), senza richiedere necessariamente Docker Desktop, Podman Desktop o altri prodotti che aggiungono un proprio livello di gestione. Microsoft ha infatti portato WSL Containers, abbreviato in WSLC, alla disponibilità generale e integra una piattaforma container accessibile dalla nuova utility wslc.exe.
La novità era comparsa a fine giugno 2026 con WSL 2.9.3 in anteprima pubblica. Da allora Microsoft ha aggiunto parecchie funzioni e, il 29 settembre 2026, ha annunciato la disponibilità pubblica di WSLC. Per installarla basta eseguire un semplice comando (lo vediamo tra poco).
Come spiega Microsoft nell’annuncio di fine settembre, WSL Containers non è semplicemente Docker rinominato e non è ancora un sostituto perfettamente intercambiabile di Docker Desktop. Microsoft ha costruito un proprio modello per eseguire container Linux sopra l’infrastruttura WSL; molti comandi ricordano volutamente quelli Docker, così chi li conosce può iniziare quasi subito, ma esistono differenze importanti. Ad esempio, al momento della pubblicazione di questa guida manca ancora il supporto integrato a Compose. Microsoft lo indica esplicitamente come una delle prossime priorità e punta a consentire in futuro l’utilizzo dei normali file compose.yaml senza modificarli.
Da WSL 1 ai container Linux integrati in Windows
La prima incarnazione di WSL seguiva una strada profondamente diversa da quella attuale. Microsoft aveva sviluppato un livello di compatibilità capace di interpretare le chiamate di sistema effettuate dai binari Linux ELF e tradurle verso il kernel Windows. Immaginatevi una sorta di Wine alla rovescia, ovvero con l’obiettivo di far funzionare su Windows i binari Linux.
Con WSL 2, annunciato nel 2019, Microsoft ha abbandonato la soluzione del livello di compatibilità in favore di un vero kernel Linux eseguito attraverso una macchina virtuale ben integrata con Windows.
È la scelta che ha reso possibile usare con molta maggiore fedeltà shell Linux, package manager, systemd, tool GNU, compilatori, database, server Web, applicazioni grafiche (che sono integrabili con l’interfaccia di Windows!), CUDA e strumenti destinati normalmente ai server Linux.
WSL Containers rappresenta un’altra estensione di quest’architettura: anziché limitarsi a ospitare distribuzioni come Ubuntu, Debian, Fedora o Kali, WSL diventa anche la base su cui Windows può creare e amministrare direttamente ambienti containerizzati Linux.
Come installare WSL Containers
Su un PC sul quale WSL 2 risulta già presente, apriamo la finestra del terminale Windows e impartiamo il seguente comando:
wsl --update
Chiudiamo quindi la finestra del terminale (è molto importante!) e riapriamola.
Controlliamo la versione installata con wsl --version e verifichiamo la presenza di WSLC avvalendoci di wslc version. Possiamo inoltre utilizzare wslc --help per ottenere l’elenco delle operazioni disponibili.
È disponibile anche l’alias container che elabora esattamente gli stessi comandi che wslc può ricevere e gestire. Esempio: container --help.
Il primo test: avviare un container Linux
Il modo più semplice per verificare il funzionamento di WSL Containers consiste nell’eseguire:
wslc run --rm hello-world
Se l’immagine non esiste localmente, WSLC la scarica automaticamente e la avvia. L’opzione --rm chiede di eliminare automaticamente il container quando termina.
Digitando wslc run --rm -it ubuntu:latest bash ci troviamo dentro una shell Bash Ubuntu eseguita in un container Linux.
L’opzione -i, come avviene con Docker, mantiene aperto lo standard input; -t crea un terminale pseudo-TTY.
Possiamo così provare i comandi seguenti quindi uscire con exit:
cat /etc/os-release
uname -a
Eseguire un server Web e raggiungerlo da Windows
Un esempio ancora più utile consiste nell’avviare nginx all’interno di un container WSLC:
wslc run -d --rm -p 8080:80 --name web nginx
L’opzione -d avvia il container in background; -p 8080:80 mappa la porta TCP 8080 del PC Windows sulla porta 80 del container; --name web assegna al container il nome web.
Da Windows, possiamo quindi digitare nella barra degli indirizzi del browser predefinito l’URL localhost:8080 oppure usare il comando curl http://localhost:8080.
Il server HTTP gira dentro Linux ma risponde direttamente sul localhost del sistema Windows. Fantastico, no? È uno degli aspetti sui quali Microsoft ha lavorato maggiormente con la nuova architettura di rete.
Come verificare quali container Linux stanno funzionando in Windows 11
Per elencare i container attivi, basta usare il comando seguente:
wslc container list
È disponibile anche la forma:
wslc container ps
Per includere quelli arrestati:
wslc container list --all
Le versioni più recenti hanno inoltre avvicinato ulteriormente formato e opzioni a quelli usati da Docker, aggiungendo ad esempio informazioni sulle dimensioni e formattazione JSON.
Come eseguire un comando in un container già avviato
Se il nostro container nginx si chiama web, possiamo eseguire un comando al suo interno senza aprirne una nuova istanza:
wslc exec web cat /etc/os-release
Oppure aprire una shell:
wslc exec -it web sh
Se l’immagine contiene Bash:
wslc exec -it web bash
È un approccio utilissimo per analizzare un’applicazione in esecuzione, verificare file di configurazione, processi e variabili d’ambiente oppure effettuare test manuali.
Per visualizzare l’output prodotto da un container, si può semplicemente impartire questo comando:
wslc container logs web
Capire davvero com’è configurato un container
Quando qualcosa non funziona conviene ricorrere al comando Inspect che mostra le proprietà interne del container: immagine utilizzata, configurazione, rete, mount, variabili d’ambiente e altri dati utili per la diagnostica.
wslc container inspect web
Lo stesso principio vale per le immagini:
wslc image inspect nginx
Per osservare le risorse utilizzate dai container, è sufficiente usare il comando seguente. È molto utile quando sul PC sono attivi contemporaneamente Web server, database, servizi di sviluppo o applicazioni AI:
wslc stats
WSLC supporta anche limiti associabili al singolo container: si può quindi evitare che un container particolarmente pesante occupi una quantità eccessiva di memoria o CPU.
Arrestare, riavviare ed eliminare un container
Per arrestare un container, basta usare la sintassi wslc container stop web. La versione di WSLC appena distribuita globalmente aggiunge inoltre il comando
wslc container restart web
Per cancellare una risorsa che non serve più si può utilizzare il relativo comando rm.
L’opzione --stop-timeout, disponibile con wslc create e wslc run, consente inoltre di stabilire quanto tempo concedere al processo affinché termini correttamente prima dell’arresto forzato. Microsoft permette anche --stop-timeout -1 per indicare un’attesa senza limite.
Le immagini possono occupare rapidamente diversi gigabyte e i container arrestati possono accumularsi nel tempo. WSLC mette a disposizione i seguenti comandi per eliminare le risorse non più necessarie. Le versioni più recenti hanno inoltre reso il comportamento di prune più simile a quello della CLI Docker:
wslc container prune
wslc image prune
Copiare file dentro e fuori dai container
Una delle aggiunte più interessanti comparse con la disponibilità generale di WSL Containers è il comando che che consente di trasferire file tra host e container:
wslc container cp
Microsoft implementa l’operazione tramite archivi tar e nelle versioni più recenti ha aggiunto ulteriori opzioni, compresa la possibilità di seguire collegamenti tramite --follow-link. È una funzione particolarmente utile per recuperare log, configurazioni o risultati prodotti dal container senza creare preventivamente un volume permanente.
Tra gli esempi citati da Microsoft sottolineamo quello che segue:
wslc container run -v C:WindowsSystem32driversetc:/volume -it debian:latest ls /volume
Una sintassi di questo tipo permette di montare file conservati nell’host Windows all’interno del container, in questo caso nella cartella Linux /volume. In questo modo si può far sì che Windows e Linux possano lavorare sugli stessi dati e accedervi senza difficoltà.
Dietro le quinte WSLC espone la directory alla macchina Linux tramite VirtIOFS, quindi la rende disponibile nel container attraverso un bind mount. È un dettaglio tecnico importante perché spiega anche uno dei miglioramenti prestazionali più interessanti.
Monitorare gli eventi in tempo reale
WSLC dispone anche del comando wslc events che genera un flusso in tempo reale degli eventi relativi ai container e, nelle versioni più recenti, anche alle reti.
Può diventare molto utile durante il debugging: invece di controllare ripetutamente lo stato delle risorse, si osservano direttamente creazioni, avvii, arresti e altre transizioni mentre avvengono.
Un’altra novità introdotta durante il percorso verso la versione finale di WSLC è il comando che riassume lo stato dell’ambiente e offre un primo punto di partenza quando si devono diagnosticare anomalie:
wslc system info
Per chi amministra molti container, avere una vista complessiva evita di interrogare singolarmente immagini, reti e sessioni.
Come funzionano le immagini di WSL Containers
WSLC può scaricare, creare, salvare, importare, esportare, ispezionare e cancellare immagini container. Per visualizzare quelle presenti basta usare uno dei seguenti due comandi:
wslc image list
wslc image ls
La gestione comprende operazioni quali pull, push, import, load, save, inspect e prune. WSLC non serve soltanto a eseguire immagini già preparate: permette anche di costruire le proprie.
Supponiamo di aver sviluppato una piccola applicazione Python: possiamo creare un file chiamato Containerfile con questo contenuto descrittivo:
FROM python:3 WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD ["python", "app.py"]
Lanciando dalla directory del progetto quanto segue, possiamo costruire un container Linux “ad hoc”, controllare l’aggiunta alla lista delle immagini disponibili ed esporre l’applicazione sulla porta indicata:
wslc build -t mia-app .
wslc image list
wslc run -d --rm -p 8000:8000 --name mia-app mia-app
Volumi VHD: ext4 invece di NTFS condiviso
WSLC introduce una possibilità particolarmente interessante per applicazioni che richiedono un vero file system Linux. Possiamo creare un volume supportato da un VHD:
wslc volume create --driver vhd -o SizeBytes=200000000 my-volume
e montarlo:
wslc container run -v my-volume:/volume -it debian:latest
All’interno del container, Microsoft mostra che il volume appare come un dispositivo con file system ext4 anziché come una semplice cartella Windows condivisa.
È una soluzione utile soprattutto per database e software Linux che dipendono da semantiche POSIX, ownership, permessi, link e comportamento del file system difficili da replicare perfettamente sopra NTFS. Il volume VHD permette inoltre di stabilire una dimensione massima.
Come funziona WSLC dietro le quinte
WSL Containers usa un modello di sessione distinto rispetto al normale WSL: le richieste passano attraverso wslservice.exe, il servizio Windows che dialoga con HCS (Host Compute Service), ma la gestione operativa della macchina virtuale viene affidata a wslcsession.exe, eseguito nel contesto dell’utente.
È quest’ultimo componente a occuparsi di creazione dei container, mount, porte, reti e storage. La separazione riduce il codice che deve operare con privilegi elevati e permette di mantenere isolate le varie sessioni WSLC.
Quando serve terminare completamente l’ambiente container si può usare wslc system session terminate. Agisce sulla sessione WSLC, a differenza del più generale wsl --shutdown.
Consommé: rete integrata con Windows
WSLC introduce anche una modalità di rete chiamata Consommé, progettata per far transitare il traffico Linux attraverso Windows in modo più naturale.
Il traffico Ethernet generato dalla VM passa attraverso code VirtIO ed è gestito da un processo Windows associato all’utente della sessione. Da qui vengono forniti DNS, routing TCP e UDP e port mapping. L’obiettivo è soprattutto migliorare la compatibilità con VPN, proxy, firewall endpoint e policy aziendali, casi nei quali una macchina virtuale tradizionale può comportarsi come un host di rete separato.
WSLC permette inoltre di creare reti dedicate e collegare o scollegare i container:
wslc network connect
wslc network disconnect
È quindi possibile separare, ad esempio, frontend, backend e database e consentire la comunicazione soltanto dove serve.
Health check, GPU e workload AI
WSLC supporta anche gli health check, utili per distinguere un container semplicemente “in esecuzione” da un servizio realmente funzionante. Per i carichi accelerati è disponibile anche --gpus all.
Un esempio fornito da Microsoft usa PyTorch:
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"
WSLC sfrutta anche CDI, Container Device Interface, per descrivere e rendere disponibili dispositivi hardware ai container.
La funzione è interessante per inferenza AI, CUDA, PyTorch, elaborazione video e calcolo scientifico, ma non elimina i normali requisiti hardware e software: driver Windows, GPU, librerie richieste dall’immagine e compatibilità dello stack continuano a essere determinanti.
VS Code e Dev Containers
WSLC può essere usato anche dai Dev Containers di Visual Studio Code: nelle impostazioni dell’estensione è possibile indicare Docker Path: wslc in modo che VS Code utilizzi WSL Containers come backend al posto di Docker Desktop.
Microsoft cita inoltre integrazioni con Aspire, l’estensione Containers di VS Code, Lazywslc e WSL Container Desktop.
Le API WSL Containers
Uno degli aspetti più interessanti di WSLC non riguarda direttamente la CLI, ma le API disponibili per le applicazioni Windows.
Microsoft distribuisce il pacchetto NuGet Microsoft.WSL.Containers, installabile con dotnet add package Microsoft.WSL.Containers.
Il modello ruota principalmente attorno a quattro oggetti: WslcService, che verifica e inizializza il servizio; Session, che rappresenta l’ambiente WSL; Container, che gestisce il ciclo di vita dell’istanza; Process, che rappresenta un processo Linux avviato al suo interno.
Un’applicazione Windows può quindi verificare WSL, scaricare un’immagine, creare un container, montare file o directory, avviare un processo, leggere stdout e stderr, inviare dati su stdin, terminare le risorse senza chiedere all’utente di amministrare manualmente l’ambiente Linux.
È probabilmente uno degli sviluppi più interessanti di WSLC: un programma Windows può incorporare un componente Linux come parte della propria architettura, ad esempio un motore di elaborazione, una toolchain, un servizio Web o un modello AI.
Microsoft supporta inoltre l’integrazione con MSBuild e CMake, permettendo di inserire creazione e distribuzione dei container direttamente nel processo di compilazione dell’applicazione.
Conclusioni
WSL Containers porta WSL un passo oltre il ruolo di semplice ambiente Linux integrato in Windows: con WSLC diventa possibile creare immagini, avviare container, pubblicare porte, usare volumi, reti dedicate, GPU e persino integrare la gestione dei container direttamente nelle applicazioni Windows tramite API ufficiali.
La somiglianza con Docker rende l’approccio immediato per chi conosce già i container, ma WSLC mantiene una propria architettura e non va considerato, almeno per ora, un sostituto perfettamente equivalente del Docker Engine o di Docker Desktop. Alcune funzioni avanzate, e soprattutto Compose, devono ancora maturare.
Il vantaggio principale è un altro: Windows 11 dispone ormai di una piattaforma container Linux strettamente integrata con WSL, senza imporre necessariamente l’installazione di un runtime desktop separato. Per sviluppatori, ambienti di test, strumenti DevOps e applicazioni che necessitano di componenti Linux, è una possibilità concreta da valutare già oggi.
Resta infine una distinzione importante sul piano della sicurezza. Un container offre isolamento tra processi e applicazioni, ma non costituisce automaticamente una sandbox sicura per eseguire codice ostile. Microsoft stessa chiarisce che WSL non rappresenta di per sé un security boundary: per codice non attendibile è quindi preferibile ricorrere a una macchina virtuale o a un ambiente progettato espressamente per fornire un isolamento più forte.
Powered by WPeMatico