Vraag Hoe verschilt Docker van een virtuele machine?


Ik blijf herlezen de documentatie van Docker om het verschil tussen Docker en een volledige VM te begrijpen. Hoe slaagt het erin om een ​​volledig bestandssysteem, geïsoleerde netwerkomgeving, etc. te bieden zonder zo zwaar te zijn?

Waarom is het implementeren van software in een docker-afbeelding (als dat de juiste term is) eenvoudiger dan eenvoudigweg implementeren in een consistente productieomgeving?


2910
2018-04-16 21:19


oorsprong


antwoorden:


Docker oorspronkelijk gebruikt LinuX-containers (LXC), maar later overgeschakeld naar Runc (voorheen bekend als libcontainer), die in hetzelfde besturingssysteem als de host wordt uitgevoerd. Hierdoor kan het een groot deel van de bronnen van het besturingssysteem van de host delen. Het maakt ook gebruik van een gelaagd bestandssysteem (aufs) en beheert het netwerken.

AuFS is een gelaagd bestandssysteem, dus u kunt een alleen-lezen gedeelte en een schrijfgedeelte hebben die samengevoegd zijn. Men zou de gemeenschappelijke delen van het besturingssysteem als alleen-lezen kunnen hebben (en kunnen worden gedeeld tussen al uw containers) en elke container zijn eigen mount kunnen geven voor schrijven.

Dus laten we zeggen dat je een containergeschiedenis van 1 GB hebt; als u een volledige VM wilt gebruiken, moet u 1 GB x keer zoveel VM's hebben als u wilt. Met Docker en AuFS kunt u het grootste deel van de 1 GB tussen alle containers delen en als u 1000 containers hebt, hebt u misschien nog steeds iets meer dan 1 GB aan ruimte voor de containers OS (aangenomen dat ze allemaal hetzelfde OS-image gebruiken) .

Een volledig gevirtualiseerd systeem krijgt zijn eigen set van resources toegewezen, en doet minimaal delen. Je krijgt meer isolatie, maar het is veel zwaarder (vereist meer middelen). Met Docker krijgt u minder isolatie, maar de containers zijn licht van gewicht (hebben minder middelen nodig). U kunt dus eenvoudig duizenden containers op een host uitvoeren en deze knippert niet eens. Probeer dat met Xen te doen, en tenzij je een hele grote gastheer hebt, denk ik niet dat het mogelijk is.

Een volledig gevirtualiseerd systeem heeft meestal enkele minuten nodig om te starten, terwijl Docker / LXC / runC-containers seconden duren, en vaak zelfs minder dan een seconde.

Er zijn voor- en nadelen voor elk type gevirtualiseerd systeem. Als u volledige isolatie met gegarandeerde bronnen wilt, is een volledige VM de juiste keuze. Als u alleen processen van elkaar wilt isoleren en een ton ervan wilt uitvoeren op een redelijk grote host, lijkt Docker / LXC / runC de juiste keuze.

Raadpleeg voor meer informatie deze reeks blogberichten die goed uitleggen hoe LXC werkt.

Waarom is het implementeren van software in een docker-afbeelding (als dat de juiste term is) eenvoudiger dan eenvoudigweg implementeren in een consistente productieomgeving?

Het implementeren van een consistente productieomgeving is gemakkelijker gezegd dan gedaan. Zelfs als u tools zoals gebruikt Chef en Marionet, er zijn altijd OS-updates en andere dingen die veranderen tussen hosts en omgevingen.

Docker biedt u de mogelijkheid om het OS in een gedeelde afbeelding te snapshotten en maakt het eenvoudig te implementeren op andere Docker-hosts. Lokaal, dev, qa, prod, enz .: allemaal hetzelfde beeld. Natuurlijk kun je dit met andere hulpmiddelen doen, maar lang niet zo gemakkelijk of snel.

Dit is geweldig om te testen; stel dat u duizenden tests hebt die verbinding moeten maken met een database en dat elke test een onberispelijke kopie van de database nodig heeft en wijzigingen in de gegevens aanbrengt. De klassieke benadering hiervan is om de database na elke test opnieuw in te stellen, met aangepaste code of met tools zoals Flyway - dit kan zeer tijdrovend zijn en betekent dat tests serieel moeten worden uitgevoerd. Met Docker kunt u echter een afbeelding van uw database maken en één exemplaar per test uitvoeren, en vervolgens alle tests parallel uitvoeren, omdat u weet dat ze allemaal tegen dezelfde momentopname van de database zullen draaien. Aangezien de tests parallel lopen en in Docker-containers, zouden ze allemaal tegelijk in dezelfde doos kunnen worden uitgevoerd en zouden ze veel sneller moeten worden voltooid. Probeer dat te doen met een volledige VM.

Van reacties ...

Interessant! Ik veronderstel dat ik nog steeds in de war ben door het idee van "snapshot [ting] the OS". Hoe doe je dat zonder, nou, een beeld van het besturingssysteem te maken?

Laten we kijken of ik het kan uitleggen. U begint met een basisafbeelding en brengt vervolgens uw wijzigingen aan en legt die wijzigingen vast met Docker en maakt een afbeelding. Deze afbeelding bevat alleen de verschillen met de basis. Wanneer u uw afbeelding wilt uitvoeren, hebt u ook het basisstation nodig en wordt uw afbeelding boven op de basis gelaagd met behulp van een gelaagd bestandssysteem: zoals hierboven vermeld, gebruikt Docker AUFS. AUFS voegt de verschillende lagen samen en u krijgt wat u wilt; je moet het gewoon uitvoeren. Je kunt steeds meer afbeeldingen (lagen) toevoegen en alleen de diff's opslaan. Aangezien Docker meestal bouwt op kant-en-klare afbeeldingen van een register, je hoeft het hele OS zelf maar zelden te "snapshoten".


2807
2018-04-16 22:35



Goede antwoorden. Om een ​​beeldrepresentatie van container versus VM te krijgen, bekijkt u die hieronder.

enter image description here

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


338
2017-10-14 18:02



Het kan handig zijn om te begrijpen hoe virtualisatie en containers op een laag niveau werken. Dat zal veel dingen opruimen.

Opmerking: ik vereenvoudig een beetje in het beschrijven hieronder. Zie referenties voor meer informatie.

Hoe virtualisatie op laag niveau werkt?

In dit geval neemt de VM-manager de CPU-ring 0 over (of de "root-modus" in nieuwere CPU's) en onderschept alle geprivilegieerde oproepen die door gast-OS zijn gemaakt om illusie te creëren dat gast-OS zijn eigen hardware heeft. Leuk weetje: vóór 1998 werd gedacht dat dit onmogelijk was in x86-architectuur omdat er geen manier was om dit soort onderschepping te doen. De mensen bij VMWare waren de eerste die een idee had om de uitvoerbare bytes in het geheugen te herschrijven voor geprivilegieerde oproepen van gast-OS om dit te bereiken.

Het netto effect is dat virtualisatie je in staat stelt om twee compleet verschillende OS op dezelfde hardware uit te voeren. Elk gast-besturingssysteem doorloopt het hele proces van bootstrapping, laden van de kernel, enz. Je kunt een zeer strakke beveiliging hebben, bijvoorbeeld dat gast-OS geen volledige toegang kan krijgen tot host-besturingssystemen of andere gasten en dingen verpest.

Hoe containers op een laag niveau werken?

In de omgeving van 2006, mensen inclusief een aantal van de werknemers bij Google geïmplementeerd nieuwe kernel level-functie genoemd namespaces (echter het idee lang voor bestond in FreeBSD). Eén functie van het besturingssysteem is het delen van globale bronnen zoals netwerk en schijf met processen mogelijk te maken. Wat als deze globale resources in naamruimten zijn ingepakt, zodat ze alleen zichtbaar zijn voor die processen die in dezelfde naamruimte worden uitgevoerd? Stel dat je een stuk schijf kunt krijgen en dat in naamruimte X kunt plaatsen en vervolgens processen in naamruimte kunt verwerken die Y niet kan zien of er niet bij kan. Op dezelfde manier hebben processen in naamruimte X geen toegang tot iets in het geheugen dat is toegewezen aan naamruimte Y. Natuurlijk kunnen processen in X niet zien of praten met processen in naamruimte Y. Dit biedt soort van virtualisatie en isolatie voor algemene bronnen. Dit is hoe docker werkt: elke container wordt in zijn eigen naamruimte uitgevoerd, maar gebruikt precies de dezelfde kernel als alle andere containers. De isolatie gebeurt omdat de kernel de naamruimte kent die aan het proces is toegewezen en tijdens API-oproepen zorgt ervoor dat dit proces alleen toegang heeft tot bronnen in zijn eigen naamruimte.

De beperkingen van containers versus VM moeten nu duidelijk zijn: je kunt niet een heel ander besturingssysteem gebruiken in containers zoals in VM's. Hoe jij ook kan verschillende distro's van Linux uitvoeren omdat ze dezelfde kernel delen. Het isolatieniveau is niet zo sterk als in VM. In feite was er een manier voor een "gast" -container om de host over te nemen in vroege implementaties. Ook kunt u zien dat wanneer u een nieuwe container laadt, de volledige nieuwe kopie van het besturingssysteem niet start zoals in de VM. Alle containers deel dezelfde kernel. Dit is de reden waarom de containers licht zijn. In tegenstelling tot VM hoeft u geen belangrijk stuk geheugen vooraf toe te wijzen aan containers, omdat we geen nieuw exemplaar van OS gebruiken. Dit maakt het mogelijk om duizenden containers op één OS uit te voeren, terwijl je ze sandboxing, wat misschien niet mogelijk is als we een afzonderlijke kopie van OS in zijn eigen VM draaien.


294
2018-01-13 01:49



Ik hou van het antwoord van Ken Cochrane.

Maar ik wil een extra standpunt toevoegen dat hier niet in detail wordt behandeld. Naar mijn mening verschilt Docker ook in het hele proces. In tegenstelling tot VM's gaat Docker niet (alleen) over optimaal delen van resources, maar biedt het ook een "systeem" voor verpakkingstoepassingen (bij voorkeur maar niet een must, als een set microservices).

Voor mij past het in de kloof tussen Developer Oriented tools zoals rpm, debian packages, maven, npm + git aan de ene kant en Ops tools zoals Puppet, VMWare, Xen noem maar op ...

Waarom is het implementeren van software in een docker-afbeelding (als dat de juiste term is) eenvoudiger dan eenvoudigweg implementeren in een consistente productieomgeving?

Uw vraag veronderstelt een consistente productieomgeving. Maar hoe houd je het consistent?  Overweeg een hoeveelheid (> 10) van servers en applicaties, fasen in de pijplijn. Om dit synchroon te houden, zult u iets als Puppet, Chef of uw eigen provisioning-scripts, niet-gepubliceerde regels en / of veel documentatie gaan gebruiken ... In theorie kunnen servers voor onbepaalde tijd worden uitgevoerd en volledig consistent en up-to-date worden gehouden. Oefening slaagt er niet in om de serverconfiguratie volledig te beheren, dus er is veel ruimte voor configuratiedrift en onverwachte wijzigingen in actieve servers.

Er is dus een bekend patroon om dit te voorkomen, de zogenaamde Onveranderlijke server. Maar het onveranderlijke serverpatroon was niet geliefd. Vooral vanwege de beperkingen van VM's werd het vóór Docker gebruikt. Omgaan met meerdere Gigabytes grote afbeeldingen, het verplaatsen van die grote afbeeldingen, alleen maar om een ​​aantal velden in de app te veranderen, was heel erg omslachtig. Begrijpelijk...

Met een Docker-ecosysteem hoeft u nooit meer rond Gigabytes te bewegen op 'kleine wijzigingen' (Bedankt aufs en Register) en hoeft u zich tijdens runtime geen zorgen te maken over het verliezen van de prestaties door verpakkingstoepassingen in een Docker-container. U hoeft zich geen zorgen te maken over de versies van die afbeelding. En tot slot zul je zelfs vaak in staat zijn om complexe productieomgevingen te reproduceren, zelfs op je linux-laptop (bel me niet als het niet werkt in jouw geval;))

En natuurlijk kunt u Docker-containers in VM's starten (het is een goed idee). Beperk uw serverregistratie op VM-niveau. Al het bovenstaande kan worden beheerd door Docker.

Postscriptum Ondertussen gebruikt Docker zijn eigen implementatie "libcontainer" in plaats van LXC. Maar LXC is nog steeds bruikbaar.


279
2017-09-19 16:21



Docker is geen virtualisatiemethodologie. Het is afhankelijk van andere tools die virtualisatie op basis van containers of virtualisatie op besturingssysteemniveau implementeren. Daarvoor gebruikte Docker in eerste instantie het LXC-stuurprogramma en vervolgens naar libcontainer, die nu wordt hernoemd als runc. Docker richt zich primair op het automatiseren van de inzet van applicaties binnen applicatiecontainers. Applicatiecontainers zijn ontworpen om een ​​enkele service te verpakken en uit te voeren, terwijl systeemcontainers zijn ontworpen om meerdere processen uit te voeren, zoals virtuele machines. Docker wordt dus beschouwd als een containerbeheer of applicatie-implementatietool op gecontaineriseerde systemen.

Om te weten hoe het verschilt van andere virtualisaties, gaan we door virtualisatie en de typen. Dan zou het gemakkelijker zijn om te begrijpen wat het verschil daar is.

virtualisatie

In zijn bedachte vorm werd het beschouwd als een methode voor het logisch delen van mainframes zodat meerdere applicaties gelijktijdig kunnen worden uitgevoerd. Het scenario veranderde echter drastisch toen bedrijven en open-sourcecommunities een manier konden bieden om de gepriviligeerde instructies op de een of andere manier te verwerken en ervoor te zorgen dat meerdere besturingssystemen tegelijkertijd konden worden uitgevoerd op een enkel op x86 gebaseerd systeem.

hypervisor

De hypervisor zorgt voor het maken van de virtuele omgeving waarop de virtuele gastmachines werken. Het houdt toezicht op de gastsystemen en zorgt ervoor dat de resources zo nodig aan de gasten worden toegewezen. De hypervisor bevindt zich tussen de fysieke machine en virtuele machines en biedt virtualisatieservices aan de virtuele machines. Om dit te realiseren onderschept het de werking van het gastbesturingssysteem op de virtuele machines en emuleert het de werking op het besturingssysteem van de hostcomputer.

De snelle ontwikkeling van virtualisatietechnologieën, voornamelijk in de cloud, heeft het gebruik van virtualisatie verder gedreven door toe te staan ​​dat meerdere virtuele servers op één fysieke server worden gemaakt met behulp van hypervisors, zoals Xen, VMware Player, KVM, enz. integratie van hardware-ondersteuning in commodity-processors, zoals Intel VT en AMD-V.

Typen virtualisatie

De virtualisatiemethode kan worden gecategoriseerd op basis van hoe het de hardware nabootst op een gastbesturingssysteem en de gastomgeving van de gast emuleert. In de eerste plaats zijn er drie soorten virtualisatie:

  • wedijver
  • paravirtualisatie
  • Op containers gebaseerde virtualisatie

wedijver

Emulatie, ook bekend als volledige virtualisatie, voert de OS-kernel van de virtuele machine volledig uit in software. De hypervisor die in dit type wordt gebruikt, staat bekend als Type 2-hypervisor. Het is geïnstalleerd op de top van het host-besturingssysteem dat verantwoordelijk is voor het vertalen van gast-OS-kernelcode naar software-instructies. De vertaling gebeurt volledig in software en vereist geen hardware-betrokkenheid. Emulatie maakt het mogelijk om een ​​niet-gewijzigd besturingssysteem uit te voeren dat de geëmuleerde omgeving ondersteunt. Het nadeel van dit type virtualisatie is extra systeemresourceoverhead die leidt tot prestatieverliezen in vergelijking met andere typen virtualisaties.

Emulation

Voorbeelden in deze categorie zijn VMware Player, VirtualBox, QEMU, Bochs, Parallels, etc.

paravirtualisatie

Paravirtualization, ook bekend als Type 1 hypervisor, loopt rechtstreeks op de hardware, of "bare-metal", en levert virtualisatieservices rechtstreeks aan de virtuele machines die erop draaien. Het helpt het besturingssysteem, de gevirtualiseerde hardware en de echte hardware om samen te werken om optimale prestaties te bereiken. Deze hypervisors hebben meestal een vrij kleine voetafdruk en vereisen geen uitgebreide middelen.

Voorbeelden in deze categorie zijn Xen, KVM, etc.

Paravirtualization

Op containers gebaseerde virtualisatie

Op containers gebaseerde virtualisatie, ook bekend als virtualisatie op besturingssysteemniveau, maakt meerdere geïsoleerde uitvoeringen mogelijk binnen één enkele besturingssysteemkernel. Het heeft de best mogelijke prestaties en dichtheid en beschikt over dynamisch bronnenbeheer. De geïsoleerde virtuele uitvoeringsomgeving die door dit type virtualisatie wordt geboden, wordt container genoemd en kan worden bekeken als een getraceerde groep processen.

Container-based virtualization

Het concept van een container wordt mogelijk gemaakt door de functie namespaces die is toegevoegd aan Linux-kernelversie 2.6.24. De container voegt zijn ID toe aan elk proces en voegt nieuwe toegangscontroles toe aan elke systeemaanroep. Het is toegankelijk door de clone () systeemaanroep waarmee afzonderlijke exemplaren van voorheen globale naamruimten kunnen worden gemaakt.

Namespaces kunnen op veel verschillende manieren worden gebruikt, maar de meest gebruikelijke benadering is om een ​​geïsoleerde container te maken die geen zichtbaarheid of toegang tot objecten buiten de container heeft. Processen die in de container worden uitgevoerd lijken op een normaal Linux-systeem te draaien, hoewel ze de onderliggende kernel delen met processen in andere naamruimten, hetzelfde voor andere soorten objecten. Als u bijvoorbeeld namespaces gebruikt, wordt de rootgebruiker in de container niet behandeld als root buiten de container, waardoor extra beveiliging wordt toegevoegd.

Het subsysteem Linux Control Groups (cgroups), het volgende hoofdonderdeel voor het inschakelen van op containers gebaseerde virtualisatie, wordt gebruikt om processen te groeperen en hun totale resourceverbruik te beheren. Het wordt vaak gebruikt om het geheugen en CPU-verbruik van containers te beperken. Omdat een gecontaineriseerd Linux-systeem slechts één kernel heeft en de kernel volledig zichtbaar is in de containers, is er maar één niveau van brontoewijzing en -planning.

Verschillende managementtools zijn beschikbaar voor Linux-containers, waaronder LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker, etc.

Containers versus virtuele machines

In tegenstelling tot een virtuele machine hoeft een container de kernel van het besturingssysteem niet te booten, dus containers kunnen in minder dan een seconde worden gemaakt. Deze functie maakt op containers gebaseerde virtualisatie uniek en wenselijk dan andere virtualisatiebenaderingen.

Omdat op containers gebaseerde virtualisatie weinig of geen overhead toevoegt aan de hostcomputer, heeft op containers gebaseerde virtualisatie bijna-native prestaties

Voor op containers gebaseerde virtualisatie is geen extra software vereist, in tegenstelling tot andere virtualisaties.

Alle containers op een host-machine delen de planningsprogramma's van de host-machine waardoor er extra hulpbronnen nodig zijn.

Containerstaten (Docker- of LXC-afbeeldingen) zijn klein in vergelijking met afbeeldingen van virtuele machines, zodat containerafbeeldingen eenvoudig kunnen worden gedistribueerd.

Resourcemanagement in containers wordt bereikt via cgroups. Cgroups staan ​​niet toe dat containers meer bronnen verbruiken dan aan hen zijn toegewezen. Vanaf nu zijn echter alle bronnen van de hostmachine zichtbaar in virtuele machines, maar deze kunnen niet worden gebruikt. Dit kan worden gerealiseerd door te hardlopen top of htop op containers en hostmachine op hetzelfde moment. De uitvoer in alle omgevingen zal er hetzelfde uitzien.


121
2018-04-02 00:55



Via deze post zullen we enkele verschillen trekken tussen VM's en LXC's. Laten we ze eerst definiëren.

VM:

Een virtuele machine emuleert een fysieke computeromgeving, maar aanvragen voor CPU, geheugen, harde schijf, netwerk en andere hardwarebronnen worden beheerd door een virtualisatielaag die deze verzoeken vertaalt naar de onderliggende fysieke hardware.

In deze context wordt de VM de gast genoemd, terwijl de omgeving waarop deze wordt uitgevoerd de host wordt genoemd.

LXCs:

Linux-containers (LXC) zijn besturingssystemen op besturingssysteemniveau die het mogelijk maken om meerdere geïsoleerde Linux-containers op één beheergastheer (de LXC-host) uit te voeren. Linux-containers dienen als een lichtgewicht alternatief voor VM's omdat ze de hypervisors niet nodig hebben. Virtualbox, KVM, Xen, etc.

Tenzij je gedrogeerd was door Alan (Zach Galifianakis - uit de Hangover-serie) en het afgelopen jaar in Vegas bent geweest, zul je je behoorlijk bewust zijn van de enorme belangstelling voor Linux-containers, en als ik specifiek een container zal zijn project dat in de afgelopen paar maanden wereldwijd furore heeft gemaakt - Docker leidt tot enkele echo's dat cloud computing-omgevingen virtuele machines (VM's) moeten verlaten en vervangen door containers vanwege hun lagere overheadkosten en mogelijk betere prestaties.

Maar de grote vraag is, is het haalbaar ?, zal het verstandig zijn?

een. LXC's zijn geschikt voor een Linux-exemplaar. Het kunnen verschillende smaken van Linux zijn (bijv. Een Ubuntu-container op een CentOS-host, maar het is nog steeds Linux.) Op dezelfde manier zijn Windows-gebaseerde containers nu een voorbeeld van Windows, als we naar VM's kijken, hebben ze een breder bereik en gebruiken ze de hypervisors bent u niet beperkt tot besturingssystemen Linux of Windows.

b. LXC's hebben lage overheadkosten en hebben betere prestaties in vergelijking met VM's. Tools te weten Dockers die op de schouders van de LXC-technologie zijn gebouwd, hebben ontwikkelaars een platform geboden om hun toepassingen uit te voeren en hebben tegelijkertijd mensen in de hand gewerkt met een tool waarmee ze dezelfde container op productieservers of datacenters kunnen implementeren. Het probeert de ervaring te maken tussen een ontwikkelaar die een toepassing uitvoert, een toepassing opstart en test en een operationele persoon die die toepassing naadloos implementeert, omdat hier alle wrijving ligt en het doel van DevOps is om die silo's op te splitsen.

Dus de beste aanpak is dat de leveranciers van cloudinfrastructuur een gepast gebruik van de VM's en LXC moeten aanbevelen, omdat ze elk geschikt zijn voor specifieke werkbelastingen en scenario's.

Het verlaten van VM's is vanaf nu niet praktisch. Dus zowel VM's als LXC's hebben hun eigen individuele bestaan ​​en belang.


117
2017-08-26 07:46



De meeste antwoorden hebben het hier over virtuele machines. Ik ga je een one-liner antwoord geven op deze vraag die me het meest heeft geholpen in de afgelopen paar jaar van het gebruik van Docker. Het is dit:

Docker is gewoon een mooie manier om een ​​proces uit te voeren, geen virtuele machine.

Laat me wat meer uitleggen over wat dat betekent. Virtuele machines zijn hun eigen beest. Ik wil graag uitleggen wat havenarbeider zal je helpen dit meer te begrijpen dan uit te leggen wat een virtuele machine is. Vooral omdat er hier veel goede antwoorden zijn die je precies vertellen wat iemand bedoelt als ze 'virtuele machine' zeggen. Zo...

Een Docker-container is slechts een proces (en de onderliggende items) dat wordt gecompartimenteerd met cgroups in de kernel van het gastheersysteem van de rest van de processen. Je kunt je Docker-container daadwerkelijk zien draaien door te draaien ps aux op de host. Bijvoorbeeld starten apache2 "in een container" is net begonnen apache2 als een speciaal proces op de host. Het is alleen gecompartimenteerd van andere processen op de machine. Het is belangrijk om op te merken dat uw containers niet bestaan ​​buiten de levensduur van uw containerproces. Wanneer uw proces sterft, sterft uw container. Dat komt omdat Docker wordt vervangen pid 1 in uw container met uw toepassing (pid 1 is normaal het init-systeem). Dit laatste punt over pid 1 is zeer belangrijk.

Wat betreft het bestandssysteem dat door elk van die containerprocessen wordt gebruikt, gebruikt Docker UnionFS-back-up afbeeldingen, dat is wat je aan het downloaden bent als je een a docker pull ubuntu. Elke "afbeelding" is slechts een reeks lagen en gerelateerde metagegevens. Het concept van gelaagdheid is hier erg belangrijk. Elke laag is slechts een verandering van de laag eronder. Wanneer u bijvoorbeeld een bestand in uw Docker-bestand verwijdert terwijl u een Docker-container maakt, maakt u eigenlijk alleen een laag bovenop de laatste laag die zegt "dit bestand is verwijderd". Overigens is dit de reden waarom je een groot bestand van je bestandssysteem kunt verwijderen, maar de afbeelding neemt nog steeds dezelfde hoeveelheid schijfruimte in beslag. Het bestand is er nog steeds, in de lagen onder het huidige bestand. Lagen zelf zijn slechts tarballs van bestanden. Je kunt dit uittesten met docker save --output /tmp/ubuntu.tar ubuntuen dan cd /tmp && tar xvf ubuntu.tar. Dan kun je rondkijken. Al die mappen die eruit zien als lange hashes zijn eigenlijk de individuele lagen. Elke bevat bestanden (layer.tar) en metadata (json) met informatie over die bepaalde laag. Die lagen beschrijven alleen veranderingen in het bestandssysteem die als een laag "bovenop" zijn oorspronkelijke staat worden opgeslagen. Bij het lezen van de "huidige" gegevens leest het bestandssysteem gegevens alsof het alleen naar de bovenste lagen van veranderingen kijkt. Daarom lijkt het bestand te zijn verwijderd, ook al bestaat het nog steeds in "vorige" lagen, omdat het bestandssysteem alleen naar de bovenste lagen kijkt. Hierdoor kunnen volledig verschillende containers hun bestandssysteemlagen delen, ook al zijn er enkele belangrijke wijzigingen in het bestandssysteem op de bovenste lagen in elke container gebeurd. Dit kan u heel wat schijfruimte besparen, wanneer uw containers hun basisbeeldlagen delen. Wanneer u echter mappen en bestanden van het hostsysteem als volumes opvoert in uw container, worden die volumes "overslaan" door de UnionFS, zodat wijzigingen niet in lagen worden opgeslagen.

Netwerken in Docker wordt bereikt door een ethernet-bridge (genaamd docker0 op de host) en virtuele interfaces voor elke container op de host. Hiermee wordt een virtueel subnet gemaakt docker0 voor uw containers om te communiceren "tussen" elkaar. Hier zijn veel opties voor netwerken, zoals het maken van aangepaste subnetten voor uw containers en de mogelijkheid om de netwerkstack van uw host te "delen" zodat uw container rechtstreeks toegang krijgt.

Docker beweegt erg snel. Haar documentatie is een van de beste documentatie die ik ooit heb gezien. Het is over het algemeen goed geschreven, beknopt en nauwkeurig. Ik raad u aan de beschikbare documentatie te raadplegen voor meer informatie en de documentatie te vertrouwen op al het andere dat u online leest, waaronder Stack Overflow. Als u specifieke vragen heeft, raad ik u aan om lid te worden #docker op Freenode IRC en daar te vragen (je kunt zelfs Freenode's gebruiken online chat daarom!).


89
2018-04-04 02:35



Docker kapselt een applicatie in met al zijn afhankelijkheden, een virtualizer kapselt een O.S. die alle applicaties kan draaien die normaal gesproken op een bare metal-machine kunnen worden uitgevoerd.


57
2017-08-27 18:25



Ze zijn allebei heel verschillend. Docker is lichtgewicht en maakt gebruik van LXC / libcontainer (die afhankelijk is van kernel namespacing en cgroups) en heeft geen machine / hardware-emulatie zoals hypervisor, KVM. Xen die zwaar zijn.

Docker en LXC zijn meer bedoeld voor sandboxing, containerisatie en bronisolatie. Het maakt gebruik van de clone-API van het host-besturingssysteem (momenteel alleen Linux-kernel) die namespacing biedt voor IPC, NS (mount), netwerk, PID, UTS, enz.

Hoe zit het met geheugen, I / O, CPU, etc.? Dat wordt beheerd met behulp van cgroups waar je groepen met bepaalde resource (CPU, geheugen, etc.) specificatie / beperking kunt maken en je processen daarin kunt plaatsen. Bovenop LXC biedt Docker een opslagbackend (http://www.projectatomic.io/docs/filesystems/), bijvoorbeeld union mount-bestandssysteem, waar u lagen kunt toevoegen en lagen kunt delen tussen verschillende mount-naamruimten.

Dit is een krachtige functie waarbij de basisafbeeldingen meestal alleenleesbaar zijn en alleen wanneer de container iets in de laag wijzigt, het iets schrijft naar lees- en schrijfpartitie (a.k.a. kopie bij schrijven). Het biedt ook veel andere wrappers, zoals register en versiebeheer van afbeeldingen.

Bij normale LXC moet je komen met een aantal rootfs of de rootfs delen en wanneer gedeeld, en de veranderingen worden weerspiegeld in andere containers. Vanwege veel van deze toegevoegde functies is Docker populairder dan LXC. LXC is populair in ingesloten omgevingen voor het implementeren van beveiliging rond processen die zijn blootgesteld aan externe entiteiten zoals het netwerk en de gebruikersinterface. Docker is populair in cloud-multi-tenancy-omgevingen waar een consistente productieomgeving wordt verwacht.

Een normale VM (bijvoorbeeld VirtualBox en VMware) maakt gebruik van een hypervisor en gerelateerde technologieën hebben ofwel een speciale firmware die de eerste laag wordt voor het eerste besturingssysteem (host-besturingssysteem of gast-besturingssysteem 0) of een software die wordt uitgevoerd op het host-besturingssysteem om bieden hardware-emulatie, zoals CPU, USB / accessoires, geheugen, netwerk, etc., aan de gast-besturingssystemen. VM's zijn nog steeds (vanaf 2015) populair in een multi-tenant omgeving met hoge beveiliging.

Docker / LXC kan bijna op elke goedkope hardware worden uitgevoerd (minder dan 1 GB geheugen is ook in orde zolang u een nieuwere kernel hebt) versus normale VM's hebben ten minste 2 GB geheugen, enz. Nodig om er iets zinnigs mee te doen . Maar Docker-ondersteuning op het host-besturingssysteem is niet beschikbaar in OS zoals Windows (vanaf november 2014), waarbij ook typen VM's kunnen worden uitgevoerd op Windows, Linux en Macs.

Hier is een foto van docker / rightscale: Here is a pic from rightscale


45
2017-11-03 17:44



1. Lichtgewicht

Dit is waarschijnlijk de eerste indruk voor veel dokwerkstudenten.

Ten eerste zijn Docker-afbeeldingen meestal kleiner dan VM-images, waardoor het eenvoudig is om te bouwen, kopiëren en delen.

Ten tweede kunnen Docker-containers in verschillende milliseconden worden gestart, terwijl VM in seconden wordt gestart.

2. Gelaagd bestandssysteem

Dit is een ander belangrijk kenmerk van Docker. Afbeeldingen hebben lagen en verschillende afbeeldingen kunnen lagen delen, waardoor het nog meer ruimtebesparend en sneller te bouwen is.

Als alle containers Ubuntu als hun basisafbeeldingen gebruiken, heeft niet elke afbeelding zijn eigen bestandssysteem, maar delen ze dezelfde onderstreepte ubuntu-bestanden en verschillen ze alleen in hun eigen toepassingsgegevens.

3. Gedeelde OS-kernel

Beschouw containers als processen!

Alle containers die op een host worden uitgevoerd, zijn inderdaad een aantal processen met verschillende bestandssystemen. Ze delen dezelfde OS-kernel, kapselen alleen de systeembibliotheek en afhankelijkheden in.

Dit is goed voor de meeste gevallen (geen extra OS kernel onderhoudt) maar kan een probleem zijn als strikte isolaties tussen containers nodig zijn.

Waarom het uitmaakt?

Al deze lijken op verbeteringen, geen revolutie. Goed, kwantitatieve accumulatie leidt tot kwalitatieve transformatie.

Denk aan de inzet van applicaties. Als we een nieuwe software (service) willen implementeren of een upgrade willen uitvoeren, is het beter om de configuratiebestanden en -processen te wijzigen in plaats van een nieuwe VM te maken. Omdat het maken van een VM met bijgewerkte service, het testen ervan (delen tussen Dev & QA), het implementeren in de productie uren, zelfs dagen kost. Als er iets misgaat, moet je opnieuw beginnen en nog meer tijd verspillen. Gebruik daarom de configuratiebeheertool (marionet, saltstack, chef enz.) Om nieuwe software te installeren, nieuwe bestanden te downloaden heeft de voorkeur.

Als het gaat om Docker, is het onmogelijk om een ​​nieuw aangemaakte docker-container te gebruiken om de oude container te vervangen. Onderhoud is veel eenvoudiger! Een nieuwe afbeelding bouwen, delen met QA, testen, in gebruik nemen duurt slechts minuten (als alles automatisch is), uren in het slechtste geval. Dit heet onveranderlijke infrastructuur: onderhoud geen (upgrade) software, maar maak in plaats daarvan een nieuwe.

Het transformeert hoe diensten worden geleverd. We willen toepassingen, maar moeten VM's onderhouden (wat een pijn is en weinig te maken heeft met onze applicaties). Met Docker kunt u zich concentreren op toepassingen en alles gladstrijken.


23
2017-08-10 04:25