Distroless images concept in Docker - Step-by-Step Execution

Process Flow - Distroless images concept

Start with base image

↓

Remove OS shell and package manager

↓

Include only app runtime and dependencies

↓

Build minimal image

↓

Deploy smaller, secure container

↓

Run app with minimal attack surface

↓

End

Distroless images start from a base, remove shells and package managers, keep only app runtime and dependencies, then build a minimal, secure container image.

Execution Sample

Docker

FROM gcr.io/distroless/base
COPY app /app
CMD ["/app"]

This Dockerfile uses a distroless base, copies the app binary, and runs it without a shell.

Process Table

Step	Action	Details	Result
1	FROM gcr.io/distroless/base	Use distroless base image	Base image has no shell or package manager
2	COPY app /app	Copy app binary into image	App binary is inside image at /app
3	CMD ["/app"]	Set container to run app directly	Container runs app without shell
4	Build image	Docker builds image layers	Image is minimal and smaller than typical base images
5	Run container	Start container from image	App runs with minimal dependencies and attack surface
6	Exit	Container stops when app finishes	Container exits cleanly

💡 Execution stops after container runs app and exits

Status Tracker

Variable	Start	After Step 2	After Step 4	Final
Image Size	N/A	Reduced (no shell)	Minimal (only app + runtime)	Minimal
Shell Present	Yes (normal base)	No (distroless base)	No	No
Package Manager Present	Yes	No	No	No
App Binary	Not present	Copied to /app	Present	Present

Key Moments - 3 Insights

Why can't we run shell commands inside a distroless container?

Because the distroless base image removes the shell and package manager, as shown in execution_table step 1 and variable_tracker 'Shell Present' being 'No'.

How does the container run the app without a shell?

The CMD instruction runs the app binary directly without a shell wrapper, as seen in execution_table step 3.

Why is the image size smaller with distroless?

Because unnecessary OS tools like shells and package managers are removed, reducing image size as shown in variable_tracker 'Image Size' changes.

Visual Quiz - 3 Questions

Look at the execution_table at step 1. What is missing in the distroless base image compared to a normal base?

A Shell and package manager

B App binary

C Network tools

D Docker daemon

💡 Hint

Check the 'Details' and 'Result' columns at step 1 in execution_table.

According to variable_tracker, after which step is the app binary present inside the image?

A After Step 1

B After Step 2

C After Step 4

D Final

💡 Hint

Look at the 'App Binary' row and see when it changes from 'Not present' to 'Copied to /app'.

If we added a shell back into the image, how would the 'Shell Present' variable change in variable_tracker?

A It would change to 'Yes' after Step 4

B It would change to 'Yes' after Step 2

C It would change to 'Yes' at Final

D It would remain 'No'

💡 Hint

Think about when the shell would be added back during the build process.

Concept Snapshot

Distroless images remove shells and package managers
Include only app runtime and dependencies
Result in smaller, more secure containers
Run app binary directly without shell
Ideal for production deployments

Full Transcript

Distroless images start from a base image that has no shell or package manager. This means you cannot run shell commands inside the container. The Dockerfile copies the app binary directly into the image and sets it to run without a shell. This results in a smaller image size and reduces the attack surface, making the container more secure. The container runs the app directly and exits cleanly when the app finishes. Variables like image size and shell presence change as the image is built, showing the minimal nature of distroless images.

Practice

1. What is the main advantage of using distroless images in Docker containers?

easy

A. They keep containers small and secure by including only necessary files

B. They include a full Linux distribution for easier debugging

C. They come with built-in shells and package managers

D. They automatically update the application inside the container

Solution

1. Step 1: Understand what distroless images contain

   Distroless images include only the application and its runtime dependencies, excluding shells and package managers.

2. Step 2: Identify the benefit of minimal content

   By including only what is needed, the image size is smaller and the attack surface is reduced, improving security.

3. Final Answer:

   They keep containers small and secure by including only necessary files -> Option A

4. Quick Check:

   Minimal content = Small and secure [OK]

Hint: Distroless means minimal, no shells or extras included [OK]

Common Mistakes:

• Thinking distroless images have shells for debugging
• Assuming they include full Linux distributions
• Believing they auto-update applications

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

easy

A. FROM ubuntu:latest

B. FROM alpine:3.15

C. FROM gcr.io/distroless/base

D. FROM node:distroless

Solution

1. Step 1: Identify official distroless image naming

   Distroless images are hosted at gcr.io/distroless with names like 'base', 'static', or language-specific tags.

2. Step 2: Compare options to distroless naming

   Only 'gcr.io/distroless/base' matches the official distroless image naming convention.

3. Final Answer:

   FROM gcr.io/distroless/base -> Option C

4. Quick Check:

   Official distroless images start with gcr.io/distroless [OK]

Hint: Distroless images start with gcr.io/distroless prefix [OK]

Common Mistakes:

• Using common Linux distros like ubuntu or alpine as distroless
• Assuming 'node:distroless' is a valid tag
• Confusing distroless with minimal Linux images

3. Given this Dockerfile snippet using a distroless image:

FROM gcr.io/distroless/base
COPY app /app
CMD ["/app"]

What will happen if you try to run docker run and then execute sh inside the container?

medium

A. You will get a shell prompt because distroless images include shells

B. You will get an error saying 'sh: not found' because no shell is included

C. The container will crash immediately on start

D. The container will open a shell automatically

Solution

1. Step 1: Understand distroless image contents

   Distroless images do not include shells or package managers, only the app and runtime.

2. Step 2: Predict shell availability inside container

   Trying to run 'sh' will fail because the shell binary is missing, causing 'sh: not found' error.

3. Final Answer:

   You will get an error saying 'sh: not found' because no shell is included -> Option B

4. Quick Check:

   No shell in distroless = 'sh: not found' error [OK]

Hint: Distroless images have no shell, so 'sh' command fails [OK]

Common Mistakes:

• Assuming shells exist for debugging
• Expecting container to crash on start
• Thinking shell opens automatically

4. You wrote this Dockerfile using a distroless image:

FROM gcr.io/distroless/base
COPY app /app
CMD ["/app"]

But when you run the container, it exits immediately with no logs. What is the most likely cause?

medium

A. The CMD syntax is incorrect for distroless images

B. The distroless image requires a shell to run commands

C. The container needs a package manager to start

D. The app binary is missing executable permissions

Solution

1. Step 1: Check distroless image requirements

   Distroless images run the app binary directly without a shell or package manager.

2. Step 2: Identify common cause of immediate exit

   If the app binary lacks executable permission, the container will exit immediately without running the app.

3. Final Answer:

   The app binary is missing executable permissions -> Option D

4. Quick Check:

   Missing exec permission = container exits immediately [OK]

Hint: Check app permissions; distroless runs binary directly [OK]

Common Mistakes:

• Thinking distroless needs a shell to run commands
• Assuming CMD syntax differs for distroless
• Believing package manager is required to start

5. You want to build a secure production Docker image for a Go app using distroless. Which multi-stage Dockerfile snippet correctly builds and runs the app with minimal image size and attack surface?

hard

A. FROM golang:1.20 AS build
WORKDIR /app
COPY . .
RUN go build -o app
FROM gcr.io/distroless/base
COPY --from=build /app/app /app
CMD ["/app"]

B. FROM golang:1.20
WORKDIR /app
COPY . .
RUN go build -o app
CMD ["./app"]

C. FROM alpine:latest
WORKDIR /app
COPY . .
RUN go build -o app
CMD ["./app"]

D. FROM gcr.io/distroless/base
COPY app /app
RUN go build -o app
CMD ["/app"]

Solution

1. Step 1: Understand multi-stage build for distroless

   Build the Go app in a full image with build tools, then copy the binary into a minimal distroless image.

2. Step 2: Analyze options for correct multi-stage usage

   Only FROM golang:1.20 AS build WORKDIR /app COPY . . RUN go build -o app FROM gcr.io/distroless/base COPY --from=build /app/app /app CMD ["/app"] uses golang image to build, then copies binary into distroless base image for runtime, minimizing size and attack surface.

3. Final Answer:

   FROM golang:1.20 AS build WORKDIR /app COPY . . RUN go build -o app FROM gcr.io/distroless/base COPY --from=build /app/app /app CMD ["/app"] -> Option A

4. Quick Check:

   Build in full image, run in distroless = secure minimal image [OK]

Hint: Build in full image, copy binary to distroless for runtime [OK]

Common Mistakes:

• Trying to build inside distroless image (no build tools)
• Using single-stage build with full image (larger size)
• Using alpine without distroless for production