Overzicht

Bij het bouwen van Docker-images komt het vaak voor dat de grootte onbedoeld toeneemt. De meeste oorzaken zijn te vinden in onlangs gecreëerde layers. Dit artikel deelt mijn optimalisatie-ervaring bij het gebruik van de docker history opdracht om de 'stamboom' van een image te verifiëren en zo de echte image te verlichten.

Met deze opdracht kunt u precies achterhalen wat een image zwaarder maakt en een efficiëntere image maken.

docker history: Controleer de stamboom van een image

docker history is een opdracht die toont hoe een bepaalde image is opgebouwd en welke componenten zijn inbegrepen. U kunt zien welke layers zijn opgebouwd door de verschillende opdrachten in de Dockerfile, evenals het tijdstip van creatie en de grootte van elke layer.

De basisgebruik is heel eenvoudig.

docker history [opties] <image naam:tag>

Bijvoorbeeld, de opdracht om de geschiedenis van de lokale my-app:latest image te controleren is als volgt:

docker history my-app:latest

De uitvoer toont de bovenste layer (de nieuwste) tot aan de basis image (de oudste) in volgorde.

IMAGE          GECREËERD      GECREËERD DOOR                                  GROTE
a6215f271958   5 minuten geleden  /bin/sh -c #(nop)  CMD ["/bin/sh"]        0B
<missing>      7 weken geleden  /bin/sh -c #(nop) ADD file:f28242cf608f6...   7.81MB

  • GECREËERD DOOR: De Dockerfile-opdracht die deze layer heeft gecreëerd

  • GROTE: De grootte van deze layer

Nuttige tip: Bekijk de volledige opdracht met --no-trunc

De standaard uitvoer van docker history wordt afgekapt als de opdracht van de GECREËERD DOOR kolom te lang is. Wanneer u de --no-trunc optie gebruikt, kunt u de volledige opdracht zonder afkapping bekijken, wat essentieel is voor nauwkeurige analyse.

docker history --no-trunc my-app:latest

Waarom layer-analyse belangrijk is: Echte optimalisatie-ervaring

Het basisprincipe van Docker-images is dat er één layer per regel in de Dockerfile wordt gemaakt. Elke layer is een 'wijziging' bovenop de vorige layer.

Het probleem is dat als layers onnodig worden gesplitst, de image-grootte aanzienlijk kan toenemen.

Voorbeeld: De valkuil van COPY en RUN chown

Bij het schrijven van een Dockerfile komt het vaak voor dat projectbestanden worden gekopieerd (COPY) naar de container, gevolgd door het wijzigen van de eigendom naar een specifieke gebruiker (bijv. appuser) met RUN chown.

On efficiënte methode: 2 layers

Oorspronkelijk schreef ik de Dockerfile als volgt:

# 1. Kopieer de bestanden eerst (gekopieerd als root)
COPY . .

# 2. Wijzig de eigendom (uitgevoerd als aparte opdracht)
RUN chown -R appuser:appgroup /app

Bij het controleren van de geschiedenis van de gebouwde image met docker history, bleken er twee layers te zijn aangemaakt.

IMAGE          GECREËERD DOOR                                   GROTE
<layer_id_2>   /bin/sh -c chown -R appuser:appgroup /app        150MB  <-- (probleem!)
<layer_id_1>   /bin/sh -c #(nop) COPY dir:abc in /app           150MB

Hier ontstaat een ernstig probleem.

  1. De bestanden van 150MB zijn toegevoegd aan layer 1 via het COPY . . commando.

  2. Het RUN chown commando kopieert de 150MB bestanden van layer 1 opnieuw en wijzigt alleen de eigendomsinformatie, wat resulteert in layer 2.

Hoewel de inhoud van de bestanden identiek is, zijn ze opgeslagen in verschillende layers met verschillende eigenaars: root en appuser. Dit resulteert in een totaal image-afmetingen van 300MB (150MB + 150MB).

Efficiënte methode: 1 layer

Dit probleem kan eenvoudig worden opgelost door de --chown vlag bij het COPY commando te gebruiken.

# 1. Kopieer en geef de eigendom aan
COPY --chown=appuser:appgroup . .

Na het aanpassen van de Dockerfile controleerde ik opnieuw met docker history.

IMAGE          GECREËERD DOOR                                       GROTE
<layer_id_1>   /bin/sh -c #(nop) COPY --chown=appuser... dir:abc   150MB

Er is slechts één layer gecreëerd en de totale grootte van de image is verminderd tot 150MB. Het was eenvoudigweg het combineren van twee regels in één dat leidde tot bijna de helft van de image-grootte.

Conclusie

docker history is meer dan alleen een weergave van de creatiegeschiedenis van een image; het is een sleutelanalyse-instrument voor image-optimalisatie.

Na het aanpassen van de Dockerfile is het een goede gewoonte om docker history --no-trunc uit te voeren om te controleren of de layers zijn gemaakt zoals bedoeld en of er onnodige layers zijn die ruimte innemen. Deze kleine gewoonte kan bijdragen aan het creëren van lichtere en efficiëntere images.