Een van de duurste zinnen in IT is "het werkt op mijn machine". Software die bij de ene persoon draait en bij de andere crasht, kost uren aan zoeken naar het verschil — een andere versie van een programmeertaal, een ontbrekende instelling, een besturingssysteem dat net iets anders reageert. Docker maakt dat probleem grotendeels overbodig: je verpakt een applicatie samen met haar volledige omgeving, zodat ze overal exact hetzelfde draait — van je eigen laptop tot een server bij een hostingpartij. Dit is het principe "reproduceerbaar denken" uit de eerste les, nu gegoten in concrete tooling.

Container versus virtuele machine

De kern is de container: een geïsoleerd proces dat draait bovenop een gedeelde kernel van het besturingssysteem. Dit is lichter dan een volledige virtuele machine, omdat een container niet een compleet eigen besturingssysteem hoeft op te starten — hij deelt de kernel van de host en start daardoor in seconden in plaats van minuten. Een virtuele machine simuleert complete hardware en draait een volledig eigen besturingssysteem erbovenop; dat is zwaarder, maar biedt ook een sterkere isolatie. Voor de meeste MKB-toepassingen (een website, een klein intern dashboard, een testomgeving) is een container ruim voldoende en veel efficiënter met resources.

Een container wordt gestart vanuit een image: een onveranderlijke sjabloon met alles wat de applicatie nodig heeft — code, runtime, bibliotheken en configuratie. De image is dus de blauwdruk; de container is de draaiende instantie ervan. Je kunt van dezelfde image tien containers tegelijk starten, elk in hun eigen geïsoleerde omgeving, zonder dat ze elkaar beïnvloeden.

De Dockerfile: het recept voor een image

Hoe een image eruitziet, beschrijf je in een Dockerfile. Daarin zet je in een paar declaratieve instructies de basisimage, de benodigde onderdelen, de bouwstappen en het commando dat bij opstarten wordt uitgevoerd. Een minimale Dockerfile voor een simpele webpagina met de webserver nginx ziet er bijvoorbeeld zo uit:

FROM nginx:alpine
COPY ./html /usr/share/nginx/html
EXPOSE 80

Deze drie regels zeggen: begin met de officiële, lichte nginx-image, kopieer je eigen HTML-bestanden naar de juiste map, en maak poort 80 beschikbaar. Uit dit recept bouw je vervolgens een image met docker build -t mijn-website ., en die image kun je overal starten waar Docker draait — jouw laptop, een collega's laptop, of een server bij een hostingpartij — met exact hetzelfde resultaat.

Werk je met meerdere onderdelen tegelijk — bijvoorbeeld een webapp, een database en een reverse proxy — dan gebruik je een docker-compose.yml om die containers samen te orkestreren: opstartvolgorde, netwerkverbindingen en configuratie in één bestand, zodat je met één commando (docker compose up) de hele stack start.

Data die blijft bestaan: volumes

Een container is standaard vergankelijk: stop je hem en verwijder je hem, dan verdwijnt alles wat erin is opgeslagen. Voor een webserver zonder eigen data is dat geen probleem, maar voor een database met klantgegevens is dat onaanvaardbaar. Daarvoor bestaan volumes: opslag die buiten de levenscyclus van de container blijft bestaan. Je koppelt een map op de host (of een door Docker beheerd volume) aan een map in de container, zodat de data overleeft ook als de container wordt vervangen door een nieuwere versie.

Poorten bereikbaar maken: port mapping

Een container draait standaard geïsoleerd — ook zijn netwerkpoorten zijn niet automatisch vanaf de buitenwereld bereikbaar. Met port mapping maak je een poort binnen de container bereikbaar op de host. Het commando docker run -p 8080:80 mijn-website start de container van hierboven en koppelt poort 80 in de container aan poort 8080 op je eigen machine — open je daarna http://localhost:8080 in je browser, dan zie je de website die in de container draait.

De vier kernbegrippen samengevat

• Image — alleen-lezen sjabloon met code, runtime, bibliotheken en configuratie.
• Dockerfile — bouwinstructies (FROM, COPY, RUN, CMD, EXPOSE) om een image te bouwen.
• Volume — opslag die los staat van de levenscyclus van een container, voor data die moet blijven bestaan.
• Orchestratie — het gecoördineerd beheren van meerdere containers tegelijk, bijvoorbeeld via docker-compose.

Samenvatting en verder lezen

Docker verpakt een applicatie met haar volledige omgeving in een reproduceerbare image, zodat "het werkt op mijn machine" verandert in "het werkt overal waar Docker draait". Containers zijn lichter dan virtuele machines omdat ze de kernel van de host delen, en volumes zorgen dat belangrijke data niet verdwijnt zodra een container stopt. In de volgende les bouwen we hierop voort met webbeveiliging: hoe zorg je dat wat je in een container publiceert ook veilig bereikbaar is.

Verder lezen: de officiële documentatie op docs.docker.com bevat een heldere "Get Started"-gids; voor MKB-gebruik is ook de officiële Docker Hub (hub.docker.com) de moeite waard om te verkennen — daar vind je kant-en-klare, officieel onderhouden images voor veelgebruikte software.