Al Microsoft Build 2026, Microsoft ha annunciato WSL Container, una nuova funzionalità integrata nel Windows Subsystem for Linux (WSL) che consente di eseguire container Linux OCI-compatibili direttamente su Windows, senza la necessità di installare Docker Desktop o altri strumenti di terze parti.
Si tratta di un cambiamento significativo per sviluppatori e amministratori di sistema che lavorano in ambienti misti Windows/Linux, e che fino ad oggi dovevano fare affidamento su Docker Desktop (a pagamento per le organizzazioni sopra una certa dimensione) o su soluzioni alternative più complesse.
Perché WSL Container cambia le regole del gioco
Eseguire container Linux su Windows è da sempre un’operazione che richiede un livello di indirezione: Docker Desktop, ad esempio, avvia una macchina virtuale Linux in background e su di essa esegue i container. Questo approccio funziona bene, ma porta con sé costi di licenza, overhead di configurazione e una gestione centralizzata separata dalla piattaforma Windows stessa.
WSL Container integra questo meccanismo direttamente nel sistema operativo, eliminando la dipendenza da software di terze parti. Il risultato è una pipeline di sviluppo e operativa più snella, completamente gestibile tramite strumenti nativi Windows.
Come funziona tecnicamente
WSL Container esegue i container OCI all’interno di una macchina virtuale Hyper-V dedicata, separata dalle distribuzioni Linux WSL 2 tradizionali. La comunicazione tra il processo Windows e la VM avviene tramite Hyper-V socket, un canale a bassa latenza ottimizzato per la comunicazione host-guest in ambienti virtualizzati.
La configurazione predefinita della VM prevede:
- 2 vCPU
- 2.000 MB di RAM
- 32 GB di disco virtuale ad espansione dinamica
Questi parametri sono personalizzabili tramite l’SDK C# esposto dal pacchetto NuGet ufficiale.
Il CLI: wslc.exe
Il nuovo strumento da riga di comando wslc.exe sarà distribuito con il prossimo aggiornamento stabile di WSL. Microsoft ha scelto deliberatamente una sintassi analoga a Docker, così chi già conosce Docker non deve imparare nulla di nuovo:
# Avvia un container interattivo e rimuovilo all'uscita
wslc run --rm -it ubuntu:latest bash -c "echo Ciao da WSL Container!"
# Elenca le immagini disponibili localmente
wslc image ls
# Avvia un web server nginx in background, esponendo la porta 8080
wslc run -it --rm -d -p 8080:80 --name webserver nginx
# Elenca i container in esecuzione
wslc container ps
# Ferma il container
wslc container stop webserver
# Accesso a registry privati
wslc registry login registry.example.com
wslc registry logout registry.example.comLa portabilità dei comandi rispetto a Docker è intenzionale: permette di adottare WSL Container senza riscrivere script o pipeline esistenti.
Modalità di rete supportate
WSL Container supporta tre modalità di rete a livello di VM:
- none: nessuna connettività di rete
- NAT: il traffico della VM viene tradotto attraverso la rete dell’host Windows
- virtio-proxy: interfaccia di rete paravirtualizzata, con traffico più diretto e minore overhead
A livello di singolo container, si può scegliere tra bridge, host, none oppure condividere il namespace di rete di un altro container. Il publish delle porte, al momento, inoltro solo connessioni TCP su localhost.
API per sviluppatori Windows
Per chi sviluppa applicazioni Windows, WSL Container espone un’API programmatica via NuGet che include:
- Una libreria C nativa (
wslcsdk.dll) - Una proiezione WinRT (la moderna superficie API di Windows)
- Bindings C# per integrazione .NET
Tramite l’API è possibile: scaricare immagini, creare e avviare container, gestire stdin/stdout, pubblicare porte, montare volumi e abilitare il pass-through GPU. Microsoft cita come scenari d’uso principali i workload AI locali, le pipeline di test e l’elaborazione basata su Linux, anche se i dettagli tecnici specifici sono ancora limitati data la fase di preview.
Controllo enterprise con Group Policy
Per gli ambienti aziendali, WSL Container introduce un’impostazione di Group Policy chiamata WSLContainerRegistryAllowlist. Questa policy limita i registry da cui gli utenti possono scaricare immagini: se un utente tenta di fare pull da un registry non in lista, l’operazione fallisce con l’errore WSLC_E_REGISTRY_BLOCKED_BY_POLICY.
La policy viene applicata a livello di servizio e vale sia per il CLI, sia per l’API, sia per eventuali plugin. Non è aggirabile chiamando l’SDK direttamente. Si tratta di un controllo importante per le organizzazioni che devono garantire la provenienza delle immagini container usate dai team di sviluppo.
Stato attuale e limitazioni
Come chiarito dalla documentazione Microsoft Learn, WSL Container è ancora in sviluppo attivo al momento della scrittura di questo articolo (giugno 2026). Non è ancora disponibile in una release stabile di WSL. Per seguire l’avanzamento del progetto, Microsoft rimanda al repository open-source microsoft/wsl su GitHub.
Tra le informazioni non ancora pubblicate: la versione minima di Windows richiesta, le specifiche di compatibilità hardware, e la roadmap per la disponibilità generale (GA).
Perché è rilevante per sistemisti e DevOps
L’integrazione nativa dei container Linux in Windows apre scenari interessanti:
- Riduzione dei costi di licenza: nessun Docker Desktop a pagamento per le organizzazioni grandi
- Gestione centralizzata via Group Policy: controllo degli allowlist di registry già nei tool di amministrazione esistenti
- Pipeline CI/CD semplificate: possibilità di eseguire container Linux in ambienti Windows senza dipendenze esterne
- Workload AI locali: esecuzione di modelli o pipeline ML su macchine Windows di sviluppo con pass-through GPU
Vale la pena monitorare l’evoluzione di questa funzionalità, specialmente per i team che lavorano su Windows e hanno bisogno di compatibilità con l’ecosistema container Linux.
Fonte: 4sysops – WSL container: Linux containers built into Windows | Microsoft Build 2026