Microsoft ha aperto la preview pubblica dei container WSL su Windows 11 e i primi test mostrano una novità molto concreta: è possibile costruire, avviare e gestire container Linux senza passare da Docker Desktop o da altri runtime desktop di terze parti.
Il punto interessante è che tutto resta dentro l’ecosistema WSL, con un nuovo strumento da riga di comando e un’API dedicata. Per chi sviluppa su Windows, significa un flusso più nativo e integrato, anche se al momento restano alcuni limiti importanti sul fronte orchestrazione, interfaccia grafica e analisi delle immagini.
I container WSL portano Linux su Windows 11 in modo più diretto
La nuova funzione aggiunge a WSL una capacità container nativa: dopo l’aggiornamento, il sistema integra il tool wslc. exe, già inserito nel PATH, con anche l’alias container. exe. In pratica, Windows 11 può eseguire container Linux direttamente nel contesto WSL, senza richiedere una piattaforma desktop esterna dedicata.
Microsoft accompagna questa parte con una WSL Container API distribuita come pacchetto NuGet e compatibile con C, C++ e C#. Questo permette anche agli sviluppatori Windows di incorporare container Linux nelle proprie applicazioni, con un approccio più vicino all’integrazione software che alla semplice gestione manuale da terminale.
- Strumento principale: wslc.exe con alias container.exe.
- Gestione nativa di build, run e amministrazione dei container Linux in Windows 11.
- API dedicata disponibile via NuGet per C, C++ e C#.
- La tecnologia è già stata mostrata in scenari reali, come l’esecuzione del motore di rendering Linux open source Moonray dentro un eseguibile Windows.
Come funziona nella pratica tra installazione, avvio e riconnessione ai container
L’attivazione passa dall’aggiornamento di WSL in canale pre-release. Una volta completato il processo e riavviato WSL, il comando wslc –version deve restituire la versione 2.9. 3.0, segnale che il supporto ai container è stato installato correttamente.
Nei test, il comando wslc run -it debian:latest ha scaricato e avviato un container Debian senza passaggi aggiuntivi. All’interno del container, uname -a ha confermato la presenza di un kernel Linux legato a WSL2.
È stato provato anche il processo di build con un Containerfile, che funziona in modo analogo a un Dockerfile. Il comando wslc build -t my-linux-inspector consente quindi di creare immagini usando una sintassi familiare a chi lavora già in ambienti containerizzati.
- Aggiornamento iniziale con wsl –update –pre-release.
- Riavvio dell’ambiente con wsl –shutdown.
- Verifica dell’installazione con wslc –version.
- Esecuzione di un container Debian con wslc run -it debian:latest.
- Elenco dei container con wslc ps -a e riconnessione con wslc attach.
Isolamento più forte, ma oggi ci sono compromessi rispetto a Docker Desktop
Sul piano architetturale, ogni applicazione Windows che usa la WSL Container API riceve una macchina virtuale Hyper-V dedicata; anche il flusso da riga di comando dispone di una propria VM isolata. È una scelta che punta molto sull’isolamento, ma che si differenzia dal modello di Docker Desktop, basato su una singola VM condivisa per tutti i container.
La conseguenza pratica è chiara: Docker Desktop resta più efficiente nell’uso delle risorse quando si lavora con più container sullo stesso host. Inoltre, la preview WSL non offre ancora strumenti ormai considerati standard in molti team, come orchestrazione multi-servizio in stile Docker Compose, pannello grafico di controllo o funzioni di scansione immagini paragonabili a Docker Scout.
- Ogni app o flusso CLI ottiene una VM Hyper-V dedicata.
- Docker Desktop usa invece una VM condivisa, in genere più efficiente sulle risorse.
- Manca un sistema multi-servizio equivalente a Docker Compose.
- Assenti per ora un pannello grafico e strumenti integrati di scansione immagini.
