Docker layer caching in CI - Step-by-Step Execution

Process Flow - Docker layer caching in CI

Start CI Build

↓

Check Cache for Layers

↓

Reuse Layer

↓

Assemble Image

↓

Push Image & Cache

↓

End CI Build

The CI build checks if Docker image layers exist in cache. If yes, it reuses them; if not, it builds new layers, then assembles and pushes the image and cache.

Execution Sample

Docker

docker build --cache-from=myrepo/myimage:latest -t myrepo/myimage:ci .

This command builds a Docker image using cached layers from a previous image to speed up the build in CI.

Process Table

Step	Action	Cache Check	Layer Built/Reused	Result
1	Start build	N/A	N/A	Build begins
2	Check base image layer	Hit	Reused	Base layer reused from cache
3	Check dependencies layer	Hit	Reused	Dependencies layer reused from cache
4	Check application code layer	Miss	Built	New application code layer built
5	Assemble final image	N/A	N/A	Image assembled with reused and new layers
6	Push image and cache	N/A	N/A	Image and updated cache pushed to registry
7	Build complete	N/A	N/A	CI build finished successfully

💡 Build ends after pushing updated image and cache to registry

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Base Layer	Not checked	Reused	Reused	Reused	Reused
Dependencies Layer	Not checked	Not checked	Reused	Reused	Reused
App Code Layer	Not checked	Not checked	Not checked	Built	Built
Image State	Empty	Partial (base)	Partial (deps)	Partial (app)	Complete

Key Moments - 3 Insights

Why is the application code layer rebuilt even though other layers are reused?

Because the application code changed, cache for that layer missed, so it must be rebuilt (see execution_table step 4).

What happens if the cache is not available at all?

All layers will be built from scratch, making the build slower. This is not shown here but would mean all cache checks miss.

How does using --cache-from help in CI builds?

It tells Docker to use layers from a previous image as cache source, speeding up build by reusing unchanged layers (see execution_table steps 2 and 3).

Visual Quiz - 3 Questions

Look at the execution table, at which step is the application code layer built?

A Step 3

B Step 4

C Step 2

D Step 5

💡 Hint

Check the 'Layer Built/Reused' column for 'Built' status related to application code.

According to the variable tracker, what is the state of the dependencies layer after step 3?

A Reused

B Not checked

C Built

D Missing

💡 Hint

Look at the 'Dependencies Layer' row under 'After Step 3' column.

If the cache was missing for all layers, how would the execution table change?

A All 'Cache Check' would be 'Hit'

B All 'Layer Built/Reused' would be 'Reused'

C All 'Cache Check' would be 'Miss' and layers built

D No change, cache is ignored

💡 Hint

Consider what happens when cache is not found for layers in the build process.

Concept Snapshot

Docker layer caching in CI:
- Docker images build in layers.
- CI uses --cache-from to reuse layers.
- Cache hit: layer reused, speeds build.
- Cache miss: layer rebuilt.
- Push updated image to update cache.

Full Transcript

In Docker layer caching during CI builds, the process starts by checking if each image layer exists in the cache. If a layer is found (cache hit), it is reused to save time. If not found (cache miss), the layer is rebuilt. After all layers are processed, the final image is assembled and pushed to the registry along with the updated cache. This speeds up CI builds by avoiding rebuilding unchanged layers. The example command uses --cache-from to specify the cache source image. The execution table shows steps where base and dependencies layers are reused, but the application code layer is rebuilt due to changes. Variables track the state of each layer through the build. Key points include understanding why some layers rebuild and how cache-from helps reuse layers. The quiz tests understanding of when layers build or reuse and the effect of cache misses.