Uso di contenitori Windows per "containerizzare" le applicazioni esistenti

Si applica a: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

I contenitori di Windows offrono un ottimo meccanismo per modernizzare le applicazioni tradizionali o legacy. Anche se si può sentire questo approccio definito "lift-and-shift in contenitori", la metafora lift-and-shift deriva dallo spostamento di carichi di lavoro da fisici a macchine virtuali e viene usata quando si fa riferimento allo spostamento dei carichi di lavoro nel cloud. Oggi, questo termine viene applicato in modo più appropriato alla migrazione di macchine virtuali (VM). Tuttavia, i contenitori non sono macchine virtuali, e pensarli come tali può portare a confusione sul modo in cui un'applicazione viene containerizzata, o se può, o dovrebbe, essere containerizzata.

Questo argomento fornisce indicazioni pratiche sullo spostamento di applicazioni tradizionali in contenitori Windows. L'obiettivo è aiutare a classificare in ordine di priorità le applicazioni da inserire in contenitori, spiegando considerazioni speciali iniziali.

Introduzione

Cosa sono i contenitori di Windows e cosa non sono

Il termine contenitore generico fa riferimento a una tecnologia che virtualizza il sistema operativo. Questa virtualizzazione offre un livello di isolamento dal sistema operativo del server/host stesso, che a sua volta consente maggiore agilità per sviluppatori di applicazioni e team operativi.

I contenitori di Windows sono un'implementazione specifica della tecnologia contenitore. Forniscono istanze di sistemi operativi virtualizzati isolati dal sistema operativo Windows. Tuttavia, l'interdipendenza totale tra contenitore e host è impossibile: un contenitore Windows deve coordinare la domanda di risorse e funzioni con il sistema operativo Windows. Perché è importante? Poiché un contenitore Windows non è un intero server virtualizzato e alcune delle operazioni che è possibile eseguire con un'applicazione non possono essere eseguite solo con un sistema operativo virtualizzato.

Per altre informazioni su questo argomento, vedere Contenitori e macchine virtuali. Tuttavia, alcuni punti utili per aiutarti a ricordare la distinzione tra contenitori e macchine virtuali sono:

• I contenitori non sono una soluzione equivalente alla virtualizzazione delle applicazioni desktop. Supportano solo applicazioni lato server che non richiedono una sessione interattiva. Poiché vengono eseguite su immagini di contenitori specializzate, supportano solo le applicazioni che non necessitano di un front-end grafico.
• I contenitori sono temporanei per natura. Ciò significa che, per impostazione predefinita, non esiste alcun meccanismo per salvare lo stato di un'istanza del contenitore. Se un'istanza ha esito negativo, verrà eseguita un'altra istanza.

La tecnologia dei contenitori è iniziata in Linux, con Docker emergente come standard. Microsoft ha lavorato a stretto contatto con Docker per garantire che la funzionalità del contenitore sia la stessa possibile in Windows. Le differenze intrinseche tra Linux e Windows possono presentarsi in modi che sembrano essere limitazioni dei contenitori Windows quando in realtà sono solo le differenze tra Linux e Windows. D'altra parte, i contenitori di Windows forniscono alcune implementazioni univoche, ad esempio Hyper-V isolamento, che verranno trattate in un secondo momento. Questo argomento illustra le differenze e spiega come gestirle.

Vantaggi dell'uso dei contenitori

Analogamente all'esecuzione di più macchine virtuali in un singolo host fisico, è possibile eseguire più contenitori in un singolo host fisico o virtuale. A differenza delle macchine virtuali, tuttavia, non è necessario gestire il sistema operativo per un contenitore, che offre la flessibilità necessaria per concentrarsi sullo sviluppo di applicazioni e sull'infrastruttura sottostante. Significa anche che è possibile isolare un'applicazione in modo che non sia influenzata da qualsiasi altro processo supportato dal sistema operativo.

I contenitori forniscono un metodo leggero di creazione e arresto dinamico delle risorse necessarie per un'applicazione funzionante. Anche se è possibile creare e distribuire macchine virtuali man mano che aumenta la domanda di applicazioni, è più rapido usare i contenitori per la scalabilità orizzontale. Con i contenitori, è anche possibile riavviare rapidamente in caso di arresto anomalo o interruzione dell'hardware. I contenitori consentono di portare qualsiasi app dallo sviluppo all'ambiente di produzione con modifiche minime o senza modifiche al codice, perché "contengono" dipendenze dell'applicazione in modo che funzionino in ambienti diversi. La possibilità di inserire in contenitori un'applicazione esistente con modifiche minime al codice, grazie all'integrazione di Docker tra gli strumenti di sviluppo Microsoft, è anche un fattore potente nello sviluppo e nella manutenzione delle applicazioni.

Infine, uno dei vantaggi più importanti dell'uso dei contenitori è l'agilità che si ottiene per lo sviluppo di app, poiché è possibile avere versioni diverse di un'app in esecuzione nello stesso host senza conflitti di risorse.

È possibile trovare un elenco più completo dei vantaggi per l'uso di contenitori per le applicazioni esistenti nella pagina della documentazione di Microsoft .NET.

Concetto importante di livello di isolamento

I contenitori di Windows forniscono l'isolamento dal sistema operativo Windows, l'isolamento che è vantaggioso quando si compila, si testa e si promuove un'app in produzione. Ma il modo in cui viene ottenuto l'isolamento è importante capire quando si sta pensando di inserire un'applicazione in contenitori.

I contenitori di Windows offrono due modalità distinte di isolamento del runtime: processo e Hyper-V. I contenitori in entrambe le modalità vengono creati e gestiti in modo identico e funzionano in modo identico. Quindi, quali sono le differenze e perché è necessario prendersi cura?

In isolamento del processo, più contenitori sono eseguiti contemporaneamente su un singolo host con isolamento fornito tramite namespace, controllo delle risorse e altre funzionalità. I contenitori in modalità di isolamento del processo condividono lo stesso kernel con l'host e l'uno con l'altro. Si tratta approssimativamente dello stesso modo in cui i contenitori Linux vengono eseguiti.

In Hyper-V isolamento, anche più contenitori operano simultaneamente su un singolo host, ma i contenitori operano all'interno di macchine virtuali altamente ottimizzate, con ciascuno che ottiene effettivamente il proprio kernel. La presenza di questa macchina virtuale – essenzialmente una "VM di servizio" – fornisce un isolamento a livello hardware tra ciascun container e l'host del container.

In un certo senso, la modalità di isolamento Hyper-V è quasi come un ibrido tra una macchina virtuale e un container, offrendo un ulteriore livello di sicurezza particolarmente utile se l'app richiede multitenancy. Tuttavia, i possibili compromessi dell'uso della modalità di isolamento Hyper-V includono:

• Tempo di avvio più lungo per il contenitore e un probabile impatto sulle prestazioni complessive dell'app.
• Non tutti gli strumenti funzionano in modo nativo con isolamento Hyper-V.
• Al momento, né il servizio Azure Kubernetes (AKS) né AKS in Azure Stack HCI supportano l'isolamento Hyper-V.

Per altre informazioni su come vengono implementate le due modalità di isolamento, vedere l'argomento Modalità di isolamento. Quando si crea per la prima volta un contenitore per un'app, è necessario scegliere tra le due modalità. Fortunatamente, è molto facile passare da una modalità a un'altra in un secondo momento, perché non richiede alcuna modifica all'applicazione o al contenitore. Tenere tuttavia presente che, quando si containerizza un'app, la scelta tra le due modalità è una delle prime operazioni da eseguire.

Orchestrazione dei contenitori

La possibilità di eseguire più contenitori in un singolo o più host senza preoccuparsi della gestione del sistema operativo offre una grande flessibilità, consentendo di passare a un'architettura basata su microservizi. Un compromesso per questa flessibilità, tuttavia, è che un ambiente basato su contenitori e microservizi può rapidamente espandersi in molte componenti in movimento, troppe per tenere traccia. Fortunatamente, la gestione del bilanciamento del carico, la disponibilità elevata, la pianificazione dei contenitori, la gestione delle risorse e molto altro ancora, è il ruolo di un agente di orchestrazione dei contenitori.

Gli orchestratori sono forse erroneamente denominati; sono più simili ai direttori d'orchestra in quanto coordinano l'attività di più container per garantire il funzionamento continuo. In un certo senso, gestiscono la pianificazione e l'allocazione delle risorse per i contenitori in modo simile al funzionamento di un sistema operativo. Pertanto, quando si passa a inserire in contenitori le applicazioni, è necessario scegliere tra gli agenti di orchestrazione che supportano i contenitori di Windows. Alcuni dei più comuni sono Kubernetes e Docker Swarm.

Cosa non può essere spostato nei contenitori di Windows

Quando si valuta se un'app può essere in contenitori o meno, è probabilmente più semplice iniziare con l'elenco di fattori che esclude completamente i contenitori di Windows come opzione.

La tabella seguente riepiloga i tipi di app che non possono essere spostate nei contenitori di Windows e perché no. I motivi sono descritti più in dettaglio nelle sottosezioni dopo la tabella. Comprendere i motivi di queste limitazioni può offrire un'idea più chiara delle differenze tra i contenitori e le differenze tra le macchine virtuali. Ciò consentirà, a sua volta, di valutare meglio le funzionalità dei contenitori di Windows che è possibile sfruttare con le app esistenti che è possibile inserire in contenitori.

Nota: l'elenco seguente non è un elenco completo. Si tratta invece di una compilazione di app che Microsoft ha visto i clienti provare a inserire in contenitori.

Applicazioni/funzionalità non supportate	Perché non è supportato	Puoi risolvere questo problema?
Applicazioni che richiedono un desktop	I contenitori non supportano l'interfaccia utente grafica (GUI)	Se l'applicazione richiede solo un'interfaccia utente grafica da installare, la modifica in un'installazione invisibile all'utente potrebbe essere una soluzione
Applicazioni che usano Remote Desktop Protocol (RDP)	RDP è per le sessioni interattive, quindi il principio precedente si applica anche qui	È possibile usare Windows Admin Center (WAC) o PowerShell remoto come alternativa alla gestione remota
Applicazioni con stato	I contenitori sono temporanei	Sì, alcune applicazioni potrebbero richiedere modifiche minime, quindi non archiviano i dati o lo stato all'interno del contenitore
Applicazioni di database	I contenitori sono temporanei	Sì, alcune applicazioni potrebbero richiedere modifiche minime, quindi non archiviano i dati o lo stato all'interno del contenitore
Active Directory	La progettazione e lo scopo di Active Directory impediscono l'esecuzione in un contenitore	No. Tuttavia, le app dipendenti da Active Directory possono usare gli account del servizio gestito del gruppo. Maggiori informazioni su gMSA (account del servizio gestito del gruppo) sono disponibili di seguito
Versioni precedenti di Windows Server	È supportato solo Windows Server 2016 o versione successiva	No. Tuttavia, la compatibilità delle applicazioni potrebbe essere un'opzione: la maggior parte delle app di Windows Server 2008/R2 e precedenti viene eseguita in versioni più recenti di Windows Server
App che usano .NET Framework versione 2.0 o precedenti	Sono necessarie immagini contenitore specifiche per supportare .NET Framework e sono supportate solo versioni più recenti	Le versioni precedenti alla 2.0 non sono supportate, ma vedere di seguito per le immagini del contenitore necessarie per le versioni successive
App che usano altri framework di terze parti	Microsoft non certifica o supporta in modo specifico l'uso di framework non Microsoft nei contenitori Windows	Verificare con il fornitore del framework specifico o dell'app i criteri di supporto per i contenitori di Windows. Per altre informazioni, vedere di seguito

Si considerino a loro volta ognuna di queste limitazioni.

Applicazioni che richiedono un desktop

I contenitori sono ideali per le funzioni temporanee richiamate da altre applicazioni, incluse quelle con interazioni utente. Tuttavia, non è possibile usarli per le applicazioni che dispongono di interfacce utente. Questo vale anche se l'applicazione stessa non ha un'interfaccia utente grafica, ma ha un programma di installazione che si basa su un'interfaccia utente grafica. In generale, Windows Installer può essere richiamato tramite PowerShell, ma se l'applicazione richiede l'installazione tramite un'interfaccia utente grafica, tale requisito lo elimina come candidato per la containerizzazione.

Questo non è un problema con il modo in cui sono stati implementati i contenitori Windows, ma piuttosto un concetto fondamentale del funzionamento dei contenitori.

È un'altra questione se un'app necessita di API GUI. Le API sono supportate, anche se l'interfaccia grafica utente fornita da tali API non lo è. Questo argomento è più descritto nell'argomento Nano Server x Server Core x Server - Qual è l'immagine di base più adatta per te?

Applicazioni che usano RDP

Poiché l'intero scopo di Remote Desktop Protocol (RDP) è stabilire una sessione visiva interattiva, viene applicata anche la limitazione dell'interfaccia utente grafica appena descritta. Un'applicazione che usa RDP non può essere in contenitori as-is.

Tuttavia, una buona alternativa è uno strumento di gestione remota come Windows Admin Center. È possibile usare Windows Admin Center per gestire gli host dei contenitori di Windows e i contenitori stessi, senza la necessità di eseguire RDP. È anche possibile aprire una sessione remota di PowerShell per l'host e/o i contenitori per gestirli.

Applicazioni con stato

Le applicazioni che devono conservare i dati di stato possono essere incluse in contenitori solo se si isolano i dati necessari da una sessione a quella successiva e la archivia in una risorsa di archiviazione permanente. Ciò potrebbe richiedere una "riprogettazione", che può o non essere semplice, ma procedere con esso eliminerà questa barriera alla containerizzazione.

Un esempio di stato è un'applicazione Web che archivia immagini o file musicali in una cartella locale. In un ambiente Windows tradizionale, un file viene salvato su disco al momento della conclusione dell'operazione di scrittura, quindi se l'istanza (in questo caso una macchina virtuale) ha esito negativo, è sufficiente riportarla su e il file sarà ancora presente. Al contrario, se un'istanza del contenitore che esegue un'operazione di scrittura non riesce, la nuova istanza del contenitore non includerà tale file. Per questo motivo, è consigliabile usare l'archiviazione permanente in modo che tutte le istanze del contenitore possano archiviare i dati o i file di stato in una posizione centralizzata e durevole. Questo tipo di riprogettazione non richiede di modificare il codice dell'applicazione, solo il tipo di spazio di archiviazione usato dall'istanza di Windows. Per ulteriori informazioni, consultare la documentazione sui contenitori di Windows sull'archiviazione .

Tuttavia, questo porta in un altro argomento correlato...

Applicazioni di database

Come regola generale, le applicazioni di database non sono ottimi candidati per la containerizzazione. Sebbene sia possibile eseguire un database all'interno di un contenitore, il contenitore di un database esistente non è in genere ideale per due motivi.

Prima di tutto, le prestazioni necessarie per un database potrebbero richiedere l'intera risorsa hardware disponibile per l'host, che svaluta il vantaggio del consolidamento. In secondo luogo, più istanze di un singolo livello di database richiedono il coordinamento per le operazioni di scrittura. L'orchestrazione dei contenitori può risolvere questo problema, ma per i database esistenti, l'orchestrazione può diventare un sovraccarico. La maggior parte dei database, ad esempio Microsoft SQL Server, dispone di un meccanismo predefinito di bilanciamento del carico e disponibilità elevata.

Ruoli dell'infrastruttura in Windows Server

I ruoli dell'infrastruttura di Windows Server gestiscono principalmente le funzioni più vicine al sistema operativo, ad esempio AD, DHCP e File Server. Di conseguenza, non sono disponibili per l'esecuzione di contenitori. Pertanto, le applicazioni che necessitano di questi ruoli saranno sempre difficili da inserire in contenitori.

Ci sono alcune aree grigie. Ad esempio, alcune funzionalità come DNS possono funzionare nei contenitori windows anche se non sono effettivamente destinate a essere usate nei contenitori. Altri ruoli dell'infrastruttura vengono semplicemente rimossi dall'immagine del contenitore di base e non possono essere installati, ad esempio Active Directory, DHCP e altri.

Active Directory (AD)

Active Directory è stato rilasciato più di vent'anni fa lungo Windows 2000 Server. Usa un meccanismo in cui ogni dispositivo o utente è rappresentato da un oggetto archiviato nel relativo database. Questa relazione è strettamente associata e gli oggetti vengono mantenuti nel database anche se l'utente o il dispositivo effettivo non è più in gioco. Questo approccio per Active Directory contraddice direttamente la natura effimera dei contenitori, che dovrebbero essere di breve durata o eliminati quando sono disattivati. La gestione di questa relazione uno-a-uno con Active Directory non è ideale per questi scenari.

Per questo motivo, i contenitori di Windows non possono essere aggiunti a un dominio. A tale scopo, non è possibile eseguire Active Directory Domain Services come ruolo di infrastruttura nei contenitori Windows. È possibile eseguire il modulo PowerShell per la gestione remota dei controller di dominio all'interno di un contenitore Windows.

Per le applicazioni in esecuzione in contenitori di Windows dipendenti da Active Directory, usare account del servizio gestito del gruppo (gMSA), che verranno illustrati ulteriormente.

App che usano .NET Framework versione 2.0 o precedenti

Se l'applicazione richiede .NET, la possibilità di inserire in contenitori dipende interamente dalla versione di .NET Framework usata. Qualsiasi versione precedente a .NET Framework 2.0 non è affatto supportata; le versioni successive richiedono l'uso di immagini specifiche, come descritto più avanti.

App che usano framework di terze parti (non Microsoft)

In generale, Microsoft non è in grado di certificare framework o applicazioni di terze parti o di supportarli in esecuzione in contenitori Windows, ovvero macchine fisiche e virtuali. Tuttavia, Microsoft esegue i propri test interni per l'usabilità di più framework e strumenti di terze parti, tra cui Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat e molti altri.

Per qualsiasi framework o software di terze parti, convalidarne il supporto nei contenitori Windows con il fornitore che lo fornisce.

Candidati ideali per la containerizzazione

Ora che abbiamo considerato le limitazioni rigide per la creazione di contenitori delle app, è più facile vedere quali tipi di app si prestano più facilmente ai contenitori di Windows. I candidati ideali per i contenitori di Windows e le considerazioni speciali per la loro containerizzazione sono riportati nella tabella seguente.

Tipo di applicazione	Perché questi sono buoni candidati	Considerazioni speciali
Applicazioni console	Senza limitazioni dell'interfaccia utente grafica, le app console sono candidati ideali per i contenitori.	Usare l'immagine del contenitore di base appropriata a seconda delle esigenze dell'applicazione.
Servizi Windows	Poiché si tratta di processi in background che non richiedono alcuna interazione diretta dell'utente	Usare l'immagine del contenitore di base appropriata a seconda delle esigenze dell'applicazione. È necessario creare un processo in primo piano per mantenere in esecuzione qualsiasi processo containerizzato in background. Consultare la sezione sui servizi in background di seguito.
Servizi Windows Communication Foundation (WCF)	Poiché sono app orientate ai servizi che vengono eseguite anche in background	Usare l'immagine del contenitore di base appropriata a seconda delle esigenze dell'applicazione. Potrebbe essere necessario creare un processo in primo piano per tenere in esecuzione qualsiasi processo in background containerizzato. Vedere la sezione servizi in background di seguito.
Web app	Le applicazioni Web sono essenzialmente servizi in background in ascolto su una porta specifica e sono quindi ottimi candidati per la containerizzazione, poiché sfruttano la scalabilità offerta dai contenitori	Usare l'immagine del contenitore di base appropriata a seconda delle esigenze dell'applicazione.

Nota: anche questi candidati ideali per la containerizzazione possono basarsi su funzionalità e componenti principali di Windows che dovranno essere gestiti in modo diverso nei contenitori di Windows. La sezione successiva, che illustra in dettaglio tali considerazioni pratiche, ti preparerà meglio per sfruttare le funzionalità dei contenitori di Windows.

Considerazioni pratiche per le applicazioni che possono essere incluse in contenitori

I progetti di ristrutturazione delle app in genere prendono in considerazione se una determinata app può essere inserita in contenitori tramite la prospettiva della funzione aziendale dell'app. Ma la funzionalità aziendale non è il fattore che determina se è tecnicamente possibile. Ciò che è importante è l'architettura dell'app, ad esempio i componenti tecnici su cui si basa. Pertanto, non c'è una risposta semplice a una domanda come "Posso containerizzare la mia applicazione delle risorse umane?" perché non è ciò che l'applicazione sta facendo, ma è come (e quali componenti/servizi di Windows usa) a fare la differenza.

Si tratta di una distinzione importante, perché se l'applicazione non è compilata con un'architettura di microservizi per iniziare, è probabile che sia più difficile da inserire in contenitori. Quando si procede alla creazione di contenitori, alcune funzionalità potrebbero richiedere una gestione speciale. Alcuni potrebbero essere dovuti all'uso dell'app di componenti e framework di Windows di base non supportati nei contenitori di Windows. Altri, ad esempio la registrazione e il monitoraggio degli eventi, sono dovuti a differenze intrinseche tra Linux e Windows che diventano evidenti solo quando si containerizza l'app. Altri, ad esempio le attività pianificate e i servizi in background, devono essere compresi dal punto di vista che un contenitore non è una macchina virtuale, ma è temporaneo e quindi richiede una gestione speciale.

La tabella seguente presenta un breve riepilogo dei componenti/funzionalità delle applicazioni che richiedono considerazioni speciali quando si sta pensando alla containerizzazione. Le sottosezioni che seguono forniscono maggiori dettagli, inclusi esempi che illustrano le tecniche per la gestione di ogni scenario. Mentre l'elenco seguente illustra gli scenari supportati nei contenitori Windows, questi scenari devono comunque rispettare le indicazioni del capitolo precedente. Ad esempio, mentre sono supportati i servizi in background, l'esecuzione di un servizio in background in .NET Framework 1.1 non è supportata.

Funzionalità/componente di Windows che richiede una gestione speciale	Ragione
Accodamento della messaggistica Microsoft (MSMQ)	MSMQ ha avuto origine molto prima dei contenitori e non tutti i relativi modelli di distribuzione per le code di messaggi sono compatibili con l'architettura del contenitore.
Microsoft Distributed Transaction Coordinator (MSDTC)	La risoluzione dei nomi tra MSDTC e il contenitore richiede una particolare considerazione.
IIS	IIS è uguale a quello di una macchina virtuale, ma esistono considerazioni importanti per l'esecuzione in un ambiente contenitore, ad esempio la gestione dei certificati, le stringhe di connessione del database e altro ancora.
Attività pianificate	I contenitori di Windows possono eseguire attività pianificate, esattamente come qualsiasi istanza di Windows. Tuttavia, potrebbe essere necessario avviare un'attività in primo piano per mantenere l'istanza di container attiva. A seconda dell'applicazione, è possibile prendere in considerazione un approccio basato su eventi.
Servizi in background	Poiché i container vengono eseguiti come processi temporanei, è necessaria una gestione aggiuntiva per mantenere il container in esecuzione.
.NET Framework e .NET (in precedenza .Net Core)	Assicurarsi di usare l'immagine corretta per garantire la compatibilità, come illustrato nella sottosezione seguente.

Altri componenti di supporto

Componente che richiede una gestione speciale	Ragione	Approccio alternativo
Registrazione/monitoraggio eventi	Poiché il modo in cui Windows scrive eventi e log è intrinsecamente diverso da stdout linux	Usare il nuovo strumento Monitor dei log per normalizzare i dati e combinarli sia da Linux che da Windows.
Sicurezza dei contenitori di Windows	Anche se molte procedure di sicurezza rimangono invariate, i contenitori richiedono misure di sicurezza aggiuntive.	Utilizzare uno strumento appositamente creato per l'analisi delle immagini e del registro, ulteriori dettagli più avanti.
Backup dei contenitori di Windows	I contenitori non devono contenere dati né mantenere uno stato	Eseguire il backup di qualsiasi risorsa di archiviazione permanente usata dai contenitori, nonché immagini del contenitore.

Componenti/funzionalità di Windows

Verranno ora approfonditi i dettagli delle applicazioni e dei componenti che possono essere inseriti in contenitori, ma richiedono una gestione aggiuntiva.

MSMQ

Se l'applicazione dipende da MSMQ, se è possibile includerla in contenitori dipende dallo scenario di distribuzione MSMQ. MSMQ include più opzioni di distribuzione. I fattori delle code private e pubbliche, transazionali o meno, e il tipo di autenticazione formano una matrice di scenari che MSMQ è stato originariamente progettato per supportare. Non tutti questi possono essere facilmente spostati in contenitori windows. La tabella seguente elenca gli scenari supportati:

Ambito	Transazionale?	Posizione della coda	Tipo di autenticazione	Inviare e ricevere?
Privato	Sì	Stesso contenitore (singolo contenitore)	Anonimo	Sì
Privato	Sì	Volume persistente	Anonimo	Sì
Privato	Sì	Controller di dominio	Anonimo	Sì
Privato	Sì	Host singolo (due contenitori)	Anonimo	Sì
Pubblico	No	Due host	Anonimo	Sì
Pubblico	Sì	Due host	Anonimo	Sì

Alcune note su questi scenari supportati, convalidati dai team di sviluppo interni di Microsoft:

• Modalità di isolamento: sia la modalità di elaborazione che la modalità Hyper-V per l'isolamento funzionano con gli scenari elencati in precedenza.
• Immagine minima del sistema operativo e del contenitore: la versione minima del sistema operativo consigliata per l'uso con MSMQ è Windows Server 2019.
• Volumi persistenti: gli scenari precedenti sono stati convalidati eseguendo MSMQ nel servizio Azure Kubernetes usando i file di Azure per l'archiviazione permanente.

Quando si mettono queste considerazioni insieme alla tabella precedente, è possibile notare che l'unico scenario non supportato è per le code che richiedono l'autenticazione con Active Directory. L'integrazione degli account del servizio gestito del gruppo (gMSAs) con MSMQ non è attualmente supportata perché MSMQ ha dipendenze da Active Directory che non sono ancora presenti.

In alternativa, usare il bus di servizio di Azure anziché MSMQ. Azure Service Bus è un intermediario di messaggi per l'impresa completamente gestito con code di messaggi e argomenti di sottoscrizione pubblica (in uno spazio dei nomi). Il passaggio da MSMQ al bus di servizio di Azure richiede modifiche al codice e la ri-architettura dell'applicazione, ma offre la flessibilità necessaria per passare a una piattaforma moderna.

MSDTC

Microsoft Distributed Transaction Coordinator (MSDTC) viene ampiamente usato nelle applicazioni legacy di Windows tra aziende di grandi dimensioni. MSDTC può essere installato in contenitori Windows, ma esistono alcuni scenari che non funzionano e non possono essere riprodotti nei contenitori windows.

• Quando si crea il contenitore, assicurarsi di passare il parametro --name al comando docker run. Questo parametro name è ciò che consente ai contenitori di comunicare tramite la rete Docker. Se si usa gMSA, il nome deve corrispondere al nome host, che deve corrispondere al nome dell'account gMSA.
  • Qui è un esempio del comando run con gMSA.

docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022

• I contenitori devono essere in grado di risolversi tra loro usando il nome NETBIOS. Se c'è difficoltà con questo modo migliore per risolvere è aggiungere il nome e l'ip dei contenitori a ognuno dei file host.
• L'uuid per msdtc in entrambi i contenitori deve essere univoco. L'UUID si può ottenere eseguendo "Get-Dtc" in PowerShell all'interno dei contenitori. Se non sono univoci, un modo per risolvere è disinstallare e reinstallare msdtc in uno dei contenitori. Questi comandi powershelll possono essere usati: "uninstall-dtc", "install-dtc".
• Attualmente, MSDTC non è supportato nei servizi Azure Kubernetes. Se hai una specifica necessità di eseguire MSDTC su AKS, informa il team dei contenitori Windows segnalandolo come un problema nel repository dei contenitori Windows su GitHub usando e.

Funzionamento di IIS in un contenitore rispetto a una macchina virtuale

IIS funziona allo stesso modo in un contenitore Windows come in una macchina virtuale. Esistono tuttavia alcuni aspetti dell'esecuzione di un'istanza di IIS da considerare durante l'esecuzione in un ambiente contenitore:

• Archiviazione permanente per i dati locali: le cartelle in cui l'app scrive/legge i file in/da sono un ottimo esempio di un elemento che si mantiene in una macchina virtuale per un'istanza di IIS. Con i contenitori non si vogliono scrivere dati direttamente nel contenitore. I contenitori usano uno "spazio di lavoro" per l'archiviazione locale e quando viene creato un nuovo contenitore per la stessa applicazione, non ha accesso a tale area da un contenitore precedente. Per questo motivo, usare l'archiviazione permanente per i dati che devono essere accessibili all'applicazione Web, in modo che qualsiasi istanza del contenitore possa avere accesso a tale archiviazione.
• Certificati: anche se è possibile avere certificati locali nelle istanze del container, si consiglia di evitarlo, perché se è necessario aggiornare un certificato, è necessario ricompilare l'immagine del container. In alternativa, è possibile usare un orchestratore di container con controllo Ingress. I controller di ingresso possono applicare criteri di rete e gestire anche la gestione dei certificati per il sito Web ospitato dietro di esso. L'aspetto positivo è separare la gestione del ciclo di vita dei certificati dalla gestione del sito Web.
• Stringhe di connessione al database: per la distribuzione tradizionale di IIS, è possibile passare la stringa di connessione del database come parte della distribuzione dell'applicazione. Anche se i contenitori di Windows consentono di seguire tale modello, è consigliabile separare la stringa di connessione del database dal contenitore a una configurazione centralizzata fornita dall'agente di orchestrazione del contenitore, da cui l'applicazione può leggere. In questo modo è possibile gestire e aggiornare la stringa di connessione del database in modo indipendente dall'applicazione. Se il database cambia (per i casi di lift-and-shift nel cloud), ad esempio, è possibile modificare facilmente la stringa di connessione senza ricompilare l'immagine del contenitore. Questo approccio consente anche di mantenere i segreti (ad esempio nome utente e password per la connessione al database) in un archivio segreto.
• Scalabilità automatica orizzontale: quando il carico aumenta, i sistemi di calcolo tendono a rallentare le prestazioni percepite durante il tentativo di elaborare le richieste simultanee. Esistono in genere due modi per evitare un impatto sulle prestazioni, ovvero la scalabilità verticale o orizzontale. La scalabilità verticale aumenta le risorse disponibili per le istanze di calcolo esistenti (più CPU, memoria e così via). La scalabilità orizzontale aumenta il numero di istanze che supportano le richieste (più host fisici, macchine virtuali o contenitori). Per i livelli Web, ad esempio IIS, la scalabilità orizzontale tende a essere più efficiente rispetto alla verticale, ma gli ambienti locali potrebbero riscontrare limitazioni delle risorse e problemi di bilanciamento del carico. Con gli ambienti cloud, la scalabilità orizzontale è molto più semplice perché le risorse sono facilmente disponibili (per un costo aggiuntivo) e il provider di servizi cloud progetta in genere il suo meccanismo di bilanciamento del carico tenendo presente la scalabilità orizzontale. I contenitori di Windows possono sfruttare la scalabilità orizzontale per IIS, ma l'aspetto temporaneo dei contenitori svolge un ruolo importante. È fondamentale che i contenitori abbiano la stessa configurazione e che non vengano archiviati stati o dati per consentire l'aumento o la riduzione del numero di istanze che supportano l'applicazione Web.

Attività pianificate

Le attività pianificate vengono usate per chiamare un programma, un servizio o uno script in qualsiasi momento in un ambiente Windows. Tradizionalmente, hai un'istanza di Windows sempre attiva e in esecuzione e quando viene soddisfatto un trigger, l'attività viene eseguita. Ciò è possibile con i contenitori di Windows e, a parte il fatto che è necessario configurare e gestire le attività pianificate tramite Azure PowerShell, funzionano esattamente allo stesso modo.

Con un approccio basato su microservizi, tuttavia, sono disponibili alcune opzioni per evitare di mantenere in esecuzione un contenitore per attendere un trigger:

• Usare un paaS basato su eventi (piattaforma distribuita come servizio), ad esempio Funzione di Azure per archiviare il codice e definire un trigger per tale app. Azure Functions supporta anche l'esecuzione di immagini di contenitore Windows quando viene soddisfatto un trigger.
• Usare i contenitori di Windows insieme a un agente di orchestrazione dei contenitori. Il contenitore può essere eseguito solo quando il trigger viene soddisfatto e chiamato da altre parti dell'applicazione. In questo caso, l'orchestratore di contenitori gestirà la pianificazione e l'attivazione dell'applicazione.
• Mantenere infine in esecuzione un contenitore di Windows per eseguire un'attività pianificata. Per mantenere il contenitore in esecuzione, avrai bisogno di un servizio in primo piano, come Monitoraggio del servizio.

Servizi in background

Anche se i contenitori sono in genere per processi temporanei, è possibile inserire in contenitori un'applicazione in background a esecuzione prolungata, purché si crei un processo in primo piano per avviarlo e mantenerlo in esecuzione.

Un ottimo esempio di questo è ServiceMonitor, che è un eseguibile di Windows progettato per essere usato come processo di ingresso durante l'esecuzione di IIS nei contenitori. Anche se è stato creato per IIS, lo strumento ServiceMonitor offre un modello che può essere usato anche per monitorare altri servizi, con alcune limitazioni.

Per altre informazioni su ServiceMonitor, vedere la documentazione di su Github.

.NET Framework e .NET

I contenitori windows supportano sia .NET Framework che .NET (in precedenza .NET Core). Il team .NET crea le proprie immagini ufficiali per entrambi i framework sulle immagini dei contenitori di base di Windows. La scelta dell'immagine appropriata è fondamentale per garantire la compatibilità. Il team .NET fornisce immagini .NET Framework basate sull'immagine del contenitore Server Core e immagini .NET basate sia su Server Core che su Nano Server. Server Core ha un set di API più grande rispetto a Nano Server, che consente una maggiore compatibilità, ma anche una dimensione più grande dell'immagine. Nano Server ha una superficie API notevolmente ridotta, ma una dimensione dell'immagine molto più piccola.

In alcuni casi, potrebbe essere necessario creare un'immagine .NET Framework o .NET personalizzata basata su le immagini di contenitore base di Windows o Server. Questo potrebbe essere necessario se l'applicazione non ha solo una dipendenza del framework, ma una dipendenza del sistema operativo. Sarà possibile rilevare tali dipendenze testando l'applicazione con una particolare immagine del contenitore di base.

Ad esempio, le immagini del contenitore di base Server Core e Nano Server hanno un solo tipo di carattere disponibile per ridurre le dimensioni dell'immagine. Se l'applicazione richiede un tipo di carattere diverso, dovrai installare il tipo di carattere o usare le immagini Server o Windows, con un set di API più grande e includere tutti i tipi di carattere di Windows predefiniti. Dal punto di vista della compatibilità, ciò consente praticamente a qualsiasi app (purché rispetti la natura dei contenitori, ad esempio senza interfaccia grafica) di essere containerizzata. Sul lato negativo, saranno molto più grandi in dimensioni, che possono influire sulle prestazioni.

Quando si convalida se l'applicazione da inserire in contenitori funziona in contenitori Windows, Microsoft consiglia quanto segue:

Per questo framework	Eseguire prima il test con questa immagine del contenitore	Passare a questa immagine del contenitore se la prima non funziona	Immagine di base
.NET Framework versioni 2.X e 3.X	.NET Framework 4.x	.NET Framework 3.5	Windows Server Core
Versioni di .NET Framework 4.x	.NET Framework 4.x	Creare l'immagine del contenitore .NET Framework con immagini server o Windows	Windows Server Core
.NET 6 o 7	.NET 6 o 7 rispettivamente	Compilare l'immagine del contenitore .NET con immagini di base di Windows o Server	Windows Nano Server o Server Core

Altri componenti di supporto

I componenti e gli argomenti seguenti forniscono indicazioni aggiuntive per gli elementi che vanno insieme o che offrono maggiore chiarezza sui contenitori di Windows.

Registrazione eventi

Windows e Linux usano metodi diversi per archiviare e presentare log ed eventi agli utenti. Tradizionalmente, Windows ha usato il formato EVT, che può essere visualizzato in modo strutturato nel Visualizzatore eventi. Linux, al contrario, ha fornito un approccio semplificato con l'output standard (stdout) su cui si basano altri strumenti, ad esempio Docker.

Docker ha sempre avuto un meccanismo per estrarre i log dai contenitori Linux. Usando il comando "docker logs" con una configurazione stdout predefinita, Docker porta i log dell'applicazione dal contenitore senza aprire il contenitore in modo interattivo. Fino all'avvio dello strumento Log Monitor, tuttavia, la stessa tecnica non funzionava in Windows.

Lo strumento Monitoraggio log presenta i log di Windows nel formato stdout in modo che altri strumenti, ad esempio Docker, possano raccogliere le informazioni necessarie per visualizzarla. I vantaggi aggiuntivi dell'uso del Monitor dei log includono i seguenti:

• Essere in grado di filtrare i tipi di eventi/log da esporre in stdout. Ad esempio, è possibile filtrare il registro delle applicazioni per i messaggi di "errore" e "avviso" solo se non sei interessato agli eventi di "informazione".
• Possibilità di scegliere tra registri eventi, file di log personalizzati o Traccia eventi per Windows (ETW). Questo è particolarmente utile se la tua applicazione scrive su una fonte di log diversa. Un esempio è costituito dai log IIS che si trovano nella cartella "C:\inetpub".
• Il fatto che Log Monitor faccia sì che i contenitori Windows si comportino in modo molto simile ai contenitori Linux consente agli strumenti che cercano stdout e interagiscono con il runtime del contenitore di funzionare come previsto. Ad esempio, se si passa da Docker a ContainerD come runtime del contenitore, i log devono comunque essere visibili dall'host del contenitore tramite (ad esempio) "crictl logs".

Per altre informazioni sullo strumento Log Monitor, vedere questo post di blog.

Sicurezza dei contenitori di Windows

I contenitori di Windows sono basati sulla stessa base delle istanze di Windows in esecuzione in macchine fisiche o virtuali. Comprendere le specifiche del modo in cui vengono implementati i contenitori, in particolare la natura del kernel condiviso, consente di proteggere un'applicazione in contenitori:

• Componenti condivisi. I contenitori di Windows condividono alcuni componenti dell'host a scopo di sicurezza. Sono inclusi Windows Firewall, Windows Defender (Antivirus) e altre limitazioni di accesso alle risorse. Non è necessario configurare questi componenti direttamente nel contenitore perché l'host contenitore apporta le modifiche necessarie in base al carico di lavoro del contenitore. Ad esempio, se il contenitore effettua una richiesta Web, l'host del contenitore inoltra il traffico necessario attraverso il firewall in modo che il contenitore possa accedere al Web.
• Modalità di isolamento. Come illustrato, i contenitori di Windows possono essere distribuiti in modalità di isolamento di processo o Hyper-V, con Hyper-V che fornisce l'isolamento più sicuro. In isolamento del processo, il contenitore condivide il kernel, il file system e il registro con l'host, che consente a un processo con privilegi elevati (amministratore) di interagire con i processi e i servizi del contenitore. La scelta della modalità di isolamento corretta per l'applicazione è importante per garantire il modello di sicurezza appropriato.
• Aggiornamenti di Windows. Poiché lo stack di manutenzione non è presente nei contenitori Windows, i contenitori di Windows non ricevono aggiornamenti come le istanze di Windows generali. È invece necessario ricompilare i contenitori di Windows usando l'immagine del contenitore di base più recente disponibile. I clienti possono sfruttare le pipeline DevOps a tale scopo. Microsoft aggiorna le immagini di base del contenitore per tutte le immagini ufficiali ogni mese, seguendo il ritmo di Patch Tuesday.
• Account utente contenitore. Per impostazione predefinita, le applicazioni all'interno dei contenitori di Windows vengono eseguite con privilegi elevati con l'account utente ContainerAdmin. Ciò è utile per l'installazione e la configurazione dei componenti necessari all'interno dell'immagine del contenitore. È tuttavia consigliabile modificare l'account utente in ContainerUser quando si esegue un'applicazione che non richiede privilegi elevati. Per scenari specifici, è anche possibile creare un nuovo account con i privilegi appropriati.
• Analisi di immagini e runtime. I container richiedono che le immagini nei repository e nelle istanze di container siano sicure. Microsoft consiglia di usare Microsoft Defender per contenitori per l'analisi delle immagini e l'analisi in fase di esecuzione. Defender per contenitori supporta i contenitori di Windows per la valutazione delle vulnerabilità con analisi del Registro di sistema e protezione di runtime con il rilevamento delle minacce.

Altre informazioni sugli argomenti precedenti sono disponibili nella pagina della documentazione dei contenitori di Windows .

Backup dei contenitori di Windows

È necessario considerare i backup in modo diverso quando si usano contenitori. Come illustrato in precedenza, un contenitore non deve essere usato per archiviare lo stato o i dati in base alla sua natura temporanea. Se si separano lo stato e i dati dall'istanza del contenitore, i problemi di backup non rientrano nel runtime dell'istanza del contenitore, che può essere sostituito con uno nuovo a cui sarà ancora disponibile tutto lo spazio di archiviazione permanente necessario.

Ci sono ancora componenti responsabili del backup, tuttavia; tra cui l'applicazione, l'immagine del contenitore e il dockerfile che compila l'immagine del contenitore. La maggior parte di queste operazioni viene gestita dalla piattaforma in cui vengono eseguiti i carichi di lavoro di produzione e sviluppo. Quando si adotta un approccio DevOps, considerare i casi più comuni:

• Applicazione: l'applicazione si trova probabilmente in un repository di origine, ad esempio GitHub o Azure DevOps. Questi repository forniscono il controllo della versione, che consente di ripristinare una versione specifica dell'applicazione. Se si è proprietari del repository di origine, assicurarsi di seguire le raccomandazioni relative al backup e alla gestione.
• Immagine del contenitore: per gli ambienti di produzione, l'immagine del contenitore deve entrare in un repository di immagini centralizzato, ad esempio Registro Azure Container. È possibile eseguire il push delle immagini del contenitore nel Registro Azure Container (ACR) per renderle disponibili ad altri host affinché possano scaricarle. Registro Azure Container gestisce la disponibilità delle immagini del contenitore e funge da opzione di backup. Tenere tuttavia presente che, mentre Registro Azure Container gestisce la disponibilità dell'immagine, non impedisce l'eliminazione o la sovrascrittura di un'immagine. Per qualsiasi altro repository di immagini locale o locale, seguire la raccomandazione del fornitore per il backup dei registri esistenti.
• Dockerfile: i Dockerfile compilano nuove immagini del contenitore e vengono in genere archiviati insieme all'origine dell'applicazione. Poiché il dockerfile potrebbe non essere stato creato con l'applicazione, soprattutto se si tratta di un'applicazione esistente in contenitori, si è responsabili di garantire che il dockerfile sia archiviato in una posizione protetta e sottoposta a backup. È anche necessario assicurarsi che venga eseguito il backup di tutti gli altri asset necessari per il funzionamento dell'applicazione in un contenitore; Ad esempio, i file YAML e JSON per Kubernetes, Docker Swarm e i modelli di Azure RESOURCE Manager seguono le stesse linee guida indicate in precedenza.

Pianificazione del processo lift-and-shift

Dopo aver valutato l'idoneità dell'applicazione per la containerizzazione, usare le indicazioni generali seguenti per pianificare il processo:

1. Determinare l'immagine di base del sistema operativo Windows necessaria: Windows Server Core, Nano Server, Windowso Server immagini.
2. Determinare il tipo di modalità di isolamento per il contenitore: scegliere tra modalità di isolamento del processo o modalità di isolamento Hyper-V. Nota: Attualmente, AKS e AKS su Azure Stack HCI supportano solo contenitori con isolamento di processo. In futuro, sia AKS che AKS su Azure Stack HCI supporteranno anche i contenitori isolati di Hyper-V. Per altre informazioni, vedere modalità di isolamento .
3. Scegliere la versione corretta di Windows Server per l'applicazione a scopo di compatibilità app. La versione minima di Windows Server per i contenitori è Windows Server 2016, ma Windows Server 2019 e Windows Server 2022 sono gli unici sistemi operativi host contenitore supportati nel servizio Azure Kubernetes e nel servizio Azure Kubernetes in Azure Stack HCI.
4. Assicurarsi che i criteri di sicurezza dell'azienda siano applicati per l'ambiente contenitore. Ciò include l'adattamento a requisiti specifici del contenitore, ad esempio l'analisi del Registro di sistema e il rilevamento delle minacce.
5. Prendere in considerazione le esigenze di bilanciamento del carico. I contenitori stessi non si spostano; è invece possibile usare un agente di orchestrazione per avviare o arrestare automaticamente i contenitori nei nodi del cluster o per gestire le modifiche nel carico e nella disponibilità con scalabilità orizzontale automatica.
6. Prendere in considerazione le esigenze di orchestrazione. Una volta containerizzata, l'applicazione richiede probabilmente la gestione automatizzata disponibile con strumenti come Kubernetes, AKS o AKS in Azure Stack HCI. Vedi panoramica dell'orchestrazione dei contenitori di Windows per una discussione completa e una guida alla scelta tra gli strumenti.
7. Containerizzare l'app.
8. Invia l'app su un repository di immagini. Ciò consentirà agli host del contenitore di scaricare l'immagine in qualsiasi ambiente, tra cui sviluppo, test e produzione.

Azure Migrate può fornire un processo guidato per l'individuazione, la valutazione e la migrazione dell'applicazione Windows esistente al servizio Azure Kubernetes. Per ulteriori informazioni, consulta la pagina della documentazione di Azure Migrate .