“Installeer een Linux-virtuele machine en bouw exact dezelfde omgeving na.”
Drie maanden nadat ik bij het bedrijf was begonnen, hing er een onrustige sfeer op kantoor. De enige senior developer van het team was overgeplaatst naar een ander project en had het zo druk met zijn eigen spullen inpakken dat er nauwelijks sprake was van overdracht, terwijl de teamlead al lang was afgehaakt van de dagelijkse ontwikkelpraktijk en behoorlijk ver afstond van recente technologische trends.
Op een dag riep de teamlead me bij zich. “Als je senior weg is, ben jij de enige die nog de servers kan beheren. Zelfs als de server eruit ligt, moet je hem zelfstandig kunnen herstellen. Installeer Linux als virtuele machine, VM, op je huidige ontwikkellaptop, Windows, en probeer precies dezelfde omgeving op te bouwen als op de productie-server.”
Vanaf die dag begon mijn geploeter. Ik installeerde VMware, downloadde het Ubuntu-ISO-bestand, en alleen dat installeren kostte me al een halve dag. Ik groef door de bedrijfswiki om Java, Node.js en PostgreSQL te installeren. Ik dacht: “Nieuw is vast beter,” dus ik installeerde Java 17, maar ontdekte vervolgens dat de legacy-code nog van Java 8 uitging en niet eens wilde builden. Dus moest ik alles verwijderen en opnieuw installeren. Telkens als ik één regel code veranderde, moest ik mvn build draaien, het jar-bestand naar de VM verplaatsen en het daar uitvoeren. Het was pure ellende.
Toen schoot er ineens een vraag door mijn hoofd. “Wacht even. De vorige keer dat we naar productie deployden, was het toch gewoon klaar na één enkele docker service update-opdracht?”
Mijn lokale virtuele machine was zó zwaar en vereiste een berg aan configuratie, dus wat was dat ding genaamd Docker op de productie-server eigenlijk, dat een update met maar één opdracht kon afhandelen?
De zware oplossing: de virtuele machine
De aanpak die mijn teamlead mij opdroeg, Linux bovenop Windows installeren, is precies wat een virtuele machine, VM, is. Het is alsof je een compleet ‘virtueel huis’, een guest OS, bouwt boven op een fysieke computer, de host.
- Werkwijze: je draait meerdere besturingssystemen op één computer. Linux bovenop Windows, en daar weer Linux bovenop…
- Probleem: om een huis te bouwen moet je alles opnieuw neerzetten, van de pilaren en muren tot en met de badkamer, de kernel.
- Om één app te draaien moet je een compleet OS van meerdere gigabytes installeren.
- Opstarten duurt een eeuwigheid. Precies daarom werd mijn laptop zo traag.
- Het gaat inefficiënt om met resources. Zelfs als het niets doet, slokt het geheugen op, alleen al om het OS draaiende te houden.
Uiteindelijk isoleert een VM de omgeving wel degelijk betrouwbaar, maar voor ontwikkeling of deployment is ze simpelweg te zwaar en te traag om telkens heen en weer te blijven verplaatsen.
De lichte revolutie: Docker
Daarom verscheen Docker, oftewel containertechnologie. Docker bouwt niet een volledig huis zoals een VM dat doet. In plaats daarvan zet het een tent op.
- Werkwijze: het deelt de tuin, oftewel de kernel, van een huis dat er al staat: het host-OS, Linux. Er wordt alleen een geïsoleerde tent opgezet, de container.
- Kenmerken:
- Het deelt het OS, de kernel: in de tent zit geen zwaar OS. Er zitten alleen mijn app en de bijbehorende libraries in.
- Licht: de omvang wordt uitgedrukt in megabytes, MB.
- Snel: opstarten? Dat bestaat hier niet. Een container gaat net zo snel aan als één proces, in milliseconden.
De update-opdracht die ik op de productie-server uitvoerde, installeerde dus geen zwaar besturingssysteem opnieuw. Ze deed alleen maar “de oude tent afbreken en een nieuwe tent opzetten met de nieuwe versie van de code erin.” Natuurlijk kon dat alleen maar razendsnel klaar zijn.
[Code Verification] Is Docker echt zo licht?
Laten we niet alleen maar zeggen dat Docker licht is, maar het ook echt controleren. Als het doel is om een Linux-, Ubuntu-, omgeving te draaien, dan is het verschil tussen een VM en Docker enorm.
- Ubuntu draaien met een VM: ISO-bestand van 2GB downloaden -> 20 minuten installeren -> 1 minuut opstarten.
- Ubuntu draaien met Docker:
# Ubuntu draaien via Docker (image wordt gedownload indien nodig)
$ docker run -it ubuntu:latest /bin/bash
Resultaat:
- Download: ongeveer 30MB, een uitgeklede image met alleen de kern van Ubuntu.
- Starttijd: ongeveer 0,5 seconde.
Op het moment dat ik op Enter drukte, zat ik al in een Ubuntu-omgeving. Dat is mogelijk omdat een Docker-container geen echt besturingssysteem is. Het is slechts “een geïsoleerde ruimte die de kernel van het host-OS, mijn computer, leent terwijl het doet alsof het een apart OS is.”
Praktisch advies: de echte reden om Docker te gebruiken
Sinds we Docker op het werk hebben ingevoerd, is mijn leven compleet veranderd.
- “Richt je omgeving in” bestaat niet meer: vroeger kreeg een nieuwe collega een document van tien A4-vellen met “Installeer Java, stel de omgevingsvariabelen in, zet de DB erop…”. Nu zeg ik gewoon: “Installeer Docker en typ
docker-compose up.” - Ontsnappen uit de versiehel: wat als project A Java 8 nodig heeft en project B Java 17? Installeer je ze allebei lokaal, dan botsen ze en raakt alles in de knoop. Met Docker stop je Java 8 in container A en Java 17 in container B, en kun je ze zonder enig probleem tegelijk draaien. Ze zijn namelijk volledig van elkaar ‘geïsoleerd’, oftewel isolation.
Tot slot: we leveren geen uitvoerbaar bestand, maar een omgeving
Met de komst van Docker is het ontwikkelparadigma veranderd. We sturen niet langer alleen broncode, .java, naar de server. We vriezen ook de OS-instellingen, libraries en omgevingsvariabelen die die code nodig heeft in als één ‘image’ en versturen het hele pakket.
Maar hoe wordt deze magische ‘Docker image’ eigenlijk gemaakt? Is het gewoon een gecomprimeerd bestand? Verrassend genoeg blijkt een Docker image uit meerdere lagen, layers, opgestapeld te zijn, net als een taart.
Laten we de volgende keer het geheim achter Dockers efficiëntie uitpluizen: images en hun gelaagde structuur.
