Optimizing Docker Image Size: Practical Experience for Faster, Lighter Applications

Which Method is Most Suitable?

Through practical experience, I’ve found that there’s no single “silver bullet.” The most effective approach is to combine the methods above. For most applications, I typically apply the following strategy:

1. Always prioritize Multi-stage Builds: This is the foundation for compact and secure images.
2. Use compact Base Images in the runtime stage: Combine Multi-stage builds with base images like -slim or Alpine (if the application doesn’t have complex dependencies).
3. Optimize Layers and clean up files: Thoroughly apply .dockerignore and always clean up the cache immediately after package installation.
4. Activate BuildKit: To speed up builds and leverage advanced features.

Detailed Implementation Guide

Let’s look at a practical example for a Python application to see the difference:

Suboptimal Dockerfile (for comparison)

A simple, easy-to-write Dockerfile, but it will create a rather large image:

# SUBOPTIMAL: Build and Run in the same stage, using a large base image
FROM python:3.9

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

EXPOSE 8000

CMD ["python", "app.py"]

The image created from this Dockerfile will include all build tools (compiler, headers…) and temporary pip files, significantly increasing its size.

Optimized Dockerfile with Multi-stage Build and -slim Base Image

This is the method I typically use for Python applications in production:

# Stage 1: Build environment
FROM python:3.9-slim-buster as builder

# Set up working directory
WORKDIR /app

# Copy requirements file and install dependencies
# Use --no-cache-dir so pip doesn't store cache, helping reduce layer size
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy application source code (after dependencies are installed)
COPY . .

# Stage 2: Runtime environment
# Contains only what's necessary to run the application
FROM python:3.9-slim-buster

WORKDIR /app

# Copy installed dependencies and source code from 'builder' stage
COPY --from=builder /usr/local/lib/python3.9/site-packages /usr/local/lib/python3.9/site-packages
COPY --from=builder /app /app

EXPOSE 8000

# Command to start the application
CMD ["python", "app.py"]

In the example above, the builder stage installs Python packages. Subsequently, the runtime stage only copies the installed packages and application source code into a clean python:3.9-slim-buster image. The final image size will be significantly smaller.

Using .dockerignore

Create a file named .dockerignore at the same level as your Dockerfile. This file’s content will list the files/directories Docker should ignore when building:

# Ignore Python virtual environment
venv/

# Ignore .git directory
.git/

# Ignore cache files and compiled files
__pycache__/
*.pyc
*.egg-info/

# Ignore environment configuration files
.env
.DS_Store

# Ignore other files and directories not needed for runtime
docs/
tests/

This ensures that unnecessary files are not included in the build context, helping to reduce image size and speed up builds.

Combine RUN commands and clean up cache

When installing system packages, combine apt-get commands and clean up the cache immediately within the same RUN instruction:

# Combine commands and clean up cache immediately
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        build-essential \
        curl \
        git && \
    rm -rf /var/lib/apt/lists/* && \
    apt-get clean

The commands rm -rf /var/lib/apt/lists/* and apt-get clean are crucial for removing package manager metadata, significantly reducing layer size.

Experience and Advice from Production Reality

Optimizing Docker images is a continuous process. After 6 months of deploying applications in production with Docker, I realized that monitoring and fine-tuning Dockerfiles are essential.

A point I was particularly pleased with during this process was when I transitioned my entire stack from Docker Compose v1 to v2, and the process was quite smooth. With improvements in performance and syntax, Docker Compose v2 (now a Docker CLI plugin) has helped me manage multi-container services more efficiently, especially when working with optimized images. The startup and update speeds of services have noticeably improved.

Remember, a small image isn’t just about disk space. It’s also about security (fewer components, fewer potential vulnerabilities) and performance (faster builds, quicker deployments, less resource consumption). Treat your Dockerfile as a critical part of your application’s source code and dedicate time to optimizing it.

I hope these practical insights will help you feel more confident in optimizing your Docker images!