Come installare Docker su Windows Server 2025

Installare Docker su Windows Server 2025: cosa cambia davvero

Su Windows Server 2025 il punto non è solo “mettere Docker”. Prima va chiarito il modello: container Windows oppure Linux container. Su Windows Server, il supporto nativo riguarda i container Windows; i container Linux non si eseguono direttamente sul kernel Windows come su una distribuzione Linux. Se ti serve far girare workload Linux, la strada corretta è una VM Linux, oppure una piattaforma dedicata che ospiti Linux containers fuori da Windows Server.

Per questo motivo, in ambito server Windows la scelta più pulita è usare il runtime compatibile con i container Windows, oggi basato sullo stack Mirantis Container Runtime per gli scenari supportati da Microsoft. In pratica: installi il motore container, abiliti la feature di sistema necessaria, verifichi la compatibilità dell’edizione/licenza e poi testi con un container Windows di prova.

Se stai cercando una procedura “copio e incollo e parte tutto”, fermati un attimo: la verifica iniziale evita di perdere tempo su un nodo non compatibile o su un’immagine sbagliata.

Prerequisiti da verificare prima di installare

Prima di toccare il sistema, controlla questi punti. Sono quelli che più spesso bloccano l’installazione o fanno fallire l’avvio del primo container.

• Edizione supportata: Windows Server 2025 installato e aggiornato.
• Ruolo/feature: supporto ai container attivabile sul server.
• Virtualizzazione: se il server è in VM, verifica che la nested virtualization sia supportata se ti serve Hyper-V isolation.
• Immagini: container Windows richiedono immagini coerenti con la versione del sistema o con il livello di compatibilità previsto.
• Rete: accesso a repository e registry, DNS funzionante, proxy se presente.

Controlli rapidi da PowerShell:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Get-WindowsFeature -Name Containers, Hyper-V

Atteso: il sistema risponde con la versione corretta e le feature risultano installabili o già presenti. Se la macchina è in un ambiente con policy restrittive, la parte più comune da chiarire è il permesso di scaricare componenti e immagini dal registry.

Scelta del runtime: Docker Engine, Docker Desktop o runtime supportato

Qui conviene essere netti. Su Windows Server non si usa Docker Desktop come soluzione server standard. Docker Desktop è pensato per workstation e sviluppo, non per un host server in produzione. Per un server Windows, la scelta dipende dal workload:

• Container Windows in produzione: runtime supportato per Windows Server, tipicamente Mirantis Container Runtime.
• Test locali su workstation: Docker Desktop, ma non come target di questa guida.
• Container Linux: non su Windows Server nativo; usa Linux.

Se il tuo obiettivo è eseguire applicazioni Windows containerizzate, segui la strada supportata dal vendor. Se invece il requisito reale è “voglio Docker per qualunque immagine Linux”, la risposta tecnica è che Windows Server non è il posto giusto.

Decisione architetturale utile: su Windows Server 2025 punta ai container Windows. Se ti servono Linux containers, separa il problema e usa un host Linux.

Abilitare la feature Containers

La feature base da attivare è Containers. In molti casi basta questo per preparare il sistema al runtime container. Se prevedi isolamento Hyper-V, valuta anche la feature Hyper-V, ma solo se serve davvero.

Comando PowerShell:

Install-WindowsFeature -Name Containers -IncludeAllSubFeature -Restart

Atteso: il server si riavvia e la feature risulta installata. Dopo il reboot, verifica con:

Get-WindowsFeature -Name Containers

Se lo stato è Installed, la parte di sistema è a posto. Se fallisce, guarda l’errore completo: spesso il problema è un requisito mancante, una policy o un conflitto con funzioni di virtualizzazione già presenti.

Se non vuoi procedere direttamente da shell, puoi usare Server Manager: Add roles and features → Features → Containers. È meno automatizzabile, ma riduce errori operativi in ambienti gestiti manualmente.

Installare il runtime supportato

Per Windows Server la strada corretta è installare il runtime compatibile con il supporto Microsoft per i container Windows. In ambienti moderni questo significa allinearsi al pacchetto fornito dal vendor supportato, non prendere un installer qualsiasi da internet e sperare che vada bene.

La procedura varia a seconda del contratto, del repository disponibile e della versione esatta del runtime. Per non inventare comandi non coerenti con il tuo ambiente, la verifica va fatta sul portale del vendor o sulla documentazione ufficiale del prodotto che hai scelto. Il punto operativo è questo:

1. Scarica il pacchetto dal canale ufficiale.
2. Verifica firma e integrità del file.
3. Installa il runtime seguendo la procedura supportata per Windows Server 2025.
4. Riavvia il servizio o il server se richiesto.

Verifiche da fare dopo l’installazione:

docker version

docker info

Atteso: il client risponde e il daemon/runtime è raggiungibile. Se il comando non esiste, il binario non è nel PATH o l’installazione non è andata a buon fine. Se il client risponde ma il daemon no, il servizio del runtime non è attivo.

Se il tuo ambiente usa un package manager o uno script aziendale, conserva lo snippet di installazione in un repository interno. È l’unico modo serio per fare rollback e ripetibilità.

Configurazione base del daemon

Una volta installato il runtime, conviene controllare la configurazione base prima di mettere immagini e workload. Su Windows il file di configurazione del daemon, quando presente, è spesso in una posizione simile a C: un sl est no, non usare percorsi a memoria: il percorso effettivo dipende dal runtime e dall’installazione. La verifica va fatta sul file di configurazione del prodotto installato o sulla documentazione del vendor.

Le cose da controllare sono sempre le stesse:

• Log level adeguato al troubleshooting.
• Registry mirrors se hai problemi di latenza o rate limit.
• Proxy se il server esce su internet solo tramite proxy.
• Data root se vuoi spostare immagini e layer su un volume con più spazio.

Se devi cambiare configurazione, fai prima un backup del file corrente. Esempio operativo:

Copy-Item -Path <config-file> -Destination <config-file>.bak

Dopo la modifica, riavvia il servizio del runtime e verifica che lo stato sia Running. Se la modifica non è documentata o non sai esattamente dove il runtime legge la configurazione, fermati e recupera il path corretto dal vendor o dai servizi installati.

Verificare che il server sia pronto

Prima di lanciare un container vero, fai tre controlli: servizio, rete, immagine.

1. Servizio attivo: il daemon/runtime deve essere in esecuzione.
2. Rete uscente: il server deve raggiungere il registry.
3. Compatibilità immagine: l’immagine deve essere Windows-based e compatibile con l’host.

Test rete minimo:

Test-NetConnection -ComputerName mcr.microsoft.com -Port 443

Atteso: TcpTestSucceeded : True. Se fallisce, il problema non è Docker ma rete, DNS, proxy o firewall.

Test di download immagine, se l’ambiente lo consente e il runtime è pronto:

docker pull mcr.microsoft.com/windows/servercore:ltsc2025

Atteso: download completato senza errori di compatibilità o accesso. Se l’immagine non esiste o non è disponibile, verifica il tag corretto per la tua build di Windows Server 2025. Non dare per scontato che un tag “simile” funzioni.

Primo container di prova

Il test minimo deve essere semplice e reversibile. Su Windows Server, usa un’immagine di test coerente con la versione del sistema.

docker run --rm mcr.microsoft.com/windows/servercore:ltsc2025 cmd /c echo hello

Atteso: output hello e uscita del container con codice 0. Se il container parte ma fallisce subito, guarda l’errore completo: spesso si tratta di mismatch tra host e immagine, oppure di problemi sul layer storage o sul runtime.

Per vedere i container presenti:

docker ps -a

Per ispezionare un container fermo:

docker logs <container_id>

Se i log non ci sono o il container non arriva a start, il problema è precedente all’applicazione: runtime, immagine, isolamento o configurazione host.

Problemi comuni e come leggerli

Il primo errore utile è quasi sempre diagnostico, non casuale. Leggilo in ordine di probabilità.

• Errore di compatibilità immagine/host: il tag dell’immagine non corrisponde alla build di Windows Server.
• Runtime non avviato: servizio Docker/runtime fermo o installazione incompleta.
• Rete o proxy: pull fallito per DNS, firewall o proxy autenticato.
• Spazio disco: layer storage pieno o volume con poco margine.
• Policy di sicurezza: hardening, AppLocker, Defender o restrizioni aziendali interferiscono con il runtime.

Controlli rapidi utili:

Get-Service | Where-Object {$_.Name -match 'docker|container'}

Get-Volume

Get-WinEvent -LogName Application -MaxEvents 50 | Select-Object TimeCreated, Id, ProviderName, Message

Se hai un fallimento ripetibile, raccogli sempre: comando esatto, output completo, versione di Windows, versione del runtime, tag immagine e log del servizio. Senza questi dati si va a tentativi.

Hardening minimo dopo l’installazione

Una volta funzionante, non lasciare il server “aperto per default”. Anche in un ambiente containerizzato Windows, la sicurezza parte da pochi controlli basilari.

• Limita chi può amministrare il runtime.
• Usa immagini da registry affidabili e controllati.
• Non esporre porte inutili verso l’esterno.
• Applica aggiornamenti di sistema con una finestra di manutenzione.
• Monitora spazio disco, servizio e error rate dei container.

Se il server è esposto in rete, verifica anche il firewall di Windows e le regole in ingresso relative alle porte pubblicate dai container. La regola pratica è semplice: apri solo ciò che serve e verifica con un test esterno reale, non solo locale.

Checklist finale operativa

Prima di considerare conclusa l’installazione, chiudi questa lista:

1. Get-WindowsFeature -Name Containers mostra Installed.
2. docker version risponde senza errori.
3. docker info mostra il daemon attivo.
4. Test-NetConnection mcr.microsoft.com -Port 443 ritorna True.
5. Un container di test parte e termina con exit code 0.

Se uno di questi punti fallisce, non andare avanti con il deploy applicativo. Risolvi prima il livello infrastrutturale, poi il resto.

Assunzione operativa: la guida è pensata per container Windows su Windows Server 2025; per workload Linux la soluzione corretta resta un host Linux o una VM dedicata.

Quando fermarsi e cambiare approccio

Se il tuo obiettivo finale è eseguire stack Linux classici, microservizi Linux-only o tooling che dipende da kernel Linux, insistere su Windows Server complica tutto. In quel caso la decisione tecnica più economica è spostare il workload su Linux, non forzare un adattamento innaturale.

Se invece hai applicazioni legacy Windows, servizi .NET o componenti pensati per Windows container, Windows Server 2025 è una base sensata, purché tu mantenga il perimetro chiaro: runtime supportato, immagine corretta, rete pulita, logging attivo e rollback disponibile.

Per ambienti enterprise, la parte più importante non è il primo docker run. È la ripetibilità: documenta versione OS, runtime, configurazione e tag immagine. Senza questi dati, ogni reinstallazione diventa un esercizio di fortuna.