Why Reducing final image size by 80 percent in Docker? - Purpose & Use Cases

The Big Idea

What if your Docker images could be 80% smaller without losing anything important?

The Scenario

Imagine you build a Docker image for your app, but it ends up huge--several gigabytes. You try to share it, but it takes forever to upload and download. Your cloud storage costs rise, and deployments slow down.

The Problem

Manually trimming down images means hunting through layers, removing unused files, and tweaking configurations by hand. This is slow, error-prone, and often misses hidden bloat. You waste time and still get bulky images.

The Solution

By learning how to reduce final image size by 80 percent, you use smart techniques like multi-stage builds and minimal base images. This cuts unnecessary parts automatically, making your images small, fast, and easy to manage.

Before vs After

✗ Before

FROM ubuntu
RUN apt-get update && apt-get install -y python3
COPY . /app
CMD ["python3", "/app/app.py"]

✓ After

FROM python:3.12-slim
WORKDIR /app
COPY . /app
CMD ["python3", "app.py"]

What It Enables

Smaller images mean faster downloads, quicker deployments, and lower costs--making your DevOps workflow smooth and efficient.

Real Life Example

A startup reduced their Docker image from 1.5GB to 300MB, cutting deployment time from 10 minutes to under 2 minutes, speeding up their release cycles dramatically.

Key Takeaways

Manual image management is slow and error-prone.

Reducing image size uses smart Docker features to cut bloat.

Smaller images speed up deployment and save resources.

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