Solution : Docker Images taking huge space

Reducing Docker / Container Image Disk Usage

If a Docker (or container) image is occupying a large amount of disk space, there are several strategies you can take, depending on whether you’re trying to free space or prevent it in the future.

1️⃣ Remove Unused or Dangling Images

Docker and container runtimes store layers, and sometimes old images accumulate.

# List all images
docker images

# Remove a specific image
docker rmi <image-name>:<tag>

# Remove dangling (unused) images
docker image prune

# Remove all unused images, containers, volumes
docker system prune -a 

-a deletes all unused images, not just dangling ones. Be careful if other containers rely on them. 

 

 

2️⃣ Remove Unused Containers and Volumes

Sometimes disk is consumed by stopped containers or unused volumes.

# List all containers
docker ps -a

# Remove stopped containers
docker container prune

# Remove unused volumes
docker volume prune

 

3️⃣ Use Smaller Base Images

Large images often come from heavy OS layers like ubuntu or debian. Use slim or minimal images like alpine (~5 MB) when possible:

 # Instead of
FROM ubuntu:22.04

# Use
FROM alpine:3.18

 

This reduces the image size dramatically. 

 

4️⃣ Multi-stage Builds

Build your app in one stage and copy only the needed artifacts to a smaller final image.

 # Build stage
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Final stage
FROM alpine:3.18
COPY --from=builder /app/myapp /myapp
CMD ["/myapp"]

 

 Result: final image only contains the runtime binary, not the full Go toolchain.

 

5️⃣ Clean Up Cache in Dockerfile

Package managers leave caches in the image. Clean them to reduce layer size:

 

# Example for Ubuntu/Debian
RUN apt-get update && apt-get install -y \
    curl \
 && rm -rf /var/lib/apt/lists/* 

6️⃣ Use Container Runtime Tools to Clean Up Node

If images are occupying containerd or Kubernetes nodes:

 # Check images on node
crictl images

# Remove unused images
crictl rmi <image-id>

 Kubernetes kubelet also does image garbage collection, but you can force cleanup if needed.

 

7️⃣ Monitor Image Size Proactively

• Use docker images or crictl images regularly

• Consider CI/CD tools to warn or fail builds if image > X MB

• Remove old images from the registry to avoid pushing huge layers repeatedly

Registry Cleanup

1️⃣ Docker Hub

Manual Cleanup

1. Log in to Docker Hub

2. Go to your repository → Tags

3. Delete old/unwanted tags manually

Automated Cleanup

• Pro/Team accounts can automatically delete untagged images

• Otherwise, use scripts with the Docker Hub API

   

  2️⃣ Harbor (Self-hosted Registry)

• Go to Harbor web UI → Projects → Repositories → Tags

• Delete old tags manually

• Run garbage collection to free space

•  

  Understanding Layers and Storage

  Even if your Dockerfile has the same number of instructions, Docker caching may increase layers:

  Example Dockerfile

 FROM ubuntu:22.04   # Layer 1
RUN apt-get update && apt-get install -y curl   # Layer 2
COPY . /app                                   # Layer 3

 

• ✅ 3 instructions → nominally 3 layers

• ✅ Layer 1 & 2 are stable if unchanged

What Happens When /app Changes

• COPY . /app creates Layer 3

• Every time /app changes → Docker sees it as a new layer

• Old Layer 3 remains in the registry if previous tag exists

 

Effect on ECR Storage

• Docker reuses identical layers (Layer 1 & 2 shared)

• Layer 3 changes → stored as a new layer

• Pushing multiple builds with changes in /app → ECR accumulates multiple Layer 3 versions

 

Layer	Content	Stored?
Layer 1	Ubuntu base	Reused across builds
Layer 2	curl install	Reused across builds
Layer 3	/app v1	Stored
Layer 3	/app v2	New layer, stored separately
Layer 3	/app v3	New layer, stored separately

TL;DR: Dockerfile has 3 layers. Each time /app changes → new Layer 3 → registry sees multiple Layer 3s → storage increases over time.