## 🐳 De start van het [[Docker]] image-dieet: de stamboom ontrafelen met `docker history` {#sec-168deae1dd0f}
Soms lanceer je een ogenschijnlijk lichte app, maar bij het controleren van de imagegrootte zie je dat deze gemakkelijk meer dan 1 GB bedraagt. "Wat heb ik er in hemelsnaam allemaal in gestopt?" vraag je je dan verbaasd af. Dit is precies het moment waarop je de 'stamboom' van je image moet uitpluizen.

![Docker-laagdieet](/media/whitedec/blog_img/de42f6f1949c4e91bc6defa030f10ea5.webp)
## "Wat heb je gegeten om zo groot te worden?" {#sec-5eaafdc2833e}

Een Docker-image is als een ui met meerdere lagen. `docker history` is het röntgenapparaat dat deze lagen één voor één afpelt om de boosdoener te vinden.

De basisgebruik is uiterst eenvoudig:

```bash
# Basisgebruik
docker history [opties] <imagename:tag>

# Voorbeeld: de geschiedenis van mijn app controleren
docker history my-app:latest
```

Als je de opdracht uitvoert, zie je de geschiedenis van de meest recente laag tot de basisimage, in omgekeerde volgorde.

```text
IMAGE          CREATED          CREATED BY                                      SIZE
a6215f271958   5 minutes ago    /bin/sh -c #(nop)  CMD ["/bin/sh"]               0B
<missing>      7 weeks ago      /bin/sh -c #(nop) ADD file:f28242cf608f6...     7.81MB
```

Let goed op de kolom **SIZE**. Als daar honderden MB's staan waar 0B zou moeten staan, dan heb je je dieetkandidaat gevonden. Met wat ervaring zul je al snel 'verdachte plekken' herkennen.

> \*\*💡 Handige tip: `--no-trunc**  `
> 
> Standaard wordt de uitvoer afgekapt als de opdracht te lang is. Voeg de optie `--no-trunc` toe om de volledige opdracht te zien, wat essentieel is voor een nauwkeurige analyse.
> 
> `docker history --no-trunc my-app:latest`

***

## Praktijkvoorbeeld: "De boosdoener was `chown`" {#sec-036665971432}

Ik zal je een waargebeurd verhaal vertellen. Ik bouwde een projectbestand van 150 MB, maar de image bleek meer dan 300 MB te zijn. De boosdoener waren twee ogenschijnlijk onschuldige regels in de Dockerfile.

**[Inefficiënte methode: twee lagen creëren]**

```dockerfile
# 1. Bestanden kopiëren (standaard gekopieerd als root-eigenaar)
COPY . .

# 2. Eigendom wijzigen voor beveiliging (uitgevoerd als aparte opdracht)
RUN chown -R appuser:appgroup /app
```

Na het bouwen hiervan en controleren met `docker history`, kreeg ik dit resultaat:

```text
IMAGE          CREATED BY                                        SIZE
<layer_id_2>   /bin/sh -c chown -R appuser:appgroup /app         150MB  <-- (Het probleem!)
<layer_id_1>   /bin/sh -c #(nop) COPY dir:abc in /app            150MB
```

Hier komt de verraderlijke aard van Docker-lagen naar voren. Wanneer je in stap 1 een bestand van 150 MB kopieert, wordt er één laag gecreëerd. Maar wanneer je in stap 2 `chown` uitvoert, denkt Docker: "Hé, de bestandsinformatie (eigendom) is gewijzigd? Dan moet ik een nieuwe laag maken met de gewijzigde status!" en kopieert het de bestaande 150 MB opnieuw om een nieuwe laag te stapelen.

Het resultaat is dat de inhoud identiek is, maar er een dubbele opslag is van bestanden met alleen een ander eigendom, waardoor de grootte verdubbelt.

***

## De oplossing: een dieet van één regel! {#sec-b564ee91d4d9}

De oplossing is simpel: specificeer de eigenaar direct bij het kopiëren om de lagen samen te voegen tot één.

**[Efficiënte methode: één laag creëren]**

```dockerfile
# Kopiëren en tegelijkertijd het eigendom specificeren!
COPY --chown=appuser:appgroup . .
```

Als je de Dockerfile zo aanpast en `docker history` opnieuw uitvoert, zie je een dramatisch resultaat:

```text
IMAGE          CREATED BY                                               SIZE
<layer_id_1>   /bin/sh -c #(nop) COPY --chown=appuser... dir:abc       150MB
```

Zie je het? Er is slechts één laag gecreëerd en de imagegrootte is weer slank: 150 MB. Door twee commando's samen te voegen tot één, is de grootte gehalveerd.

***

## Conclusie: controleer altijd de 'geschiedenis' na het bouwen! {#sec-74645a10d229}

Vergeet niet dat een [[Docker]] image **één laag per commando** creëert.

Net zoals je code test na het schrijven, is het een goede gewoonte om na elke build `docker history --no-trunc` uit te voeren. Als je jezelf afvraagt "Waarom is deze `apt-get` zo zwaar?" of "Waarom is deze laag gesplitst?", zul je gaandeweg een zeer licht en efficiënt systeem opbouwen.

Onnodige lagen zijn immers de vijand van je systeem!

***

**Vond je dit nuttig?** Geef dan een like!

Lees ook gerelateerde artikelen.

**Gerelateerde artikelen**

[Docker gedeeld geheugen (shm_size en ipc) volledig begrijpen](/ko/whitedec/2025/11/5/docker-shm-size-ipc/)

[Docker: Communicatie tussen containers via hostpoorten zonder netwerkdeling](/ko/whitedec/2025/11/4/docker-host-port-container-communication/)

[Docker Volume kopiëren, ‘waarom’ is dat nodig?](/ko/whitedec/2025/11/10/docker-volume-copy-reason/)