Reducing final image size by 80 percent in Docker - Deep Dive

Overview - Reducing final image size by 80 percent

What is it?

Reducing the final image size means making your Docker container images much smaller. This helps them download faster, use less storage, and start quicker. It involves techniques like choosing smaller base images, cleaning up unnecessary files, and using multi-stage builds. Smaller images are easier to share and deploy.

Why it matters

Without reducing image size, Docker images can become very large, causing slow downloads and wasting storage. This slows down development, testing, and deployment, especially in cloud or limited bandwidth environments. Smaller images save time and money, making software delivery smoother and more efficient.

Where it fits

Before learning this, you should understand basic Docker concepts like images, containers, and Dockerfiles. After mastering image size reduction, you can explore advanced Docker optimizations, container security, and orchestration with Kubernetes.

Mental Model

Core Idea

A Docker image is like a packed suitcase, and reducing its size means packing only what you truly need to travel light and move fast.

Think of it like...

Imagine packing for a trip: if you bring everything you own, your suitcase is heavy and hard to carry. But if you pack only essentials, your suitcase is light, easy to carry, and you can move quickly. Docker images work the same way.

┌─────────────────────────────┐
│       Docker Image           │
│ ┌───────────────┐           │
│ │ Base Image    │           │
│ ├───────────────┤           │
│ │ Application   │           │
│ │ Dependencies  │           │
│ └───────────────┘           │
│                             │
│  ↓ Remove unused files       │
│  ↓ Use smaller base images   │
│  ↓ Multi-stage builds        │
│                             │
│ ┌───────────────┐           │
│ │ Smaller Image │           │
│ └───────────────┘           │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Docker Image Basics

Concept: Learn what a Docker image is and what it contains.

A Docker image is a snapshot of a filesystem with your app and everything it needs to run. It includes a base operating system layer, your application code, and any libraries or tools your app requires. Images are built using Dockerfiles, which list instructions to assemble the image step-by-step.

Result

You know that images are layered filesystems containing all app dependencies.

Understanding that images are layered helps you see why removing or optimizing layers reduces size.

2

Foundation

Why Image Size Affects Performance

Concept: Learn how image size impacts download, storage, and startup speed.

Large images take longer to download and use more disk space. This slows down starting containers and increases cloud storage costs. Smaller images start faster and save bandwidth, making development and deployment more efficient.

Result

You realize that smaller images improve speed and reduce resource use.

Knowing the real-world impact of image size motivates optimizing your Dockerfiles.

3

Intermediate

Choosing Minimal Base Images

🤔Before reading on: do you think using a full OS base image or a minimal base image results in smaller final images? Commit to your answer.

Concept: Using smaller base images reduces the starting size of your Docker image.

Instead of using large base images like ubuntu or centos, use minimal ones like alpine or scratch. Alpine is a tiny Linux distribution with only essential packages. Scratch is an empty image, letting you add only what you need. This drastically cuts image size.

Result

Your image size drops significantly by starting with a smaller base.

Understanding base image choice is key because it forms the foundation of your image size.

4

Intermediate

Cleaning Up Unnecessary Files

🤔Before reading on: do you think leftover package manager caches and temporary files increase or decrease image size? Commit to your answer.

Concept: Removing temporary files and caches during image build reduces final size.

When installing packages, package managers often leave caches or temp files. If you don't delete them, they stay in the image. Use commands like 'apt-get clean' or 'rm -rf /var/lib/apt/lists/*' after installing. Also, delete build tools or docs not needed at runtime.

Result

The image size shrinks by removing files not needed after build.

Knowing to clean up during build prevents hidden bloat that silently inflates images.

5

Intermediate

Using Multi-Stage Builds

🤔Before reading on: do you think building and running your app in the same image is more or less efficient than using multi-stage builds? Commit to your answer.

Concept: Multi-stage builds let you compile or build in one stage, then copy only the final app to a smaller image.

In a multi-stage Dockerfile, the first stage contains all build tools and dependencies. After building, you copy only the necessary output (like a binary) to a clean, minimal base image in the final stage. This removes all build-time files from the final image.

Result

Final images are much smaller because they contain only runtime essentials.

Understanding multi-stage builds unlocks powerful size reduction by separating build and runtime environments.

6

Advanced

Minimizing Layers and Combining Commands

🤔Before reading on: do you think combining multiple RUN commands into one affects image size? Commit to your answer.

Concept: Each Dockerfile instruction creates a new layer; combining commands reduces layers and size.

Docker images are built in layers. Each RUN, COPY, or ADD creates a new layer. If you install packages in one RUN command and clean caches in another, the cache files remain in the earlier layer. Combining commands with '&&' lets you install and clean in one layer, reducing size.

Result

Images have fewer layers and less leftover data, making them smaller.

Knowing how layers work helps you write Dockerfiles that avoid hidden bloat.

7

Expert

Advanced Tricks: Using Scratch and Distroless

🤔Before reading on: do you think using scratch or distroless images requires more or less manual setup? Commit to your answer.

Concept: Scratch and distroless images are ultra-minimal but need careful app preparation.

Scratch is an empty image with no OS, so you must include all dependencies your app needs. Distroless images contain only your app and its runtime dependencies without package managers or shells. They reduce attack surface and size but require static binaries or careful dependency management.

Result

Final images can be tiny and secure but need advanced setup.

Understanding these ultra-minimal images reveals trade-offs between size, security, and complexity.

Under the Hood

Docker images are built as layers stacked on each other. Each Dockerfile instruction creates a new layer that stores changes like added files or installed packages. When you build an image, Docker caches these layers. The final image size is the sum of all layers. Cleaning files in a later layer does not remove them from earlier layers, so combining commands or using multi-stage builds avoids leftover data. Multi-stage builds create temporary images for building, then copy only needed artifacts to the final image, leaving build dependencies behind.

Why designed this way?

Docker uses layered images to speed up builds and downloads by reusing unchanged layers. This design balances efficiency and flexibility. Multi-stage builds were introduced to separate build and runtime environments, solving the problem of large images caused by leftover build tools. Minimal base images like alpine and scratch exist to give developers control over size and security, trading off convenience for leaner images.

┌───────────────┐
│ Dockerfile    │
├───────────────┤
│ RUN apt-get   │
│ install ...   │
├───────────────┤
│ RUN rm cache  │
├───────────────┤
│ COPY app      │
└───────────────┘
       ↓
┌───────────────┐
│ Layer 1: OS   │
├───────────────┤
│ Layer 2: apt  │
│ packages     │
├───────────────┤
│ Layer 3: rm   │
│ cache files  │
├───────────────┤
│ Layer 4: app │
└───────────────┘

Note: cache files remain in Layer 2 despite removal in Layer 3.

Multi-stage build:
Stage 1: Build with tools
Stage 2: Copy only final app
Final image: minimal layers, no build tools.

Myth Busters - 4 Common Misconceptions

Quick: Does deleting files in a later Dockerfile layer remove them from the final image? Commit yes or no.

Common Belief: Deleting files in a later layer completely removes them from the final image.

Reality: Files deleted in a later layer still exist in earlier layers, so they remain in the final image and do not reduce size.

Why it matters: This misunderstanding leads to images larger than expected, wasting storage and bandwidth.

Quick: Is using the 'latest' tag for base images always safe for small image sizes? Commit yes or no.

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

Reality: 'Latest' can point to large or unstable images; it may increase size or cause build inconsistencies.

Why it matters: Relying on 'latest' can cause unexpected image bloat and unpredictable builds.

Quick: Do multi-stage builds always make images smaller regardless of how you use them? Commit yes or no.

Common Belief: Any use of multi-stage builds automatically reduces image size.

Reality: If you copy unnecessary files or don't clean build artifacts, multi-stage builds won't reduce size effectively.

Why it matters: Misusing multi-stage builds can give a false sense of optimization while images remain large.

Quick: Can you always use scratch base images for any application without changes? Commit yes or no.

Common Belief: Scratch images work out-of-the-box for all apps and reduce image size drastically.

Reality: Scratch requires static binaries and no OS dependencies; many apps need modification to run on scratch.

Why it matters: Trying to use scratch without preparation leads to broken containers and wasted effort.

Expert Zone

1

Layer caching can cause unexpected large images if intermediate files are not cleaned in the same RUN command.

2

Using distroless images improves security by removing shells and package managers, reducing attack surface beyond just size.

3

Combining multi-stage builds with build cache optimizations can speed up CI/CD pipelines while keeping images small.

When NOT to use

Avoid minimal base images like alpine or scratch if your app depends on complex OS features or dynamic libraries. In such cases, use standard base images or container slimming tools like Docker Slim. Also, multi-stage builds add complexity and may not be needed for simple apps.

Production Patterns

In production, teams use multi-stage builds to separate build and runtime, choose alpine or distroless bases for security and size, and automate image scanning for vulnerabilities. CI pipelines often cache layers to speed builds while enforcing size limits to control costs.

Connections

Software Packaging

Both involve bundling only necessary components to reduce size and improve portability.

Understanding how software packages include dependencies helps grasp why Docker images should be minimal and clean.

Supply Chain Management

Reducing image size is like optimizing supply chains to remove waste and improve delivery speed.

Knowing supply chain principles clarifies why removing unnecessary parts speeds up software delivery.

Minimalism in Design

Both focus on keeping only essential elements to improve efficiency and user experience.

Appreciating minimalism helps understand the value of lean Docker images for faster, cleaner deployments.

Common Pitfalls

#1 Leaving package manager caches in the image increases size unnecessarily.

Wrong approach:

RUN apt-get update && apt-get install -y curl

Correct approach:

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

Root cause:

Not cleaning caches after installation leaves large temporary files in image layers.

#2 Using multiple RUN commands for install and cleanup creates extra layers with leftover data.

Wrong approach:

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

Correct approach:

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

Root cause:

Each RUN creates a layer; cleanup in a separate layer does not remove files from previous layers.

#3 Copying entire build directory in multi-stage builds instead of only needed files bloats final image.

Wrong approach:

COPY --from=builder /app /app

Correct approach:

COPY --from=builder /app/myapp-binary /app/myapp-binary

Root cause:

Copying unnecessary files from build stage adds unwanted data to final image.

Key Takeaways

Docker images are built in layers; each instruction adds size that can accumulate if not managed.

Choosing minimal base images and cleaning up during build drastically reduces final image size.

Multi-stage builds separate build and runtime environments, allowing only essential files in the final image.

Combining commands in Dockerfiles prevents leftover files in intermediate layers, keeping images lean.

Ultra-minimal images like scratch and distroless offer smallest sizes but require advanced preparation.