Come eseguire Linux su Windows Server 2022 con WSL

WSL su Windows Server 2022: quando ha senso davvero

Su Windows Server 2022, WSL non è un trucco per “mettere Linux dentro Windows” e basta. È una possibilità utile quando sul server Windows ti servono tool Linux, script Bash, utility di build, diagnostica o piccoli ambienti di lavoro che devono stare vicino al sistema Windows senza aprire subito una VM completa. La distinzione importante è questa: WSL è comodo per eseguire software Linux lato amministrazione e sviluppo, non è la risposta giusta per ogni carico server Linux classico.

Su un host server, la domanda corretta non è “si può installare?”, ma “cosa devo farci girare e con quali vincoli?”. Se devi eseguire Ansible, Bash, Python, strumenti di rete, parser, agent leggeri o pipeline locali, WSL è spesso pratico. Se invece vuoi un web stack Linux completo con systemd, reverse proxy, database e servizi persistenti esposti in produzione, la valutazione cambia: una VM Linux resta spesso più pulita da gestire e da supportare.

La differenza tra WSL 1 e WSL 2 su un server

La scelta reale è quasi sempre WSL 2. WSL 1 traduce le chiamate Linux sul kernel Windows e oggi ha senso soprattutto in casi particolari di compatibilità o accesso ai file Windows. WSL 2 usa invece un vero kernel Linux in una macchina virtuale molto leggera gestita da Windows. Questo cambia parecchio il comportamento: filesystem, rete, integrazione con processi e prestazioni non sono identici a un host Linux nativo.

Su Windows Server 2022 il punto da tenere a mente è semplice: WSL 2 è il modello da considerare per la maggior parte degli scenari utili. Ti dà un ambiente Linux più fedele, ma introduce anche la natura “virtualizzata” del sottosistema. Il risultato pratico è che i file dentro la distribuzione Linux vanno bene per lavorare, mentre i file montati dal filesystem Windows possono diventare il collo di bottiglia se li usi in modo intensivo.

Primo controllo: prerequisiti e compatibilità

Prima di installare, verifica tre cose: edizione corretta di Windows Server 2022, virtualizzazione abilitata e aggiornamenti recenti. Il server deve poter usare i componenti di virtualizzazione richiesti da WSL 2. Se la virtualizzazione è disattivata a livello BIOS/UEFI o non è disponibile nel layer hypervisor, l’installazione può fallire o degradare verso comportamenti non desiderati.

Per un controllo rapido da PowerShell amministrativo, puoi partire da questi comandi:

systeminfo | findstr /i "Hyper-V Requirements"
wsl --status
wsl --version

Se wsl --version non è disponibile, non significa automaticamente che tutto sia rotto: dipende dal livello di aggiornamento della macchina e dalla presenza dei componenti più recenti. Quello che ti interessa è capire se il server riconosce WSL, se il sottosistema è installato e se la versione di default è coerente con l’uso che devi fare.

Installazione pulita su Windows Server 2022

Su Server 2022, l’approccio più lineare è usare PowerShell con privilegi elevati. Il vantaggio non è estetico: è che hai una procedura ripetibile e verificabile. Prima abiliti le feature necessarie, poi riavvii, poi installi la distribuzione Linux, infine fai il primo avvio e configuri l’utente.

Una sequenza tipica è questa:

DISM /Online /Enable-Feature /FeatureName:Microsoft-Windows-Subsystem-Linux /All /NoRestart
DISM /Online /Enable-Feature /FeatureName:VirtualMachinePlatform /All /NoRestart
shutdown /r /t 0

Dopo il riavvio, verifica lo stato e imposta WSL 2 come default se il server lo supporta:

wsl --set-default-version 2
wsl --list --verbose

Il passo successivo è installare una distribuzione. Su server, in pratica, conviene scegliere una distro minimale e prevedibile, come Ubuntu LTS o Debian, se il tuo obiettivo è avere strumenti standard e meno sorprese sui pacchetti. L’installazione può avvenire con il Microsoft Store dove disponibile, oppure con import manuale di una rootfs se il contesto server è più controllato e lo store non è una strada desiderabile.

Distribuzione Linux: scelta pratica, non religiosa

La distro va scelta in base al lavoro, non per abitudine. Se devi fare amministrazione generica, scripting e tool molto diffusi, Ubuntu LTS è spesso la scelta più rapida per disponibilità di pacchetti e documentazione. Se vuoi un ambiente più sobrio e lineare, Debian è una buona alternativa. Se il tuo flusso dipende da software specifico, la compatibilità dei pacchetti conta più del gusto personale.

Su WSL, il tema non è solo la disponibilità del pacchetto, ma anche il modo in cui il filesystem e i processi si comportano. Una distribuzione molto leggera può sembrare “meglio” finché non ti serve un tool che assume certi comportamenti di sistema. Al contrario, una distro più comune riduce il rischio di dover inseguire workaround inutili.

Integrazione con Windows: cosa funziona bene e cosa no

Il punto forte di WSL è l’integrazione. Dal lato operativo puoi lanciare eseguibili Linux da Windows e viceversa, scambiare file, usare script misti e tenere vicino strumenti che altrimenti richiederebbero una VM dedicata. Questo è utile su un server quando devi fare troubleshooting o automazione locale senza sporcare l’host con tool Windows equivalenti o packaging instabili.

Il limite è altrettanto chiaro: non devi dare per scontato che ogni servizio Linux si comporti come su una macchina Linux completa. Alcuni demoni, integrazioni con systemd e scenari di rete avanzata meritano verifica specifica. Se il tuo processo richiede avvio automatico al boot del kernel Linux, gestione dei socket in modo classico e controllo stretto di permessi e namespace, devi testare con attenzione prima di dichiararlo idoneo alla produzione.

Filesystem: il dettaglio che fa la differenza

Il filesystem è spesso il primo punto dove WSL smette di sembrare “magico”. In pratica, i file dentro il filesystem Linux della distro sono più adatti a carichi Linux reali. I file montati da C:\ o da volumi Windows possono essere comodi per lavorare, ma non sono il posto ideale per operazioni molto chatty, tante letture piccole o tool che fanno scansioni massive. In quei casi le prestazioni possono degradare in modo evidente.

La regola pratica è semplice: se il carico è Linux-centrico, tienilo nel filesystem Linux. Se devi solo leggere o scrivere pochi file condivisi con Windows, il mount va bene. Se invece parliamo di build pesanti, repository grandi, cache di dipendenze o processi che aprono migliaia di file, conviene misurare prima di decidere. Il riscontro non è teorico: differenze di latenza e throughput si vedono subito.

Per un test minimale puoi confrontare operazioni sul filesystem Linux e su un path Windows montato, ad esempio con un semplice time su una copia di file di prova. Non serve sofisticazione: basta capire se il collo di bottiglia è il layer di storage e non il tool che stai eseguendo.

Rete e accesso ai servizi: attenzione ai dettagli operativi

Su WSL 2 la rete è virtualizzata. Per l’uso quotidiano va bene, ma quando devi esporre un servizio o fare troubleshooting su porte e binding, conviene verificare bene dove sta ascoltando il processo. Un servizio che in Linux ascolta su 127.0.0.1 non è automaticamente raggiungibile dal modo in cui ti aspetti lato Windows o da una macchina esterna. Il test corretto è sempre quello di verificare porta, binding e reachability reale.

Per esempio, se avvii un web server dentro WSL e vuoi raggiungerlo dal sistema Windows host, controlla prima il listening socket nella distro:

ss -lntp

Se il servizio risponde solo su localhost Linux, l’accesso esterno non è garantito. Se invece ascolta su 0.0.0.0 o su un’interfaccia corretta, il passo successivo è capire come viene instradato dal layer WSL. In scenari più seri, il test da fare è sempre doppio: dentro la distro e dal lato Windows con curl o Test-NetConnection.

Systemd, servizi persistenti e avvio automatico

Uno dei fraintendimenti più comuni è pensare che WSL equivalga a una normale VM Linux per la gestione dei servizi. La realtà è più sfumata. Oggi alcune integrazioni sono migliorate, ma il comportamento di startup e persistenza va comunque validato con cura. Se devi eseguire servizi che devono restare su, essere monitorati e avere restart policy chiare, il test di resilienza è obbligatorio.

Se ti serve un processo Linux persistente, verifica che la tua distribuzione e la configurazione WSL supportino il modello che vuoi usare. Il controllo base resta sempre lo stesso: avvio, restart, stop, verifica log. Se il servizio non si comporta in modo deterministico dopo un riavvio dell’host Windows, non è un buon candidato per essere trattato come servizio core.

In pratica, per attività amministrative o strumenti che lanci manualmente, il problema è limitato. Per un servizio da tenere acceso h24, il rischio operativo cresce e la documentazione interna deve descrivere chiaramente cosa succede dopo reboot, update di Windows e sospensione/riattivazione dell’host.

Uso tipico su server: casi in cui WSL è una buona scelta

Ci sono casi in cui WSL su Server 2022 è sensato e pulito. Uno è il troubleshooting: hai bisogno di grep, awk, sed, curl, jq, strumenti SSH e script Bash senza aprire una VM. Un altro è la compatibilità applicativa leggera: un piccolo tool Linux che gira accanto a un ambiente Windows esistente, magari per automatizzare export, check, inventari o conversioni file.

Un altro scenario utile è il bridge operativo: il server Windows ospita un software principale, ma i tecnici hanno bisogno di un ambiente Linux locale per validare comandi, testare script o fare analisi di log con tool più comodi. In questo caso WSL riduce tempi e attrito, senza costringerti a introdurre una seconda macchina virtuale solo per tool di supporto.

Il criterio corretto è la durata del carico e la sua criticità. Più il carico è breve, controllato e legato all’amministrazione, più WSL è interessante. Più il carico è un servizio stabile, esposto, con requisiti di audit e ripristino, più una VM o un host Linux nativo torna ad avere senso.

Quando evitare WSL e scegliere altro

Evita WSL se il tuo obiettivo è sostituire un server Linux tradizionale con le stesse garanzie operative. Non è la strada giusta quando contano isolamento forte, lifecycle classico dei servizi, tuning profondo del kernel, integrazione completa con systemd e amministrazione standardizzata su Linux puro. Anche in presenza di supporto tecnico, il costo di spiegare eccezioni e limiti può superare il vantaggio iniziale.

Evitalo anche se il server è già carico e poco prevedibile. WSL 2 introduce un ulteriore layer che consuma risorse e aggiunge variabili. Su una macchina già tirata tra database, applicazione Windows e processi di backup, aggiungere un ambiente Linux non è gratis. Prima misura CPU, RAM, I/O e latenza; poi decidi.

Verifiche finali: stabilità, consumo e ripetibilità

Dopo l’installazione, il controllo serio non è “parte?”. È: si avvia sempre, consuma il previsto, resta accessibile, si aggiorna senza rompere il resto? Le verifiche minime sono tre: elenco distro, versione effettiva, accesso a un comando Linux banale e ripetibile.

wsl --list --verbose
wsl -d Ubuntu -- uname -a
wsl -d Ubuntu -- cat /etc/os-release

Se questi comandi rispondono in modo coerente, hai una base buona. A quel punto puoi aggiungere test applicativi: script, accesso a filesystem, connessioni in uscita, eventuale esposizione di porte e integrazione con task schedulati o procedure manuali. Il criterio è sempre lo stesso: ogni passaggio deve essere ripetibile da un secondo operatore, non solo da chi ha fatto l’installazione.

Gestione operativa e manutenzione

Su un server, la manutenzione vale quanto l’installazione. Tieni traccia della versione di Windows Server, della distro, delle feature abilitate e di eventuali eccezioni di rete o filesystem. Se usi WSL per attività importanti, conviene documentare anche il percorso di recovery: come reinstallare la distro, dove stanno i dati, cosa è effettivamente persistente e cosa invece vive nel layer della distribuzione.

Per sicurezza, tratta la distribuzione come un sistema separato dal punto di vista delle credenziali. Non salvare segreti in chiaro negli script, non lasciare token in file condivisi e non dare per scontato che il contesto Linux erediti le stesse protezioni del sistema Windows. Se devi gestire chiavi SSH, password o token API, usa meccanismi di vault, file protetti e rotazione controllata.

Per performance e affidabilità, la regola è conservativa: misura prima, sposta i dati nel filesystem giusto, evita di usare WSL come contenitore generico per servizi critici e documenta sempre il rollback. Se qualcosa dipende da WSL in modo strutturale, il piano di ritorno deve essere già scritto: disabilitazione feature, export dei dati necessari e ripristino su VM o host alternativo.

Decisione pratica: criterio rapido per scegliere

Se ti serve un ambiente Linux di supporto su Windows Server 2022, WSL è una scelta sensata. Se ti serve un vero server Linux da governare come tale, no. La linea di confine è netta: tooling e automazione leggera sì, sostituzione di una piattaforma Linux completa no. È una distinzione utile perché evita di trasformare una comodità operativa in una dipendenza fragile.

In pratica, la domanda finale da farsi è semplice: il beneficio principale è velocità operativa per l’amministratore, oppure è erogazione stabile di un servizio Linux? Nel primo caso WSL ha senso. Nel secondo, meglio un Linux vero, con i suoi strumenti, il suo ciclo di vita e la sua curva di gestione, invece di forzare un compromesso che prima o poi presenta il conto.