docker image

Een image is een tarball met een belofte.

Die belofte luidt: draai mij, en je krijgt exact dezelfde applicatie, op elke machine die Docker trekt. Code, runtime, systeembibliotheken, instellingen — alles zit erin, bevroren in een read-only pakket dat niemand meer kan wijzigen. Niet jij, niet je collega, niet de server waar het per ongeluk terechtkomt.

Wat je wél kunt doen is er iets bovenop leggen. Een Docker image is opgebouwd uit lagen, en elke laag is het verschil met de laag eronder. Installeer je nginx, dan komt er een laag bij. Kopieer je je applicatiecode, weer een laag. Verwijder je een bestand, dan leg je een laag met een delete-markering bovenop de laag waar dat bestand nog gewoon staat.

Dat is het copy-on-write-principe, en het is de reden dat images zo efficiënt zijn. Tien images die allemaal op `alpine` draaien delen die ene basislaag. Je schijf betaalt één keer voor de basis, niet tien keer. En als je een image pulled dat je buurman al eens heeft binnengehaald, dan haalt Docker alleen de lagen binnen die jij nog niet hebt.

Onderin ligt altijd een base image: `alpine`, `ubuntu`, `debian`. Daar bouw je bovenop met een Dockerfile, waarin elke instructie een nieuwe laag oplevert. Het image zelf verandert daarna nooit meer. Wil je een beveiligingspatch, dan bouw je een nieuw image met een nieuwe laag. Het oude blijft bestaan, identificeerbaar via zijn digest, een vingerafdruk van de inhoud.

Die onveranderlijkheid is geen beperking, het is de garantie dat wat je in ontwikkeling test ook is wat er in productie draait.

Het beheer doet zich via de `docker image`-subcommando's. `docker image ls` toont wat er lokaal staat: repository, tag, image ID, grootte, aanmaakdatum. Voeg `--all` toe en je ziet ook de dangling images — verweesde lagen die overblijven na een rebuild. Ze nemen ruimte in en doen verder niets.

`docker image inspect` geeft het volledige verhaal in JSON: architectuur, besturingssysteem, de volledige laagstructuur, de `CMD` die draait zodra je een container start. Met `--format` pluk je er één veld uit, bijvoorbeeld `{{ .Size }}` als je alleen de grootte wilt weten. De uitvoer is gedetailleerd, maar als je weet waar je zoekt is het sneller dan een GUI.

`docker image history` vertelt hoe het image is ontstaan, laag voor laag. Welk commando heeft welke laag gecreëerd, wanneer, en hoe groot is die laag. Handig bij het opsporen van een image dat onnodig groot is geworden — meestal zit er een `apt-get install` zonder `clean` tussen.

Images delen doe je via een registry, publiek of privaat. Maar soms wil je een image zonder netwerk naar een andere machine brengen. `docker image save -o myapp.tar myapp:latest` pakt het image, inclusief alle lagen en tags, in één tar-bestand. Aan de andere kant haalt `docker image load -i myapp.tar` het weer binnen. Geen registry nodig, geen internet, alleen een USB-stick of een `scp`-commando.

Let op het verschil met `docker image import`. Die leest een tarball van een bestandssysteem en maakt er een image van met één enkele laag. De originele laagstructuur en geschiedenis zijn weg. Import is voor migratie van bestaande omgevingen, niet voor het overzetten van je eigen images. Daar gebruik je save en load.

Tags zijn namen, geen versies. `docker image tag myapp:latest myapp:v1.2` verandert niets aan het image, het voegt alleen een alias toe. Twee namen die naar hetzelfde image wijzen, met dezelfde image ID. Het is een handige manier om een image klaar te zetten voor een registry zonder het opnieuw te bouwen.

Een image kan meerdere architecturen tegelijk bedienen via manifesten. Eén naam, meerdere varianten: `linux/amd64` voor je server, `linux/arm64` voor die Raspberry Pi. Docker kiest bij `docker pull` automatisch de juiste variant. Je hoeft niet meer te onthouden welke architectuur waar draait.

De keuze is niet of je images gebruikt, maar hoe je ze bouwt. Een image met alles erop is makkelijk, maar groot en moeilijk te onderhouden. Een image met alleen de minimale runtime is sneller en veiliger, maar vergt dat je begrijpt wat je applicatie nodig heeft. De balans tussen gemak en controle bepaal je zelf, laag voor laag.

Wat je ook kiest, het image is het enige artefact dat de reis van je laptop naar de productieserver overleeft zonder onderweg te veranderen. Dat is geen luxe. Dat is de basis waarop je kunt vertrouwen dat wat daar draait, ook is wat jij hebt gebouwd.