Image size and minimal base images in Docker - Commands & Configuration

Introduction

Large Docker images take longer to download and use more storage. Using minimal base images helps keep images small and efficient, making your apps start faster and use fewer resources.

When you want your app to start quickly in a cloud environment with limited bandwidth.

When you need to save disk space on servers running many containers.

When you want to reduce security risks by including fewer unnecessary packages.

When you want faster deployment times during continuous integration and delivery.

When you want to optimize resource usage on development machines.

Config File - Dockerfile

Dockerfile

FROM alpine:3.18

RUN apk add --no-cache python3 py3-pip

COPY app.py /app/app.py

CMD ["python3", "/app/app.py"]

FROM alpine:3.18 sets a very small base image with just essential tools.

RUN apk add --no-cache python3 py3-pip installs Python without caching to keep the image small.

COPY app.py /app/app.py copies your application code into the image.

CMD runs the Python app when the container starts.

Commands

Builds the Docker image named 'my-python-app' from the Dockerfile in the current directory.

Terminal

docker build -t my-python-app .

Expected Output

Sending build context to Docker daemon  3.072kB

Step 1/4 : FROM alpine:3.18

3.18: Pulling from library/alpine

Digest: sha256:...

Status: Downloaded newer image for alpine:3.18

 ---> 3f53bb00af94

Step 2/4 : RUN apk add --no-cache python3 py3-pip

 ---> Running in abcdef123456

fetch http://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz

(1/7) Installing python3 (3.11.4-r0)

(2/7) Installing py3-pip (23.1.2-r0)

Executing busybox-1.35.0-r21.trigger

OK: 15 MiB in 29 packages

Removing intermediate container abcdef123456

 ---> 123456abcdef

Step 3/4 : COPY app.py /app/app.py

 ---> 789abc123def

Step 4/4 : CMD ["python3", "/app/app.py"]

 ---> Running in 456def789abc

Removing intermediate container 456def789abc

 ---> fedcba987654

Successfully built fedcba987654

Successfully tagged my-python-app:latest

Shows the size and details of the built image to verify it is small.

Terminal

docker images my-python-app

Expected Output

REPOSITORY      TAG       IMAGE ID       CREATED          SIZE

my-python-app   latest    fedcba987654   10 seconds ago   30MB

Runs the container from the image to check the app works as expected.

Terminal

docker run --rm my-python-app

Expected Output

Hello from app.py

→

--rm - Automatically removes the container after it stops to keep the system clean

Key Concept

If you remember nothing else from this pattern, remember: using minimal base images like Alpine keeps your Docker images small and efficient.

Common Mistakes

Using large base images like 'ubuntu' without considering size.

This makes images bulky, slow to download, and wastes storage.

Choose minimal base images like 'alpine' or 'scratch' when possible.

Installing packages without cleaning cache or using no-cache flags.

This leaves unnecessary files in the image, increasing size.

Use package manager flags like '--no-cache' in Alpine to avoid cache files.

Copying unnecessary files into the image.

Extra files increase image size and may expose sensitive data.

Only copy needed files and use .dockerignore to exclude others.

Summary

Use minimal base images like Alpine to reduce Docker image size.

Install only necessary packages with no-cache options to avoid leftover files.

Verify image size with 'docker images' and test the container runs correctly.

Practice

1. Which base image is known for being very small and commonly used to create minimal Docker images?

easy

A. Ubuntu

B. Alpine

C. Debian

D. CentOS

Solution

1. Step 1: Understand common base images

   Ubuntu, Debian, and CentOS are full Linux distributions and tend to be larger in size.

2. Step 2: Identify minimal base images

   Alpine is a lightweight Linux distribution designed for minimal size, often under 10 MB.

3. Final Answer:

   Alpine -> Option B

4. Quick Check:

   Minimal base image = Alpine [OK]

Hint: Alpine is the go-to small base image for minimal Docker images [OK]

Common Mistakes:

• Choosing Ubuntu or Debian as minimal base images
• Confusing full distributions with minimal ones
• Not knowing Alpine is designed for small size

2. Which of the following Dockerfile base image declarations is syntactically correct for using Alpine Linux?

easy

A. FROM alpine:latest

B. BASE alpine

C. USE alpine

D. IMAGE alpine

Solution

1. Step 1: Recall Dockerfile syntax for base images

   The correct keyword to specify a base image is FROM followed by the image name and optional tag.

2. Step 2: Check each option

   Only 'FROM alpine:latest' uses the correct syntax. Others are invalid Dockerfile commands.

3. Final Answer:

   FROM alpine:latest -> Option A

4. Quick Check:

   Base image syntax = FROM [OK]

Hint: Base images start with FROM in Dockerfiles [OK]

Common Mistakes:

• Using incorrect keywords like BASE or USE
• Omitting the FROM keyword
• Not specifying image tag correctly

3. Given this Dockerfile snippet:

FROM alpine:3.18
RUN apk add --no-cache curl

What is the main reason this image remains small compared to using Ubuntu as base?

medium

A. Alpine automatically removes all packages after installation

B. Alpine installs curl faster than Ubuntu

C. Ubuntu images do not support curl installation

D. Alpine uses apk with --no-cache to avoid cache files, reducing size

Solution

1. Step 1: Understand Alpine's package manager behavior

   Alpine uses apk, and the --no-cache option prevents storing temporary cache files, keeping the image small.

2. Step 2: Compare with Ubuntu

   Ubuntu uses apt which caches package files unless explicitly cleaned, increasing image size.

3. Final Answer:

   Alpine uses apk with --no-cache to avoid cache files, reducing size -> Option D

4. Quick Check:

   apk --no-cache reduces image size [OK]

Hint: Use apk add --no-cache on Alpine to keep images small [OK]

Common Mistakes:

• Thinking Alpine installs packages faster
• Believing Ubuntu can't install curl
• Assuming Alpine removes all packages automatically

4. You wrote this Dockerfile:

FROM alpine
RUN apk add curl

But your final image is much larger than expected. What is the likely cause?

medium

A. You forgot to use --no-cache with apk add, so cache files remain

B. Alpine base image is always large regardless of commands

C. You should use Ubuntu base image for smaller size

D. The RUN command syntax is incorrect

Solution

1. Step 1: Analyze apk add command

   Without --no-cache, apk stores cache files in the image, increasing size.

2. Step 2: Understand base image size and syntax

   Alpine is small by default, RUN syntax is correct, and Ubuntu is larger, so those are not causes.

3. Final Answer:

   You forgot to use --no-cache with apk add, so cache files remain -> Option A

4. Quick Check:

   Missing --no-cache causes larger images [OK]

Hint: Always add --no-cache with apk to keep Alpine images small [OK]

Common Mistakes:

• Assuming Alpine is large by default
• Using wrong RUN syntax
• Switching to Ubuntu thinking it is smaller

5. You want to create the smallest possible Docker image for a Go application. Which base image and approach is best to minimize image size?

hard

A. Use FROM ubuntu and install Go runtime

B. Use FROM alpine and install full Go toolchain

C. Use FROM scratch and copy only the compiled Go binary

D. Use FROM debian and add all dependencies

Solution

1. Step 1: Understand the scratch base image

   Scratch is an empty image with zero size, ideal for copying only necessary files like a compiled binary.

2. Step 2: Compare other options

   Ubuntu, Alpine, and Debian add extra layers and packages, increasing image size unnecessarily.

3. Final Answer:

   Use FROM scratch and copy only the compiled Go binary -> Option C

4. Quick Check:

   Scratch + compiled binary = smallest image [OK]

Hint: Use scratch base and copy binary for tiniest Go images [OK]

Common Mistakes:

• Installing full runtimes increasing image size
• Using larger base images unnecessarily
• Not using multi-stage builds to compile separately