Docker neemt bedrijf voor 'unikernels' over

Het Amerikaanse Docker neemt de Britse start-up Unikernels Systems over. Het kleine bedrijf richt zich op unikernels, die de minimaal vereiste onderdelen van een besturingssysteem gebruiken om applicaties te laten draaien. Docker ziet unikernels als aanvulling op Docker-containers.

Unikernel Systems is vorig jaar opgericht en er werken dertien mensen bij het bedrijf, van wie een groot aantal voorheen betrokken was bij de ontwikkeling van Xen-hypervisors. Het bedrijf richtte zich op de ontwikkeling van tools die ontwikkelaars kunnen gebruiken bij het maken van unikernels. Bij unikernels wordt broncode gecompileerd in een eigen besturingssysteem, waarbij slechts functionaliteit wordt gebruikt die de applicatie minimaal nodig heeft om te draaien.

Unikernels zijn daarmee nog aanzienlijk kleiner dan containers, met alle voordelen op het gebied van flexibiliteit, eenvoud, snelheid en veiligheid van dien. Docker hoopt met de overname een nog stevigere voet aan de grond te krijgen op de markt voor de ontwikkeling van microservices, ook met het oog op de toekomst waarin internet-of-things-toepassingen belangrijker worden. Unikernels vullen containers volgens het bedrijf op dit vlak aan.

De tools van Docker waren al deels geschikt voor unikernels, maar nu Unikernel Systems deel uitmaakt van Docker, zal de integratie verbeterd worden, waarbij er een enkel platform voor virtuele machines, containers en unikernels aangeboden kan worden.

Reacties (44)

[ApexAlpha]

Dus die Unikernels zijn een soort JeOs (Just Enough OS) principe? Alleen wat je écht nodig hebt om te kunnen draaien?

Hoop stiekem op een +3 reactie met wat uitleg over dit principe van Unikernels hier in de comments want klinkt oprecht interessant! als iemand ook een rustige vrijdag op werk heeft...

edit: haha, niet mij +3 geven grappenmakers. Ik hoop dat iemand met uitleg komt over Unikernels die een +3 waard is.

[Reactie gewijzigd door ApexAlpha op 24 juli 2024 09:12]

[svennd]

https://ma.ttias.be/what-is-a-unikernel/

Volgens ik begrijp is unikernel eerder gefocussed, dus niet "just enough OS" om alles te draaien, maar "just enough om iets specifiek te draaien". In mijn hoofd hangt het ook vast aan Docker, dus een verwachte overname.

[atlaste]

Ja, dat vind ik ook logisch. Docker is in principe bedoeld als een container om 1 applicatie in te draaien. Je wilt daarmee zo weinig mogelijk 'bloat' hebben om de containers zo klein mogelijk te houden.

De kernel is zo'n stukje noodzakelijke 'bloat'. Ik vind het dus logisch dat we die ook zo klein mogelijk gaan maken.

Ik heb een paar maanden geleden voor mijn nieuwe server geprobeerd deze helemaal op Docker te baseren. Helaas vond ik de technologie destijds nog niet mature genoeg... ik liep nog tegen te veel issues aan.

De grote vraag die ik had bij de unikernel is of het een Linux ding is of een Windows ding of beiden? Docker draait op beiden.

[svennd]

Linux kernel natuurlijk, de windows kernel is niet opensource

[NLxAROSA]

Microsoft is ook bezig met een unikernel, zoek maar eens op Drawbridge.

[atlaste]

Gevonden. Voor de geinteresseerden: uitleg en goede beschrijving van unikernels gevonden op: http://research.microsoft.com/en-us/projects/drawbridge/

[goarilla]

Is dat niet eerder een nieuw container/sandbox mechanisme, dat minimale library OS lijkt constant te zijn en niet te wijzigen per applicatie.

[svennd]

Aha, dat was nieuws, maar dit bedrijf zal met Linux unikernels bezig zijn neem ik aan.

[DenBeke]

"De grote vraag die ik had bij de unikernel is of het een Linux ding is of een Windows ding of beiden? Docker draait op beiden."

Docker gebruikt Linux containers. Die Linux containers werken met een shared (Linux) kernel. Als je dan Windows gaat gebruiken ben je het hele nut van die shared kernel kwijt.

Ik weet niet hoe Docker op Windows draait, maar op Mac draait Docker eigenlijk in een Linux VM, en dan worden daarin de Docker images gespawned.

tl;dr: Linux

[atlaste]

Hmm ik had ergens gevonden dat het ook onder windows draait. Kan de link niet meer vinden, maar deze voldoet voor nu wel:

https://azure.microsoft.c...ocker-windows-and-trends/

In Windows Server 2016, we will be releasing two flavors of containers, both of which will be deployable using Docker APIs and the Docker client: Windows Server Containers and Hyper-V Containers. Linux containers require Linux APIs from the host kernel and Windows Server Containers require the Windows APIs of a host Windows kernel, so you cannot run Linux containers on a Windows Server host or a Windows Server Container on a Linux host. However, the same Docker client can manage all of these containers, and while you can’t run a packaged Windows container on Linux, a Windows container package works with Windows Server Containers and Hyper-V Containers because they both utilize the Windows kernel.

[Jack Flushell]

Een mooi voorbeeld van een project dat dit principe gebruikt met de Linux-kernel is OpenELEC.

[goarilla]

Ik heb VM hypervisor en containers altijd als concurrerend technologieen gezien. Ze over elkaar leggen vind ik wat vies. Maar hiermee zouden ze inderdaad kunnen een antwoord bieden op full-on VM appliances ?

[Jasper Janssen]

Het OS waar de containers in draaien zal in de praktijk meestal wel een VM zijn. Wat ze in feite doen is het concept uitbreiden naar een *iets* vollere stack, maar wel met zo min mogelijk cruft erin, en natuurlijk nog steeds met de manageability van Docker.

[ApexAlpha]

Oh thanks, dit lijkt op wat ik nodig heb!

Dadelijk even lezen als deze beller zijn standaardprinter weer goed heeft weten te zetten... classic helpdesk

[LauPro]

Als je een normale Linux kernel zou pakken dan zitten daar ook tig drivers in om bijvoorbeeld de videokaart aan te sturen of geluidskaarten, usb etc. Het idee is dat je eigenlijk alleen een netwerk interface hebt, een disk en stukje geheugenbeheer. Vervolgens een klein beetje userspace hebt met wat libraries (libc etc), misschien wat interpreters (PHP, Perl, Python) en uiteraard de data veilig kan opslaan.

Op deze wijze kan je dus services compleet geïsoleerd van elkaar draaien op dezelfde machine. Dit gaat nog wat verder dan alleen een chroot, omdat je dus ook alle risico's van drivers e.d. weg neemt.

Echter denk ik zelf dat als je kijkt naar recente lekken dan zitten die vooral in de applicatielaag. Denk bijvoorbeeld aan iets als SQL injection. Dan kan je alsnog de database en de php-server in een aparte docker hebben staan maar je blijft kwetsbaar voor het lek.

Een ander groot voordeel van de dockers is dat je makkelijker updates kan doen zonder veel impact. Je kan bijvoorbeeld alleen de omgeving (docker) van je MySQL server updaten maar niet de rest. De docker is eigenlijk een soort image met een config en een dataset. Makkelijk te deployen en te migreren.

[ApexAlpha]

dus 'straks' draaien we servers virtueel met voor elke applicatie met de Unikernel erbij geleverd?

en is het vooral de beveiliging waar dit goed voor is of merk je ook echt performance verbeteringen? Want een extra driver doet niets lijkt me als hij niet gebruikt wordt maar idle in de core zit.

[mxcreep]

Toch heb ik wel het idee dat het deels om een hype gaat, zeker zijn er toepassingen waarbij dit echt heel handig is, tijdelijke development en test omgevingen bijvoorbeeld.

Wij baseren onze productie omgevingen echter nog steeds op volledige vm's en daarin wordt ook al de scheiding aangebracht per functionaliteit. Losse applicatie servers, losse loadbalancers, losse database servers etc. Allemaal uitgerold via configuration management en dus ook snel en zo foutloos als software kan zijn.

Het updaten voordeel wat je net noemt zie ik bijvoorbeeld ook niet als specifiek Docker, misschien als je een server met 10 services erop gecombineerd vergelijkt met Docker maar de meeste omgevingen hebben wel aparte vm's per service, alleen de shared hosting en goedkope vps'jes hoek niet echt.

Docker is heel handig om cheap Platform As A Service aan te bieden, RedHat OpenShift en dat soort platformen. Minimale containertjes met een afgeschermde service erin, als je echter ook enigzins performance en resources nodig hebt ben je beter af met gewoon vm's.

Je punt rondom security ben ik het mee eens, de applicatie laag op zich lijkt de meest gevoelige. De servers zelf zijn over het algemeen aardig afgeschermd van de buitenwereld op wat publieke services na.

Eerlijk gezegd zie ik niet perse een toegevoegde waarde qua security, sterker nog Docker introduceert weer een volledig nieuwe software stack naast de al bestaande die ook nog best gecompliceerd is, dus de kans dat daar lekken in voorkomen is ook niet ondenkbaar. En vergeet ook de configuratie fouten niet mee te nemen.

[Anoniem: 474132]

Ja, zo werkt het volgens mij wel. Alleen het benodigde van de kernel/drivers voor je app wordt meegelinkt en als baremetal container door de hypervisor uitgevoerd. Wel vraag ik me af of als je heel veel van die containers draait met evenzoveel specialized kernels of je dan niet meer resources verbruikt dan veel containers met 1 shared kernel.

[blorf]

Hm, geen idee hoe dit werkt, maar het is denk ik zaak om de kernel zo op te bouwen dat ie snel en modulair/dynamisch zichzelf vorkt afhankelijk van de eisen van een specifieke thread en dat daarna ook weer direct opruimt. Maar er zal idd nog wel een klein beetje kernel-code onnodig dubbel geladen worden in bepaalde situaties.

[Reactie gewijzigd door blorf op 24 juli 2024 09:12]

[Anoniem: 474132]

Ik denk dat het (mogelijk) extra resource gebruik bij veel containers gewoon een nadeel is van specialized kernels vs shared kernels (zie plaatje artikel).

Maar wellicht dat de eigenschap 'Isolation' die alleen door duplicated en specialized kernels aangeboden kan worden een must have is. In dat geval is de keuze voor specialized ipv duplicated wel te rechtvaardigen omdat die minder resources verbruikt en de isolation feature heeft.

[Reactie gewijzigd door Anoniem: 474132 op 24 juli 2024 09:12]

[goarilla]

Ik dacht ook dat dit een Linux kernel stripping dienst was. Maar dat is het niet. Docker zal gebruikt worden om een applicatie & specifieke minikernel te deployen. Deze minikernel zal dan zo gebouwd zijn, dat hij enkel de OS functionaliteiten die de applicatie nodig heeft (subset Linux/Unix API), zal voorzien. Wow !

[Jasper Janssen]

Ja, dat kun je ook in het grafiekje zien, totaal resource gebruik is hoger (met name bij veel VMs), maar de isolatie is beter. 't Is maar net wat je nodig hebt.

De 1-container-per-VM implementaties van Docker geven aan dat er vraag is naar die isolatie.

[Clueless]

Ben wel benieuwd hoe dit zich verhoudt tot bijv. het Photon platform van VMware. Met name de combinatie van Photon Machine en Project Photon OS. Met Photon OS zou je iets dergelijks kunnen doen met vSphere en in Photon Machine zit dat allemaal ingebouwd in de microvisor die gebruikt wordt om de containers te draaien.

Blijft een interessante ontwikkeling allemaal dat zeker...

[djwice]

Ik denk dat je het zo moet zien:

• Unikernal heb je voor 1 micro service precies wat je nodig hebt. (elke micro service kan net andere dingen nodig hebben)
• Docker heb je een OS met alles en dan een container voor je database en een container voor je micro service die gebruik maakt van je andere docker container.

1. RaRa wat gaat er nu gebeuren?
Die onderste os-laag gaat weg en de docker containers krijgen in plaats daarvan elk een Unikernal.

2. RaRa wat gaat er daarna gebeuren?
De Unikernals uit verschillende docker containers die overlap hebben worden verwijderd uit die containers en geplaatst in een eigen container.

Resultaat
En zo heb je optimale software met geïsoleerde updates.

Note
Bij de laatste stap moet gelet worden dat je geen cross user kunt maken (by design) zodat je niet per ongeluk ongewilt de data van een andere container beïnvloed, die dezelfde username gebruikt.

[Reactie gewijzigd door djwice op 24 juli 2024 09:12]

[goarilla]

Ze willen de kernel dus extra strippen om iedere Docker container (een Linux-only soort lichtgewicht VM) op een afzonderlijke VM op een bare-metal hypervisor (ook een soort kernel trouwens) te draaien.
Neemt dit het spreekwoordelijke "omdat het kan" niet iets te ver ?

[Rafe]

Een paar belangrijke nuances:

• Unikernels zijn vanaf scratch ontworpen en geschreven in nieuwere talen dan C, waardoor ze bepaalde (aantoonbare) eigenschappen hebben. Bijvoorbeeld MirageOS is in OCaml geschreven. Rust zou hier ook een goede kandidaat voor zijn.
• Je kan per applicatie de meest geschikte unikernel kiezen, in plaats van vast te zitten aan een generieke Linux-kernel.
• Containers bieden wel scheiding (met Docker heb je een packaged userland), maar een shared kernel is nog niet zo sterk gescheiden als een VM is.
• Omdat een unikernel zo klein is, heb je niet te maken met dezelfde overhead als bij een gewone VM.
• Wijzigingen of updates? Je compileert de hele boel opnieuw en rolt je nieuwe image (met unikernel en app) uit. Je krijgt 'immutable' servers, tools als Puppet, Chef en Ansible zijn niet meer nodig.

Het lijkt me voorlopig vooral geschikt voor vrij specifieke use cases, vooral die waar security heel erg belangrijk is.

[Reactie gewijzigd door Rafe op 24 juli 2024 09:12]

[Jerie]

Unikernels zijn vanaf scratch ontworpen en geschreven in nieuwere talen dan C, waardoor ze bepaalde (aantoonbare) eigenschappen hebben

Zoals?

Bij een Linux kernel kun je mobprobe uitzetten en alles wat je niet nodig hebt eruit gooien. Welke voordelen bieden unikernels? Waar liggen de overhead winsten (memory, CPU, I/O?). Zal dit vooral handig zijn voor embedded toepassingen, voor bulk, of beide?

[Rafe]

Hangt van de taal af, bijvoorbeeld memory safety: MirageOS heeft een in OCaml geschreven TLS stack. Zie https://mirage.io/blog/why-ocaml-tls

Ik denk dat de overhead meer winst oplevert op kleine IoT-devices dan dikke (cloud)servers. Het scheelt links- of rechtsom wel als je images tientallen ipv honderden megabytes is.

[Reactie gewijzigd door Rafe op 24 juli 2024 09:12]

[goarilla]

Ik denk dat de overhead meer winst oplevert op kleine IoT-devices dan dikke (cloud)servers.

Dus binnenkort hypervisors overal of die minikernel+applicatie gewoon rechtstreeks op je device en je dus in de embedded wereld begeven ? Dit lijkt zo een coole technologie die wilt groeien uit academia maar het heel moeilijk heeft een markt te vinden.

[Rafe]

Het lijkt me juist een ideale manier om apps eenvoudig te installeren op een IoT device en toch sterke security boundries af te dwingen. Zie bijvoorbeeld nieuws: Canonical stopt in Desktop Next met .deb ten faveure van 'snappy apps' en nieuws: Eneco en Nerdalize starten proeven met serververwarming in huishoudens waar containers al gebruikt worden - dit is een logische vervolgstap imo. We zullen zien

[goarilla]

Aah zo. Ja misschien wel ja. Ik krijg zo een beetje het gevoel met al die containertech dat we "Shared Libraries" beu zijn. En niet meer geloven in bytecode runtimes.

[goarilla]

Ik heb mij er ook eventjes op ingelezen. En het lijkt mij heel ambitieus. Ze moeten de linux/UNIX API modulair herimplementeren en efficiente interfacecode voor de hypervisor schrijven in Ocaml.

Wijzigingen of updates? Je compileert de hele boel opnieuw en rolt je nieuwe image (met unikernel en app) uit. Je krijgt 'immutable' servers, tools als Puppet, Chef en Ansible zijn niet meer nodig.

Maar dat kan toch pas op voorwaarde dat je je data kan scheiden naar je kritieke "data servers" ?

[Rafe]

POSIX is een open en bekende standaard. Hypervisors kan je een keuze in maken welke je wel en niet ondersteund, dit lijkt de MirageOS-code voor Xen te zijn.

[Ed Vertijsment]

Wijzigingen of updates? Je compileert de hele boel opnieuw en rolt je nieuwe image (met unikernel en app) uit. Je krijgt 'immutable' servers, tools als Puppet, Chef en Ansible zijn niet meer nodig.

Volgens mij opereren deze tools op een ander niveau. In mijn eigen setup zorgt bijvoorbeeld Ansible ervoor dat de firewall + unattended upgraded geregeld zijn ennnnn...

...Docker geinstalleerd wordt + alle containers (en upstart scripts etc.). Ansible zorgt puur dat de "bare metal" in orde is (of VM) en docker start alle services daarop. Het een sluit het andere niet uit, sterker nog: ze zijn goeie vriendjes.

[Anoniem: 668730]

Een docker is "lichtgewicht" omdat het geen eigen kernel heeft. Het nadeel daarvan is dat je de kernel dan ook niet kunt optimaliseren zonder dat andere dockers daar (mogelijk negatief) door worden beinvloed. Het alternatief is dan om volwaardige VM's te gebruiken.

Dat laatste gaat echter in tegen het hele idee van Docker: het distribueren van applicaties (in de ruime zin), en niet van virtuele machines. Vanuit dat perspectief is het logisch om een "beetje" kernel mee te leveren maar er geen hele VM van te maken.

Uiteraard is het technische aspect slechts de helft van het verhaal. Het verkoopt ook gewoon beter als je iets unieks aanbied en niet een gewone VM met een docker sausje. Ik ben erg benieuwd of het uiteindelijk ook noemenswaardig iets oplevert wat performance betreft.

[NLxAROSA]

Denk dat het doel van de overname is om uiteindelijk je container rechtstreeks op de Hypervisor te deployen in plaats van op het OS. Of een 'DockerOS' oid. Grote voordeel van een unikernel, naast wat hierboven al is genoemd, is de grootte. 15-25 MB is niet uitzonderlijk. Dus rechtstreeks vanuit je build deployen op een virtuele doos. Scheelt een laag aan provisioning en het is snel.

Verbaas me zelf dat partijen als Oracle niet hetzelfde doen met Java. Nu heb je alleen dat brakke Java Cloud, wat gebaseerd is op WebLogic. Waarom niet ala JRockit rechtstreeks JVM draaien op de Hypervisor?

[Reactie gewijzigd door NLxAROSA op 24 juli 2024 09:12]

[mxcreep]

Eigenlijk zou je op een Hypervisor zowieso al niet een volledige kernel nodig hebben, het aanbod van virtuele hardware is zeer beperkt en dus zouden er veel modules weg kunnen.

[Philip J. Dijkstra]

Ik heb op een synology nas een hele vm opgetuigd voor 1 'oude' windows applicatie.
Op dit moment vraagt die vm het maximale van de nas hardware.
Synology is bezig met docker ondersteuning, het zou mooi zijn als ik straks die windows applicatie via docker kan draaien op mn nas. Ik denk dat het voor heel veel mkb met legacy applicaties een migratie vergemakkelijkt. Iedereen heeft wel van die applicaties die nog maar heel af en toe geraadpleegd moeten worden maar net niet helemaal uitgefaseerd kunnen worden.

[decide1000]

De basis is als volgt: Docker praat rechtstreeks met de kernel van een OS, bijvoorbeeld Ubuntu of CentOs. Applicaties zijn virtueel en niet afhankelijk van een besturingssysteem.

Docker kun je het beste installeren op een Debian systeem ivm compatibiliteit. Vervolgens geef je in een Dockerfile aan wat voor config je container dient te hebben. Wil je een container met Nginx? Zoek even de juiste naam/versie en je hebt hem virtueel draaien. Er kunnen dependencies zijn naar een OS. Nginx kan bijvoorbeeld vereisen dat het 'draait' op Ubuntu. In werkelijkheid gebruikt Docker de kernel waardoor niet het systeem virtueel wordt gestart. Het is dus niet zoals bij Vmware dat je een virtueel OS hebt draaien met daarop een applicatie; Je hebt echt een applicatie draaien zonder OS. Het starten van een container is dus in een fractie van een seconde gebeurt. Je hebt dus geen lack van je OS. In theorie is een virtuele applicatie altijd sneller dan een virtuele machine met OS.

Check ook vooral Google Cloud Container gebaseerd op Kubernetes. Dit werkt echt geweldig is wordt naar mijn idee de nieuwe standaard voor hosting; geen complete hostingomgevingen meer, gewoon een applicatie virtueel laten draaien op je hardware. Google is overigens een grondlegger van Docker; Google's systemen draaien al jaren op gevirtualiseerde applicaties.

[sfranken]

Docker draait hier op Fedora net zo goed als op Debian hoor. Heb je uitleg waarom je Docker het best op Debian zou kunnen draaien?

[z1rconium]

"Docker kun je het beste installeren op een Debian systeem ivm compatibiliteit."
Ontgaat je het doel van Docker ?

[decide1000]

Nee het doel ontgaat mij niet.. Docker werkt gewoon langzamer op CentOs omdat de storage langzamer werkt.

Standaard gebruikt Docker AUFS, als fallback wordt gebruik gemaakt van device mapper. CentOs gebruikt geen AUFS (omdat het geen standaard kernel functionaliteit is). Het resultaat is dat CentOs de storage altijd via de device mapper aanspreekt, wat traag is.

Overigens speelt het storage probleem op zowel RHEL als Fedora. Er is wel een workaround voor RHEL met LVM, mocht je het doel van Docker willen begrijpen.

[mxcreep]

Ik vraag me ten zeerste af of dit de toekomst is van hosting, je moet dan namelijk in elke docker omgeving je webserver, applicatie server (php/tomcat oid) en database server gaan implementeren. Elk met hun eigen geheugen gebruik etc. Vooral de db server met al zijn buffers en caches kun je moeilijk steeds kleiner maken, dat performed niet. Meer sites/applicaties die dezelfde services delen zijn toch echt nog steeds veel efficienter in resource gebruik. Ja het is makkelijker de sites/applicaties gescheiden te houden met Docker maar het zal ook een hoger prijskaartje opleveren waarvan een groot deel van de site eigenaren niet bereid is dat te betalen denk ik.

Desalnietemin zijn er zeker wel leuke toepassingen voor Docker te bedenken, het is alleen op dit moment wel goed merkbaar dat het nieuw is en dat men het nu ineens overal voor wil gebruiken.

Eens trouwens met de andere twee reakties, het is kletskoek dat je Docker het best op Debian kunt draaien. Wij draaien een RedHat OpenShift omgeving en dat is super easy uit te rollen en te managen en draait vlekkeloos. Denk dat ik minder werk heb aan 10 nieuwe hosts uitrollen en vullen met containers als jij met Debian. Niets ten nadele van Debian overigens hoor.

By the way: 'Wil je een container met Nginx? Zoek even de juiste naam/versie en je hebt hem virtueel draaien..

Nee dank je, ik maak mijn eigen templates liever, veel van die kant en klaar dingen zijn toch alles behalve goed geconfigureerd en passen zowieso vaak al niet echt in de manier van werken die we hier hanteren.

[Reactie gewijzigd door mxcreep op 24 juli 2024 09:12]

[smartbit]

Bryan Cantrill (CTO van Joyent) legt uit waarom "Unikernels are unfit for production".
Zeer aan te raden, leest goed en zette mijn gedachtes over Unikernels op z'n kop.
Woensdag geeft Docker tekst en uitleg. Ik zou hopen dat ze vooral op Bryan's verhaal ingaan. Eerste aanzet tot discussie op HN.

#ilovebryancantrill Die vent is super!

Anil Madhavapeddy was in September in Amsterdam te gast bij Software Circus.
Op de 31c3 kwam Unikernels aan de orde bij twee sessies:

• een uitstekende introductie in MirageOS met uitleg over de TLS implementatie Bij de rondvraag stelde Joanna Rutkowska van QubesOS nog een paar vragen.
• Peter Sewell legt uit dat software engineering nog in de kinderschoenen staat in de presentatie met de veelzeggende titel "Why are computers so @#!*, and what can we do about it?" Peter is professor in Cambridge waar Xen en MirageOS ontwikkeld zijn.

Xen's commerciële implementatie is verkocht aan Citrix, MirageOS's commerciële implementatie aan Docker. Opeens hebben Citrix en Docker een product uit dezelfde stal, nl. de universiteit van Cambridge. Dat kan zeer interessante synergy opleveren. Denk alleen al aan het feit dat Docker nu een Virtualisatie (VM) platform gaat ondersteunen dat een aantal grote verschillen heeft met containers oa

• security: op Linux & Windows worden containers niet zo veilig geacht als Virtualisatie.
• memory: containers kunnen dynamisch geheugen aanpassen, geheugen in VM's is veel statischer.

Het worden leuke tijden....

[Reactie gewijzigd door smartbit op 24 juli 2024 09:12]