Contenitori in Windows Server 2016: cosa devi sapere

In un articolo che ho scritto per Computerworld a gennaio, che era una recensione di Windows Server 2016 Technical Preview 4, ho menzionato il nuovo supporto di Windows Server per i contenitori Hyper-V che era stato aggiunto al suo supporto per i contenitori in stile Docker (presente nella versione beta prodotto dalla precedente versione beta milestone).

Tuttavia, la presenza di due opzioni di contenitore ha portato a molte domande. Qual è la differenza tra un contenitore Docker e un nuovo contenitore Hyper-V? In quali scenari vorresti utilizzare una soluzione container rispetto all'altra? Esistono metodi separati per distribuire ciascuno di questi?

Microsoft non ha fatto un ottimo lavoro nel documentare queste due opzioni di contenitore e i contenitori stessi sono nuovi per la piattaforma Windows Server. Alla luce di questi due fattori, voglio dedicare un'intera storia a quali soluzioni container specifiche Windows Server 2016 fornisce ora in anteprima nelle versioni disponibili o promette di fornire prima della data di rilascio del software per la produzione (RTM), molto probabilmente in la seconda metà del 2016.

Panoramica

Al momento in Windows Server 2016 sono presenti due tipi di contenitori: contenitori di Windows Server e contenitori Hyper-V. Entrambi supportano solo Windows Server; nessuno dei due può combinare Linux e / o Unix, per esempio.

Per gli amministratori pigri come me, chiariamo subito la domanda importante: uno dei due tipi di container è più difficile da distribuire dell'altro? La risposta è un deciso no.

[Ulteriori letture: Primo sguardo: Esegui VM in VM con contenitori Hyper-V]

I tipi di contenitore vengono eseguiti in modo diverso e hanno diversi livelli di isolamento e fiducia nell'hypervisor. Ma in sostanza, questa è una decisione in fase di distribuzione presa dal proprietario della macchina fisica - il proprietario dell'host - sul tipo di contenitore che verrà utilizzato ed è semplice come controllare il pulsante di opzione corretto in una procedura guidata . Scegli semplicemente tra i due al momento della creazione. La decisione influenza il modo in cui Windows Server 2016 - il sistema operativo stesso (l'hypervisor, che si trova in fondo a tutte queste cose, in esecuzione sul silicio e sul ferro fisico) - isola ed esegue i carichi di lavoro all'interno di ciascun contenitore.

Quindi ora che sai che entrambe le opzioni del contenitore sono la stessa quantità di lavoro per te, come decidi in modo intelligente tra le due? In sostanza, si tratta di fiducia: se ti fidi del codice in esecuzione all'interno del contenitore, sceglierai un contenitore Windows Server (leggi: tradizionale, in stile Docker). Se non ti fidi del codice, o non puoi verificarlo, o non proviene dai tuoi sviluppatori interni all'interno della tua organizzazione, allora un contenitore Hyper-V è la strada da percorrere. Diamo un'occhiata a ciascuna opzione in dettaglio.

Contenitori di Windows Server

I contenitori di Windows Server sono in realtà solo una parte del progetto contenitore open source Docker, quindi se pensi a un contenitore in stile Docker, starai pensando a un contenitore Windows Server. Questi contenitori sono essenzialmente un nuovo tipo di macchina virtuale che in qualche modo ha meno isolamento rispetto a una macchina virtuale tradizionale, ovvero perché, in molti casi, le cose comuni a tutti i contenitori in esecuzione su un host sono condivise. Tra questi elementi condivisi vi sono file del sistema operativo, directory e servizi in esecuzione. Questo viene fatto per una maggiore efficienza, perché se stai eseguendo tre diversi contenitori su un host, tutti con la stessa versione di Windows Server come ospiti, hai bisogno di una sola copia della directory C: \ Windows in un dato momento.

Questa condivisione separa ancora i contenitori da qualsiasi applicazione che potrebbe essere eseguita su un host, ma riduce anche il sovraccarico e rende i contenitori più leggeri. Hai più spazio per server che esegue i contenitori a causa di questa condivisione, rispetto all'esecuzione di macchine virtuali tradizionali, che sono più isolate e non condividono nulla, e quindi tendono ad avere molte più duplicazioni. Inoltre, in genere utilizzeresti i contenitori di Windows Server quando l'host e il guest eseguono tutti lo stesso sistema operativo per sfruttare questa condivisione; di conseguenza, non è possibile eseguire un contenitore con Ubuntu Server in esecuzione su un host Windows Server 2016. (Per quel tipo di carico di lavoro, usereste macchine virtuali tradizionali. I contenitori non sarebbero appropriati per questo. Usereste solo VM, che sono state supportate in Windows dal 2008.)

Per quel che vale, in questo momento i due sistemi operativi container-immagine supportati dai container di Windows Server sono Server Core (Windows senza la sua interfaccia utente grafica) e Windows Nano Server, il microserver radicalmente refactored adatto a ruoli orientati ai piccoli microservizi. (Maggiori informazioni sui microservizi tra poco.)

Quindi come si inserisce Docker in tutto questo? Docker fornisce un "livello di gestione", se vuoi, di API e motori per gestire i container, uno che è diventato rapidamente uno standard del settore, molto probabilmente perché Docker stesso è open source e ampiamente utilizzato. Il Docker Hub, disponibile per l'utilizzo da parte di chiunque su Internet, è un vero repository di applicazioni in stile mercato che vengono eseguite all'interno di contenitori in stile Docker.

Docker fornisce anche un framework mentale che gli sviluppatori possono utilizzare per avvicinarsi al funzionamento effettivo del loro codice e per creare interi contenitori degli ambienti che il loro codice richiede per l'esecuzione. Gli sviluppatori creano essenzialmente immagini del contenitore, che vengono quindi inviate alle operazioni abbastanza facilmente ed eseguite essenzialmente come sono come ospiti su quell'host. Aggiornamenti e correzioni di codice possono essere gestiti rapidamente e facilmente allo stesso modo.

Ognuna di queste immagini del contenitore potrebbe funzionare anche su una parte molto piccola dell'applicazione complessiva, il che rende la soluzione in componenti e semplifica il lavoro in un ambiente orientato ai microservizi. Da una prospettiva generale, lavorare con i contenitori aumenta la responsabilità per gli sviluppatori di scrivere un buon codice che funzioni esattamente all'interno del loro ambiente. Gli sviluppatori non possono più scrivere codice che funzioni perfettamente sulle loro macchine di sviluppo, ma cade quando viene distribuito sul software di produzione: poiché sono la stessa cosa, il codice deve funzionare in entrambi i posti. Ciò riduce anche l'attrito tra le operazioni e l'IT: l'IT con i suoi ambienti server incontaminati e gli sviluppatori che si aspettano determinate configurazioni ma spesso non hanno la capacità o la motivazione per modificare gli ambienti di produzione in base alle loro aspettative.

Questi contenitori di Windows Server in stile Docker implicano una certa attendibilità: che tu abbia scaricato un'applicazione attendibile da Docker Hub o che gli sviluppatori interni o gli sviluppatori a contratto ti abbiano fornito un contenitore che esegue codice di cui ti fidi. Per le applicazioni in contenitori che contengono codice attendibile, i contenitori di Windows Server sono consigliati e appropriati. La condivisione e la proiezione dei file del sistema operativo non dovrebbero essere un problema per il codice affidabile.

Ma cosa succede quando c'è bisogno di un po 'più di sicurezza, un po' più di isolamento, con codice o app meno che completamente affidabili?

Contenitori Hyper-V

È allora che inizi a guardare i contenitori Hyper-V, che sposano il modello di isolamento e astrazione dalle macchine virtuali tradizionali con la flessibilità, l'immagine e i formati di facile ridistribuzione dei contenitori di Windows Server in stile Docker, insieme all'API Docker e agli strumenti di gestione che Ho discusso nella sezione precedente.

Mark Russinovich, CTO di Microsoft Azure, lo ha espresso così in un post di blog dell'anno scorso: i contenitori Hyper-V "isolano le applicazioni con le garanzie associate alla virtualizzazione tradizionale, ma con la semplicità, il formato dell'immagine e il modello di gestione dei contenitori di Windows Server, inclusi il supporto di Docker Engine ". La differenza qui è il livello di isolamento: i contenitori Hyper-V non condividono direttamente file, processi e servizi del sistema operativo con l'host. Piuttosto, Windows Server racchiude ogni piccola immagine del contenitore in una macchina virtuale con un overhead molto basso, che raggiunge l'astrazione e il limite di attendibilità che un contenitore Windows Server in stile Docker non ha.

Tuttavia, questa macchina virtuale è, a tutti gli effetti, trasparente per l'amministratore. Le stesse immagini del contenitore che eseguono Windows Server capiscono che sono, in realtà, immagini del contenitore e non vengono eseguite su un normale silicio libero, e quindi sono in grado di sfruttare le ottimizzazioni del sistema operativo che derivano da tale consapevolezza. Tuttavia, anche se le immagini dei contenitori sono più isolate, non vengono distribuite in modo diverso rispetto ai contenitori di Windows Server. Utilizzi ancora le API Docker. Utilizzi ancora il client Docker. È sufficiente selezionare una casella diversa, ma le immagini del contenitore stesse vengono create e fornite allo stesso modo indipendentemente dal modello di isolamento che si desidera utilizzare per eseguirle.

Lo svantaggio di questo approccio: c'è più overhead. A causa dell'isolamento aggiuntivo, vengono duplicati più codice e processi. C'è anche il fatto che, anche se il wrapper leggero della macchina virtuale per un contenitore Hyper-V è piccolo, in effetti aggiunge una "tassa" al costo di esecuzione di un'immagine del contenitore. Quindi, mentre puoi riempire un host potente pieno di contenitori Windows Server in stile Docker, i contenitori Hyper-V sarebbero limitati a un certo numero inferiore di contenitori, tutto il resto è uguale dal punto di vista hardware.

Anche in questo caso, queste immagini del contenitore supporteranno solo Windows Server. Anche se c'è isolamento, c'è ancora una comunanza condivisa tra le immagini del contenitore e il sistema operativo host. Quindi, se le immagini del tuo contenitore eseguono Linux, un altro sapore di Unix, BSD o qualsiasi altro sistema operativo alternativo, nessuna di queste nuove funzionalità di Windows Server 2016 avrà importanza per te.

In conclusione: codice di terze parti, codice marketplace o codice che altrimenti non è completamente attendibile da nessuna parte dell'organizzazione deve essere eseguito in contenitori Hyper-V. Questi sono anche la scelta migliore per cloud pubblici multi-tenant e altri ambienti simili. Non perdi altro che capacità e ottieni i vantaggi in termini di sicurezza di essere più isolato.

Contenitori Docker

Ora, per dimostrare che il marchio è sempre la parte più difficile di qualsiasi tecnologia, consentitemi di introdurre i contenitori Docker. Sopra, ho menzionato che i contenitori di Windows Server sono una parte del progetto open source Docker. I contenitori Docker sono diversi dai contenitori di Windows Server. I contenitori di Windows Server possono usare tutta la tecnologia sottostante Docker, ma il set di strumenti Docker esistente per la gestione dei contenitori Docker non funziona (almeno in questa versione) con i contenitori di Windows Server. Né gli strumenti di gestione dei contenitori di Windows Server, a questo punto, una serie di comandi PowerShell, possono eseguire operazioni di valore con i contenitori Docker stessi.

I contenitori Docker sono la loro cosa specifica e mentre i contenitori di Windows Server agiscono come contenitori Docker nella loro capacità di condividere ma isolare - motivo per cui li ho definiti contenitori di Windows Server in stile Docker - non sono contenitori Docker di per sé . Ciò potrebbe cambiare in futuro, in particolare in un service pack o nella prossima versione di Windows Server, ma per ora questi tre tipi di contenitori, anche se possono essere tutti simili, rimangono concetti distinti. Solo due sono attualmente supportati da Windows Server.

Dov'è la tecnologia oggi

Al momento, il supporto dei contenitori in Windows Server 2016 è un lavoro in corso. Ci sono molte parti in movimento nei contenitori: rimozione delle dipendenze dai file host e del sistema operativo, versioni specifiche e livelli di patch; ottenere il giusto isolamento e garantire che nessun codice possa violare tale confine di sicurezza e fiducia; rendere giusta la storia dello sviluppatore con strumenti e automazione che consentono agli sviluppatori di lavorare con i contenitori nel loro ambiente di sviluppo integrato (IDE) preferito ed "esportare" le loro applicazioni direttamente nel contenitore; assicurarsi che i container possano spostarsi su e giù nel cloud pubblico senza problemi; e altro ancora.

In tutti questi casi, ci sono ancora errori fatali e bug su cui lavorare. Se i contenitori sono cruciali per la tua roadmap delle offerte di servizi all'interno del tuo negozio, potresti iniziare a testare le funzionalità dei contenitori di Windows Server e dei contenitori Hyper-V ora e in particolare controllare i comandi di PowerShell disponibili per abilitare i contenitori e gestirli su un host Windows Server 2016.

Tuttavia, se i contenitori sono una buona opzione ma non un must per la tua organizzazione, la mia raccomandazione informata sarebbe quella di evitare di tentare qualsiasi cosa tranne l'esplorazione più rudimentale utilizzando i bit Technical Preview 4. Ci sono ancora troppe verruche, inclusi gli errori fatali e i bug menzionati in precedenza, per avere davvero un senso coerente di ciò che sta accadendo.

Il supporto dei container sarà un'aggiunta entusiasmante alla piattaforma Windows. C'è ancora molto da scrivere e da raccontare di quella storia.

Questa storia, "Contenitori in Windows Server 2016: cosa devi sapere" è stata originariamente pubblicata da Computerworld.