Docker layer caching in CI - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the base image in a Dockerfile.

Docker

FROM [1]

Drag options to blanks, or click blank then click option'

ARUN apt-get update

Bubuntu:20.04

CCOPY . /app

DCMD ["bash"]

Attempts:

3 left

💡 Hint

Common Mistakes

Using RUN or COPY instead of a base image after FROM.

Leaving FROM instruction empty.

The FROM instruction sets the base image for the Docker build. Here, ubuntu:20.04 is a valid base image.

2fill in blank

medium

Complete the GitHub Actions step to restore Docker cache using actions/cache.

Docker

- name: Restore Docker cache
  uses: actions/cache@v3
  with:
    path: /tmp/.buildx-cache
    key: ${{ runner.os }}-docker-[1]

Drag options to blanks, or click blank then click option'

Abuildx-cache

Bdockerfile

Ccache-key

Dimage-tag

Attempts:

3 left

💡 Hint

Common Mistakes

Using unrelated strings like 'dockerfile' or 'image-tag' as cache keys.

Not including runner.os in the key for OS-specific caching.

The cache key should be unique to the build context. buildx-cache is commonly used to identify the Docker build cache.

3fill in blank

hard

Fix the error in the Docker build command to enable cache from a local directory.

Docker

docker buildx build --cache-from=type=local,src=[1] --cache-to=type=local,dest=/tmp/.buildx-cache .

Drag options to blanks, or click blank then click option'

A/tmp/.buildx-cache

B/var/lib/docker

C/cache/buildx

D/home/user/cache

Attempts:

3 left

💡 Hint

Common Mistakes

Using unrelated directories that do not contain the cache.

Mismatching cache-from and cache-to paths.

The --cache-from option should point to the directory where the cache was saved, here /tmp/.buildx-cache.

4fill in blank

hard

Fill both blanks to create a Docker build command that pushes the image and uses cache correctly.

Docker

docker buildx build --push --tag myimage:latest --cache-from=type=[1],src=/tmp/.buildx-cache --cache-to=type=[2],dest=/tmp/.buildx-cache .

Drag options to blanks, or click blank then click option'

Alocal

Bregistry

Cinline

Dgha

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing different cache types for from and to options.

Using 'registry' or 'inline' when local caching is intended.

Using local for both --cache-from and --cache-to means the cache is stored and retrieved from a local directory.

5fill in blank

hard

Fill all three blanks to define a GitHub Actions job step that builds, caches, and pushes a Docker image.

Docker

- name: Build and push Docker image
  run: |
    docker buildx build \
    --tag myapp:latest \
    --cache-from=type=[1],src=/tmp/.buildx-cache \
    --cache-to=type=[2],dest=/tmp/.buildx-cache \
    --push .
  env:
    DOCKER_BUILDKIT: [3]

Drag options to blanks, or click blank then click option'

Alocal

C1

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Using different cache types for from and to.

Forgetting to enable BuildKit by setting DOCKER_BUILDKIT=1.

The cache types for from and to are both local. Setting DOCKER_BUILDKIT to 1 enables BuildKit, which supports advanced caching.

Practice

1. What is the main purpose of Docker layer caching in Continuous Integration (CI)?

easy

A. To speed up Docker image builds by reusing unchanged layers

B. To increase the size of Docker images

C. To delete unused Docker images automatically

D. To run Docker containers faster

Solution

1. Step 1: Understand Docker layers

   Docker images are built in layers, each representing a step in the Dockerfile.

2. Step 2: Purpose of caching layers in CI

   Reusing unchanged layers avoids rebuilding them, which speeds up the build process in CI pipelines.

3. Final Answer:

   To speed up Docker image builds by reusing unchanged layers -> Option A

4. Quick Check:

   Docker layer caching = speed up builds [OK]

Hint: Caching reuses unchanged steps to build faster [OK]

Common Mistakes:

• Thinking caching deletes images
• Confusing caching with container runtime speed
• Assuming caching increases image size

2. Which Docker build command option is used to specify a cache source in a CI pipeline?

easy

A. --rm

B. --build-arg

C. --no-cache

D. --cache-from

Solution

1. Step 1: Identify cache-related options

   Docker build supports options like --cache-from to specify images to use as cache sources.

2. Step 2: Match option to cache source usage

   --cache-from tells Docker to use layers from the specified image as cache, which is essential in CI for caching.

3. Final Answer:

   --cache-from -> Option D

4. Quick Check:

   Cache source option = --cache-from [OK]

Hint: Use --cache-from to specify cache images in CI builds [OK]

Common Mistakes:

• Using --no-cache disables caching
• Confusing --build-arg with caching
• Thinking --rm affects caching

3. Given this Docker build command in a CI pipeline:

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

What happens if the base image layers have not changed since the last build?

medium

A. Docker rebuilds all layers from scratch

B. Docker uses cached layers from myrepo/myimage:latest to speed up the build

C. Docker ignores the cache and pulls a new base image

D. Docker fails with an error about missing cache

Solution

1. Step 1: Understand --cache-from behavior

   The --cache-from option allows Docker to reuse layers from the specified image if they match the current build steps.

2. Step 2: Effect when base image layers are unchanged

   If the base image layers are unchanged, Docker will reuse those cached layers, speeding up the build process.

3. Final Answer:

   Docker uses cached layers from myrepo/myimage:latest to speed up the build -> Option B

4. Quick Check:

   Unchanged layers reused = faster build [OK]

Hint: Unchanged layers reuse cache with --cache-from [OK]

Common Mistakes:

• Assuming Docker always rebuilds all layers
• Thinking cache-from pulls new images
• Expecting errors if cache is missing

4. A CI pipeline uses Docker layer caching with --cache-from, but caching is not working and builds are slow. What is the most likely cause?

medium

A. The cache image is not pushed to or pulled from the registry

B. The base image is too large

C. The Dockerfile has syntax errors

D. The Docker daemon is not running

Solution

1. Step 1: Check cache image availability

   For caching to work in CI, the cache image must be pushed to a registry and pulled before building.

2. Step 2: Identify common caching failure cause

   If the cache image is missing or not pulled, Docker cannot reuse layers, causing slow builds.

3. Final Answer:

   The cache image is not pushed to or pulled from the registry -> Option A

4. Quick Check:

   Cache image missing = no caching [OK]

Hint: Ensure cache image is pushed and pulled in CI [OK]

Common Mistakes:

• Blaming Dockerfile syntax for caching issues
• Ignoring cache image push/pull steps
• Assuming base image size affects caching directly

5. In a CI pipeline, you want to maximize Docker layer caching efficiency across multiple builds. Which approach is best?

hard

A. Use --no-cache to force fresh builds every time

B. Build images locally on the CI server without pushing

C. Push the built image to a registry and use --cache-from with that image in subsequent builds

D. Delete all images after each build to save space

Solution

1. Step 1: Understand persistent caching in CI

   To reuse cache between builds, the cache must be stored persistently, usually by pushing images to a registry.

2. Step 2: Use cache-from with pushed images

   Using --cache-from with the pushed image allows Docker to reuse layers from previous builds, speeding up future builds.

3. Final Answer:

   Push the built image to a registry and use --cache-from with that image in subsequent builds -> Option C

4. Quick Check:

   Persistent cache storage + --cache-from = efficient caching [OK]

Hint: Push images and use --cache-from for persistent caching [OK]

Common Mistakes:

• Using --no-cache disables caching
• Deleting images removes cache
• Building locally without pushing loses cache between runs