Docker-images bygges i lag — hver Dockerfile-instruktion opretter et lag, og Docker cacher lag for at fremskynde genbygninger. At forstå lag og caching er nøglen til at skrive effektive Dockerfiles, der bygges hurtigt og producerer mindre images.
Lag — hver instruktion tilføjer et lag
Each Dockerfile instruction (FROM, RUN, COPY, etc.) creates a read-only LAYER:
→ layers stack to form the image; layers are CACHED and SHARED between images
→ if a layer is unchanged, Docker REUSES the cached layer (skips rebuilding it)
→ Layer caching makes rebuilds fast — only changed layers (and those AFTER) rebuild.
Caching-reglen (rækkefølgen betyder noget)
Docker caches layers IN ORDER. When an instruction's input changes, that layer AND
ALL layers AFTER IT are rebuilt (cache invalidated from that point down).
→ Put STABLE things EARLY and FREQUENTLY-CHANGING things LATE in the Dockerfile.
Den klassiske optimering: afhængigheder før kode
# ✅ GOOD — copy dependency manifest first, install, THEN copy code
COPY package*.json ./
RUN npm install # this layer is cached UNLESS package.json changes
COPY . . # code changes here don't invalidate the npm install layer
# ❌ BAD — copy everything first
COPY . . # ANY code change invalidates...
RUN npm install # ...so npm install RE-RUNS on every code change (slow!)
Ved at kopiere afhængighedsfiler og installere før du kopierer resten af koden, forbliver det (langsomme) afhængigheds-installeringslag cachelagret på tværs af kodeændringer — en enormt vigtig optimering, der gør genbygninger hurtige.
Reduktion af image-størrelse
✓ Combine related RUN commands (fewer layers) and clean up in the SAME layer
RUN apt-get update && apt-get install -y x && rm -rf /var/lib/apt/lists/*
✓ Use small base images (alpine, slim, distroless)
✓ Use .dockerignore to exclude unneeded files from the build context
✓ Use multi-stage builds (build artifacts in one stage, copy only what's needed)
Hvorfor det betyder noget
At forstå Docker-lag og build-caching er vigtigt for at skrive effektive Dockerfiles, der bygges hurtigt og producerer mindre images, så det er værdifuld praktisk viden, der significerelt påvirker udviklerproduktivitet og deployment.
Fundamentalkonceptet — hver Dockerfile-instruktion opretter et cachelagret, genanvendeligt lag, og Docker genbruger uændrede cachelagre, mens det genbygger ændrede lag og alt efter dem — forklarer, hvordan man laver hurtige bygninger.
Caching-reglen (cache invalideres fra den første ændrede instruktion og nedefter, så rækkefølgen betyder noget: stabile ting først, ofte-ændrede ting sidst) driver den eneste vigtigste optimering: at kopiere afhængighedsfiler og installere afhængigheder før du kopierer applikationskode, så det langsomme afhængigheds-installeringslag forbliver cachelagret på tværs af hyppige kodeændringer (i stedet for at køre npm install/pip install ved hver kodeændring — forskellen mellem hurtige og pinefuldt langsomme genbygninger).
At forstå alene dette mønster forbedrer byggetider dramatisk, som er en konstant udvikler-oplevelse-bekymring.
At kende teknikker til at reducere image-størrelse — kombinere RUN-kommandoer med oprydning i samme lag, bruge små basis-images (alpine, slim, distroless), .dockerignore til at udelukke unødvendige filer, og multi-stage builds — producerer mindre, hurtigere-at-deploye images (reducerer lagerplads, overførselstid og angrebsflade).
Da Docker-bygninger sker konstant (i udvikling og CI/CD) og langsomme bygninger eller oppustede images skader produktivitet og deployment, og da det at forstå lag og caching er det, der muliggør at skrive Dockerfiles, der bygges hurtigt og forbliver små, er det at forstå Docker-lag og build-caching — lag-modellen, den ordre-afhængige caching-regel, optimering af afhængigheder-før-kode, og størrelses-redukteknikker — værdifuld, ofte-anvendt viden for effektiv Docker-brug, en nøglefærdighed, der skelner dem, der skriver hurtige, slanke Dockerfiles, fra dem, der lider under langsomme bygninger og oppustede images.