Image size and minimal base images in Docker - Step-by-Step Execution

Process Flow - Image size and minimal base images

Choose base image

↓

Check image size

↓

Use minimal base image?

No→Use standard base image

Yes↓

Add only needed packages

↓

Build final image

↓

Check final image size

↓

Deploy or optimize further

This flow shows choosing a base image, deciding if a minimal image is suitable, building with only needed packages, and checking the final image size.

Execution Sample

Docker

FROM alpine:3.18
RUN apk add --no-cache curl
CMD ["curl", "--version"]

This Dockerfile uses a minimal Alpine base image, adds curl without cache to keep size small, and runs curl version command.

Process Table

Step	Action	Image Size (MB)	Description
1	Start with alpine:3.18 base image	5	Alpine is a minimal Linux image (~5MB)
2	Run apk add --no-cache curl	7	Adds curl package without cache, small size increase
3	Set CMD to run curl --version	7	No size change, sets default command
4	Build final image	7	Final image size is about 7MB, very small
5	Compare with ubuntu base image	29	Ubuntu base image is much larger (~29MB)
6	Exit	-	Finished building minimal image

💡 Build finished with minimal base image resulting in a small final image size

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
Image Size (MB)	5 (alpine base)	7 (after curl install)	7 (after CMD set)	7 (final image)

Key Moments - 3 Insights

Why does using alpine base image reduce image size compared to ubuntu?

Alpine is designed to be minimal and small (~5MB), while Ubuntu includes many packages by default making it larger (~29MB), as shown in execution_table rows 1 and 5.

What does --no-cache do in apk add command?

It prevents caching package index files, so they are not saved in the image, keeping the image size smaller, as seen in step 2 where size only increases slightly.

Does setting CMD affect image size?

No, setting CMD only defines the default command to run and does not change the image size, as shown in step 3.

Visual Quiz - 3 Questions

Look at the execution table, what is the image size after adding curl to alpine?

A 5 MB

B 7 MB

C 29 MB

D 12 MB

💡 Hint

Check the 'Image Size (MB)' column at step 2 in the execution_table

At which step does the image size increase from the base image size?

A Step 2

B Step 3

C Step 1

D Step 5

💡 Hint

Look for the first step where 'Image Size (MB)' changes from 5 to 7 in execution_table

If we used ubuntu base image instead of alpine, what would be the approximate base image size?

A 5 MB

B 7 MB

C 29 MB

D 50 MB

💡 Hint

Refer to step 5 in execution_table comparing ubuntu base image size

Concept Snapshot

Use minimal base images like alpine (~5MB) to keep Docker images small.
Add only needed packages with no cache to avoid size bloat.
Standard images like ubuntu are larger (~29MB).
Setting CMD does not affect image size.
Check image size after build to confirm minimal footprint.

Full Transcript

This lesson shows how choosing a minimal base image like alpine reduces Docker image size compared to standard images like ubuntu. We start with alpine base image of about 5MB. Adding curl with apk add --no-cache increases size slightly to about 7MB. Setting CMD does not change size. The final image remains small and efficient. Using no-cache prevents extra files from being saved, keeping the image lean. Comparing with ubuntu base image shows it is much larger at about 29MB. This teaches how minimal base images and careful package installation help keep Docker images small and fast to deploy.

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