Inderdaad, met containers kan je bedrijf veel meer apps in één fysieke server stoppen dan met een virtual machine (VM). Containertechnologieën, zoals Docker, verslaan VM's op dit onderdeel van de cloud- of datacentercompetitie.

Ook nemen VM's veel systeembronnen in beslag. Ze voeren elk niet alleen een volledig exemplaar van een besturingssysteem uit, maar ook een virtuele kopie van alle hardware die het besturingssysteem nodig heeft. Dan kom je al snel op heel veel RAM- en CPU-cyclussen. Een container daarentegen hoeft alleen maar dat deel van een besturingssysteem, de ondersteunende programma's en bibliotheken en de systeembronnen te hebben dat nodig is om een specifiek programma te draaien.

Dit betekent in de praktijk dat je met een container twee à drie keer zoveel toepassingen op één server kunt zetten als met een VM.

Bovendien kun je met containers een draagbare, consistente besturingsomgeving creëren voor ontwikkeling, testen en implementatie. Dat lijkt toch een winnend drietal.

Als dit de enige verschillen waren tussen containers en virtual machines, zou ik nu een in memoriam voor VM's schrijven. Maar het gaat om meer dan alleen de vraag hoeveel apps je in een doos kunt stoppen.

Het grootste probleem met containers: beveiliging

Het grootste probleem, dat bij alle opwinding over containers vaak vergeten wordt, is de beveiliging. Daniel Walsh, een beveiligingstechnicus bij Red Hat die voornamelijk werkt met Docker en containers, zegt het zo: Containers hebben geen strakke grenzen. Neem nu Docker, deze werkt met de containertechnologie libcontainer. Om met Linux te werken heeft libcontainer toegang tot vijf naamruimten: voor proces, netwerk, koppelen, hostnaam en gedeeld geheugen (respectievelijk Process, Network, Mount, Hostname en Shared Memory). Op zich is dat prima, maar er bevinden zich heel wat belangrijke Linux-kernelsubsystemen buiten de container.

Dit zijn alle apparaten, SELinux, Cgroups en alle bestandssystemen onder /sys. Dat betekent dat als een gebruiker of toepassing binnen een container superuser-rechten heeft, het onderliggende besturingssysteem in theorie kan worden gekraakt.

En dat is echt niet goed.

Nu zijn er allerlei manieren om Docker en andere containertechnologieën te beveiligen. Je kunt bijvoorbeeld een /sys-bestandssysteem koppelen als alleen-lezen, containerprocessen dwingen alleen naar containerspecifieke bestandssystemen te schrijven en de netwerknaamruimte zo instellen dat deze alleen verbinding maakt met een opgegeven privé-intranet en dergelijke. Maar dit is allemaal niet standaard ingebouwd. Je moet er echt moeite voor doen om containers te beveiligen.

De basisregel is dat je containers net zo moet behandelen als elke andere servertoepassing. Dat doe je volgens Walsh zo:

Stop zo snel mogelijk met die toegangsrechten

Voer je services zoveel mogelijk als een niet-root-gebruiker uit

Behandel de root binnen een container alsof het een root buiten de container is

Een ander beveiligingsprobleem is dat veel mensen in een container verpakte toepassingen vrijgeven. Sommige daarvan zijn slechter dan andere. Als iemand (jij of je personeel) bijvoorbeeld de neiging heeft om, laten we zeggen, wat lui te zijn en de eerste de beste container installeert, haal je misschien wel een Trojaans paard op je server binnen. Je moet je mensen duidelijk maken dat ze niet zomaar apps van internet kunnen downloaden zoals ze met games op hun smartphone doen.

Ze moeten trouwens ook niet zomaar games downloaden, maar dat is een ander soort beveiligingsprobleem.

Andere problemen met containers

Dus als we het probleem met de beveiliging kunnen oplossen, is er toch niets mis met containers, of wel? Nou, eigenlijk wel. Er zijn met betrekking tot containers nog meer aspecten waar we aan moeten denken.

Rob Hirschfeld, CEO van RackN en lid van de raad van bestuur van de OpenStack Foundation, merkte het volgende op: "bundeling is nog steeds een risico: door een gesloten doos te maken, kun je een deel van het probleem downstream oplossen (je weet wat je hebt), maar niet upstream (je weet niet waarvan je afhankelijk bent)."

Daar zou ik aan willen toevoegen dat dit weliswaar een beveiligingsprobleem is, maar ook een kwaliteitsbewakingsprobleem. Natuurlijk, container X kan op de NGINX-webserver draaien, maar is dat wel de versie die je nodig hebt? Is hierop de TCP Load Balancing-update geïnstalleerd? Je kunt wel makkelijk een app in een container implementeren, maar als je de verkeerde installeert, verspil je uiteindelijk toch weer een heleboel tijd.

Hirschfeld wees er ook op dat een wildgroei van containers een reëel probleem kan worden. Hiermee bedoelt hij dat we ons ervan bewust moeten zijn dat het opbreken van implementaties in meerdere aparte functionele delen misschien slim is, maar dat we dan wel MEER DELEN moeten beheren. Er is een punt waarop een scheiding van zorgen overgaat in wildgroei.

Vergeet niet, bij een container ging het er juist om dat je één toepassing uitvoert. Hoe meer functionaliteit je in een container stopt, des te groter is de kans dat je beter maar meteen een virtual machine had kunnen gebruiken.

Zeker, het klopt dat sommige containertechnologieën, zoals Linux Containers (LXC), kunnen worden gebruikt als een VM. Je kunt bijvoorbeeld LXC gebruiken om voor Red Hat Enterprise Linux (RHEL) 6 bedoelde toepassingen uit te voeren in een RHEL 7-instance. Maar in het algemeen kun je containers het beste gebruiken om één toepassing uit te voeren en VM's om meerdere toepassingen uit te voeren.

De keuze: containers of VM's

Dus hoe maak je de keuze tussen VM's en containers? Scott S. Lowe, een VMware-ontwikkelingsarchitect, stelt voor om naar het bereik van je werk te kijken. Met andere woorden, als je meer exemplaren van één app, bijvoorbeeld MySQL, wilt uitvoeren gebruik je een container. Als je de flexibiliteit wilt om meerdere toepassingen uit te voeren, kies je een virtual machine.

Bovendien zit je met een container vaak vast aan een bepaalde versie van het besturingssysteem. Dat kan goed zijn: je hoeft je geen zorgen te maken over afhankelijkheden als de toepassing eenmaal goed draait in een container. Maar het beperkt je ook. Met VM's kun je, ongeacht de hypervisor die je gebruikt - KVM, Hyper-V, vSphere, Xen of wat dan ook - zo ongeveer elk besturingssysteem gebruiken. Moet je een of andere duistere app gebruiken die alleen op QNX draait? Met een VM is dat geen probleem, maar met de huidige generatie van containers is het een stuk lastiger.

Ik zal het nog eens duidelijk uitleggen.

Moet je zoveel mogelijk exemplaren van bepaalde toepassingen uitvoeren op zo weinig mogelijk servers? Dan kun je het beste containers gebruiken; maar onthoud dan wel dat je de systemen waarop de containers draaien goed in de gaten moet houden tot de containerbeveiliging is ingeschakeld.

Als je meerdere toepassingen moet uitvoeren op servers en/of allerlei verschillende besturingssystemen hebt, kun je beter VM's gebruiken. En als beveiliging vrijwel het allerhoogst op het prioriteitenlijstje van je bedrijf staat, kun je het voorlopig ook beter bij VM's houden.

In de praktijk verwacht ik dat de meesten van ons zowel containers als VM's zullen uitvoeren in onze clouds en datacenters. De financiële voordelen van grootschalige toepassing van containers zijn te interessant om te negeren. Tegelijk bieden ook VM's hun specifieke voordelen.

Ik verwacht, net als Thorsten von Eicken, CTO van enterprise cloudmanagement-bedrijf RightScale, dat wanneer de containertechnologie volwassen wordt, VM en containers samen een walhalla voor cloudportabiliteit zullen vormen. We zijn er nog niet, maar we komen er wel.

Lees ook: Deploy Kubernetes en Cloud Foundry makkelijk in je data center