Containers begrijpen

Module 9: Docker en docker compose · Leestijd: 10 minuten

Leerdoel: Na deze les kun je uitleggen wat een container is, hoe hij verschilt van een virtuele machine, waar de gegevens van een container blijven, en wanneer Docker op je server zinvol is.

Kernbegrippen: image, container, laag, registry (Docker Hub), tag, digest, namespaces, cgroups, gedeelde kernel, vluchtig bestandssysteem, volume, bind mount, poort publiceren, officieel image

Waarom containers?

Stel: je wilt op je VPS een statuspagina draaien die laat zien of je website werkt. Het programma is geschreven in Node.js, heeft een bepaalde versie daarvan nodig, plus een stuk of tweehonderd bibliotheken. Zonder containers installeer je dat allemaal op je server, naast je webserver en je database. Een jaar later wil je een tweede programma dat een andere Node.js-versie nodig heeft. Dan begint het gepuzzel.

Een container lost dat op. De maker van het programma levert het programma samen met alles wat het nodig heeft, in één pakket: een image. Op je server start je dat image als container. Het programma ziet zijn eigen bestanden, zijn eigen Node.js, zijn eigen bibliotheken, en bijt niet met de rest van je server. Weg ermee? Container weg, image weg, en er blijft niets achter in /usr of /etc.

Docker is het bekendste gereedschap om images op te halen en containers te draaien. Er zijn alternatieven (Podman, containerd zelf), maar de begrippen zijn overal hetzelfde.

Image, container en registry

Drie woorden die je steeds tegenkomt:

• Image: een alleen-lezen sjabloon met een bestandssysteem (programma, bibliotheken, instellingen) en de opdracht die moet starten. Een image is opgebouwd uit lagen: een basislaag (bijvoorbeeld een kale Debian), daarop een laag met Node.js, daarop het programma. Twee images met dezelfde basislaag delen die laag op je schijf.
• Container: een draaiend (of gestopt) exemplaar van een image. Bovenop de alleen-lezen lagen krijgt de container een eigen dunne schrijflaag. Je kunt van één image tien containers starten.
• Registry: de plek waar images staan, zoals Docker Hub (docker.io) of de registry van GitHub (ghcr.io). Docker haalt een image op met docker pull.

De naam van een image ziet er zo uit:

louislam/uptime-kuma:2
caddy:2
vaultwarden/server:latest

Het deel na de dubbele punt is de tag: een label voor een versie. Een tag kan veranderen: caddy:2 wijst vandaag naar een andere build dan over drie maanden, zodra er een nieuwe 2.x uitkomt. Wil je precies vastleggen welk image je draait, gebruik dan de digest: een vingerafdruk van de inhoud, zoals caddy@sha256:.... Die verandert nooit. De tag latest is gewoon een naam die de maker kiest; hij betekent niet automatisch "de nieuwste stabiele versie" en is daarom een slechte keuze als je wilt weten wat er draait.

Geen virtuele machine

Een container lijkt op een kleine virtuele machine, maar is het niet. Dat verschil is belangrijk voor de veiligheid.

Een container is in feite een gewoon proces op je server, dat de kernel in een afgeschermde omgeving zet:

• namespaces zorgen dat het proces zijn eigen kijk heeft op bestanden, processen, netwerk en gebruikers. In de container lijkt het programma proces nummer 1 te zijn en ziet het de rest van je server niet;
• cgroups begrenzen hoeveel processor en geheugen het mag gebruiken.

Omdat alle containers dezelfde kernel delen, is de scheiding minder streng dan tussen twee VPS'en. Een lek in de kernel of een container die te veel rechten krijgt, kan de host raken. Daarom de regels uit deze module: draai alleen images die je vertrouwt, geef containers niet meer rechten dan nodig, en mount nooit /var/run/docker.sock of / in een container (les 9.3 en 10.2).

Waar blijven je gegevens?

Dit is de klassieke valkuil voor beginners. De schrijflaag van een container is vluchtig: verwijder je de container (bijvoorbeeld bij een update, les 9.4), dan is alles wat het programma daarin schreef weg. Gegevens die moeten blijven, horen daarom buiten de container:

• Volume: een opslagplek die Docker zelf beheert (onder /var/lib/docker/volumes/). Je geeft hem een naam, bijvoorbeeld uptime-kuma, en koppelt hem aan een map in de container: -v uptime-kuma:/app/data.
• Bind mount: een gewone map op je server die je in de container hangt: -v /srv/vaultwarden:/data. Handig omdat je de bestanden direct ziet en makkelijk in je back-up (module 8) meeneemt.

Een container met goede volumes kun je weggooien en opnieuw maken zonder iets te verliezen. Dat is precies hoe updaten werkt: nieuw image ophalen, oude container weg, nieuwe container op dezelfde volumes. Zet de volumes daarom in je back-upplan (les 8.1).

Poorten publiceren

Een container heeft zijn eigen netwerk. Een webprogramma dat in de container op poort 3001 luistert, is van buiten de server niet bereikbaar, tot je die poort publiceert: -p 3001:3001 (hostpoort:containerpoort). Let op: zonder adres publiceert Docker de poort op alle adressen van je server, dus 0.0.0.0 en [::]. Dat betekent: van heel internet bereikbaar, en Docker regelt dat buiten ufw om (les 9.3). De veilige gewoonte is publiceren op loopback, -p 127.0.0.1:3001:3001, en een reverse proxy met https ervoor (les 9.4).

Wie maakt het image?

Een image is software van iemand anders die als root op je server kan draaien. Kijk daarom wie de maker is:

• Docker Official Images (zoals caddy, nginx, postgres) worden door Docker samen met de makers onderhouden;
• images van de maker zelf (zoals louislam/uptime-kuma en vaultwarden/server), herkenbaar aan de naam die de projectwebsite noemt;
• images van onbekenden met namen die erop lijken: niet gebruiken.

Gebruik altijd de naam die op de officiële website van het project staat, niet de eerste die een zoekopdracht oplevert.

Wanneer wel, wanneer niet?

Docker is handig voor programma's die de maker als image levert, voor diensten die je snel wilt kunnen weggooien of verplaatsen, en om meerdere programma's met verschillende eisen naast elkaar te draaien. Voor de basis van je server (SSH, firewall, updates) gebruik je geen containers. En een enkele website met nginx en PHP uit de pakketbron (les 7.2) werkt prima zonder Docker. Een container voegt een laag toe die je moet begrijpen en bijwerken; doe het als het iets oplevert.

Samenvatting

• Een image is een alleen-lezen sjabloon in lagen; een container is een draaiend exemplaar met een eigen schrijflaag.
• Containers delen de kernel van de host en zijn afgeschermd met namespaces en cgroups: lichter dan een VM, maar minder streng gescheiden.
• De schrijflaag is vluchtig: blijvende gegevens horen in een volume of bind mount, en die horen in je back-up.
• Een tag kan veranderen, een digest niet; latest zegt weinig.
• Publiceer poorten op 127.0.0.1 en gebruik alleen images van de maker of officiële images.

Quiz

Opdracht

Opdracht O9.1: Container of niet? Kies twee programma's die je op je server wilt draaien (of gebruik Uptime Kuma en een WordPress-site als voorbeeld). Zoek per programma op of de maker een officieel image levert en onder welke naam, welke tag je zou kiezen, welke map de blijvende gegevens bevat, en op welke poort het luistert. Leg daarna uit of je het in een container zou draaien of uit de pakketbron, en waarom.

Verder lezen

• Docker-documentatie, What is a container?: https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/
• Docker-documentatie, Volumes: https://docs.docker.com/engine/storage/volumes/
• Docker-documentatie, Port publishing and mapping: https://docs.docker.com/engine/network/port-publishing/
• Docker Official Images: https://docs.docker.com/docker-hub/repos/manage/trusted-content/official-images/