In che modo Docker è diverso da una macchina virtuale?

Continuo a rileggere la documentazione di Docker per cercare di capire la differenza tra Docker e una VM completa. Come riesce a fornire un filesystem completo, un ambiente di rete isolato, ecc. Senza essere pesante?

Perché la distribuzione del software su un'immagine Docker (se è il termine giusto) è più semplice della semplice distribuzione in un ambiente di produzione coerente?

Docker originariamente utilizzava LinuX Containers (LXC), ma in seguito passò a runC (precedentemente noto come libcontainer ), che gira nello stesso sistema operativo del suo host. Ciò consente di condividere molte delle risorse del sistema operativo host. Inoltre, utilizza un filesystem a più livelli ( AuFS ) e gestisce le reti.

AuFS è un file system a strati, quindi puoi avere una parte di sola lettura e una parte di scrittura che sono unite insieme. Si potrebbe avere le parti comuni del sistema operativo in sola lettura (e condivise tra tutti i contenitori) e quindi assegnare a ciascun contenitore il proprio supporto per la scrittura.

Supponiamo quindi di avere un'immagine del contenitore da 1 GB; se si desidera utilizzare una VM completa, è necessario disporre di 1 GB x numero di VM desiderate. Con Docker e AuFS puoi condividere la maggior parte dei 1 GB tra tutti i contenitori e se hai 1000 contenitori potresti avere ancora poco più di 1 GB di spazio per il sistema operativo dei contenitori (supponendo che eseguano tutti la stessa immagine del sistema operativo) .

Un sistema completamente virtualizzato ottiene il proprio set di risorse allocato e fa una condivisione minima. Ottieni più isolamento, ma è molto più pesante (richiede più risorse). Con Docker ottieni meno isolamento, ma i contenitori sono leggeri (richiedono meno risorse). Quindi potresti facilmente eseguire migliaia di container su un host e non lampeggerà nemmeno. Prova a farlo con Xen e, a meno che tu non abbia un host davvero grande, non credo sia possibile.

Un sistema completamente virtualizzato richiede in genere alcuni minuti per avviarsi, mentre i contenitori Docker / LXC / runC richiedono pochi secondi e spesso anche meno di un secondo.

Esistono pro e contro per ogni tipo di sistema virtualizzato. Se si desidera il completo isolamento con risorse garantite, una VM completa è la strada da percorrere. Se si desidera solo isolare i processi gli uni dagli altri e si desidera eseguirne una tonnellata su un host di dimensioni ragionevoli, Docker / LXC / runC sembra essere la strada da percorrere.

Per ulteriori informazioni, dai un'occhiata a questo set di post di blog che fanno un buon lavoro nel spiegare come funziona LXC.

Perché la distribuzione del software su un'immagine docker (se è il termine giusto) è più semplice della semplice distribuzione in un ambiente di produzione coerente?

L'implementazione di un ambiente di produzione coerente è più facile a dirsi che a farsi. Anche se usi strumenti come Chef e Puppet , ci sono sempre aggiornamenti del sistema operativo e altre cose che cambiano tra host e ambienti.

Docker offre la possibilità di eseguire l'istantanea del sistema operativo in un'immagine condivisa e semplifica la distribuzione su altri host Docker. A livello locale, dev, qa, prod, ecc .: tutta la stessa immagine. Sicuramente puoi farlo con altri strumenti, ma non altrettanto facilmente o velocemente.

Questo è ottimo per i test; supponiamo che tu abbia migliaia di test che devono connettersi a un database e ogni test ha bisogno di una copia incontaminata del database e apporterà modifiche ai dati. L'approccio classico è reimpostare il database dopo ogni test con codice personalizzato o con strumenti come Flyway : ciò può richiedere molto tempo e significa che i test devono essere eseguiti in serie. Tuttavia, con Docker è possibile creare un'immagine del database ed eseguire un'istanza per test, quindi eseguire tutti i test in parallelo poiché si sa che verranno eseguiti tutti sullo stesso snapshot del database. Poiché i test sono eseguiti in parallelo e in contenitori Docker, potrebbero essere eseguiti tutti sullo stesso box contemporaneamente e dovrebbero finire molto più velocemente. Prova a farlo con una VM completa.

Dai commenti ...

Interessante! Suppongo di essere ancora confuso dall'idea di "snapshot [ting] the OS". Come si fa a farlo senza, beh, creare un'immagine del sistema operativo?

Bene, vediamo se posso spiegare. Si inizia con un'immagine di base, quindi si apportano le modifiche e si impegna tali modifiche utilizzando la finestra mobile e crea un'immagine. Questa immagine contiene solo le differenze dalla base. Quando vuoi eseguire la tua immagine, hai anche bisogno della base, che sovrappone la tua immagine sopra la base usando un file system a strati: come menzionato sopra, Docker usa AuFS. AuFS unisce i diversi livelli e ottieni ciò che desideri; devi solo eseguirlo. Puoi continuare ad aggiungere sempre più immagini (livelli) e continuerà a salvare solo le differenze. Poiché Docker in genere si basa su immagini già pronte da un registro , raramente è necessario "snapshot" l'intero sistema operativo da soli.

Buone risposte. Solo per ottenere una rappresentazione dell'immagine di container vs VM, dai un'occhiata a quello qui sotto.

fonte

Potrebbe essere utile capire come funzionano la virtualizzazione e i contenitori a basso livello. Ciò chiarirà molte cose.

Nota: sto semplificando un po 'nel descrivere di seguito. Vedi riferimenti per maggiori informazioni.

Come funziona la virtualizzazione a basso livello?

In questo caso il gestore VM assume l'anello CPU 0 (o la "modalità root" nelle CPU più recenti) e intercetta tutte le chiamate privilegiate effettuate dal SO guest per creare l'illusione che il SO guest abbia il proprio hardware. Curiosità: prima del 1998 era impossibile raggiungere questo obiettivo nell'architettura x86 perché non c'era modo di fare questo tipo di intercettazione. Le persone di VMWare sono state le prime a aver avuto l'idea di riscrivere i byte eseguibili in memoria per ottenere chiamate privilegiate del sistema operativo guest.

L'effetto netto è che la virtualizzazione consente di eseguire due sistemi operativi completamente diversi sullo stesso hardware. Ogni SO guest passa attraverso tutto il processo di bootstrap, caricamento del kernel, ecc. Puoi avere una sicurezza molto stretta, per esempio, il SO guest non può avere pieno accesso al SO host o altri guest e rovinare tutto.

Come funzionano i container a basso livello?

Intorno al 2006 , persone tra cui alcuni dei dipendenti di Google hanno implementato una nuova funzionalità a livello di kernel chiamata namespace (tuttavia l'idea molto prima esisteva in FreeBSD). Una funzione del sistema operativo è consentire la condivisione di risorse globali come rete e disco sui processi. Cosa succederebbe se queste risorse globali fossero racchiuse in spazi dei nomi in modo che siano visibili solo a quei processi che girano nello stesso spazio dei nomi? Ad esempio, puoi ottenere un pezzo di disco e inserirlo nello spazio dei nomi X e quindi i processi in esecuzione nello spazio dei nomi Y non possono vederlo o accedervi. Allo stesso modo, i processi nello spazio dei nomi X non possono accedere a nulla in memoria allocato allo spazio dei nomi Y. Naturalmente, i processi in X non possono vedere o parlare con i processi nello spazio dei nomi Y. Ciò fornisce un tipo di virtualizzazione e isolamento per le risorse globali. Ecco come funziona la finestra mobile: ogni contenitore viene eseguito nel proprio spazio dei nomi ma utilizza esattamente lo stessokernel come tutti gli altri contenitori. L'isolamento avviene perché il kernel conosce lo spazio dei nomi assegnato al processo e durante le chiamate API si assicura che il processo possa accedere solo alle risorse nel proprio spazio dei nomi.

Le limitazioni di container vs VM ora dovrebbero essere ovvie: non è possibile eseguire sistemi operativi completamente diversi in container come nelle VM. Tuttavia è possibile eseguire diverse distribuzioni di Linux perché condividono lo stesso kernel. Il livello di isolamento non è così forte come nella VM. In effetti, c'era un modo per il container "guest" di assumere l'host nelle prime implementazioni. Inoltre, è possibile notare che quando si carica un nuovo contenitore, l'intera nuova copia del sistema operativo non si avvia come nella VM. Tutti i contenitori condividono lo stesso kernel. Ecco perché i contenitori sono leggeri. Inoltre, diversamente dalla VM, non è necessario pre-allocare blocchi significativi di memoria ai container perché non stiamo eseguendo una nuova copia del sistema operativo. Ciò consente di eseguire migliaia di container su un sistema operativo mentre li sandbox, cosa che potrebbe non essere possibile fare se stessimo eseguendo una copia separata del sistema operativo nella propria VM.

Mi piace la risposta di Ken Cochrane.

Ma voglio aggiungere un ulteriore punto di vista, non trattato in dettaglio qui. Secondo me Docker si differenzia anche per l'intero processo. A differenza delle VM, Docker non riguarda (solo) la condivisione ottimale delle risorse dell'hardware, inoltre fornisce un "sistema" per l'applicazione di packaging (preferibile, ma non indispensabile, come set di microservizi).

Per me si adatta al divario tra strumenti orientati agli sviluppatori come rpm, pacchetti Debian , Maven , npm + Git su un lato e strumenti operativi come Puppet , VMware, Xen, lo chiami ...

Perché la distribuzione del software su un'immagine docker (se è il termine giusto) è più semplice della semplice distribuzione in un ambiente di produzione coerente?

La tua domanda presuppone un ambiente di produzione coerente. Ma come mantenerlo coerente? Prendi in considerazione un numero (> 10) di server e applicazioni, fasi della pipeline.

Per mantenerlo sincronizzato, inizierai a utilizzare qualcosa come Puppet, Chef o i tuoi script di provisioning, regole non pubblicate e / o molta documentazione ... In teoria i server possono funzionare a tempo indeterminato ed essere mantenuti completamente coerenti e aggiornati. La pratica non riesce a gestire completamente la configurazione di un server, quindi esiste un notevole margine per la deriva della configurazione e modifiche inattese ai server in esecuzione.

Quindi esiste un modello noto per evitare ciò, il cosiddetto server immutabile . Ma il modello di server immutabile non è stato amato. Principalmente a causa delle limitazioni delle macchine virtuali utilizzate prima di Docker. Gestire immagini gigantesche di diversi gigabyte, spostare quelle grandi immagini, solo per cambiare alcuni campi dell'applicazione, è stato molto laborioso. Comprensibile...

Con un ecosistema Docker, non avrai mai bisogno di muoverti in gigabyte con "piccoli cambiamenti" (grazie aufs e Registry) e non dovrai preoccuparti di perdere prestazioni impacchettando le applicazioni in un contenitore Docker in fase di runtime. Non devi preoccuparti delle versioni di quell'immagine.

E infine sarai anche spesso in grado di riprodurre ambienti di produzione complessi anche sul tuo laptop Linux (non chiamarmi se non funziona nel tuo caso;))

E ovviamente puoi avviare i contenitori Docker nelle macchine virtuali (è una buona idea). Riduci il provisioning del tuo server a livello di VM. Tutto quanto sopra potrebbe essere gestito da Docker.

PS Nel frattempo Docker utilizza la propria implementazione "libcontainer" anziché LXC. Ma LXC è ancora utilizzabile.

Docker non è una metodologia di virtualizzazione. Si basa su altri strumenti che implementano effettivamente la virtualizzazione basata su container o la virtualizzazione a livello di sistema operativo. Per questo, Docker inizialmente utilizzava il driver LXC, quindi si spostava su libcontainer che ora è stato rinominato come runc. Docker si concentra principalmente sull'automazione della distribuzione di applicazioni all'interno di contenitori di applicazioni. I contenitori di applicazioni sono progettati per impacchettare ed eseguire un singolo servizio, mentre i contenitori di sistema sono progettati per eseguire più processi, come le macchine virtuali. Pertanto, Docker è considerato uno strumento di gestione dei container o di distribuzione delle applicazioni su sistemi containerizzati.

Per sapere come è diverso dalle altre virtualizzazioni, passiamo alla virtualizzazione e ai suoi tipi. Quindi, sarebbe più facile capire qual è la differenza lì.

virtualizzazione

Nella sua forma concepita, è stato considerato un metodo di divisione logica dei mainframe per consentire l'esecuzione simultanea di più applicazioni. Tuttavia, lo scenario è cambiato drasticamente quando le aziende e le comunità open source sono state in grado di fornire un metodo per gestire le istruzioni privilegiate in un modo o nell'altro e consentire l'esecuzione simultanea di più sistemi operativi su un singolo sistema basato su x86.

hypervisor

L'hypervisor gestisce la creazione dell'ambiente virtuale su cui operano le macchine virtuali guest. Supervisiona i sistemi guest e si assicura che le risorse siano allocate agli ospiti secondo necessità. L'hypervisor si trova tra la macchina fisica e le macchine virtuali e fornisce servizi di virtualizzazione alle macchine virtuali. Per realizzarlo, intercetta le operazioni del sistema operativo guest sulle macchine virtuali ed emula l'operazione sul sistema operativo della macchina host.

Il rapido sviluppo delle tecnologie di virtualizzazione, principalmente nel cloud, ha spinto ulteriormente l'uso della virtualizzazione consentendo la creazione di più server virtuali su un singolo server fisico con l'aiuto di hypervisor, come Xen, VMware Player, KVM, ecc., E integrazione del supporto hardware nei processori di materie prime, come Intel VT e AMD-V.

Tipi di virtualizzazione

Il metodo di virtualizzazione può essere classificato in base al modo in cui imita l'hardware a un sistema operativo guest ed emula un ambiente operativo guest. In primo luogo, esistono tre tipi di virtualizzazione:

• Emulazione
• paravirtualizzazione
• Virtualizzazione basata su container

Emulazione

L'emulazione, nota anche come virtualizzazione completa, esegue il kernel del sistema operativo della macchina virtuale interamente nel software. L'hypervisor utilizzato in questo tipo è noto come hypervisor di tipo 2. È installato nella parte superiore del sistema operativo host che è responsabile della traduzione del codice del kernel del SO guest in istruzioni software. La traduzione viene eseguita interamente in software e non richiede alcun coinvolgimento hardware. L'emulazione consente di eseguire qualsiasi sistema operativo non modificato che supporti l'ambiente da emulare. L'aspetto negativo di questo tipo di virtualizzazione è un sovraccarico di risorse di sistema aggiuntivo che porta a una riduzione delle prestazioni rispetto ad altri tipi di virtualizzazioni.

Esempi in questa categoria includono VMware Player, VirtualBox, QEMU, Bochs, Parallels, ecc.

paravirtualizzazione

La paravirtualizzazione, nota anche come hypervisor di tipo 1, viene eseguita direttamente sull'hardware o "bare metal" e fornisce servizi di virtualizzazione direttamente alle macchine virtuali in esecuzione su di esso. Aiuta il sistema operativo, l'hardware virtualizzato e l'hardware reale a collaborare per ottenere prestazioni ottimali. Questi hypervisor in genere hanno un ingombro piuttosto ridotto e non richiedono essi stessi risorse estese.

Esempi in questa categoria includono Xen, KVM, ecc.

Virtualizzazione basata su container

La virtualizzazione basata su container, nota anche come virtualizzazione a livello di sistema operativo, consente l'esecuzione multipla di esecuzioni all'interno di un singolo kernel del sistema operativo. Ha le migliori prestazioni e densità possibili e offre una gestione dinamica delle risorse. L'ambiente di esecuzione virtuale isolato fornito da questo tipo di virtualizzazione è chiamato contenitore e può essere visualizzato come un gruppo di processi tracciati.

Il concetto di contenitore è reso possibile dalla funzione namespace aggiunta alla versione 2.6.24 del kernel Linux. Il contenitore aggiunge il proprio ID a ogni processo e aggiunge nuovi controlli di controllo dell'accesso a ogni chiamata di sistema. Vi accede dal clone () chiamata di sistema che consente di creare istanze separate di spazi dei nomi precedentemente globali.

Gli spazi dei nomi possono essere utilizzati in molti modi diversi, ma l'approccio più comune è quello di creare un contenitore isolato che non abbia visibilità o accesso agli oggetti all'esterno del contenitore. I processi in esecuzione all'interno del contenitore sembrano essere in esecuzione su un normale sistema Linux sebbene condividano il kernel sottostante con processi situati in altri spazi dei nomi, lo stesso per altri tipi di oggetti. Ad esempio, quando si utilizzano gli spazi dei nomi, l'utente root all'interno del contenitore non viene trattato come root all'esterno del contenitore, aggiungendo ulteriore sicurezza.

Il sottosistema Linux Control Groups (cgroups), il prossimo componente principale per abilitare la virtualizzazione basata su container, viene utilizzato per raggruppare i processi e gestirne il consumo aggregato di risorse. È comunemente usato per limitare il consumo di memoria e CPU dei container. Poiché un sistema Linux containerizzato ha un solo kernel e il kernel ha piena visibilità nei container, esiste solo un livello di allocazione e pianificazione delle risorse.

Sono disponibili numerosi strumenti di gestione per container Linux, tra cui LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker, ecc.

Contenitori vs macchine virtuali

A differenza di una macchina virtuale, un contenitore non ha bisogno di avviare il kernel del sistema operativo, quindi i contenitori possono essere creati in meno di un secondo. Questa funzionalità rende la virtualizzazione basata su container unica e desiderabile rispetto ad altri approcci di virtualizzazione.

Poiché la virtualizzazione basata su container aggiunge un sovraccarico minimo o nullo al computer host, la virtualizzazione basata su container offre prestazioni quasi native

Per la virtualizzazione basata su container, non è necessario alcun software aggiuntivo, a differenza di altre virtualizzazioni.

Tutti i contenitori su una macchina host condividono lo scheduler della macchina host risparmiando risorse aggiuntive.

Gli stati del contenitore (immagini Docker o LXC) sono di dimensioni ridotte rispetto alle immagini della macchina virtuale, quindi le immagini del contenitore sono facili da distribuire.

La gestione delle risorse nei container è ottenuta tramite cgroups. I cgroups non consentono ai contenitori di consumare più risorse di quelle assegnate a loro. Tuttavia, a partire da ora, tutte le risorse della macchina host sono visibili nelle macchine virtuali, ma non possono essere utilizzate. Questo può essere realizzato eseguendo topohtop su contenitori e macchine host contemporaneamente. L'output in tutti gli ambienti sarà simile.

Aggiornare:

In che modo Docker esegue i contenitori in sistemi non Linux?

Se i contenitori sono possibili a causa delle funzionalità disponibili nel kernel Linux, la domanda ovvia è come i sistemi non Linux eseguono i contenitori. Sia Docker per Mac che Windows utilizzano macchine virtuali Linux per eseguire i contenitori. Docker Toolbox utilizzato per eseguire contenitori nelle macchine virtuali Virtual Box. Ma l'ultimo Docker utilizza Hyper-V in Windows e Hypervisor.framework in Mac.

Ora, lasciami descrivere come Docker per Mac gestisce i contenitori in dettaglio.

Docker per Mac utilizza https://github.com/moby/hyperkit per emulare le funzionalità dell'hypervisor e Hyperkit utilizza hypervisor.framework nel suo nucleo. Hypervisor.framework è la soluzione hypervisor nativa di Mac. Hyperkit utilizza inoltre VPNKit e DataKit rispettivamente per la rete dello spazio dei nomi e il filesystem.

La VM Linux che Docker esegue in Mac è di sola lettura. Tuttavia, puoi bash in esso eseguendo:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.

Ora possiamo persino controllare la versione del kernel di questa VM:

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux.

Tutti i contenitori vengono eseguiti all'interno di questa VM.

Ci sono alcune limitazioni a hypervisor.framework. Per questo motivo Docker non espone docker0l'interfaccia di rete in Mac. Pertanto, non è possibile accedere ai contenitori dall'host. A partire da ora, docker0è disponibile solo all'interno della VM.

Hyper-v è l'hypervisor nativo in Windows. Stanno anche cercando di sfruttare le capacità di Windows 10 per eseguire nativamente i sistemi Linux.

Attraverso questo post tracciamo alcune linee di differenza tra VM e LXC. Prima definiamoli.

VM :

Una macchina virtuale emula un ambiente informatico fisico, ma le richieste di CPU, memoria, disco rigido, rete e altre risorse hardware sono gestite da un livello di virtualizzazione che traduce queste richieste nell'hardware fisico sottostante.

In questo contesto la VM viene chiamata come Guest mentre l'ambiente in cui viene eseguita viene chiamato host.

LXC :

Linux Containers (LXC) sono funzionalità a livello di sistema operativo che consentono di eseguire più container Linux isolati, su un host di controllo (l'host LXC). I container Linux servono come alternativa leggera alle macchine virtuali poiché non richiedono l'hypervisor, vale a dire. Virtualbox, KVM, Xen, ecc.

A meno che tu non sia stato drogato da Alan (Zach Galifianakis della serie Hangover) e sia stato a Las Vegas nell'ultimo anno, sarai abbastanza consapevole del tremendo interesse che ha suscitato la tecnologia dei container Linux e se sarò specifico per un container Il progetto che ha creato un brusio in tutto il mondo negli ultimi mesi è: Docker porta ad alcune opinioni eche che gli ambienti di cloud computing dovrebbero abbandonare le macchine virtuali (VM) e sostituirle con contenitori a causa del loro sovraccarico e delle prestazioni potenzialmente migliori.

Ma la grande domanda è: è fattibile? Sarà sensato?

un. Gli LXC sono inclusi in un'istanza di Linux. Potrebbe trattarsi di versioni diverse di Linux (ad es. Un contenitore Ubuntu su un host CentOS ma è ancora Linux). Allo stesso modo, i contenitori basati su Windows sono ora passati a un'istanza di Windows se guardiamo alle VM hanno un ambito piuttosto ampio e usando hypervisor non sei limitato ai sistemi operativi Linux o Windows.

b. Gli LXC hanno bassi costi generali e prestazioni migliori rispetto alle macchine virtuali. Strumenti vale a dire. Docker che è costruito sulle spalle della tecnologia LXC ha fornito agli sviluppatori una piattaforma per eseguire le loro applicazioni e allo stesso tempo ha dato alle persone operative uno strumento che consentirà loro di distribuire lo stesso container su server di produzione o data center. Cerca di rendere l'esperienza tra uno sviluppatore che esegue un'applicazione, l'avvio e il test di un'applicazione e una persona operativa che distribuisce l'applicazione senza soluzione di continuità, perché è qui che si trova tutto l'attrito e lo scopo di DevOps è quello di abbattere quei silos.

Pertanto, l'approccio migliore è che i fornitori di infrastrutture cloud dovrebbero sostenere un uso appropriato delle macchine virtuali e di LXC, poiché sono tutti adatti a gestire carichi di lavoro e scenari specifici.

Abbandonare le VM non è pratico al momento. Quindi sia le VM che le LXC hanno la loro esistenza e importanza individuali.

La maggior parte delle risposte qui parla di macchine virtuali. Ho intenzione di darti una risposta unica a questa domanda che mi ha aiutato di più negli ultimi due anni nell'uso di Docker. È questo:

Docker è solo un modo elegante per eseguire un processo, non una macchina virtuale.

Ora, lasciami spiegare un po 'di più su cosa significhi. Le macchine virtuali sono la loro bestia. Ho voglia di spiegare cosa Docker ti aiuterà a capire questo più che spiegare cos'è una macchina virtuale. Soprattutto perché ci sono molte belle risposte che ti dicono esattamente cosa significa qualcuno quando dicono "macchina virtuale". Così...

Un contenitore Docker è solo un processo (e i relativi figli) suddiviso in compartimenti utilizzando i cgroup all'interno del kernel del sistema host dal resto dei processi. Puoi effettivamente vedere i processi del tuo contenitore Docker eseguendolo ps auxsull'host. Ad esempio, l'avvio apache2"in un contenitore" è solo apache2un processo speciale sull'host. È appena stato suddiviso in compartimenti rispetto ad altri processi sulla macchina. È importante notare che i contenitori non esistono al di fuori della durata del processo containerizzato. Quando il processo muore, il contenitore muore. Questo perché Docker sostituisce pid 1all'interno del contenitore con l'applicazione ( pid 1normalmente è il sistema init). Quest'ultimo punto in meritopid 1 è molto importante.

Per quanto riguarda il filesystem utilizzato da ciascuno di questi processi container, Docker utilizza UnionFS immagini supportate da , che è ciò che si sta scaricando quando si esegue una . Ogni "immagine" è solo una serie di livelli e metadati correlati. Il concetto di stratificazione è molto importante qui. Ogni livello è solo un cambiamento rispetto al livello sottostante. Ad esempio, quando si elimina un file nel file Docker mentre si crea un contenitore Docker, in realtà si sta semplicemente creando un livello sopra l'ultimo livello che dice "questo file è stato eliminato". Per inciso, questo è il motivo per cui puoi eliminare un file di grandi dimensioni dal tuo filesystem, ma l'immagine occupa ancora la stessa quantità di spazio su disco. Il file è ancora lì, nei livelli sotto quello corrente. Gli stessi livelli sono solo tarball di file. Puoi provarlo con e quindi . Quindi puoi dare un'occhiata in giro. Tutte quelle directory che sembrano lunghi hash sono in realtà i singoli livelli. Ognuno contiene file (docker pull ubuntudocker save --output /tmp/ubuntu.tar ubuntucd /tmp && tar xvf ubuntu.tarlayer.tar ) e metadati (json) con informazioni su quel particolare livello. Quei livelli descrivono semplicemente le modifiche al filesystem che vengono salvate come livello "sopra" il suo stato originale. Durante la lettura dei dati "correnti", il filesystem legge i dati come se guardassero solo ai livelli più alti delle modifiche. Ecco perché il file sembra essere eliminato, anche se esiste ancora nei livelli "precedenti", perché il filesystem sta guardando solo ai livelli più alti. Ciò consente a container completamente diversi di condividere i loro livelli di file system, anche se potrebbero essersi verificati cambiamenti significativi al file system sui livelli più in alto in ciascun contenitore. Questo può farti risparmiare un sacco di spazio su disco, quando i tuoi contenitori condividono i loro livelli di immagine di base. Però,

Il networking in Docker si ottiene utilizzando un bridge ethernet (chiamato docker0sull'host) e interfacce virtuali per ogni contenitore sull'host. Crea una sottorete virtuale per consentire docker0ai container di comunicare "tra loro". Ci sono molte opzioni per la rete qui, inclusa la creazione di sottoreti personalizzate per i contenitori e la possibilità di "condividere" lo stack di rete dell'host per l'accesso diretto al contenitore.

La finestra mobile si sta muovendo molto velocemente. La sua documentazione è la migliore documentazione che abbia mai visto. È generalmente ben scritto, conciso e preciso. Ti consiglio di controllare la documentazione disponibile per ulteriori informazioni e di fidarti della documentazione su tutto ciò che leggi online, incluso StackTranslate.it. Se hai domande specifiche, ti consiglio vivamente di iscriverti #dockera Freenode IRC e di chiedere lì (puoi anche usare la webchat di Freenode per questo!).

Docker incapsula un'applicazione con tutte le sue dipendenze.

Un virtualizzatore incapsula un sistema operativo in grado di eseguire qualsiasi applicazione che normalmente può essere eseguita su una macchina bare metal.

Entrambi sono molto diversi. Docker è leggero e utilizza LXC / libcontainer (che si basa sullo spazio dei nomi del kernel e sui cgroups) e non ha emulazioni macchina / hardware come hypervisor, KVM. Xen che sono pesanti.

Docker e LXC è pensato soprattutto per sandboxing, containerizzazione e isolamento delle risorse. Utilizza l'API clone del sistema operativo host (attualmente solo kernel Linux) che fornisce spazi dei nomi per IPC, NS (mount), rete, PID, UTS, ecc.

Che dire di memoria, I / O, CPU, ecc.? Ciò è controllato tramite cgroups in cui è possibile creare gruppi con determinate specifiche / restrizioni di risorse (CPU, memoria, ecc.) E inserire i processi all'interno. Oltre a LXC, Docker fornisce un back-end di archiviazione ( http://www.projectatomic.io/docs/filesystems/ ), ad esempio un file system di montaggio unione in cui è possibile aggiungere livelli e condividere livelli tra diversi spazi dei nomi di montaggio.

Questa è una potente funzionalità in cui le immagini di base sono in genere di sola lettura e solo quando il contenitore modifica qualcosa nel livello scriverà qualcosa in partizione di lettura / scrittura (ovvero copia su scrittura). Fornisce inoltre molti altri wrapper come il registro e il controllo delle versioni delle immagini.

Con LXC normale è necessario venire con alcuni rootfs o condividere i rootfs e, quando condivisi, e le modifiche si riflettono su altri contenitori. Grazie a molte di queste funzionalità aggiunte, Docker è più popolare di LXC. LXC è popolare negli ambienti embedded per l'implementazione della sicurezza attorno a processi esposti a entità esterne come la rete e l'interfaccia utente. Docker è popolare nell'ambiente multi-tenancy cloud in cui è previsto un ambiente di produzione coerente.

Una macchina virtuale normale (ad esempio VirtualBox e VMware) utilizza un hypervisor e le tecnologie correlate hanno un firmware dedicato che diventa il primo livello per il primo sistema operativo (sistema operativo host o sistema operativo guest 0) o un software che esegue il sistema operativo host per fornire emulazione hardware come CPU, USB / accessori, memoria, rete, ecc., ai SO guest. Le VM sono ancora (a partire dal 2015) popolari nell'ambiente multi-tenant ad alta sicurezza.

Docker / LXC può quasi essere eseguito su qualsiasi hardware economico (meno di 1 GB di memoria è OK purché si disponga di un kernel più recente) rispetto alle VM normali hanno bisogno di almeno 2 GB di memoria, ecc. Per fare qualcosa di significativo con esso . Ma il supporto Docker sul sistema operativo host non è disponibile in sistemi operativi come Windows (da novembre 2014) in cui è possibile eseguire tipi di VM su Windows, Linux e Mac.

Ecco una foto da docker / rightscale:

1. Leggero

Questa è probabilmente la prima impressione per molti studenti di docker.

Innanzitutto, le immagini docker sono generalmente più piccole delle immagini VM, facilitano la creazione, la copia e la condivisione.

In secondo luogo, i contenitori Docker possono avviarsi in alcuni millisecondi, mentre la macchina virtuale si avvia in pochi secondi.

2. File system a strati

Questa è un'altra caratteristica chiave di Docker. Le immagini hanno livelli e immagini diverse possono condividere livelli, rendendo ancora più salvaspazio e più veloce da costruire.

Se tutti i contenitori utilizzano Ubuntu come immagini di base, non tutte le immagini hanno il proprio file system, ma condividono gli stessi file di Ubuntu sottolineati e differiscono solo nei dati delle proprie applicazioni.

3. Kernel SO condiviso

Pensa ai contenitori come processi!

Tutti i contenitori in esecuzione su un host sono in effetti un insieme di processi con diversi file system. Condividono lo stesso kernel del sistema operativo, incapsulano solo la libreria di sistema e le dipendenze.

Questo è utile per la maggior parte dei casi (non è necessario alcun kernel del sistema operativo aggiuntivo) ma può essere un problema se sono necessari rigorosi isolamenti tra i contenitori.

Perchè importa?

Tutti questi sembrano miglioramenti, non rivoluzione. Bene, l'accumulazione quantitativa porta alla trasformazione qualitativa .

Pensa alla distribuzione delle applicazioni. Se vogliamo distribuire un nuovo software (servizio) o aggiornarne uno, è meglio cambiare i file e i processi di configurazione invece di creare una nuova macchina virtuale. Poiché la creazione di una macchina virtuale con un servizio aggiornato, la verifica (condivisione tra Dev e QA), la distribuzione in produzione richiede ore, persino giorni. Se qualcosa va storto, devi ricominciare, perdendo ancora più tempo. Quindi, utilizzare lo strumento di gestione della configurazione (burattino, saltstack, chef ecc.) Per installare un nuovo software, è preferibile scaricare nuovi file.

Quando si tratta di docker, è impossibile utilizzare un contenitore docker appena creato per sostituire quello vecchio. La manutenzione è molto più semplice! Costruire una nuova immagine, condividerla con il QA, testarla, distribuirla richiede solo pochi minuti (se tutto è automatizzato), ore nel peggiore dei casi. Questa si chiama infrastruttura immutabile : non mantenere (aggiornare) il software, crearne uno nuovo.

Trasforma il modo in cui i servizi vengono erogati. Vogliamo applicazioni, ma dobbiamo mantenere le macchine virtuali (il che è una seccatura e ha poco a che fare con le nostre applicazioni). Docker ti concentra sulle applicazioni e semplifica tutto.

Docker, sostanzialmente container, supporta la virtualizzazione del sistema operativo, ovvero l'applicazione ritiene che abbia un'istanza completa di un sistema operativo, mentre la VM supporta la virtualizzazione dell'hardware . Ti senti come se fosse una macchina fisica in cui è possibile avviare qualsiasi sistema operativo.

In Docker, i contenitori in esecuzione condividono il kernel del sistema operativo host, mentre nelle macchine virtuali hanno i propri file del sistema operativo. L'ambiente (il sistema operativo) in cui si sviluppa un'applicazione sarebbe lo stesso quando lo si distribuisce in vari ambienti di servizio, come "testing" o "produzione".

Ad esempio, se si sviluppa un server Web in esecuzione sulla porta 4000, quando lo si distribuisce nel proprio ambiente di "test", quella porta è già utilizzata da qualche altro programma, quindi smette di funzionare. In contenitori ci sono strati; tutte le modifiche apportate al sistema operativo verranno salvate in uno o più livelli e tali livelli faranno parte dell'immagine, quindi ovunque vada l'immagine saranno presenti anche le dipendenze.

Nell'esempio mostrato di seguito, la macchina host ha tre macchine virtuali. Al fine di fornire alle applicazioni nelle VM un isolamento completo, ognuna ha le proprie copie dei file del sistema operativo, delle librerie e del codice dell'applicazione, insieme a un'istanza completa in memoria di un sistema operativo. Considerando che la figura seguente mostra lo stesso scenario con i contenitori. Qui, i container condividono semplicemente il sistema operativo host, inclusi il kernel e le librerie, quindi non hanno bisogno di avviare un sistema operativo, caricare librerie o pagare un costo di memoria privata per quei file. L'unico spazio incrementale che occupano è la memoria e lo spazio su disco necessari per l'esecuzione dell'applicazione nel contenitore. Mentre l'ambiente dell'applicazione sembra un sistema operativo dedicato, l'applicazione viene distribuita proprio come se fosse su un host dedicato. L'applicazione in container si avvia in pochi secondi e molte più istanze dell'applicazione possono adattarsi alla macchina rispetto al caso della VM.

Fonte: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

Esistono tre diverse configurazioni che forniscono uno stack su cui eseguire un'applicazione (Questo ci aiuterà a riconoscere cos'è un contenitore e cosa lo rende così potente rispetto ad altre soluzioni):

1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers

1) Lo stack di server tradizionale è costituito da un server fisico che esegue un sistema operativo e l'applicazione.

vantaggi:

• Utilizzo di risorse grezze

• Isolamento

svantaggi:

• Tempi di implementazione molto lenti
• Costoso
• Risorse sprecate
• Difficile da ridimensionare
• Difficile migrare
• Configurazione complessa

2) Lo stack VM è costituito da un server fisico che esegue un sistema operativo e un hypervisor che gestisce la macchina virtuale, le risorse condivise e l'interfaccia di rete. Ogni Vm esegue un sistema operativo guest, un'applicazione o un set di applicazioni.

vantaggi:

• Buon uso delle risorse
• Facile da ridimensionare
• Facile da eseguire il backup e la migrazione
• Efficienza dei costi
• Flessibilità

svantaggi:

• L'allocazione delle risorse è problematica
• Lockin del fornitore
• Configurazione complessa

3) L' installazione del contenitore , la differenza chiave con altri stack è la virtualizzazione basata su contenitore che utilizza il kernel del sistema operativo host per frugare più istanze guest isolate. Queste istanze guest sono chiamate come contenitori. L'host può essere un server fisico o una macchina virtuale.

vantaggi:

• Isolamento
• leggero
• Risorsa efficace
• Facile da migrare
• Sicurezza
• Spese generali basse
• Speculare ambiente di produzione e sviluppo

svantaggi:

• Stessa architettura
• Risorsa app pesanti
• Problemi di rete e sicurezza.

Confrontando la configurazione del contenitore con i suoi predecessori, possiamo concludere che la containerizzazione è la configurazione più veloce, più efficiente in termini di risorse e più sicura che conosciamo fino ad oggi. I contenitori sono istanze isolate che eseguono l'applicazione. Docker fa ruotare il contenitore in un certo modo, i livelli ottengono la memoria del runtime con i driver di archiviazione predefiniti (driver di sovrapposizione) quelli vengono eseguiti in pochi secondi e il livello di copia-scrittura creato sopra di esso una volta che ci impegniamo nel contenitore, che alimenta l'esecuzione di contenitori.Nel caso di VM ci vorrà circa un minuto per caricare tutto nell'ambiente virtualizzare. Queste istanze leggere possono essere sostituite, ricostruite e spostate facilmente. Questo ci consente di rispecchiare l'ambiente di produzione e sviluppo ed è di grande aiuto nei processi CI / CD. I vantaggi che i contenitori possono offrire sono così avvincenti che sono sicuramente qui per rimanere.

In relazione con:-

"Perché la distribuzione del software su un'immagine docker è più semplice della semplice distribuzione in un ambiente di produzione coerente?"

La maggior parte del software viene distribuita in molti ambienti, in genere un minimo di tre dei seguenti:

1. PC / i singoli sviluppatori
2. Ambiente di sviluppo condiviso
3. PC / i tester individuali
4. Ambiente di test condiviso
5. Ambiente di controllo qualità
6. Ambiente UAT
7. Test di carico / prestazioni
8. Messa in scena dal vivo
9. Produzione
10. Archivio

Ci sono anche i seguenti fattori da considerare:

• Gli sviluppatori, e in effetti i tester, avranno tutti configurazioni per PC sottilmente o molto diverse, per la natura stessa del lavoro
• Gli sviluppatori possono spesso svilupparsi su PC al di fuori del controllo delle regole di standardizzazione aziendale o aziendale (ad es. Liberi professionisti che si sviluppano sulle proprie macchine (spesso in remoto) o contribuiscono a progetti open source che non sono "impiegati" o "contratti" per configurare un determinato PC modo)
• Alcuni ambienti saranno costituiti da un numero fisso di più macchine in una configurazione con bilanciamento del carico
• Molti ambienti di produzione avranno server basati su cloud creati dinamicamente (o "elasticamente") e distrutti a seconda dei livelli di traffico

Come puoi vedere, il numero totale estrapolato di server per un'organizzazione è raramente in cifre singole, è molto spesso in cifre triple e può facilmente essere ancora significativamente più elevato.

Tutto ciò significa che la creazione di ambienti coerenti in primo luogo è abbastanza difficile solo a causa del volume puro (anche in uno scenario di campo verde), ma mantenerli coerenti è quasi impossibile dato l'elevato numero di server, l'aggiunta di nuovi server (dinamicamente o manualmente), aggiornamenti automatici da fornitori di o / s, fornitori di antivirus, fornitori di browser e simili, installazioni manuali di software o modifiche di configurazione eseguite da sviluppatori o tecnici del server, ecc. Lasciatemelo ripetere: è praticamente (nessuna scommessa prevista) impossibile per mantenere coerenti gli ambienti (va bene, per i puristi, si può fare, ma comporta una grande quantità di tempo, sforzi e disciplina, motivo per cui sono stati ideati VM e container (ad esempio Docker).

Pensa quindi alla tua domanda più in questo modo "Data l'estrema difficoltà di mantenere tutti gli ambienti coerenti, è più facile distribuire software su un'immagine docker, anche quando si tiene conto della curva di apprendimento?" . Penso che troverai la risposta invariabilmente "sì" - ma c'è solo un modo per scoprirlo, pubblicare questa nuova domanda su Stack Overflow.

Ci sono molte risposte che spiegano più in dettaglio le differenze, ma ecco la mia brevissima spiegazione.

Una differenza importante è che le macchine virtuali usano un kernel separato per eseguire il sistema operativo . Questo è il motivo per cui è pesante e richiede tempo per l'avvio, consumando più risorse di sistema.

In Docker, i contenitori condividono il kernel con l'host; quindi è leggero e può avviarsi e fermarsi rapidamente.

In Virtualization, le risorse vengono allocate all'inizio della configurazione e quindi le risorse non vengono completamente utilizzate quando la macchina virtuale è inattiva per molte volte. In Docker, i contenitori non sono allocati con una quantità fissa di risorse hardware ed è libero di utilizzare le risorse in base ai requisiti e quindi è altamente scalabile.

Docker utilizza il file system UNION . Docker utilizza una tecnologia di copia e scrittura per ridurre lo spazio di memoria consumato dai contenitori. Leggi di più qui

Con una macchina virtuale , abbiamo un server, abbiamo un sistema operativo host su quel server e quindi abbiamo un hypervisor. E poi in esecuzione su quell'hypervisor, abbiamo un numero qualsiasi di sistemi operativi guest con un'applicazione e i suoi binari dipendenti e librerie su quel server. Porta con sé un intero sistema operativo guest. È abbastanza pesante. Inoltre c'è un limite a quanto puoi effettivamente mettere su ogni macchina fisica.

I container Docker invece sono leggermente diversi. Abbiamo il server. Abbiamo il sistema operativo host. Ma invece un hypervisor , abbiamo il motore Docker , in questo caso. In questo caso, non stiamo portando con noi un intero sistema operativo guest. Stiamo introducendo un livello molto sottile del sistema operativo e il container può parlare nel sistema operativo host per accedere alle funzionalità del kernel. E questo ci consente di avere un contenitore molto leggero.

Tutto ciò che contiene è il codice dell'applicazione e tutti i file binari e le librerie richiesti. E quei binari e librerie possono effettivamente essere condivisi tra contenitori diversi se si desidera che anche loro lo siano. E ciò che ci consente di fare è una serie di cose. Hanno tempi di avvio molto più rapidi . Non puoi alzare una singola VM in pochi secondi in quel modo. E allo stesso modo, eliminandoli il più rapidamente possibile ... in modo che possiamo aumentare e ridurre molto rapidamente e lo vedremo più avanti.

Ogni contenitore pensa che sia in esecuzione sulla propria copia del sistema operativo. Ha il suo file system, il suo registro, ecc. Che è una specie di bugia. In realtà viene virtualizzato.

Fonte: Kubernetes in azione.

Ho usato Docker in ambienti di produzione e messa in scena molto. Quando ti abituerai, lo troverai molto potente per la costruzione di un multi container e ambienti isolati.

Docker è stato sviluppato sulla base di LXC (Linux Container) e funziona perfettamente in molte distribuzioni Linux, in particolare Ubuntu.

I contenitori Docker sono ambienti isolati. Puoi vederlo quando emetti il ​​filetop comando in un contenitore Docker creato da un'immagine Docker.

Oltre a ciò, sono molto leggeri e flessibili grazie alla configurazione dockerFile.

Ad esempio, è possibile creare un'immagine Docker e configurare un DockerFile e dirlo ad esempio quando è in esecuzione quindi wget 'this', apt-get 'that', eseguire 'alcuni script di shell', impostare variabili di ambiente e così via.

Nei progetti di micro-servizi e nell'architettura Docker è una risorsa molto praticabile. È possibile ottenere scalabilità, resilienza ed elasticità con Docker, Docker Swarm, Kubernetes e Docker Compose.

Un altro problema importante riguardante Docker è Docker Hub e la sua community. Ad esempio, ho implementato un ecosistema per il monitoraggio di kafka usando Prometheus, Grafana, Prometheus-JMX-Exporter e Docker.

Per fare ciò, ho scaricato i contenitori Docker configurati per zookeeper, kafka, Prometheus, Grafana e jmx-collector, quindi ho montato la mia configurazione per alcuni di essi utilizzando i file YAML, o per altri, ho cambiato alcuni file e configurazioni nel contenitore Docker e ho costruire un intero sistema per il monitoraggio di kafka usando Docker multi-contenitore su una singola macchina con isolamento, scalabilità e resilienza che questa architettura può essere facilmente spostata su più server.

Oltre al sito Docker Hub c'è un altro sito chiamato quay.io che puoi usare per avere la tua dashboard di immagini Docker lì e tirare / spingere da / verso di essa. Puoi persino importare le immagini Docker dall'hub Docker alla banchina e poi eseguirle dalla banchina sul tuo computer.

Nota: l'apprendimento di Docker in primo luogo sembra complesso e difficile, ma quando ti ci abitui non puoi lavorare senza di esso.

Ricordo i primi giorni di lavoro con Docker quando ho emesso comandi errati o rimosso i miei contenitori e tutti i dati e le configurazioni per errore.

Ecco come Docker si presenta:

Docker è la società che guida il movimento dei container e l'unico fornitore di piattaforme container a soddisfare tutte le applicazioni nel cloud ibrido. Le aziende di oggi sono sotto pressione per trasformarsi digitalmente ma sono vincolate dalle applicazioni e dalle infrastrutture esistenti, razionalizzando al contempo un portafoglio sempre più diversificato di cloud, data center e architetture applicative. Docker consente una vera indipendenza tra applicazioni e infrastruttura e sviluppatori e operatori IT possono sbloccare il loro potenziale e creare un modello per una migliore collaborazione e innovazione.

Quindi Docker è basato su container, il che significa che hai immagini e container che possono essere eseguiti sulla tua macchina attuale. Non include il sistema operativo come VM , ma come un pacchetto di diversi pacchetti di lavoro come Java, Tomcat, ecc.

Se capisci i container, ottieni cos'è Docker e in che modo è diverso dai VM ...

Quindi, cos'è un contenitore?

Un'immagine contenitore è un pacchetto leggero, autonomo ed eseguibile di un software che include tutto il necessario per eseguirlo: codice, runtime, strumenti di sistema, librerie di sistema, impostazioni. Disponibile per le app basate su Linux e Windows, il software in container funzionerà sempre allo stesso modo, indipendentemente dall'ambiente. I container isolano il software dall'ambiente circostante, ad esempio le differenze tra ambienti di sviluppo e di gestione temporanea e aiutano a ridurre i conflitti tra i team che eseguono software diverso sulla stessa infrastruttura.

Quindi, come vedi nell'immagine qui sotto, ogni container ha un pacco separato ed è in esecuzione su una singola macchina che condivide il sistema operativo di quella macchina ... Sono sicuri e facili da spedire ...

Ci sono molte belle risposte tecniche qui che discutono chiaramente delle differenze tra macchine virtuali e container, nonché le origini di Docker.

Per me la differenza fondamentale tra VM e Docker è il modo in cui gestisci la promozione della tua applicazione.

Con le VM promuovi la tua applicazione e le sue dipendenze da una VM al successivo DEV, da UAT a PRD.

1. Spesso queste VM avranno patch e librerie diverse.
2. Non è raro che più applicazioni condividano una VM. Ciò richiede la gestione della configurazione e delle dipendenze per tutte le applicazioni.
3. Il backout richiede l'annullamento delle modifiche nella VM. O ripristinandolo se possibile.

Con Docker l'idea è quella di raggruppare l'applicazione all'interno del proprio contenitore insieme alle librerie di cui ha bisogno e quindi promuovere l' intero contenitore come una singola unità.

1. Ad eccezione del kernel, le patch e le librerie sono identiche.
2. Come regola generale, esiste una sola applicazione per container che semplifica la configurazione.
3. Il backout consiste nell'arresto e nella cancellazione del contenitore.

Quindi al livello più fondamentale con le VM promuovi l'applicazione e le sue dipendenze come componenti discreti mentre con Docker promuovi tutto in un colpo solo.

E sì, ci sono problemi con i container, inclusa la loro gestione, anche se strumenti come Kubernetes o Docker Swarm semplificano notevolmente l'attività.