docker-image
Een image is een tarball met een belofte.
Die belofte luidt: draai mij, en u 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 u, niet uw collega, niet de server waar het per ongeluk terechtkomt.
Wat u 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. Installeert u nginx, dan komt er een laag bij. Kopieert u uw applicatiecode, weer een laag. Verwijdert u een bestand, dan legt u 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. Uw schijf betaalt één keer voor de basis, niet tien keer. En als u een image pulled dat uw buurman al eens heeft binnengehaald, dan haalt Docker alleen de lagen binnen die u nog niet hebt.
Onderin ligt altijd een base image: `alpine`, `ubuntu`, `debian`. Daar bouwt u bovenop met een Dockerfile, waarin elke instructie een nieuwe laag oplevert. Het image zelf verandert daarna nooit meer. Wilt u een beveiligingspatch, dan bouwt u 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 u in ontwikkeling test ook is wat er in productie draait.
Het beheer doet u via de `docker image`-subcommando's. `docker image ls` toont wat er lokaal staat: repository, tag, image ID, grootte, aanmaakdatum. Voegt u `--all` toe en u 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 u een container start. Met `--format` plukt u er één veld uit, bijvoorbeeld `{{ .Size }}` als u alleen de grootte wilt weten. De uitvoer is gedetailleerd, maar als u weet waar u 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 deelt u via een registry, publiek of privaat. Maar soms wilt u 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 uw eigen images. Daarvoor gebruikt u 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 uw server, `linux/arm64` voor die Raspberry Pi. Docker kiest bij `docker pull` automatisch de juiste variant. U hoeft niet meer te onthouden welke architectuur waar draait.
De keuze is niet of u images gebruikt, maar hoe u 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 u begrijpt wat uw applicatie nodig heeft. De balans tussen gemak en controle bepaalt u zelf, laag voor laag.
Wat u ook kiest, het image is het enige artefact dat de reis van uw laptop naar de productieserver overleeft zonder onderweg te veranderen. Dat is geen luxe. Dat is de basis waarop u kunt vertrouwen dat wat daar draait, ook is wat u hebt gebouwd.