Reducing final image size by 80 percent in Docker - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the Dockerfile line to use a smaller base image.

Docker

FROM [1]

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

Aalpine:latest

Bubuntu:latest

Cdebian:latest

Dcentos:latest

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing a full Linux distribution like Ubuntu increases image size.

Using CentOS or Debian also results in larger images.

Using alpine:latest as the base image reduces the image size significantly because Alpine is a minimal Linux distribution.

2fill in blank

medium

Complete the command to remove unnecessary package cache after installation.

Docker

RUN apk add --no-cache curl && rm -rf [1]

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

A/tmp

B/usr/local/bin

C/var/cache/apk/*

D/etc/apk

Attempts:

3 left

💡 Hint

Common Mistakes

Removing /usr/local/bin deletes installed binaries.

Removing /etc/apk breaks package management.

Removing /tmp may not affect package cache.

Removing /var/cache/apk/* clears the package cache, reducing image size.

3fill in blank

hard

Fix the error in the Dockerfile line to reduce layers by combining commands.

Docker

RUN apk add curl \
    && [1] /var/cache/apk/*

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

Acp -r

Bmkdir

Ctouch

Drm -rf

Attempts:

3 left

💡 Hint

Common Mistakes

Using mkdir or cp does not remove files.

touch only creates empty files.

Using rm -rf removes the cache in the same layer, reducing final image size.

4fill in blank

hard

Fill both blanks to create a multi-stage Dockerfile that copies only the final binary.

Docker

FROM golang:1.20-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o [1] .

FROM alpine:latest
COPY --from=builder /app/[2] /usr/local/bin/
CMD ["[3]"]

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

Aapp

Bmain

Attempts:

3 left

💡 Hint

Common Mistakes

Using different names for the binary causes copy errors.

CMD not matching the binary name causes runtime errors.

The binary is named main in the build step and copied from the builder stage. The command runs main.

5fill in blank

hard

Fill all three blanks to create a Dockerfile that cleans up build tools and reduces image size.

Docker

FROM node:18-alpine AS build
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
RUN npm run build

FROM alpine:latest
RUN apk add --no-cache [1]
COPY --from=build /app/dist /app
CMD ["[2]", "[3]"]

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

Anodejs

Bnpm

Cnode

Dserve

Eindex.js

Attempts:

3 left

💡 Hint

Common Mistakes

Installing npm in the final image increases size unnecessarily.

CMD not matching the app entry point causes failure.

The final image installs only node to run the app. The CMD runs serve index.js to start the app.

Practice

1. What is the main benefit of using multi-stage builds in Docker to reduce image size?

easy

A. It allows copying only necessary files to the final image, reducing size.

B. It speeds up the build process by running all commands in one stage.

C. It automatically compresses the image layers without manual steps.

D. It enables running multiple containers from one image simultaneously.

Solution

1. Step 1: Understand multi-stage builds purpose

   Multi-stage builds let you use one stage to build your app and another to create a smaller final image.

2. Step 2: Identify how size is reduced

   By copying only the needed files from the build stage to the final stage, unnecessary build tools and files are excluded.

3. Final Answer:

   It allows copying only necessary files to the final image, reducing size. -> Option A

4. Quick Check:

   Multi-stage builds copy only needed files [OK]

Hint: Remember: multi-stage copies only needed files [OK]

Common Mistakes:

• Thinking multi-stage speeds up build time
• Assuming multi-stage compresses layers automatically
• Confusing multi-stage with running multiple containers

2. Which Dockerfile syntax correctly starts a multi-stage build with a small final image?

easy

A. FROM node:18-slim
RUN npm install
COPY /app /app

B. FROM node:18-slim AS build
RUN npm install
FROM node:18
COPY --from=build /app /app

C. FROM node:18
RUN npm install
COPY /app /app

D. FROM node:18 AS build
RUN npm install
FROM node:18-slim
COPY --from=build /app /app

Solution

1. Step 1: Identify multi-stage build syntax

   Multi-stage builds use 'AS' to name stages and 'COPY --from=stage' to copy files.

2. Step 2: Check base images for build and final stages

   FROM node:18 AS build RUN npm install FROM node:18-slim COPY --from=build /app /app uses full node image for build and smaller node:18-slim for final, which reduces size.

3. Final Answer:

   FROM node:18 AS build RUN npm install FROM node:18-slim COPY --from=build /app /app -> Option D

4. Quick Check:

   Correct multi-stage syntax with smaller final image [OK]

Hint: Use 'AS' to name build stage and copy from it [OK]

Common Mistakes:

• Not using 'AS' to name build stage
• Using larger base image in final stage
• Copying files without specifying source stage

3. Given this Dockerfile snippet, what will be the approximate size difference between the final image and the build stage image?

FROM golang:1.20 AS build
WORKDIR /app
COPY . .
RUN go build -o myapp
FROM alpine:latest
COPY --from=build /app/myapp /myapp
CMD ["/myapp"]

medium

A. Final image is about 80% smaller than the build image.

B. Final image is larger than the build image.

C. Final image and build image are about the same size.

D. Final image is about 20% smaller than the build image.

Solution

1. Step 1: Analyze base images used

   The build stage uses golang:1.20 (large image with build tools), final uses alpine (very small).

2. Step 2: Understand what is copied to final image

   Only the compiled binary is copied, excluding all build dependencies, drastically reducing size.

3. Final Answer:

   Final image is about 80% smaller than the build image. -> Option A

4. Quick Check:

   Copying only binary to alpine reduces size ~80% [OK]

Hint: Copy only binary to tiny base image for big size drop [OK]

Common Mistakes:

• Assuming final image includes build tools
• Thinking final image is bigger due to alpine
• Believing size difference is minimal

4. You wrote this Dockerfile to reduce image size but the final image is still large:

FROM python:3.12 AS build
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
FROM python:3.12
COPY --from=build /app /app
CMD ["python", "/app/app.py"]

What is the main issue causing the large final image?

medium

A. You forgot to run pip install in the final stage.

B. The final stage uses the full python:3.12 image instead of a smaller base.

C. COPY command syntax is incorrect and copies nothing.

D. The requirements.txt file is missing in the build stage.

Solution

1. Step 1: Check base images in build and final stages

   Both stages use python:3.12, which is a large image; no size reduction from multi-stage.

2. Step 2: Identify how to reduce size

   Using a smaller base like python:3.12-slim or alpine in the final stage reduces image size significantly.

3. Final Answer:

   The final stage uses the full python:3.12 image instead of a smaller base. -> Option B

4. Quick Check:

   Final stage base image too large [OK]

Hint: Use smaller base image in final stage to shrink size [OK]

Common Mistakes:

• Thinking pip install must run in final stage
• Assuming COPY syntax is wrong
• Believing requirements.txt missing causes large image

5. You want to reduce your Docker image size by 80%. Your app requires Node.js to build but only needs the compiled files to run. Which Dockerfile approach best achieves this?

hard

A. Use multi-stage build: first stage with node:alpine to build, second stage with node:latest to run.

B. Use a single stage with node:latest and delete node_modules after build.

C. Use multi-stage build: first stage with full node image to build, second stage with node:alpine copying only build output.

D. Use a single stage with node:alpine and install build tools at runtime.

Solution

1. Step 1: Understand build and runtime needs

   Building requires full Node.js image with tools; running only needs compiled files and a small base.

2. Step 2: Choose multi-stage build with appropriate images

   First stage uses full node image to build; second stage uses smaller node:alpine image copying only build output to reduce size.

3. Final Answer:

   Use multi-stage build: first stage with full node image to build, second stage with node:alpine copying only build output. -> Option C

4. Quick Check:

   Multi-stage with full build image and small runtime image [OK]

Hint: Build with full image, run with small image copying only output [OK]

Common Mistakes:

• Using single stage and deleting files later
• Building on small image lacking tools
• Running on large image unnecessarily