Reducing image size strategies in Docker - Deep Dive

Overview - Reducing image size strategies

What is it?

Reducing image size strategies are methods used to make Docker container images smaller. Smaller images use less disk space, download faster, and start quicker. These strategies involve choosing lightweight base images, cleaning up unnecessary files, and optimizing layers. The goal is to create efficient images that run well in production.

Why it matters

Without reducing image size, containers become bulky and slow to deploy, wasting bandwidth and storage. Large images increase startup time and resource use, which can slow down development and production environments. Smaller images improve speed, reduce costs, and make scaling easier, especially in cloud or resource-limited setups.

Where it fits

Learners should know basic Docker concepts like images, containers, and Dockerfiles before this. After mastering image size reduction, they can explore advanced Docker optimizations, multi-stage builds, and container security best practices.

Mental Model

Core Idea

A Docker image is like a layered sandwich, and reducing its size means choosing thinner, fewer, and cleaner layers.

Think of it like...

Imagine packing a suitcase for a trip: packing only what you need, folding clothes tightly, and using smaller containers saves space and makes travel easier.

┌───────────────┐
│ Final Image   │
├───────────────┤
│ Layer 3: App  │
├───────────────┤
│ Layer 2: Libs │
├───────────────┤
│ Layer 1: Base │
└───────────────┘

Smaller layers = smaller image

Build-Up - 6 Steps

1

Foundation

Understanding Docker Image Layers

Concept: Docker images are made of layers stacked on top of each other, each adding files or changes.

Each command in a Dockerfile creates a new layer. Layers are cached and reused to speed up builds. But each layer adds size to the final image. Knowing this helps us see why fewer and smaller layers reduce image size.

Result

You see that a Docker image is not one big file but many layers combined.

Understanding layers is key because image size depends on how many layers and how big each is.

2

Foundation

Choosing Lightweight Base Images

Concept: The base image is the starting point for your Docker image and greatly affects its size.

Common base images like 'ubuntu' or 'debian' are large because they include many tools. Alternatives like 'alpine' are tiny because they include only essentials. Using a smaller base image reduces the starting size of your image.

Result

Your image starts smaller, saving space and download time.

Choosing the right base image is the easiest way to reduce image size from the start.

3

Intermediate

Cleaning Up Temporary Files and Cache

🤔Before reading on: do you think deleting files in one Dockerfile command reduces image size more than deleting them in separate commands? Commit to your answer.

Concept: Removing unnecessary files like package caches or build tools after installation keeps the image lean.

When you install software, temporary files and caches are created. If you delete them in a separate Dockerfile command, the layer with those files still exists, keeping the image large. Instead, delete them in the same command to avoid adding extra size.

Result

The final image does not include temporary files, making it smaller.

Knowing how layers work prevents common mistakes that keep unwanted files in the image.

4

Intermediate

Using Multi-Stage Builds for Optimization

🤔Before reading on: do you think multi-stage builds increase or decrease final image size? Commit to your answer.

Concept: Multi-stage builds let you use one image to build your app and another smaller image to run it, copying only needed files.

You can have a build stage with all tools to compile your app, then a final stage with just the runtime and app files. This avoids including build tools and source code in the final image.

Result

The final image is much smaller and contains only what is needed to run.

Multi-stage builds separate concerns and remove build-time clutter from the final image.

5

Advanced

Minimizing Layers and Combining Commands

🤔Before reading on: do you think combining many commands into one Dockerfile RUN instruction reduces image size? Commit to your answer.

Concept: Each Dockerfile command creates a new layer, so combining commands reduces the number of layers and total size.

Instead of multiple RUN commands, combine them with '&&' so all changes happen in one layer. This reduces overhead and removes intermediate files in the same layer.

Result

Fewer layers and smaller image size.

Layer count affects image size; fewer layers mean less overhead and cleaner images.

6

Expert

Advanced Image Compression and Custom Base Images

🤔Before reading on: do you think customizing a base image always saves space compared to official images? Commit to your answer.

Concept: Experts create custom minimal base images or use advanced compression to push size reduction further.

Custom base images include only the bare minimum libraries and tools needed. Also, image formats like Docker's 'zstd' compression reduce size on disk and transfer. These techniques require deep knowledge but yield the smallest images.

Result

Ultra-small images optimized for specific applications and environments.

Going beyond defaults unlocks maximum efficiency but requires careful tradeoffs and maintenance.

Under the Hood

Docker images are stored as a series of read-only layers stacked together. Each layer represents changes from a Dockerfile command. When building, Docker caches layers to speed up rebuilds. The final image size is the sum of all layer sizes. Layers are immutable; deleting files in a later layer does not remove them from earlier layers, so careful command grouping is needed to truly reduce size.

Why designed this way?

Layered images allow caching and reuse, speeding up builds and downloads. This design balances efficiency and flexibility. Alternatives like single monolithic images would be slower to build and update. The tradeoff is that careless layering can increase image size, so best practices evolved to manage this.

┌───────────────┐
│ Final Image   │
├───────────────┤
│ Layer N: App  │
├───────────────┤
│ Layer N-1: Lib│
├───────────────┤
│ Layer 1: Base │
└───────────────┘

Each layer is read-only and stacked.
Deleting files in Layer N does not remove them from Layer N-1.

Myth Busters - 4 Common Misconceptions

Quick: Does deleting files in a later Dockerfile command reduce the final image size? Commit yes or no.

Common Belief: Deleting files in any Dockerfile command removes them from the final image.

Reality: Deleting files in a later layer only adds a new layer that removes files logically, but earlier layers still contain those files, so the image size does not shrink.

Why it matters: This causes images to be larger than expected, wasting space and bandwidth.

Quick: Is the 'latest' tag always the smallest and most efficient Docker image? Commit yes or no.

Common Belief: Using the 'latest' tag ensures you get the smallest and most optimized image.

Reality: 'Latest' often points to a full-featured image that may be large; smaller tags or specific versions like 'alpine' are usually smaller.

Why it matters: Blindly using 'latest' can lead to unnecessarily large images and slower deployments.

Quick: Does combining many RUN commands always make the image smaller? Commit yes or no.

Common Belief: More RUN commands mean smaller images because changes are isolated.

Reality: More RUN commands create more layers, increasing image size overhead; combining commands reduces layers and size.

Why it matters: Misunderstanding this leads to bloated images and slower builds.

Quick: Can multi-stage builds include unnecessary build tools in the final image? Commit yes or no.

Common Belief: Multi-stage builds always remove build tools from the final image.

Reality: If not carefully configured, build tools can be copied into the final stage, increasing size.

Why it matters: Assuming multi-stage builds automatically optimize size can cause hidden bloat.

Expert Zone

1

Some base images labeled 'minimal' still include unnecessary libraries; verifying contents is essential.

2

Layer caching can cause stale files to persist if Dockerfile commands are not ordered properly.

3

Using 'scratch' as a base image requires manually adding all dependencies, which is powerful but complex.

When NOT to use

Reducing image size aggressively is not always best when debugging or developing locally; full images with tools are easier to troubleshoot. In such cases, use development images and switch to slim images only for production.

Production Patterns

Real-world systems use multi-stage builds with Alpine base images, combine RUN commands carefully, and automate image scanning to detect unnecessary files. CI pipelines often build both debug and slim images for different environments.

Connections

Software Packaging

Both involve bundling only necessary components for deployment.

Understanding how software packages exclude unnecessary files helps grasp why Docker images should be minimal.

Supply Chain Logistics

Reducing image size is like optimizing shipment weight and volume to save cost and time.

Knowing logistics principles clarifies why smaller images speed up delivery and reduce resource use.

Data Compression Algorithms

Image compression uses similar principles to data compression to reduce size without losing content.

Understanding compression helps appreciate advanced image size reduction techniques.

Common Pitfalls

#1 Deleting temporary files in separate Dockerfile commands.

Wrong approach:

RUN apt-get update && apt-get install -y build-essential
RUN rm -rf /var/lib/apt/lists/*

Correct approach:

RUN apt-get update && apt-get install -y build-essential && rm -rf /var/lib/apt/lists/*

Root cause:

Misunderstanding that each RUN creates a new layer, so deleting files in a separate layer does not reduce previous layer size.

#2 Using large base images without need.

Wrong approach:

FROM ubuntu:20.04

Correct approach:

FROM alpine:3.18

Root cause:

Not considering the base image size impact on the final image.

#3 Copying build tools into final image in multi-stage builds.

Wrong approach:

FROM builder AS build
RUN make all
FROM alpine
COPY --from=build /usr/bin/myapp /usr/bin/myapp
COPY --from=build /usr/bin/gcc /usr/bin/gcc

Correct approach:

FROM builder AS build
RUN make all
FROM alpine
COPY --from=build /usr/bin/myapp /usr/bin/myapp

Root cause:

Not carefully selecting files to copy from build stage, accidentally including build tools.

Key Takeaways

Docker images are built in layers; each command adds a layer that affects size.

Choosing a small base image like Alpine drastically reduces starting image size.

Combining commands and cleaning up temporary files in the same layer prevents leftover data from bloating images.

Multi-stage builds separate build and runtime environments, producing smaller final images.

Advanced users create custom base images and use compression to push size reduction further, but this requires careful tradeoffs.