Docker Image Optimization

Learn how to optimize Docker images by using best practices to reduce image size, improve performance, and make builds more efficient.

These days, a lot of apps use Docker to run,and you probably know how it works making those containers and images. So, we're not going to talk about the very basics. Instead, this blog is going to focus on something really important: making your Docker images smaller.

Why does that matter? Well, smaller images mean they download faster. They also take up less space on your computer or server, which can save you money, smaller images usually have fewer components, which means fewer security risks. Plus, smaller images often mean they run faster, too.

In this post, I’ll show you some simple ways to make your Docker images smaller and more efficient.

1. Base Images

Before we go further, let's quickly look at how Docker images are formatted.

A Docker image is written as <image>:<tag>.

• The "image" part can be things like python, ubuntu, nodejs, etc.
• The "tag" is usually a version or a special version name, like 3.10, 3.10-slim, 3.10-buster-slim (for Python), or 21-bullseye, 21-slim (for Node.js).

Instead of always using the latest image (like python:3.10 or node:21), we can use smaller images like alpine or slim. These images are much lighter and only include the essentials needed to run the app, which helps keep things smaller and faster.

This idea applies to pretty much all images, so it’s a good habit to look for smaller alternatives whenever you can.

So instead of:

dockerfileCopy
 
  # instead of
  FROM python:3.10
 
  # We will use Alpine (smaller and more efficient)
  FROM python:3.10-alpine
 
  # or python:3.10-slim
  FROM python:3.10-alpine
 

Of course, going with the smallest image isn’t always the best choice due to potential compatibility issues. Sometimes, it can lead to installation problems or missing dependencies. In these cases, we might need to use a larger image during the build phase, and then switch to a smaller image for the runtime phase. We'll cover how to do this using multi-stage builds later on.

2. Combine and Minimize Layers

Now, let's talk about Docker layers, which are key to optimizing Docker images.

A Docker image is made up of layers, and each layer represents a change or command from your Dockerfile (like installing dependencies or copying files). Simply put, every instruction in a Dockerfile (e.g., RUN, COPY, ADD) creates a new layer. These layers are stacked on top of each other, and Docker caches them to speed up builds, so it won’t rebuild the same layer each time.

But here's the catch: too many layers can make your image larger. By combining multiple commands into a single RUN statement, you can reduce the number of layers, making the image smaller and faster to build.

For Example:

dockerfileCopy
  FROM python:3.10-alpine
 
  # Install dependencies in separate layers
  RUN pip install --upgrade pip
  RUN pip install -r requirements.txt
 
  # Copy the application to the container
  RUN mkdir /app
  RUN cp -r . /app
 
  # Set the working directory and run the app
  WORKDIR /app
  RUN python app.py

In this example, we have five layers:

1. Upgrading pip
2. Installing Python dependencies
3. Creating the /app directory
4. Copying the application files
5. Running the application (python app.py)

Now, here's the optimized version:

dockerfileCopy
 
  FROM python:3.10-alpine
 
  # Combine all setup steps into fewer layers
  RUN pip install --upgrade pip && \
      pip install -r requirements.txt && \
      mkdir /app && \
      cp -r . /app
 
  # Set the working directory and run the app in a single layer
  WORKDIR /app
  CMD ["python", "app.py"]
 

In this Dockerfile, we've combined multiple setup steps into fewer layers. Instead of creating separate layers for upgrading pip, installing dependencies, creating a directory, and copying files, we've combined all these steps into a single RUN command. This reduces the number of layers in the final image, making it smaller and faster to build.

By doing this, we optimize storage usage and improve build performance, making the overall process more efficient.

5. Leverage Caching

Docker uses a layer caching mechanism to speed up builds by reusing previously built layers when the contents of those layers haven't changed. To make the most of Docker’s caching, you should order your Dockerfile instructions strategically. This allows Docker to reuse layers that don’t change often, such as installing dependencies, and avoid rebuilding parts that are unlikely to change, like the application code.

Here's a Dockerfile example:

dockerfileCopy
  FROM python:3.10-alpine
 
  # Upgrade pip (cached unless base image or pip version changes)
  RUN pip install --upgrade pip
 
  # Install dependencies (cached unless requirements.txt changes)
  COPY requirements.txt .
  RUN pip install -r requirements.txt
 
  # Copy the application code (changes more frequently)
  COPY . /app
 
  # Set the working directory and run the app
  WORKDIR /app
  CMD ["python", "app.py"]

Explanation:

• Upgrade pip first: By upgrading pip early, Docker caches this layer, avoiding redundant upgrades in future builds.

• Install dependencies second: Installing dependencies after copying requirements.txt ensures that this layer is cached unless the dependencies change.

• Copy application code last: Since application code changes more often, copying it last avoids unnecessary rebuilds of the earlier layers.

Why This is Optimized:

• Maximizes Cache Reuse: Docker only rebuilds layers that change. With this order, only the application code is rebuilt when it changes, while pip and dependencies are cached.
• Efficient Layering: By separating the application code from the dependencies, Docker can reuse layers for faster builds, improving efficiency.

This strategy ensures faster, more efficient Docker builds by taking advantage of Docker’s caching system.

4. Use Multi-Stage Builds

As mentioned earlier, sometimes the smallest optimized image may not be sufficient, especially when certain dependencies are only needed during the build process and not at runtime. In many applications, there are build-time dependencies that help compile or prepare the application but aren’t required after the build is complete. In these cases, we can use multi-stage builds to keep the final image lean and efficient.

Multi-stage builds allow us to separate the build environment (where we install build-time dependencies) from the runtime environment (where only the application and runtime dependencies are required). This technique ensures that unnecessary build tools and dependencies aren’t included in the final image, making it smaller and more secure.

Example:

Imagine we are building a Python Flask API. We need to install some dependencies like flask and possibly other tools during the build phase, but we don’t need them in the final production environment.

Here’s how we can optimize the Dockerfile using multi-stage builds:

dockerfileCopy
 
  # Stage 1: Build stage
  FROM python:3.10 as builder
 
  # Set the working directory in the builder stage
  WORKDIR /app
 
  # Copy requirements.txt to the container and install dependencies
  COPY requirements.txt .
  RUN pip install --upgrade pip
  RUN pip install --no-cache-dir --upgrade -r requirements.txt
 
  # Copy the application source code
  COPY . .
 
  # Stage 2: Production stage
  FROM python:3.10-alpine as production
 
  # Set the working directory in the production stage
  WORKDIR /app
 
  # Copy the installed dependencies from the build stage
  COPY --from=builder /usr/local/lib/python3.10/site-packages /usr/local/lib/python3.10/site-packages
 
  # Copy the application source code from the build stage
  COPY --from=builder /app /app
 
  # Expose port 5000 for the Flask application
  EXPOSE 5000
 
  # Define the command to run the Flask application
  CMD ["python", "app.py"]
 

Explanation of the Dockerfile:

• The first stage uses the official python:3.10 image to install the required dependencies. The requirements.txt is copied to the container, and dependencies are installed using pip. After installing the dependencies, the entire application source code is copied into the container. This stage is primarily responsible for setting up the application environment and ensuring all dependencies are ready.

• The second stage uses the smaller python:3.10-alpine image to run the Python application. This image is much lighter, as it doesn't contain the build tools or dependencies that are only necessary during the build stage. It copies the installed dependencies and the application source code from the previous stage to create a more optimized production environment.

This multi-stage build approach ensures that only the necessary runtime artifacts (such as the installed dependencies and application code) are included in the final image, while the build dependencies are excluded. As a result, the final image remains minimal, optimized for production, and faster to deploy.

5. Remove Unnecessary Files

In some cases, we might unintentionally copy unnecessary files or folders into our Docker image. For example, in the previous Dockerfile, we used COPY . . to copy everything from the local directory to the Docker container. This can accidentally include temporary files or folders like .git, node_modules, .venv, or files created for debugging purposes that are not needed in the final image.

To avoid this, we can create a .dockerignore file to explicitly exclude these files and folders from being copied into the container. This ensures that only the necessary files are included in the Docker image, keeping it smaller and more efficient.

Here’s an example of a .dockerignore file:

gitignoreCopy
  .venv
  node_modules
  .git
  *.log

This .dockerignore file tells Docker to ignore certain files and directories, such as virtual environments (.venv), log files (*.log), Git metadata (.git), and node_modules. By doing so, we prevent unnecessary or sensitive files from being copied into the Docker image, helping reduce the image size and improve security.

6. Use Tools Like Docker Slim or Dive

To further optimize your Docker images, you can use tools like Docker Slim or Dive. These tools help you inspect, analyze, and optimize Docker images.

• Docker Slim: This tool automatically reduces the size of your Docker images by removing files and dependencies that aren't needed. It helps make your image much smaller without breaking your app.

• Dive: Dive lets you see the size of each layer in your Docker image. It shows you a breakdown of your image so you can find areas where you can improve or remove things that aren't necessary.

By using these tools, you can easily spot files or layers that are taking up space and clean them up. This helps make your Docker images even smaller and faster to work with.

Conclusion

In this post, we went over some key steps to help reduce and optimize your Docker images. By following these practices, you can make your images smaller, more efficient, and quicker to build and deploy. There are plenty of other ways to optimize further, but these steps should give you a solid start.

Optimizing Docker images not only boosts app performance but also saves on resources, improves security, and speeds up deployment.