1 21/10/2026 12 min

Su Windows Server 2019 e 2022 Docker non si tratta come su un desktop Windows con Docker Desktop: qui il punto non è “installare l’app”, ma allineare versione del sistema operativo, tipo di container, runtime e rete a ciò che Microsoft supporta davvero in ambito server. La differenza pratica è semplice: se vuoi eseguire container Windows, devi stare dentro il perimetro dei container Windows; se vuoi container Linux, su Windows Server la strada non è nativa e richiede un host diverso o una strategia alternativa.

La decisione architetturale prima dell’installazione

Il primo errore tipico è partire dall’installazione senza chiarire il vincolo principale: Windows Server 2019 e 2022 eseguono container Windows, non container Linux in modo nativo. Se l’obiettivo è far girare immagini Linux, la soluzione corretta è usare un host Linux, una VM Linux su Hyper-V, oppure un’infrastruttura separata. Cercare scorciatoie su Windows Server porta quasi sempre a una catena di problemi su networking, filesystem e compatibilità del runtime.

Se invece il target è eseguire applicazioni .NET Framework, IIS, servizi Windows o workload Windows containerizzati, allora il percorso è sensato. In quel caso devi scegliere anche il formato del container: process isolation o Hyper-V isolation. Il primo è più leggero ma richiede compatibilità stretta tra host e image; il secondo offre un isolamento maggiore e spesso è la scelta più sicura quando la compatibilità è meno lineare.

Compatibilità tra Windows Server 2019, 2022 e le immagini container

La regola operativa è: host e image devono essere allineati a livello di versione base di Windows. Su Windows container non puoi ragionare come su Linux, dove un’immagine può girare su kernel diversi con più elasticità. Qui la base dell’immagine conta molto di più. In pratica, un host 2019 deve usare immagini costruite per quel ramo o per una compatibilità prevista; lo stesso vale per 2022. Quando il mismatch c’è, il sintomo non è elegante: il container non parte, oppure parte e poi fallisce con errori di runtime poco chiari.

Per questo, prima di toccare il server, controlla la build del sistema operativo:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

Se vuoi il dettaglio della build e della release, un controllo più utile è:

wmic os get Caption,Version,BuildNumber /value

Il dato che ti interessa non è estetico: serve per capire se l’immagine che intendi usare è coerente con l’host. Se non hai certezza, la verifica più pulita è provare una singola immagine ufficiale compatibile con la tua versione di Windows Server e leggere l’errore in modo letterale, senza andare a tentativi su più tag.

Docker su Windows Server: cosa installare davvero

Storicamente, su Windows Server l’approccio corretto è stato usare il runtime container supportato da Microsoft e non il flusso tipico di Docker Desktop. Oggi la scelta pratica dipende dal tuo scenario, ma il principio resta: non installare componenti superflui. Se ti serve il motore container per workload Windows, installa ciò che è richiesto per l’host server e limita il resto.

Per verificare lo stato dei ruoli e delle funzionalità di container, puoi usare PowerShell:

Get-WindowsFeature *container*

Se il ruolo non è abilitato, l’output ti dice esattamente cosa manca. In ambienti server conviene sempre preferire un’installazione dichiarativa e verificabile, perché riduce il rischio di avere prerequisiti incompleti. Dopo l’abilitazione, un riavvio può essere necessario. È una banalità, ma su Windows Server saltare il reboot è una delle cause più comuni di “è installato ma non funziona”.

Windows Server 2019: scenario tipico e limiti pratici

Su Windows Server 2019 la domanda vera non è “posso usare Docker?”, ma “quale tipo di workload voglio eseguire?”. Se il carico è composto da applicazioni Windows containerizzate, il server è assolutamente utilizzabile. Se invece il tuo stack è composto da immagini Linux standard, la risposta operativa è no: non è il posto giusto. In molte migrazioni la scelta migliore è lasciare Windows Server per i componenti Windows-only e spostare i servizi Linux su VM o host dedicati.

Quando si lavora con Windows Server 2019, il punto critico è anche la rete. I container Windows usano driver e modalità che non sempre si comportano come ci si aspetta da un ambiente Linux. Se devi esporre porte, integrare DNS o far parlare container e host con servizi esterni, verifica prima la topologia. Non dare per scontato che il bridge networking “funzioni uguale” a quello di Linux.

Un controllo utile, prima di andare oltre, è vedere se il servizio container risponde e se il motore è disponibile:

Get-Service docker

Se il servizio non esiste, il problema è a monte: non c’è un engine operativo. Se esiste ma è fermo, la diagnosi passa dai log del servizio e dall’event viewer. Su Windows Server non è raro che un problema di prerequisiti o di aggiornamento cumulativo lasci il servizio installato ma inutilizzabile.

Windows Server 2022: perché è più semplice, ma non “magico”

Windows Server 2022 è in genere una base migliore per i container Windows perché è più recente, più allineata con le immagini moderne e meno esposta a vecchie incompatibilità. Questo non significa che tutto funzioni automaticamente: significa solo che riduci il numero di eccezioni da gestire. Il vantaggio reale si vede quando usi immagini aggiornate, pipeline di build coerenti e host patchato.

Il rischio più comune su 2022 è la falsa sensazione di essere “coperti” dal fatto che il sistema è nuovo. In realtà, se l’immagine è stata costruita male o il tagging è ambiguo, il problema resta identico. Quindi la verifica non deve fermarsi alla versione del server: devi controllare anche il tag dell’immagine, la base layer e il comportamento del container in esecuzione.

Per un test minimo, usa un’immagine ufficiale coerente con il tuo ramo e verifica che il container si avvii e resti in stato running. Un esempio concettuale è questo:

docker run --isolation=process mcr.microsoft.com/windows/servercore:ltsc2022 cmd /c ver

Se il container non parte, la prima ipotesi da falsificare è la compatibilità tra host e image. Se parte ma fallisce l’applicazione, allora il problema è a livello di runtime dell’app, non del motore container.

Installazione e verifica del motore: approccio operativo

In ambiente server conviene procedere per passi piccoli e reversibili. Prima verifica i prerequisiti, poi il servizio, poi un container di test. Questo evita di confondere un errore di installazione con un errore applicativo. La logica è semplice: prima il motore, poi la rete, poi l’app.

Una sequenza di controllo sensata è questa:

  1. Verifica la versione di Windows Server e annota la build.
  2. Controlla che il supporto ai container sia installato e che il servizio sia presente.
  3. Avvia un container di test con immagine ufficiale compatibile.
  4. Controlla log, stato del servizio e risposta del container.

Se vuoi uno snapshot rapido della situazione, usa anche i processi e il servizio:

Get-Process | Where-Object {$_.ProcessName -match "dock|container"}

Non è il comando “più bello”, ma in troubleshooting veloce aiuta a capire se il motore è vivo e se il sistema sta effettivamente eseguendo componenti legati ai container. Se non vedi nulla, non significa per forza guasto: potrebbe significare semplicemente che il servizio non è stato avviato o che il nome del processo è diverso in base al layer installato.

Rete, porte e DNS: il punto che rompe quasi tutto

Su Windows Server i problemi di container si presentano spesso come problemi di rete. Il container parte, ma l’app non risponde; oppure risponde in locale ma non dall’esterno; oppure il DNS interno non risolve i nomi come previsto. Qui bisogna distinguere tra reachability del container e reachability del servizio pubblicato. Sono due cose diverse.

Il controllo minimo da fare è sempre lo stesso: verifica che la porta sia in ascolto sull’host e che il servizio risponda. Per esempio:

netstat -ano | findstr :8080

Se la porta non compare, il problema è nel mapping o nel processo applicativo. Se compare ma dall’esterno non raggiungi il servizio, allora il colpevole è più probabilmente firewall, policy di rete o binding errato. In ambienti con firewall restrittivo, la verifica deve includere anche le regole in ingresso del Windows Defender Firewall e, se presente, eventuali ACL di rete o security group esterni.

Un dettaglio pratico che spesso viene dimenticato: alcuni team testano il container solo dal server stesso e concludono che tutto sia a posto. In realtà la prova vera è da una macchina esterna, perché è lì che emergono i problemi di NAT, binding su localhost e filtri di rete. Il test locale dice poco se stai pubblicando un servizio.

Storage, log e permessi: dove si nascondono gli errori sporchi

Quando Docker o il runtime container su Windows Server si comportano in modo anomalo, controlla subito tre cose: spazio disco, log e permessi. Su sistemi Windows Server un volume quasi pieno può degradare il comportamento del motore in modo molto meno evidente rispetto a un crash netto. Il sintomo può essere un avvio lento, un pull che si blocca o un container che non scrive correttamente i file temporanei.

La verifica dello spazio è banale ma non negoziabile:

Get-PSDrive -PSProvider FileSystem

Per i log, su Windows Server conviene controllare sia i log del servizio sia quelli di sistema. Se il motore è installato come servizio, l’errore vero spesso si trova nell’Event Viewer, non nel prompt. Il percorso da guardare è quello di Windows Logs, in particolare System e Application. Se hai un log applicativo dedicato, usalo, ma non dare per scontato che basti.

Quanto ai permessi, evita di eseguire container o processi con privilegi più alti del necessario. In ambienti server la tentazione di “farlo partire come amministratore” è forte, ma spesso nasconde un problema di ACL che andrebbe corretto alla radice. Se un volume non è accessibile dal container, la soluzione non è sempre aprire tutto: a volte basta correggere il mapping, il path o il gruppo di accesso.

Un esempio operativo: test minimale di funzionamento

Quando vuoi capire se la piattaforma è sana, non partire subito con l’applicazione finale. Usa un test minimale con immagine ufficiale e comportamento prevedibile. L’obiettivo non è “fare qualcosa di utile”, ma chiudere il cerchio tra host, engine, rete e logging. Se quel test fallisce, non ha senso discutere ancora della tua app.

Un test utile è avviare un container, eseguire un comando semplice e verificare l’output:

docker run --rm mcr.microsoft.com/windows/nanoserver:ltsc2022 cmd /c echo OK

Se l’output non arriva, hai già una base concreta per la diagnosi. A quel punto distingui tra errore di pull, errore di avvio, errore di isolamento e errore di compatibilità. Non mischiare i livelli. Un errore di immagine non si risolve con un firewall tweak, e un errore di rete non si risolve cambiando tag all’immagine.

Cosa fare quando il container parte ma l’app non risponde

Questo è il caso più fastidioso, perché il motore sembra funzionare ma il servizio applicativo no. Qui il metodo è molto semplice: verifica che il processo dell’app sia vivo dentro il container, poi verifica il binding della porta, poi controlla i log applicativi. Se l’app è IIS, guarda anche il sito, l’application pool e l’eventuale configurazione del binding host header.

Se lavori con un’app .NET o con un servizio custom, non limitarti a “il container è up”. Entra nel container e controlla il processo attivo, oppure ispeziona l’entrypoint. Una configurazione sbagliata dell’entrypoint è una delle cause più frequenti di container che sembrano sani ma non servono nulla.

In caso di IIS, il controllo di base resta quello della configurazione del sito e del pool. Se il sito parte ma restituisce errori, il problema è spesso nel codice, nelle dipendenze runtime o nell’accesso a file e variabili d’ambiente. Non trattarlo come un problema di Docker finché non hai escluso il livello applicativo.

Best practice che evitano ore di troubleshooting

Ci sono alcune regole che riducono in modo netto il tempo perso. La prima è usare immagini ufficiali e tag espliciti, non tag vaghi o impliciti. La seconda è mantenere allineati host, immagine e pipeline di build. La terza è documentare il tipo di isolamento usato, perché “process” e “Hyper-V” non sono dettagli cosmetici: cambiano comportamento, compatibilità e diagnostica.

La quarta regola è preparare un rollback. Se stai cambiando il motore container, aggiornando il server o modificando il networking, devi sapere come tornare indietro: snapshot della VM, export della configurazione, nota delle regole firewall toccate e lista delle immagini usate. Su Windows Server, una modifica apparentemente piccola può impattare altri servizi della macchina, quindi il blast radius va considerato sempre.

La quinta regola è osservare prima di toccare. Prima di cambiare qualcosa, raccogli almeno: versione OS, stato servizio, evento di errore, output del comando di test e comportamento della porta esposta. Con questi dati hai una diagnosi molto più solida di un semplice “non parte”.

Quando conviene non usare Windows Server per i container

La risposta onesta è: ogni volta che il carico è nativamente Linux e non hai una ragione forte per rimanere su Windows. Se il tuo stack è composto da nginx, PHP-FPM, Redis, Postgres o microservizi Linux standard, forzarlo su Windows Server ti complica la vita senza un vero vantaggio. In quel caso la scelta tecnica più pulita è un host Linux o una VM Linux dedicata.

Windows Server ha senso quando devi integrare workload Windows, dipendenze legacy, servizi IIS, componenti .NET Framework o vincoli aziendali specifici. Fuori da questi casi, il costo operativo tende a superare il beneficio. È una valutazione architetturale, non ideologica.

Chiusura operativa

Se devi eseguire Docker su Windows Server 2019 o 2022, la sequenza giusta non è “installa e spera”, ma verifica compatibilità, abilita il supporto container, testa il motore, controlla rete e log, poi porta dentro l’applicazione. È questo ordine che evita di perdere tempo dietro sintomi fuorvianti. Su Windows Server il container non è un oggetto astratto: è una combinazione molto concreta di build OS, isolamento, networking e policy di sistema.

Se il tuo obiettivo è affidabilità operativa, la scelta più robusta resta semplice: usa immagini ufficiali, tieni allineata la versione dell’host, documenta il tipo di isolamento e conserva sempre un percorso di rollback. Il resto è troubleshooting, non magia.