Reducing final image size by 80 percent in Docker - Commands & Configuration

Introduction

Large Docker images take longer to download and use more storage. Reducing the image size by 80 percent helps apps start faster and saves space on servers.

When you want your app to start quickly on any machine.

When you have limited storage on your server or cloud.

When you want to reduce data transfer time during deployments.

When you want to keep your Docker images clean and efficient.

When you want to avoid including unnecessary files or tools in your app image.

Config File - Dockerfile

Dockerfile

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

This Dockerfile uses a slim Python base image to keep the size small.

It installs only required packages without caching to avoid extra files.

It copies only necessary files into the image.

The CMD runs the Python app.

Commands

Builds the Docker image using the Dockerfile that reduces size by using a slim base and no cache during install.

Terminal

docker build -t my-app:small .

Expected Output

Sending build context to Docker daemon  5.12MB

Step 1/5 : FROM python:3.11-slim

 ---> 123abc456def

Step 2/5 : WORKDIR /app

 ---> Using cache

 ---> 789def012abc

Step 3/5 : COPY requirements.txt .

 ---> Using cache

 ---> 345abc678def

Step 4/5 : RUN pip install --no-cache-dir -r requirements.txt

 ---> Running in 456def789abc

Collecting flask

Installing collected packages: flask

Successfully installed flask-2.3.2

Removing intermediate container 456def789abc

 ---> 901abc234def

Step 5/5 : COPY . .

 ---> 567def890abc

Successfully built 567def890abc

Successfully tagged my-app:small

→

-t - Names the image for easy reference

Shows the size of the newly built small image to verify the reduction.

Terminal

docker images my-app:small

Expected Output

REPOSITORY   TAG       IMAGE ID       CREATED          SIZE

my-app       small     567def890abc   10 seconds ago   45MB

Runs the small image to confirm the app works correctly after size reduction.

Terminal

docker run --rm my-app:small

Expected Output

 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

→

--rm - Automatically removes the container after it stops

Key Concept

If you remember nothing else from this pattern, remember: use slim base images and avoid caching to drastically reduce Docker image size.

Common Mistakes

Using a full base image like python:3.11 instead of python:3.11-slim

Full base images include unnecessary tools and files, making the image much larger.

Use slim or alpine base images that contain only essential components.

Not using --no-cache-dir when installing packages

Pip caches installation files inside the image, increasing size unnecessarily.

Add --no-cache-dir flag to pip install commands to avoid caching.

Copying the entire project including unnecessary files like docs or tests

Unneeded files increase image size and slow down builds.

Use .dockerignore to exclude unnecessary files or copy only needed files explicitly.

Summary

Use a slim base image to start with a smaller foundation.

Install packages without cache to avoid extra files in the image.

Copy only necessary files to keep the image clean and small.

Verify image size with docker images command.

Run the image to ensure the app still works after size reduction.

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