Docker voordelen en nadelen

Dockers zijn niet alleen handig voor systeembeheerders en webdevelopers. Iedereen die wel eens vaker software uitprobeert kan ervan profiteren. Dat geldt met name voor webapplicaties, die vaak moeizaam op te zetten zijn. Maar er zitten aan Docker voordelen en nadelen. Zoals zo vaak ligt ge- en misbruik dicht bij elkaar.

Docker lijkt uitgevonden te zijn om webdevelopers en systeembeheerders het leven makkelijker te maken. Zij kunnen van hun applicaties pakketten maken, Docker-images genoemd, die makkelijk te distribueren zijn. Die images staan in een register, bijvoorbeeld op de servers van het bedrijf Docker Inc. Daar kun je ook de lokaal draaiende Docker-daemon downloaden. Met een enkel commando start die daemon de in een image zittende software als proces in een zogeheten container. Een container gebruikt speciale technieken in het besturingssysteem die de processen sterker van elkaar scheiden dan gebruikelijk. Een container kan bijvoorbeeld een eigen netwerkkaart gebruiken en ziet geen vreemde processen of data. Een image is op zich geheel compleet en bevat alle bibliotheken die voor een applicatie nodig zijn.

Docker is al lang niet meer puur alleen voor beheerders en ontwikkelaars op Linux-gebied. Moderne NAS-apparaten kunnen Docker-images als functie-uitbreidingen gebruiken. Op een Raspberry Pi kun je het installeren van complexe software­projecten er een stuk makkelijker mee maken. Zelfs voor moderne Windows-versies stelt Micro­soft zelf Docker-images beschikbaar. Daaronder vind je containers met zowel Windows- als Linux-inhoud. Docker is op die manier steeds meer een alternatief geworden voor het inrichten en draaien van software en is in elk geval op serversystemen al een concurrent voor pakketmanagers en volledige virtualisatie.

Windows 10 kan containers als feature activeren, maar je moet Docker zelf handmatig starten. Met Linux-images is het zeker bruikbaar, maar om met Windows-images te werken moet je wel wat doorzettingsvermogen hebben.

Het gebruiksgemak is vooral groter bij applicaties die het front-end zijn van een web­server, maar niet alleen daarbij. De serverkant van dergelijke webapplicaties heeft vaak afhankelijkheden: ze vergen een webserver met een bepaalde configuratie, vallen terug op complexe frameworks en hebben daar specifieke recente versies en de bijbehorende uitbreidingen van nodig. Dat wordt bij een reguliere installatie al snel een warboel om te beheren. Een Docker-image kan dat allemaal bij elkaar voegen en beter beheersbaar maken als reproduceerbare installatie. Dankzij het ‘vercontaineren’ kunnen meerdere van dergelijke verschillende applicaties vreedzaam naast elkaar hun werk doen. Dat is een van de Docker voordelen.

De afzonderlijke componenten van dergelijke applicaties, bijvoorbeeld een benodigde database, zet je normaal gesproken niet in dezelfde image. Daar gebruik je dan een andere container voor, waarbij de containers dan via het netwerk met elkaar kunnen communiceren. Op die manier kunnen complexe bouwwerken ontstaan van onderling afhankelijke containers die tezamen een applicatie vormen. Het installeren is desondanks met een enkel commando te regelen dankzij docker-compose. Dat start en verbindt meerdere containers. Daarvoor wordt een YAML-bestand afgewerkt waarin de onderlinge afhankelijkheden beschreven staan. Dat klinkt allemaal erg mooi en handig, en is niet moeilijk om te leren.

Praktische voordelen

Aan de hand van het softwarevoorbeeld voor een Magic Mirror op de Raspberry Pi (zie c’t 10/2017) is snel te herkennen wat de benodigde stappen zijn voor het installeren van Docker. De normale installatie van het project vereist alleen al vanwege het downloaden van een shellscript veel vertrouwen, of je moet zelf allerlei stappen uitvoeren om onder meer een recente Node.js te installeren. Op het betreffende systeem laat dit sporen na die buiten de reguliere installatiemechanismes vallen. Dat zullen ervaren systeembeheerders vanwege de slechte beheersbaarheid zo veel mogelijk willen vermijden. Met Docker is het installeren niet meer dan een enkel commando. Als je de container en de image weer opruimt, zijn alle sporen uitgewist. Dat zijn belangrijke Docker voordelen.

Op de achtergrond gebeurt van alles: een container bestaat niet alleen uit de bestanden die in de image zitten, maar hij biedt ook plaats aan gebruiks- en configuratie­bestanden. Die staan normaal gesproken op apart door de Docker-­daemon beheerde volumes, die onafhankelijk bestaan van de containers. Daardoor kun je de software bijwerken met een nieuwe image, zonder dat je bang hoeft te zijn dat je de gebruiks- en configuratiebestanden verliest. Om eventuele ongelukken te voorkomen: volumes zijn veilig voor allerlei opruimprocessen zolang er minstens één container naar refereert.

Docker kan eigenlijk meer dan alleen dienen als goedkope virtualisatiemethode op een host. Het wordt vaak een bouwsteen voor de industrialisering van IT genoemd: het moet ervoor zorgen dat applicaties goed te schalen zijn doordat er bij een groeiende vraag simpelweg gewoon meer server-nodes met containers gevuld kunnen worden. Dankzij geautomatiseerde processen voor het continue samenvoegen en testen van nieuwe features, moeten ontwikkelaars en systeembeheerders beter kunnen samenwerken. Daar zijn beheertools als Kubernetes heel handig bij – voor maar een enkele image of een paar containers is dat echter overkill.

Het klinkt in eerste instantie natuurlijk geweldig dat de mogelijkheid bestaat om Docker op verschillende platforms zoals Linux, NAS-systemen en Windows te gebruiken, maar in de praktijk zitten daar wat haken en ogen aan. Docker Inc. en Microsoft hebben er aardig wat moeite in gestopt om zowel containers met Windows- als met Linux-inhoud uit te kunnen voeren (bij die laatste draait er een virtuele machine met Linux op de achtergrond). Maar het succes bij Windows-containers is matig en het beoogde gemengd gebruik wordt bemoeilijkt doordat die twee werelden op detailniveau zoveel van elkaar verschillen.

Het wordt met name lastig als het op details aankomt van de netwerkconfiguratie – dat geldt zowel voor Windows als NAS-systemen en bij IPv6 zelfs voor Linux. Docker op een Linux-host heeft verschillende manieren voor het verbinden van een container met het netwerk, waar bij Windows niet altijd een equivalent voor is. Ook NAS-fabrikanten maken er hun eigen versies van. Als een container te veel afhankelijk is van bepaalde details in de netwerkconfiguratie of het bestandssysteem (bijvoorbeeld het aanwezig zijn van ACL’s), dan werkt hij wellicht alleen onder Linux en helemaal niet op een NAS.

Op x86-NAS-systemen behoort Docker inmiddels tot de standaarduitrusting. Door aanpassingen voor het fabrikantspecifieke ecosysteem zijn al te veeleisende images echter niet bruikbaar.

Als je voor een bepaalde taak op zoek gaat naar een kant-en-klare container-image, valt dit vaak tegen. In de Docker-Hub of in de Docker-Store (de opvolger van de Hub), staan voor dezelfde software vaak meerdere honderden images. Hoe goed die zijn, kun je onder andere zien aan het aantal keer dat ze gedownload zijn. Daarnaast sponsort het bedrijf Docker Inc. een team dat ‘gecontroleerde’ images maakt van populaire software. Dat laatste garandeert een bepaalde kwaliteitsstandaard – Docker Inc. heeft het over ‘Officiële images’.

Dat betekent echter ook dat een groot deel van de images op de Docker Hub daar totaal ongecontroleerd op terechtkomt. Dat werd vanaf juli 2017 misbruikt door een gebruiker met de naam ‘docker123321’, die via Docker Hub varianten aanbood van gangbare images als mysql (doorgaans dan als docker123321/mysql). Daarbij werd een crypto-miner geïnstalleerd. Docker Hub heeft bijna een jaar ruimte geboden aan dergelijke images.

Enige argwaan is voor Docker-liefhebbers ongetwijfeld dan ook een groot goed. Zeker als je images productief wilt gaan gebruiken moet je ze heel zorgvuldig goed aan de tand voelen. Naast een aantal essentiële eisen moeten de ‘Officiële images’ ook voldoen aan allerlei andere details. Veel daarvan zijn afgestemd op het professioneel gebruik, bijvoorbeeld de voor het configureren ondersteunde technieken.

(Peter Siering, c’t magazine)