Uso di contenitori Di Windows per "Containerizzare" le applicazioni esistenti

  • Articolo

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

I contenitori Di Windows offrono un meccanismo ottimale per modernizzare le applicazioni tradizionali o legacy. Anche se si può sentire questo approccio denominato "lift and shift to container", la metafora lift-and-shift ha origine dal trasferimento dei carichi di lavoro da fisici a macchine virtuali ed è stata usata in ritardo quando si fa riferimento a carichi di lavoro come è al cloud (sia privato che pubblico). Oggi questo termine è più appropriato per la migrazione di macchine virtuali (VM). Ma i contenitori non sono macchine virtuali e pensano a loro perché le macchine virtuali possono causare confusione sul modo in cui un'applicazione può essere in contenitori o se può anche essere in contenitori.

In questo argomento vengono fornite indicazioni pratiche sullo spostamento delle applicazioni tradizionali nei contenitori di Windows. È destinato ad aiutare a definire le priorità delle applicazioni che devono essere in contenitori, spiegando considerazioni speciali in anticipo.

Introduzione

Quali contenitori di Windows sono e cosa non sono

Il contenitore generico si riferisce a una tecnologia che virtualizza il sistema operativo (OS). Questa virtualizzazione offre un livello di isolamento dal sistema operativo del server o dell'host stesso, che a sua volta consente una 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. Ma l'interdipendenza totale tra il contenitore e l'host è impossibile: un contenitore Windows deve coordinare la richiesta 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 si desidera 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 validi che consentono di ricordare il contenitore e la distinzione della macchina virtuale 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 eseguiti su immagini di contenitori specializzate, supportano solo quelle applicazioni che non necessitano di un front-end grafico.
  • I contenitori sono effimerali per natura. Ciò significa che, per impostazione predefinita, non esiste alcun meccanismo per salvare lo stato di un'istanza di un contenitore. Se un'istanza ha esito negativo, verrà eseguita un'altra istanza.

La tecnologia contenitore è iniziata in Linux, con Docker emergente come standard. Microsoft ha lavorato strettamente con Docker per garantire che la funzionalità del contenitore sia la stessa in Windows che sia ragionevolmente possibile. Le differenze intrinseche tra Linux e Windows possono essere visibili in modi che sembrano essere limitazioni dei contenitori Di Windows quando in realtà sono solo le differenze linux rispetto a Windows. D'altra parte, i contenitori Windows forniscono alcune implementazioni univoche, ad esempio l'isolamento Hyper-V, che verrà coperto in un secondo momento. Questo argomento consente di comprendere queste differenze e 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à di concentrarsi sullo sviluppo di applicazioni e sull'infrastruttura sottostante. Significa anche che è possibile isolare un'applicazione in modo che non sia influenzata da altri processi supportati dal sistema operativo.

I contenitori forniscono un metodo leggero per la creazione e l'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 aumentare la scalabilità. Con i contenitori è anche possibile riavviare rapidamente in caso di arresto anomalo o interruzione hardware. I contenitori consentono di eseguire qualsiasi app dallo sviluppo all'ambiente di produzione senza modifiche di codice, in quanto "contengono" dipendenze dell'applicazione in modo che funzionino in ambienti diversi. La possibilità di contenitori di un'applicazione esistente con modifiche minime del codice, a causa dell'integrazione di Docker negli 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à ottenuta 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 molto più completo dei vantaggi per l'uso di contenitori per le applicazioni esistenti nella pagina della documentazione di Microsoft .NET.

Concetto importante di isolamento

I contenitori di Windows forniscono l'isolamento dal sistema operativo Windows, l'isolamento vantaggioso quando si sta creando, testando e promuovendo un'app in produzione. Tuttavia, il modo in cui viene raggiunto l'isolamento è importante comprendere quando si sta pensando al contenitore di un'applicazione.

I contenitori 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é dovresti curarti? In isolamento dei processi più contenitori vengono eseguiti simultaneamente in un singolo host con isolamento fornito tramite spazio dei nomi, controllo delle risorse e altre funzionalità. I contenitori in modalità di isolamento del processo condividono lo stesso kernel con l'host e gli altri. Si tratta approssimativamente dello stesso modo in cui i contenitori Linux vengono eseguiti.

Nell'isolamento Hyper-V, più contenitori vengono eseguiti simultaneamente in un singolo host, ma i contenitori vengono eseguiti all'interno di macchine virtuali altamente ottimizzate, con ogni kernel in modo efficace. La presenza di questa macchina virtuale, in modo efficace una macchina virtuale "utilità", fornisce l'isolamento a livello hardware tra ogni contenitore e l'host del contenitore.

In un modo, la modalità di isolamento Hyper-V è quasi come un ibrido di una macchina virtuale e un contenitore, fornendo un livello di sicurezza aggiuntivo particolarmente utile se l'app necessita di 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.
  • Né servizio Azure Kubernetes (AKS) né servizio Azure Kubernetes in Azure Stack HCI supportano l'isolamento Hyper-V in questo momento.

Per altre informazioni su come vengono implementate le due modalità di isolamento nell'argomento Modalità di isolamento. Quando si esegue il primo contenitore di un'app, è necessario scegliere tra le due modalità. Fortunatamente, è molto facile cambiare da una modalità a un'altra in un secondo momento, perché non richiede modifiche all'applicazione o al contenitore. Ma tenere presente che, quando si esegue il contenitore di un'app, la scelta tra le due modalità è una delle prime operazioni da eseguire.

Orchestrazione dei contenitori

La possibilità di eseguire più contenitori in uno o più host senza preoccupazione per la gestione del sistema operativo offre una grande flessibilità, consentendo di passare a un'architettura basata su microservizi. Un compromesso per tale flessibilità, anche se, è che un ambiente basato su contenitori e microservizi può entrare rapidamente in molte parti in movimento, troppi 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 del contenitore.

Gli orchestratori sono forse misnominati; sono più simili ai conduttori di un'orchestra in cui coordinano l'attività di più contenitori per mantenere la musica in riproduzione. In un certo senso, gestiscono la pianificazione e l'allocazione delle risorse per i contenitori in modo simile al funzionamento di un sistema operativo. Quindi, quando si passa a contenitori le applicazioni, sarà 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 considera se un'app può essere in contenitori o meno, è probabilmente più semplice iniziare con l'elenco di fattori che estraono completamente i contenitori di Windows come opzione.

La tabella seguente riepiloga i tipi di app che non possono essere spostati nei contenitori di Windows e perché non. I motivi sono più descritti nelle sottosezioni dopo la tabella. Comprendere i motivi di queste limitazioni può offrire un'idea più chiara di quali contenitori sono realmente, incluso il modo in cui differiscono dalle macchine virtuali. Ciò consente di valutare meglio le funzionalità dei contenitori Di Windows che è possibile sfruttare con le app esistenti che è possibile raggruppare.

Nota: l'elenco seguente non è un elenco completo. Invece, è una compilazione di app Microsoft ha visto che i clienti tentano di 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 l'installazione di un GUI, la modifica in un'installazione invisibile all'utente potrebbe essere una soluzione
Applicazioni che usano Remote Desktop Protocol (RDP) RDP è per sessioni interattive, quindi il principio precedente si applica anche qui È possibile usare Windows Admin Center (WAC) o Remote PowerShell 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 Lo scopo e la progettazione di Active Directory impediscono l'esecuzione in un contenitore No. Tuttavia, le app dipendenti da Active Directory possono usare account del servizio gestito di gruppo (gMSA). Di seguito sono riportate altre informazioni su gMSA
Versioni precedenti di Windows Server È supportato solo Windows Server 2016 o versioni successive No. Tuttavia, la compatibilità delle applicazioni potrebbe essere un'opzione: la maggior parte delle app windows Server 2008/R2 e versioni precedenti viene eseguita nelle versioni più recenti di Windows Server
App che usano .NET Framework versione 2.0 o versione precedente Sono necessarie immagini di contenitori specifiche per supportare .NET Framework e sono supportate solo versioni più recenti Le versioni precedenti alla versione 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 Di 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 sua 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. Ma non è possibile usarli per le applicazioni con guI stessi. Questo è vero anche se l'applicazione stessa non ha un GUI, ma ha un programma di installazione che si basa su un GUI. In generale, Windows Installer può essere richiamato usando PowerShell, ma se l'applicazione richiede l'installazione tramite un GUI, tale requisito lo elimina come candidato per il contenitore.

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

È un problema diverso se un'app necessita di API GUI. Le API sono supportate anche se l'interfaccia utente gestita da tali API non è. Questo argomento è più descritto nell'argomento Nano Server x Server Core x Server - Quale immagine di base è quella giusta per te?

Applicazioni che usano RDP

Poiché l'intero scopo del protocollo RDP (Remote Desktop Protocol) è stabilire una sessione interattiva e visiva, la limitazione dell'interfaccia utente appena descritta si applica. Un'applicazione che usa RDP non può essere in contenitori come è.

Tuttavia, un'ottima alternativa è uno strumento di gestione remota, ad esempio 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 in essi. È anche possibile aprire una sessione di PowerShell remota all'host e/o ai contenitori per gestirli.

Applicazioni con stato

Le applicazioni che devono conservare i dati sullo stato possono essere contenitori solo se si isolano i dati necessari da una sessione all'altra e archiviarla nell'archiviazione persistente. Ciò potrebbe richiedere una "richitecizzazione" che può o non essere semplice ma procedere con esso eliminerà questa barriera per la 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 (una macchina virtuale in questo caso) ha esito negativo, è sufficiente eseguirne il backup e il file sarà ancora presente. Al contrario, se un'istanza del contenitore che esegue un'operazione di scrittura ha esito negativo, la nuova istanza del contenitore non includerà tale file. Per questo motivo, è consigliabile usare l'archiviazione persistente 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 ripristino non richiede di modificare il codice dell'applicazione, solo il tipo di archiviazione usato dall'istanza di Windows. Per altre informazioni, vedere la documentazione del contenitore Di Windows nell'archiviazione.

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

Applicazioni di database

Come regola generale, le applicazioni di database non sono ideali per la containerizzazione. Anche se è possibile eseguire un database all'interno di un contenitore, il ridimensionamento 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 devalore 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 potrebbe diventare un sovraccarico. La maggior parte dei database, ad esempio Microsoft SQL Server, dispone di un meccanismo di bilanciamento del carico predefinito 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 richiedono questi ruoli saranno sempre difficili da contenitore.

Ci sono alcune aree grigie. Ad esempio, alcune funzionalità come DNS possono funzionare nei contenitori Di 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 database. Questa relazione è strettamente associata e gli oggetti vengono mantenuti nel database anche se l'utente o il dispositivo effettivo non è più in gioco. Tale approccio per Active Directory contraddice direttamente la natura temporanea dei contenitori, che si prevede che siano brevi o eliminati quando disattivato. La gestione di questa relazione uno-a-uno con Active Directory non è ideale per tali 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 dell'infrastruttura nei contenitori di 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 nei contenitori windows dipendenti da Active Directory, è possibile usare account del servizio gestito di gruppo (gMSA), che verranno illustrati ulteriormente.

App che usano .NET Framework versione 2.0 o versione precedente

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

App che usano framework di terze parti (non Microsoft)

In genere, Microsoft non è in grado di certificare framework o applicazioni di terze parti o di supportarli in esecuzione nei contenitori Di Windows, o nelle macchine virtuali e fisiche per tale questione. 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, convalidare la sua supportabilità nei contenitori Windows con il fornitore che lo fornisce.

Candidati ideali per il contenitore

Ora che abbiamo considerato le limitazioni difficili per il contenitore delle app, è più facile vedere quali tipi di app si prestano in modo più semplice ai contenitori di Windows. I candidati ideali per i contenitori di Windows e tutte le considerazioni speciali per la loro creazione di contenitori sono disponibili nella tabella seguente.

Tipo di applicazione Perché questi sono buoni candidati Considerazioni speciali
Applicazioni console Senza limitazioni GUI, 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é questi sono 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 in background in contenitori. Vedere la sezione servizi in background di seguito.
Servizi Windows Communication Foundation (WCF) Poiché sono app orientate al servizio che possono essere 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 mantenere in esecuzione qualsiasi processo in background in contenitori. Vedere la sezione servizi in background di seguito.
App Web Le applicazioni Web sono in sostanza servizi in background in ascolto su una porta specifica e sono pertanto ottimi candidati per la containerizzazione, in quanto possono sfruttare 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 sulle principali funzionalità e componenti di Windows che dovranno essere gestiti in modo diverso nei contenitori di Windows. La sezione successiva, che illustra più dettagli su tali considerazioni pratiche, ti preparerà meglio per sfruttare la funzionalità dei contenitori di Windows.

Considerazioni pratiche per le applicazioni che possono essere in contenitori

I progetti di ristrutturazione delle app in genere prendono in considerazione se un'app specifica può essere in contenitori attraverso 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 a cui si basa. Pertanto, non c'è una risposta semplice a una domanda come "Posso contenitore l'applicazione HR?" perché non è quello che sta facendo l'applicazione, è come (e quali componenti/servizi di Windows usa) che rende la differenza.

Questa è una distinzione importante, perché se l'applicazione non è compilata con un'architettura di microservizi per iniziare, è probabile che sia più difficile da containerizzare. Quando si procede al contenitore, alcune funzionalità potrebbero richiedere una gestione speciale. Alcuni possono essere dovuti all'uso dell'app di componenti e framework di Windows principali che non sono supportati nei contenitori di Windows. Altri, ad esempio la registrazione degli eventi e il monitoraggio, sono dovuti a differenze intrinseche tra Linux e Windows che diventano evidenti solo quando si in contenitori 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 necessita di una gestione speciale.

La tabella seguente presenta un riepilogo rapido dei componenti/funzionalità delle applicazioni che richiedono considerazioni speciali quando si sta pensando al ridimensionamento dei contenitori. 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 i servizi in background sono supportati, l'esecuzione di un servizio in background in .NET Framework 1.1 non è supportata.

Funzionalità/componente di Windows che richiedono una gestione speciale Motivo
Microsoft Messaggi coda (MSMQ) MSMQ ha avuto origine molto prima dei contenitori e non tutti i 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 è lo stesso di una macchina virtuale, ma esistono considerazioni importanti per l'esecuzione in un ambiente contenitore, ad esempio gestione certificati, stringhe di connessione del database e altro ancora.
Attività pianificate I contenitori di Windows possono eseguire attività pianificate, esattamente come qualsiasi istanza di Windows. Potrebbe tuttavia essere necessario eseguire un'attività in primo piano per mantenere in esecuzione l'istanza del contenitore. A seconda dell'applicazione, è possibile considerare un approccio basato su eventi.
Servizi in background Poiché i contenitori vengono eseguiti come processi temporanei, è necessaria una gestione aggiuntiva per mantenere il contenitore 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 Motivo Approccio alternativo
Registrazione eventi/monitoraggio Poiché il modo in cui Windows scrive eventi e log è intrinsecamente diverso da stdout Linux Usare il nuovo strumento Log Monitor per normalizzare i dati e combinare sia da Linux che da Windows
Sicurezza dei contenitori Di Windows Mentre molte procedure di sicurezza rimangono uguali, i contenitori richiedono misure di sicurezza aggiuntive Usare uno strumento di analisi delle immagini e del Registro di sistema per scopi: altri dettagli più avanti
Backup dei contenitori Di Windows I contenitori non devono avere dati o stato in esso Eseguire il backup di qualsiasi archiviazione persistente usata dai contenitori, oltre alle immagini del contenitore

Componenti/funzionalità di Windows

Ora esaminiamo i dettagli delle applicazioni e dei componenti che possono essere contenitori, ma richiedono una gestione aggiuntiva.

MSMQ

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

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

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

  • Modalità di isolamento: modalità di elaborazione e modalità Hyper-V per l'isolamento funzionano con gli scenari elencati sopra.
  • 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 con MSMQ in servizio Azure Kubernetes (Servizio Azure Kubernetes) usando i file di Azure per l'archiviazione persistente.

Quando si inseriscono queste considerazioni insieme alla tabella precedente, è possibile notare che l'unico scenario che non è supportato è per le code che richiedono l'autenticazione con Active Directory. L'integrazione di gMSAs (Group Managed Service Accounts) con MSMQ non è attualmente supportata perché MSMQ ha dipendenze su Active Directory che non sono ancora presenti.

In alternativa, usare bus di servizio di Azure anziché MSMQ. bus di servizio di Azure è un gestore messaggi aziendale completamente gestito con code di messaggi e argomenti di pubblicazione-sottoscrizione (in uno spazio dei nomi). Il passaggio da MSMQ a bus di servizio di Azure richiede modifiche di codice e ri-architettura dell'applicazione, ma offre l'agilità per passare a una piattaforma moderna.

MSDTC

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

  • Quando si crea il contenitore, assicurarsi di passare il parametro --name al comando docker run. Questo parametro di nome è 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.
    • Ecco un esempio del comando di esecuzione 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 risolvere l'uno l'altro usando il nome NETBIOS. Se si verifica una difficoltà con questo modo migliore per risolvere, è aggiungere il nome e l'ip dei contenitori agli altri file host.
  • L'uuid per msdtc in entrambi i contenitori deve essere univoco. L'uuid è disponibile eseguendo "Get-Dtc" in PowerShell nei contenitori. Se non sono univoci, un modo per risolvere consiste nel 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 si ha una necessità specifica di eseguire MSDTC nel servizio Azure Kubernetes, contattare il team dei contenitori di Windows aprendo il problema nel repository contenitori Di Windows in GitHub.

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 che devono essere considerati 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 elementi che si manterranno 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 scratch" 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, è consigliabile usare l'archiviazione permanente per i dati che devono essere accessibili all'applicazione Web, in modo che qualsiasi istanza del contenitore possa accedere a tale archiviazione.
  • Certificati: anche se è possibile avere certificati locali nelle istanze del contenitore, è consigliabile evitare di farlo, perché se è necessario aggiornare un certificato, è necessario ricompilare l'immagine del contenitore. In alternativa, è possibile usare un agente di orchestrazione del contenitore con il controllo Ingress. I controller in ingresso possono applicare criteri di rete e gestire anche la gestione dei certificati per il sito Web ospitato dietro di esso. Lo svantaggio è la separazione tra la gestione del ciclo di vita dei certificati e la gestione del sito Web.
  • Stringhe di connessione del 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 l'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 o macchine virtuali o contenitori). Per i livelli Web, ad esempio IIS, la scalabilità orizzontale tende a essere più efficiente rispetto a quella 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 meccanismo di bilanciamento del carico tenendo conto della 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 sia archiviato alcuno stato 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, si dispone di un'istanza di Windows in esecuzione in qualsiasi momento 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 ai 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. Funzioni di Azure supporta anche l'esecuzione di immagini contenitore di 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'agente di orchestrazione del contenitore gestirà la pianificazione e il trigger per l'applicazione.
  • Infine, mantenere in esecuzione un contenitore Di Windows per eseguire un'attività pianificata. Per mantenere il contenitore in esecuzione, è necessario un servizio in primo piano, ad esempio Monitoraggio servizi.

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 è ServiceMonitor, un eseguibile di Windows progettato per essere usato come processo di ingresso durante l'esecuzione di IIS in contenitori. Anche se è stato compilato 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 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 oltre alle immagini del contenitore di base di Windows. La scelta dell'immagine appropriata è fondamentale per garantire la compatibilità. Il team .NET fornisce immagini .NET Framework sopra l'immagine del contenitore di base Server Core e le immagini .NET sopra le immagini del contenitore di base Server Core e Nano Server. Server Core ha un set di API di dimensioni maggiori 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 sopra le immagini del contenitore di 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 tale tipo di carattere o usare le immagini Server o Windows, che hanno un set di API più grande e includono tutti i tipi di carattere predefiniti di Windows. Dal punto di vista della compatibilità, ciò consente di inserire in contenitori praticamente qualsiasi app (purché rispettino la natura dei contenitori, ad esempio no-GUI). Sul lato negativo, saranno molto più grandi di 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 contenitore Eseguire il fallback a questa immagine del contenitore se prima non funziona Base image
.NET Framework versioni 2.X e 3.X .NET Framework 4.x .NET Framework 3.5 Componenti di base di Windows Server
Versioni di .NET Framework 4.x .NET Framework 4.x Creare l'immagine del contenitore .NET Framework con immagini Server o Windows Componenti di base di Windows Server
.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 Windows.

Registrazione eventi

Windows e Linux usano metodi diversi per archiviare e presentare log ed eventi agli utenti. In genere, Windows ha usato il formato EVT, che può essere visualizzato in modo strutturato in 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 consente di disconnettere i log dell'applicazione dal contenitore senza aprire il contenitore in modo interattivo. Fino all'avvio dello strumento Monitoraggio log, 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. Di seguito sono riportati i vantaggi aggiuntivi per l'uso di Log Monitor:

  • Possibilità di filtrare i tipi di eventi/log da esporre in stdout. Ad esempio, è possibile filtrare il registro applicazioni per i messaggi "error" e "warning" solo se non si è interessati agli eventi "information".
  • Possibilità di scegliere tra registri eventi, file di log personalizzati o Traccia eventi per Windows (ETW). Ciò è particolarmente utile se l'applicazione scrive in un'origine log diversa. Un esempio è costituito dai log IIS che si trovano nella cartella "C:\inetpub".
  • Il fatto che Log Monitor renda i contenitori Windows molto simili ai contenitori Linux e quindi agli strumenti che cercano stdout e interagiscono con la funzione di runtime del contenitore 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 loro 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 contenitore inoltra il traffico necessario attraverso il firewall in modo che il contenitore possa accedere al Web.
  • Modalità di isolamento. Come illustrato, i contenitori Windows possono essere distribuiti in modalità di isolamento di Elaborazione 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 di sistema 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 Windows non ricevono aggiornamenti come istanze generali di Windows. È 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 del contenitore di base per tutte le immagini ufficiali ogni mese dopo la cadenza patch martedì.
  • Account utente contenitore. Per impostazione predefinita, le applicazioni all'interno dei contenitori di Windows vengono eseguite con privilegi elevati nell'account utente ContainerAdmin. Questo è utile per l'installazione e la configurazione dei componenti necessari all'interno dell'immagine del contenitore. È tuttavia consigliabile modificare l'account utente in ContainerUser durante l'esecuzione di un'applicazione che non richiede i privilegi elevati. Per scenari specifici, è anche possibile creare un nuovo account con i privilegi appropriati.
  • Analisi delle immagini e del runtime. I contenitori richiedono che le immagini nei repository e nelle istanze dei contenitori siano sicure. Microsoft consiglia di usare Microsoft Defender per contenitori per l'analisi delle immagini e l'analisi del runtime. Defender per contenitori supporta i contenitori Windows per la valutazione della vulnerabilità con analisi del Registro di sistema e protezione del 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 effimerale. 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 persistente necessario.

Sono comunque presenti componenti responsabili del backup; inclusa 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, prendere in considerazione i casi più comuni:

  • Applicazione: l'applicazione risiede 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 possiede il repository di origine, assicurarsi di seguire le raccomandazioni relative al backup e alla gestione.
  • Immagine contenitore: per gli ambienti di produzione, l'immagine del contenitore deve essere attiva in un repository di immagini centralizzato, ad esempio Registro Azure Container (ACR). È possibile eseguire il push delle immagini del contenitore in ACR in modo da renderlo disponibile per altri host per eseguirne il pull. Il Registro Azure Container gestisce la disponibilità delle immagini del contenitore e funge da opzione di backup, tuttavia, tenere presente che, mentre ACR gestisce la disponibilità dell'immagine, non impedisce l'eliminazione o la sovrascrizione di un'immagine. Per qualsiasi altro repository di immagini locali o locali, seguire la raccomandazione del fornitore di eseguire il backup di 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 che è in fase di contenitore, è responsabile di garantire che il dockerfile sia archiviato in una posizione sicura e di backup. È anche necessario assicurarsi che tutti gli altri asset necessari per il funzionamento dell'applicazione in un contenitore siano sottoposti a backup; ad esempio: i file YAML e JSON per Kubernetes, Docker Swarm e i modelli di Azure ARM seguono le stesse linee guida riportate in precedenza.

Pianificazione del processo di lift-and-shift

Dopo aver valutato la conformità dell'applicazione per il contenitore, 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, Windows o Immagini server .
  2. Determinare il tipo di modalità di isolamento per il contenitore: scegliere tra le modalità di isolamento di processo o Hyper-V. Nota: attualmente, il servizio Azure Kubernetes e il servizio Azure Kubernetes in Azure Stack HCI supportano solo contenitori isolati dal processo. In una versione futura, sia il servizio Azure Kubernetes che il servizio Azure Kubernetes in Azure Stack HCI supporterà anche contenitori isolati Hyper-V. Per altre informazioni, vedereModalità di isolamento.
  3. Scegliere la versione corretta di Windows Server per scopi app-compat. 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 contenitori supportati nel servizio Azure Kubernetes e nel servizio Azure Kubernetes in Azure Stack HCI.
  4. Assicurarsi che i criteri di sicurezza dell'azienda siano disponibili 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; è possibile usare invece un agente di orchestrazione per avviare o arrestare automaticamente i contenitori nei nodi del cluster o per gestire le modifiche in carico e disponibilità con scalabilità orizzontale automatica.
  6. Prendere in considerazione le esigenze di orchestrazione. Una volta in contenitori, l'applicazione richiede probabilmente la gestione automatizzata disponibile con strumenti quali Kubernetes, Servizio Azure Kubernetes o servizio Azure Kubernetes in Azure Stack HCI. Per una discussione completa e una guida alla scelta tra gli strumenti, vedere Panoramica dell'orchestrazione di Contenitori di Windows .
  7. Distribuire l'app in un contenitore.
  8. Eseguire il push dell'app in un repository di immagini. In questo modo gli host del contenitore potranno 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 in servizio Azure Kubernetes. Per altre informazioni, vedere la pagina della documentazione di Azure Migrate .