Reducing final image size by 80 percent in Docker - Step-by-Step Execution

Process Flow - Reducing final image size by 80 percent

Start with large base image

↓

Use smaller base image

↓

Remove unnecessary files

↓

Use multi-stage builds

↓

Copy only needed artifacts

↓

Build final smaller image

↓

Done

This flow shows how to reduce Docker image size by choosing smaller bases, cleaning files, and using multi-stage builds.

Execution Sample

Docker

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

A simple Dockerfile using a slim Python base image to reduce image size.

Process Table

Step	Action	Image Size Impact	Resulting Image Size
1	Start with python:3.12 full image	Large base image (~900MB)	900MB
2	Switch to python:3.12-slim base image	Smaller base (~150MB)	150MB
3	Remove cache and temp files after install	Reduce ~20MB	130MB
4	Use multi-stage build to copy only needed files	Remove build dependencies (~50MB)	80MB
5	Final image built with only runtime files	Final cleanup	80MB

💡 Final image size reduced from 900MB to 80MB (~80% reduction)

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Image Size (MB)	900	150	130	80	80

Key Moments - 3 Insights

Why does switching to a slim base image reduce size so much?

Because the slim base removes many unnecessary tools and files, as shown in step 2 of the execution_table where size drops from 900MB to 150MB.

How does multi-stage build help reduce image size?

Multi-stage builds let you copy only the final needed files, removing build tools and dependencies, as seen in step 4 where size drops from 130MB to 80MB.

Why remove cache and temp files after installing packages?

Removing cache frees up space that package managers use temporarily, reducing image size as shown in step 3.

Visual Quiz - 3 Questions

Look at the execution_table, what is the image size after switching to the slim base image?

A 150MB

B 900MB

C 80MB

D 130MB

💡 Hint

Check the 'After Step 2' row in variable_tracker or step 2 in execution_table.

At which step does the image size first drop below 100MB?

A Step 3

B Step 4

C Step 2

D Step 1

💡 Hint

Look at the 'Resulting Image Size' column in execution_table.

If you skip removing cache files after install, how would the image size after step 3 change?

A It would be smaller than 80MB

B It would increase to 900MB

C It would stay at 150MB

D It would be exactly 130MB

💡 Hint

Refer to step 3 in execution_table where removing cache reduces size from 150MB to 130MB.

Concept Snapshot

Docker image size can be reduced by:
- Using smaller base images like 'slim'
- Removing cache and temp files after installs
- Using multi-stage builds to copy only needed files
- Cleaning up unnecessary dependencies
This can reduce image size by around 80%.

Full Transcript

This lesson shows how to reduce Docker image size by starting with a large base image and switching to a smaller slim base. Then, removing cache and temporary files after package installation further reduces size. Using multi-stage builds copies only necessary files into the final image, removing build dependencies. Step by step, the image size drops from 900MB to 80MB, an 80% reduction. Key points include why slim images are smaller, how multi-stage builds help, and why cleaning cache matters. Visual quizzes test understanding of size changes at each step.

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