Domanda 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. In che modo riesce a fornire un file system completo, un ambiente di rete isolato, ecc. Senza essere troppo pesante?

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


2910
2018-04-16 21:19


origine


risposte:


Docker originariamente utilizzato Contenitori LinuX (LXC), ma in seguito cambiato a Runc (formalmente conosciuto come libcontainer), che viene eseguito nello stesso sistema operativo del suo host. Ciò consente di condividere molte risorse del sistema operativo host. Inoltre, usa un filesystem a strati (aufs) e gestisce il networking.

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

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

Un sistema completamente virtualizzato riceve il proprio set di risorse ad esso assegnato e ha una condivisione minima. Ottieni più isolamento, ma è molto più pesante (richiede più risorse). Con Docker si ottiene meno isolamento, ma i contenitori sono leggeri (richiedono meno risorse). In questo modo potresti facilmente gestire migliaia di contenitori su un host e non lampeggerà nemmeno. Prova a farlo con Xen e, a meno che tu non abbia un host davvero grande, non penso sia possibile.

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

Ci sono 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 vuoi solo isolare i processi gli uni dagli altri e vuoi eseguirne una tonnellata su un host di dimensioni ragionevoli, allora Docker / LXC / runC sembra essere la strada da percorrere.

Per ulteriori informazioni, controlla questo insieme di post sul blog che fanno un buon lavoro per spiegare come funziona LXC.

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

La distribuzione di un ambiente di produzione coerente è più facile a dirsi che a farsi. Anche se usi strumenti come capocuoco e Fantoccio, ci sono sempre aggiornamenti del sistema operativo e altre cose che cambiano tra host e ambienti.

Docker ti dà la possibilità di eseguire un'istallazione del sistema operativo in un'immagine condivisa e facilita l'implementazione su altri host Docker. Localmente, dev, qa, prod, ecc .: tutta la stessa immagine. Certo, 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 apporta modifiche ai dati. L'approccio classico a questo è quello di ripristinare il database dopo ogni test sia con codice personalizzato o con strumenti come Vola via - questo 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 contro la stessa istantanea del database. Poiché i test sono eseguiti in parallelo e in contenitori Docker, possono essere eseguiti tutti sulla stessa casella nello stesso momento e dovrebbero terminare molto più velocemente. Prova a farlo con una VM completa.

Dai commenti ...

Interessante! Suppongo di essere ancora confuso dalla nozione di "snapshot [ting] il sistema operativo". Come si fa a farlo senza, beh, facendo un'immagine del sistema operativo?

Bene, vediamo se posso spiegare. Si inizia con un'immagine di base, quindi si apportano le modifiche e si effettuano le modifiche utilizzando la finestra mobile e viene creata un'immagine. Questa immagine contiene solo le differenze dalla base. Quando si desidera eseguire l'immagine, è necessaria anche la base e l'immagine viene sovrapposta alla base utilizzando un file system a livelli: come già detto, Docker utilizza AUFS. AUFS unisce insieme i diversi livelli e ottieni quello che vuoi; devi solo eseguirlo. Puoi continuare ad aggiungere sempre più immagini (livelli) e continuerà a salvare solo le differenze. Poiché Docker di solito si basa su immagini pronte da a registro, raramente devi "scattare" l'intero sistema operativo te stesso.


2807
2018-04-16 22:35



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

enter image description here

Fonte: https://www.docker.com/what-container#/package_software


338
2017-10-14 18:02



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

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

In che modo la virtualizzazione funziona a basso livello?

In questo caso, il gestore VM acquisisce l'anello CPU 0 (o la "modalità root" nelle nuove CPU) e intercetta tutte le chiamate privilegiate effettuate dal sistema operativo guest per creare l'illusione che il SO guest abbia il proprio hardware. Fatto divertente: prima del 1998 si pensava che fosse impossibile ottenere questo risultato nell'architettura x86 perché non c'era modo di fare questo tipo di intercettazione. I ragazzi di VMWare sono stati i primi chi ha avuto un'idea di riscrivere i byte eseguibili in memoria per le chiamate privilegiate del SO guest per raggiungere questo obiettivo.

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. È possibile avere una sicurezza molto stretta, ad esempio, il sistema operativo guest non può ottenere pieno accesso al sistema operativo host o ad altri ospiti e fare confusione.

Come i contenitori funzionano a basso livello?

In giro 2006, persone tra cui alcuni dei dipendenti di Google hanno implementato una nuova funzionalità a livello di kernel chiamata spazi dei nomi (comunque l'idea lungo prima esisteva in FreeBSD). Una funzione del sistema operativo è consentire la condivisione di risorse globali come rete e disco per i processi. Cosa succede se queste risorse globali sono state racchiuse in spazi dei nomi in modo che siano visibili solo a quei processi che vengono eseguiti nello stesso spazio dei nomi? Di ', puoi ottenere un blocco di disco e inserirli nello spazio dei nomi X e quindi i processi in esecuzione nello spazio dei nomi Y non possono vederli o accedervi. Allo stesso modo, i processi nello spazio dei nomi X non possono accedere a nulla nella memoria allocata allo spazio dei nomi Y. Naturalmente, i processi in X non possono vedere o parlare ai processi nello spazio dei nomi Y. Questo 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 il stesso kernel come tutti gli altri contenitori. L'isolamento avviene perché il kernel conosce lo spazio dei nomi che è stato assegnato al processo e durante le chiamate API si assicura che quel processo possa accedere alle risorse solo nel proprio spazio dei nomi.

Le limitazioni dei contenitori rispetto alla VM dovrebbero essere ovvi ora: non è possibile eseguire OS completamente diverso in contenitori come in VM. Comunque tu può eseguire diverse distribuzioni di Linux perché condividono lo stesso kernel. Il livello di isolamento non è forte come in VM. In effetti, c'era un modo per il contenitore "ospite" di assumere il controllo dell'host nelle implementazioni iniziali. Inoltre puoi vedere che quando carichi un nuovo contenitore, l'intera nuova copia del sistema operativo non si avvia come in VM. Tutti i contenitori Condividi lo stesso kernel. Questo è il motivo per cui i contenitori sono leggeri. Inoltre, diversamente da VM, non è necessario pre-allocare una parte significativa della memoria nei contenitori perché non stiamo eseguendo una nuova copia del sistema operativo. Ciò consente di eseguire migliaia di contenitori su un sistema operativo mentre li sandboxing che potrebbe non essere possibile fare se stessimo eseguendo una copia separata del sistema operativo nella sua stessa VM.


294
2018-01-13 01:49



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. Al contrario di VM, Docker non è (solo) una condivisione ottimale delle risorse hardware, inoltre fornisce un "sistema" per l'applicazione di packaging (preferibile ma non indispensabile, come un insieme di microservizi).

Per me si inserisce nel divario tra gli strumenti orientati agli sviluppatori come rpm, pacchetti debian, maven, npm + git su un lato e strumenti Ops come Puppet, VMWare, Xen lo si chiama ...

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

La tua domanda presuppone un ambiente di produzione coerente. Ma come tenerlo coerente?  Considerare una certa quantità (> 10) di server e applicazioni, fasi della pipeline. Per mantenerlo sincronizzato inizierai a utilizzare qualcosa come Puppet, Chef o script di provisioning, regole non pubblicate e / o molta documentazione ... In teoria i server possono funzionare a tempo indeterminato e rimanere completamente coerenti e aggiornati. L'esercitazione non riesce a gestire completamente la configurazione di un server, quindi vi è un considerevole margine per la deriva della configurazione e modifiche impreviste ai server in esecuzione.

Quindi c'è un modello noto per evitare questo, il cosiddetto Server immutabile. Ma il modello di server immutabile non è stato amato. Principalmente a causa delle limitazioni di VM è stato utilizzato prima di Docker. Trattare molte immagini gigabyte, spostare quelle grandi immagini, solo per cambiare alcuni campi nell'app, è stato molto laborioso. Comprensibile...

Con un ecosistema di Docker, non dovrai mai spostarti di Gigabyte su "piccole modifiche" (Grazie aufs e Registry) e non dovrai preoccuparti di perdere le prestazioni imballando le applicazioni in un contenitore Docker in fase di runtime. Non devi preoccuparti delle versioni di quell'immagine. E finalmente sarai anche 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 di finestre mobili in VM (è una buona idea). Riduci il provisioning del server a livello di VM. Tutto quanto sopra potrebbe essere gestito da Docker.

Post scriptum Nel frattempo Docker usa la sua implementazione "libcontainer" invece di LXC. Ma LXC è ancora utilizzabile.


279
2017-09-19 16:21



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 stava usando il driver LXC, quindi spostato su libcontainer che ora è 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 confezionare ed eseguire un singolo servizio, mentre i contenitori di sistema sono progettati per eseguire più processi, come macchine virtuali. Pertanto, Docker è considerato uno strumento di gestione dei contenitori 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 x86.

hypervisor

L'hypervisor gestisce la creazione dell'ambiente virtuale su cui operano le macchine virtuali guest. Supervisiona i sistemi degli ospiti e si assicura che le risorse siano assegnate agli ospiti come necessario. 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 guidato 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 incorporazione del supporto hardware nei processori commodity, come Intel VT e AMD-V.

Tipi di virtualizzazione

Il metodo di virtualizzazione può essere classificato in base al modo in cui simula l'hardware in un sistema operativo guest ed emula l'ambiente operativo guest. In primo luogo, ci sono 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 completamente 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 del sistema operativo nelle istruzioni del software. La traduzione avviene interamente in software e non richiede alcun coinvolgimento hardware. L'emulazione consente di eseguire qualsiasi sistema operativo non modificato che supporta l'ambiente emulato. Lo svantaggio di questo tipo di virtualizzazione è l'overhead delle risorse di sistema aggiuntivo che porta a una riduzione delle prestazioni rispetto ad altri tipi di virtualizzazione.

Emulation

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 essa. Aiuta il sistema operativo, l'hardware virtualizzato e l'hardware reale a collaborare per ottenere prestazioni ottimali. Questi hypervisor hanno in genere un ingombro piuttosto ridotto e non richiedono, da soli, risorse estese.

Esempi in questa categoria includono Xen, KVM, ecc.

Paravirtualization

Virtualizzazione basata su container

La virtualizzazione basata su container, nota anche come virtualizzazione a livello di sistema operativo, consente più esecuzioni isolate 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 tracciato.

Container-based virtualization

Il concetto di contenitore è reso possibile dalla funzione namespace aggiunta al kernel di Linux versione 2.6.24. Il contenitore aggiunge il proprio ID a ogni processo e aggiunge nuovi controlli di controllo dell'accesso a ogni chiamata di sistema. Vi si accede da 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 è 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 stiano condividendo 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 considerato come root al di fuori del contenitore, aggiungendo ulteriore sicurezza.

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

Sono disponibili diversi strumenti di gestione per contenitori 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 caratteristica rende la virtualizzazione basata su container unica e desiderabile rispetto ad altri approcci di virtualizzazione.

Poiché la virtualizzazione basata su container aggiunge poco o nessun overhead al computer host, la virtualizzazione basata su container presenta prestazioni quasi native

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

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

Gli stati del contenitore (immagini Docker o LXC) sono di piccole dimensioni rispetto alle immagini di macchine virtuali, quindi le immagini dei contenitori sono facili da distribuire.

La gestione delle risorse in contenitori è realizzata attraverso cgroups. Cgroups non consente ai contenitori di consumare più risorse di quelle assegnate a loro. Tuttavia, al momento, tutte le risorse del computer host sono visibili nelle macchine virtuali, ma non possono essere utilizzate. Questo può essere realizzato eseguendo top o htop su contenitori e macchina host allo stesso tempo. L'output su tutti gli ambienti sarà simile.


121
2018-04-02 00:55



Attraverso questo post disegneremo alcune linee di differenze tra VM e LXC. Iniziamo a definirli.

VM:

Una macchina virtuale emula un ambiente di elaborazione 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 Guest mentre l'ambiente su cui viene eseguito viene chiamato host.

LXCS:

Linux Containers (LXC) sono funzionalità a livello di sistema operativo che rendono possibile l'esecuzione di più contenitori Linux isolati, su un unico host di controllo (l'host LXC). I contenitori Linux rappresentano un'alternativa leggera alle macchine virtuali in quanto non richiedono la visualizzazione degli hypervisor. Virtualbox, KVM, Xen, ecc.

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

Ma la grande domanda è, è fattibile ?, sarà ragionevole?

un. I LXC hanno come ambito un'istanza di Linux. Potrebbero essere diversi tipi di Linux (ad esempio un contenitore Ubuntu su un host CentOS, ma è ancora Linux.) Allo stesso modo, i contenitori basati su Windows hanno un ambito di un'istanza di Windows ora se guardiamo alle macchine virtuali hanno un ambito più ampio e usano il hypervisor non sei limitato ai sistemi operativi Linux o Windows.

b. Gli LXC hanno costi generali bassi e prestazioni migliori rispetto alle macchine virtuali. Strumenti viz. Docker che è stato costruito sulle spalle della tecnologia LXC ha fornito agli sviluppatori una piattaforma per eseguire le loro applicazioni e allo stesso tempo ha consentito alle persone operative con uno strumento che consentirà loro di implementare lo stesso contenitore su server o data center di produzione. Cerca di fare l'esperienza tra uno sviluppatore che esegue un'applicazione, avviare e testare un'applicazione e un operatore che distribuisce l'applicazione senza soluzione di continuità, perché è qui che 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 VM e LXC, poiché sono adatti a gestire carichi di lavoro e scenari specifici.

L'abbandono delle macchine virtuali non è pratico al momento. Quindi sia VM che LXC hanno una propria esistenza e importanza.


117
2017-08-26 07:46



La maggior parte delle risposte qui parla di macchine virtuali. Vi darò una risposta one-liner a questa domanda che mi ha aiutato di più negli ultimi due anni nell'utilizzo di Docker. È questo:

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

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

Un contenitore Docker è solo un processo (e relativo figlio) che viene compartimentato usando cgroups all'interno del kernel del sistema host dal resto dei processi. È possibile visualizzare i processi del contenitore Docker in esecuzione ps aux sull'host Ad esempio, a partire apache2 "in un contenitore" sta appena iniziando apache2 come un processo speciale sull'host. È stato appena compartimentato da altri processi sulla macchina. È importante notare che i contenitori non esistono al di fuori della vita del processo containerizzato. Quando il tuo processo muore, il tuo contenitore muore. Questo perché Docker sostituisce pid 1 nel tuo contenitore con la tua applicazione (pid 1 è normalmente il sistema di init). Questo ultimo punto pid 1 è molto importante.

Per quanto riguarda il filesystem utilizzato da ciascuno di questi processi contenitore, utilizza Docker UnionFS-backback delle immagini, che è quello che stai scaricando quando si fa a docker pull ubuntu. 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 Dockerfile durante la creazione di un contenitore Docker, in realtà stai solo creando un livello sopra l'ultimo layer che dice "questo file è stato cancellato". Per inciso, questo è il motivo per cui è possibile eliminare un grosso file dal proprio filesystem, ma l'immagine occupa ancora la stessa quantità di spazio su disco. Il file è ancora lì, negli strati sotto quello corrente. Gli strati stessi sono solo archivi di file. Puoi testarlo con docker save --output /tmp/ubuntu.tar ubuntue poi cd /tmp && tar xvf ubuntu.tar. Quindi puoi dare un'occhiata in giro. Tutte quelle directory che sembrano lunghi hash sono in realtà i singoli livelli. Ognuno contiene file (layer.tar) e metadati (json) con informazioni su quel particolare livello. Questi livelli descrivono semplicemente le modifiche al filesystem che vengono salvate come livello "sopra" al suo stato originale. Durante la lettura dei dati "attuali", il filesystem legge i dati come se guardasse solo ai livelli più alti di cambiamenti. Ecco perché il file sembra essere cancellato, anche se esiste ancora nei livelli "precedenti", perché il filesystem sta guardando solo i livelli più in alto. Ciò consente a contenitori completamente diversi di condividere i livelli del loro filesystem, anche se potrebbero esserci delle modifiche significative al filesystem nei livelli più alti in ogni contenitore. Questo può farti risparmiare un sacco di spazio su disco, quando i tuoi contenitori condividono i loro livelli di immagine di base. Tuttavia, quando si montano le directory ei file dal sistema host nel contenitore tramite i volumi, tali volumi "ignorano" UnionFS, quindi le modifiche non vengono memorizzate nei livelli.

La rete in Docker si ottiene usando un bridge ethernet (chiamato docker0 sull'host) e interfacce virtuali per ogni contenitore sull'host. Crea una subnet virtuale in docker0 perché i tuoi contenitori comunichino "tra loro". Ci sono molte opzioni per il networking qui, inclusa la creazione di sottoreti personalizzate per i contenitori e la possibilità di "condividere" lo stack di rete del tuo host affinché il tuo container possa accedere direttamente.

Docker si sta muovendo molto velocemente. Suo documentazione è una delle migliori documentazioni che abbia mai visto. È generalmente ben scritto, conciso e accurato. Vi consiglio di consultare la documentazione disponibile per maggiori informazioni e di affidare la documentazione a qualsiasi altra cosa leggiate online, incluso Stack Overflow. Se hai domande specifiche, ti consiglio vivamente di iscriverti #docker su Freenode IRC e chiedendo lì (puoi anche usare Freenode webchat per quello!).


89
2018-04-04 02:35



Docker incapsula un'applicazione con tutte le sue dipendenze, un virtualizzatore incapsula un O.S. che può eseguire qualsiasi applicazione che normalmente può essere eseguita su una macchina bare metal.


57
2017-08-27 18:25



Entrambi sono molto diversi. Docker è leggero e utilizza LXC / libcontainer (che si affida al kernel namespacing e cgroups) e non ha emulazione macchina / hardware come hypervisor, KVM. Xen che sono pesanti.

Docker e LXC sono più utili per sandboxing, containerizzazione e isolamento delle risorse. Utilizza l'API clone del sistema operativo host (attualmente solo il kernel Linux) che fornisce namespacing per IPC, NS (montaggio), rete, PID, UTS, ecc.

Che dire di memoria, I / O, CPU, ecc.? Questo viene controllato usando cgroups in cui è possibile creare gruppi con determinate specifiche (CPU, memoria, ecc.) / Restrizioni e inserire i processi in tale posizione. Sulla parte superiore di LXC, Docker fornisce un back-end di archiviazione (http://www.projectatomic.io/docs/filesystems/), ad es., un filesystem union mount in cui è possibile aggiungere layer e condividere layer tra diversi namespace di mount.

Questa è una potente funzionalità in cui le immagini di base sono in genere in sola lettura e solo quando il contenitore modifica qualcosa nel livello scriverà qualcosa nella partizione di lettura-scrittura (a.k.a. copia su scrittura). Fornisce anche molti altri wrapper come il registro e la versione delle immagini.

Con il normale LXC devi venire con alcuni rootfs o condividere i rootfs e quando sono condivisi, e le modifiche si riflettono su altri contenitori. A causa di molte di queste funzionalità aggiunte, Docker è più popolare di LXC. LXC è popolare negli ambienti embedded per implementare la sicurezza attorno ai processi esposti a entità esterne come la rete e l'interfaccia utente. Docker è molto diffuso negli ambienti 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 dispongono di firmware dedicato che diventa il primo livello per il primo SO (sistema operativo host o sistema operativo guest 0) o un software che viene eseguito sul sistema operativo host per fornire l'emulazione hardware come CPU, USB / accessori, memoria, rete, ecc. ai sistemi operativi guest. Le macchine virtuali sono ancora popolari (a partire dal 2015) in ambienti multi-tenant ad alta sicurezza.

Docker / LXC può quasi essere eseguito su qualsiasi hardware a basso costo (meno di 1 GB di memoria è OK anche se si ha un kernel più recente) rispetto alle normali macchine virtuali 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 (a partire da novembre 2014), dove possono essere eseguiti tipi di VM su Windows, Linux e Mac.

Ecco una foto da docker / rightscale: Here is a pic from rightscale


45
2017-11-03 17:44



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 diversi millisecondi, mentre la VM inizia 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, renderli ancora più salvaspazio e più veloci 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 ubuntu sottolineati e differiscono solo nei propri dati applicativi.

3. Kernel OS condiviso

Pensa ai contenitori come ai processi!

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

Questo è buono per la maggior parte dei casi (nessun mantenimento del kernel del sistema operativo in più), ma può essere un problema se sono necessari rigorosi isolamenti tra i contenitori.

Perchè importa?

Tutti questi sembrano miglioramenti, non rivoluzione. Bene, l'accumulo quantitativo porta alla trasformazione qualitativa.

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

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

Trasforma la modalità di consegna dei servizi. Vogliamo le applicazioni, ma dobbiamo mantenere le VM (che è un problema e ha poco a che fare con le nostre applicazioni). Docker ti consente di concentrarti sulle applicazioni e appianare tutto.


23
2017-08-10 04:25



In relazione con:-

"Perché distribuire il software su un'immagine docker è più semplice che semplicemente   distribuire in un ambiente di produzione coerente? "

La maggior parte del software è distribuita in molti ambienti, in genere almeno tre dei seguenti:

  1. Singoli PC di sviluppo
  2. Ambiente di sviluppo condiviso
  3. Singoli tester PC (s)
  4. Ambiente di test condiviso
  5. Ambiente QA
  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 o configurazioni di PC molto sottili 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. Freelance che sviluppano sulle proprie macchine (spesso in remoto) o contributori a progetti open source che non sono "impiegati" o "contratti" per configurare i propri PC modo)
  • Alcuni ambienti saranno costituiti da un numero fisso di più macchine in una configurazione con bilanciamento del carico
  • Molti ambienti di produzione disporranno di server basati su cloud in modo dinamico (o "elasticamente") creati e distrutti a seconda dei livelli di traffico

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

Tutto ciò significa che creare 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 (in modo dinamico o manuale), gli aggiornamenti automatici dei venditori o venditori, venditori di antivirus, venditori di browser e simili, installazioni manuali di software o modifiche di configurazione eseguite da sviluppatori o tecnici server, ecc. Lasciate che lo ripeto: è virtualmente (non è previsto il gioco di parole) impossibile mantenere gli ambienti coerenti (ok, per i puristi, può essere fatto, ma comporta una quantità enorme di tempo, impegno e disciplina, che è proprio il motivo per cui VM e contenitori (es. Docker) sono stati concepiti in primo luogo).

Quindi pensa alla tua domanda più come questa "Data l'estrema difficoltà di mantenere tutti gli ambienti coerenti, è più semplice implementare il software su un'immagine docker, anche tenendo conto della curva di apprendimento?". Penso che troverai che la risposta sarà invariabilmente "sì", ma c'è solo un modo per scoprirlo, pubblica questa nuova domanda su Stack Overflow.


16
2017-10-15 11:25