Scratch base image for minimal containers in Docker - Step-by-Step Execution

Process Flow - Scratch base image for minimal containers

Start Dockerfile

↓

Use FROM scratch

↓

Add minimal files

↓

Build container image

↓

Run minimal container

↓

Container runs with minimal size

↓

End

This flow shows how a Dockerfile starts with FROM scratch, adds only needed files, builds the image, and runs a minimal container.

Execution Sample

Docker

FROM scratch
ADD hello /
CMD ["/hello"]

This Dockerfile uses scratch as base, adds a hello binary, and runs it.

Process Table

Step	Dockerfile Instruction	Action	Resulting Image State	Notes
1	FROM scratch	Start from empty base image	Image has no files or layers	Base image is empty, no OS or tools
2	ADD hello /	Add hello binary to root	Image now contains /hello file	Only the hello binary is added, minimal size
3	CMD ["/hello"]	Set default command to run /hello	Container will run /hello on start	No shell or other commands available
4	docker build -t hello-minimal .	Build image from Dockerfile	Image built with minimal size	Image size is very small, only hello binary
5	docker run --rm hello-minimal	Run container from image	Container runs and executes /hello	Container runs with minimal environment
6	Exit	Container stops after /hello finishes	Container exits cleanly	No extra processes or files remain

💡 Container exits after running the /hello binary, no OS or shell present

Status Tracker

Variable	Start	After Step 2	After Step 3	After Build	After Run	Final
Image Files	empty	/hello	/hello	/hello	/hello (running)	empty (container exited)
Container State	none	none	none	built	running /hello	exited

Key Moments - 3 Insights

Why does the image have no OS or shell?

Because FROM scratch starts with an empty image, no OS or shell is included, only what you add explicitly (see execution_table step 1).

How can the container run a command without a shell?

The CMD runs the binary directly; no shell is needed because the binary is self-contained (see execution_table step 3).

Why is the image size so small?

Only the hello binary is added, no extra OS files or libraries, so the image stays minimal (see execution_table step 2 and 4).

Visual Quiz - 3 Questions

Look at the execution table, what files exist in the image after step 2?

A Only /hello binary

B Full OS files

C No files at all

D Shell and utilities

💡 Hint

Check the 'Resulting Image State' column at step 2 in the execution_table

At which step does the container start running the /hello binary?

A Step 3

B Step 4

C Step 5

D Step 2

💡 Hint

Look at the 'Action' and 'Resulting Image State' columns in execution_table step 5

If you add a shell binary in step 2, how would the image size change?

A It would stay the same

B It would become larger

C It would become smaller

D It would fail to build

💡 Hint

Adding more files increases image size, see step 2 notes about minimal size

Concept Snapshot

FROM scratch starts an empty image with no OS.
ADD copies only needed files (like a binary).
CMD sets the command to run inside the container.
Result: minimal container size, no shell or OS included.
Use for very small, secure containers.

Full Transcript

This visual execution shows how to create a minimal Docker container using the scratch base image. The Dockerfile starts with FROM scratch, which means the image is empty with no operating system or shell. Then, the ADD instruction copies a single binary file named hello into the image. The CMD instruction sets the container to run this hello binary when started. Building the image creates a very small container image containing only the hello binary. Running the container executes the binary directly, without any shell or extra OS files. The container exits after the binary finishes. This approach is useful for creating minimal, secure containers with only the necessary files.

Practice

1. What is the main purpose of using the scratch base image in Docker?

easy

A. To automatically install dependencies for your app

B. To include a full Linux operating system inside the container

C. To create a minimal container with only your application and no extra files

D. To provide a graphical user interface for the container

Solution

1. Step 1: Understand what scratch means

   scratch is an empty base image, meaning it has no files or OS inside.

2. Step 2: Identify the purpose of minimal containers

   Using scratch lets you build very small containers by including only your app and its static binaries.

3. Final Answer:

   To create a minimal container with only your application and no extra files -> Option C

4. Quick Check:

   Minimal container = scratch base image [OK]

Hint: Scratch means empty base image for smallest containers [OK]

Common Mistakes:

• Thinking scratch includes a full OS
• Assuming scratch installs dependencies automatically
• Believing scratch provides GUI support

2. Which of the following is the correct way to specify the scratch base image in a Dockerfile?

easy

A. FROM base scratch

B. FROM scratch

C. FROM minimal/scratch

D. FROM scratch:latest

Solution

1. Step 1: Recall Dockerfile syntax for base images

   The correct syntax is FROM <image-name> without extra words.

2. Step 2: Check official usage of scratch

   scratch is a special empty image and is referenced simply as FROM scratch.

3. Final Answer:

   FROM scratch -> Option B

4. Quick Check:

   Base image syntax = FROM scratch [OK]

Hint: Use exactly 'FROM scratch' in Dockerfile [OK]

Common Mistakes:

• Adding tags like :latest to scratch
• Using extra words like 'base' or 'minimal/'
• Incorrect syntax like FROM scratch:latest

3. Given this Dockerfile snippet using scratch:

FROM scratch
COPY myapp /
CMD ["/myapp"]

What will happen if myapp is not a statically compiled binary?

medium

A. The container will fail to run because dynamic libraries are missing

B. The container will run successfully without errors

C. Docker will automatically add required libraries

D. The container will run but with degraded performance

Solution

1. Step 1: Understand scratch image limitations

   scratch has no OS or libraries, so dynamic binaries cannot find needed libraries.

2. Step 2: Analyze what happens with non-static binaries

   Non-statically compiled binaries depend on shared libraries which are missing, causing runtime failure.

3. Final Answer:

   The container will fail to run because dynamic libraries are missing -> Option A

4. Quick Check:

   Non-static binary + scratch = runtime failure [OK]

Hint: Scratch needs static binaries; dynamic ones fail [OK]

Common Mistakes:

• Assuming Docker adds missing libraries automatically
• Thinking container runs fine without libraries
• Believing performance is only affected, not failure

4. You wrote this Dockerfile:

FROM scratch
COPY app /
CMD ["/app"]

But when running the container, it fails with "exec format error". What is the most likely cause?

medium

A. The Dockerfile syntax is incorrect

B. The app file is missing execute permissions

C. The app binary is dynamically linked

D. The app binary is not compiled for the container's CPU architecture

Solution

1. Step 1: Understand "exec format error" meaning

   This error usually means the binary format does not match the CPU architecture.

2. Step 2: Check other possible causes

   Missing execute permission or dynamic linking cause different errors; syntax errors prevent build.

3. Final Answer:

   The app binary is not compiled for the container's CPU architecture -> Option D

4. Quick Check:

   Exec format error = wrong CPU architecture binary [OK]

Hint: Exec format error means binary architecture mismatch [OK]

Common Mistakes:

• Confusing exec format error with permission issues
• Assuming dynamic linking causes exec format error
• Thinking Dockerfile syntax causes this runtime error

5. You want to build a minimal Docker container using scratch that runs a Go application. Which steps should you follow to ensure the container runs correctly?

hard

A. Compile the Go app statically, use FROM scratch, copy the binary, and set CMD

B. Use FROM scratch, copy the Go source code, and run go run inside the container

C. Use FROM alpine, install Go, and compile the app inside the container

D. Compile the Go app dynamically, use FROM scratch, copy the binary, and set CMD

Solution

1. Step 1: Compile Go app statically

   Static compilation bundles all dependencies, so the binary runs without extra libraries.

2. Step 2: Use FROM scratch and copy binary

   Since scratch is empty, copy the static binary and set the command to run it.

3. Final Answer:

   Compile the Go app statically, use FROM scratch, copy the binary, and set CMD -> Option A

4. Quick Check:

   Static binary + scratch base = minimal working container [OK]

Hint: Static binary + FROM scratch + copy + CMD = minimal container [OK]

Common Mistakes:

• Trying to run source code inside scratch
• Using dynamic binaries with scratch
• Using alpine base instead of scratch for minimal size