LXD vs Docker

Non tutto ciò che è nuovo è buono e non tutto rivoluzionario è necessario. Con le tecnologie di container, come con ogni altra "prossima grande cosa", stiamo assistendo a un dilagante invenzione di astrazioni di livello superiore seguite da una distribuzione in produzione, con l'intera infrastruttura CD/CI che dipende da esso e non capisce cosa effettivamente.

Cominciamo con ciò che erano effettivamente i contenitori, storicamente. All'inizio degli anni 2000, FreeBSD ha introdotto il concetto di "carceri" che offriva un nuovo ambiente, come una nuova installazione del sistema operativo che offre tutta la biblioteca FreeBSD e l'infrastruttura del kernel che è già in atto. Una lista pulita per gli sviluppatori per testare il nuovo software.

Questo è in netto contrasto con VMware, KVM o VirtualBox come tecnologie in cui l'intero hardware è virtualizzato, dove, il tuo sistema operativo ospita un set virtuale di CPU, RAM e altre risorse. Il tuo sistema operativo ospite si trova in cima a quelle risorse hardware virtuali. Quasi ogni livello di astrazione viene ripetuto due volte e risorse come RAM e CPU una volta assegnato all'ospite non sono più disponibili per l'host (indipendentemente dal fatto che l'ospite li usi completamente).

Contenitori Docker e Linux-y

Con il sistema operativo virtualizzato, i contenitori possono essere fatti girare con quote impostate per il loro utilizzo delle risorse. Ad esempio, se impostiamo un limite massimo di 2 GB di utilizzo della RAM per il contenitore, non sarà in grado di superarlo. D'altra parte, poiché c'è un solo kernel nel ciclo, se il contenitore non utilizza l'intera RAM, il kernel può mettere la risorsa rimanente da utilizzare altrove.

Il primo svantaggio delle persone realizzate con il modello di container è che poiché stiamo virtualizzando il sistema operativo e non l'hardware, è possibile avere più istanze dello stesso sistema operativo e perdi la capacità di girare un sistema operativo arbitrario.

Non esiste una cosa come il contenitore Windows su contenitori Linux o Linux su Windows. Docker su Windows, ad esempio, utilizza Moby Linux che è effettivamente in esecuzione in una VM all'interno della tua casella Windows.

Quando si tratta di una distribuzione Linux, tuttavia, puoi fare molte cose interessanti. Dal momento che ciò che chiamiamo Linux è solo il kernel e ha bisogno di uno stack GNU di librerie per fornire un ambiente OS completo, puoi emulare varie distribuzioni come CentOS, Ubuntu, Alpine in diverse istanze del contenitore.

Questo è vero sia per LXD che per Docker.

Docker come meccanismo di imballaggio

Docker farà ad Apt, cosa ha fatto Apt a Tar. Vale a dire, userai ancora APT ma con un ulteriore livello di astrazione sopra. Per capire come, considera il seguente esempio.

Hai un'istanza del tuo sito web in esecuzione in un PHP5.6 E è necessario eseguire un altro servizio Web sullo stesso server utilizzando PHP7.0. Ora eseguire due diverse versioni di PHP stesso è un'idea spaventosa, non sapere quali conflitti deriverebbero da loro. L'aggiornamento e l'aggiornamento diventeranno presto uno sforzo senza speranza.

Ma cosa succede se avessimo la nostra istanza web originale in esecuzione all'interno di un contenitore Docker? Ora, tutto ciò di cui abbiamo bisogno è un nuovo contenitore Docker all'interno del quale possiamo installare PHP7.0 e il nostro secondo servizio Web funzionerà da questo contenitore di appena girato. Useremo ancora APT in background, proprio come APT usa il catra.

Docker è particolarmente utile per l'esecuzione di applicazioni apolide e sentirai le persone dire spesso che non puoi eseguire più di un processo in un contenitore. Sebbene, ciò sia falso, l'esecuzione di più servizi statali in un'istanza del contenitore può spesso far sì che Docker fornisca risultati incoerenti. Ti ritroverai presto a riavviare lo stesso set di contenitori più e più volte.

LXD come hypervisor

Con i contenitori LXD ciò che ottieni è molto più vicino a un sistema operativo autonomo di quello che ottieni da Docker. I container Docker condividono tutti lo stesso stack di networking e lo stack di archiviazione.

Questo significa comandi di base come ping O ifconfig non sono disponibili dall'interno di un contenitore Docker. In effetti, non puoi sapere quasi nulla della rete in cui ti trovi, dall'interno di quel contenitore. Docker Nat in esecuzione sullo stack di networking dell'host offre la maggior parte della connettività e delle strutture come Port Forwarding.

I contenitori LXD sono molto più avanti rispetto alla curva, supportando ponti di rete, MacVlan e molte altre opzioni. I tuoi contenitori LXD e il tuo host formano tutti una rete privata e possono comunicare tra loro come se stessero parlando con diversi computer su una rete.

Lo stesso vale per lo stack di archiviazione. È spesso molto più pratico utilizzare LXD con pool ZFS in cui è possibile allocare set di dati con quote che limitano l'utilizzo di archiviazione. LXD è in diretta concorrenza con VMware, KVM e altre tecnologie Hypervisor.

Usandolo, il tuo provider cloud ora può provvedere al tuo contenitore personale che odorrebbe e sembra un sistema operativo completo ed è ancora economico e veloce da girare e uccidere, insieme a tutte le bellezze dei dati persistenti che ti aspetti.

Dal punto di vista del fornitore, anche le cose sono economiche. Dal momento che non tutti usano l'intera RAM che chiedono, puoi stipare molti più contenitori sullo stesso metallo di quello che puoi.

Agli utenti finali potrebbe sembrare all'inizio come barare, ma alla fine vincono anche, i contenitori LX sono più veloci per girare e uccidere rendendo il processo molto più fluido e "scalabile" (come le persone amano dire).

È possibile girare i contenitori su un nodo di calcolo in cui risiedono i dati, eseguire il calcolo che si desidera fare e quindi distruggere il contenitore lasciando i dati intatti. Questo è molto più veloce che recuperare i dati rilevanti fino alla macchina virtuale che è in esecuzione su altri data center. Questo funziona particolarmente bene con gli ZF nel ciclo.

Tl; Dr

Per riassumere tutto ciò che sappiamo, sia LXD che Docker sono tecnologie di containerizzazione. Docker è leggero, semplicistico ed è adatto per isolare applicazioni l'una dall'altra, rendendolo popolare tra DevOps e sviluppatori. Un'app per contenitore Docker.

LXD, d'altra parte, è molto meglio attrezzato ed è molto più vicino a un ambiente di sistema operativo completo con interfacce di rete e di archiviazione. È possibile eseguire più contenitori Docker nidificati all'interno di LXD, se lo desideri.