FROM instruction for base image in Docker - Deep Dive

Overview - FROM instruction for base image

What is it?

The FROM instruction in a Dockerfile sets the starting point for building a Docker image. It tells Docker which base image to use before adding your own files and commands. This base image can be a minimal operating system or a pre-built environment with software installed. Every Dockerfile must start with a FROM instruction to define the image's foundation.

Why it matters

Without the FROM instruction, Docker wouldn't know what environment to build upon, making it impossible to create consistent and reusable images. It solves the problem of starting from scratch every time by letting you build on trusted, tested images. This saves time, reduces errors, and ensures your applications run the same way everywhere.

Where it fits

Before learning FROM, you should understand what Docker images and containers are. After mastering FROM, you can learn about layering, RUN instructions, and multi-stage builds to optimize images.

Mental Model

Core Idea

FROM sets the base image that acts like the foundation of a house on which everything else is built.

Think of it like...

Imagine building a house: the FROM instruction is like choosing the plot of land and laying the foundation before adding walls, windows, and furniture.

┌───────────────┐
│   FROM base   │  ← Base image (foundation)
├───────────────┤
│  Your layers  │  ← Additional instructions
├───────────────┤
│ Final image   │  ← Ready to run container
└───────────────┘

Build-Up - 6 Steps

1

Foundation

What is the FROM instruction

Concept: Introduces the FROM instruction as the first line in a Dockerfile that specifies the base image.

In a Dockerfile, the first line usually looks like this: FROM ubuntu:22.04 This means your image starts from the official Ubuntu 22.04 image. Docker downloads this image if you don't have it locally.

Result

Docker knows which base image to use and downloads it if needed.

Understanding that every Docker image builds on a base image helps you see Docker images as layers stacked on top of each other.

2

Foundation

Why base images matter

Concept: Explains the role of base images as pre-made environments that save time and effort.

Base images provide a ready-made environment like an operating system or language runtime. For example, 'python:3.11-slim' includes Python 3.11 installed on a small Linux base. This means you don't have to install Python yourself.

Result

You get a consistent starting environment for your application.

Knowing that base images come with pre-installed software helps you pick the right starting point for your project.

3

Intermediate

Specifying image tags and versions

🤔Before reading on: do you think omitting a tag in FROM uses the latest image or an unspecified version? Commit to your answer.

Concept: Shows how to specify exact versions or tags to control which base image you use.

The FROM instruction can include tags like 'ubuntu:22.04' or 'node:18-alpine'. If you write 'FROM ubuntu' without a tag, Docker uses the 'latest' tag by default, which can change over time. Example: FROM node:18-alpine This uses Node.js version 18 on a small Alpine Linux base.

Result

You control the exact environment your image builds on, avoiding surprises from automatic updates.

Understanding tags prevents unexpected changes in your image when the base image updates.

4

Intermediate

Using multiple FROM instructions (multi-stage builds)

🤔Before reading on: do you think a Dockerfile can have more than one FROM instruction? Commit to yes or no.

Concept: Introduces multi-stage builds where multiple FROM instructions create separate build stages.

You can write multiple FROM lines to create stages: FROM golang:1.20 AS builder RUN go build -o app FROM alpine:3.18 COPY --from=builder /app /app This builds your app in one image, then copies the result into a smaller final image.

Result

You get smaller, cleaner images by separating build and runtime environments.

Knowing multi-stage builds helps optimize images by removing build tools from the final image.

5

Advanced

FROM with platform and architecture options

🤔Before reading on: do you think FROM can specify the CPU architecture or platform? Commit to yes or no.

Concept: Explains how to specify platform (like linux/amd64 or linux/arm64) in FROM for cross-platform builds.

You can add a platform option: FROM --platform=linux/arm64 ubuntu:22.04 This tells Docker to pull the ARM64 version of the image, useful when building images for different hardware.

Result

You build images compatible with specific hardware platforms.

Understanding platform options enables building images for diverse environments like ARM-based devices.

6

Expert

How FROM affects image caching and layers

🤔Before reading on: do you think changing the FROM line invalidates all cached layers or only some? Commit to your answer.

Concept: Details how the FROM instruction influences Docker's caching mechanism and layer reuse.

Docker caches layers to speed up builds. Changing the FROM line means Docker treats the base image as new, invalidating all layers built on top. This forces a full rebuild of your image layers. Example: Changing FROM ubuntu:20.04 to FROM ubuntu:22.04 causes cache misses for all subsequent steps.

Result

Builds become slower after changing FROM because cache is invalidated.

Knowing how FROM affects caching helps manage build speed and image updates efficiently.

Under the Hood

When Docker reads a Dockerfile, it processes the FROM instruction first to pull or locate the specified base image. This base image is a set of read-only layers stored locally or fetched from a registry. Docker then adds new layers on top for each instruction in the Dockerfile. The base image layers form the foundation of the final image's filesystem.

Why designed this way?

Docker was designed to reuse existing images to save bandwidth and time. Using a FROM instruction allows layering, which means images share common parts without duplication. This design reduces storage and speeds up builds by caching layers. Alternatives like building from scratch every time would be inefficient and error-prone.

Dockerfile Processing Flow:

┌───────────────┐
│  Dockerfile   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│  FROM pulls   │
│ base image    │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Base image    │
│ layers loaded │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Add new layers │
│ from commands │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Final image   │
│ ready to run  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does omitting a tag in FROM always use the latest stable image? Commit to yes or no.

Common Belief: If you don't specify a tag in FROM, Docker uses the latest stable version of the image.

Reality: Omitting the tag uses the 'latest' tag, which is just a label and can point to any version, not necessarily stable or newest.

Why it matters: This can cause unexpected behavior or bugs if the base image changes without your knowledge.

Quick: Can you have multiple FROM instructions in a Dockerfile? Commit to yes or no.

Common Belief: A Dockerfile can only have one FROM instruction at the top.

Reality: Dockerfiles can have multiple FROM instructions to create multi-stage builds, each defining a separate build stage.

Why it matters: Missing this limits your ability to optimize images by separating build and runtime environments.

Quick: Does changing the FROM line keep all cached layers intact? Commit to yes or no.

Common Belief: Changing the FROM line does not affect cached layers built on top of it.

Reality: Changing FROM invalidates all cached layers above it because the base image changes.

Why it matters: Not knowing this leads to confusion about build times and cache misses.

Quick: Does the FROM instruction download the entire base image every time you build? Commit to yes or no.

Common Belief: FROM always downloads the full base image from the registry on every build.

Reality: Docker downloads the base image only if it is not already present locally, saving time and bandwidth.

Why it matters: Understanding this helps optimize build workflows and storage management.

Expert Zone

1

Some base images include hidden layers with metadata or security patches that affect image size and behavior subtly.

2

Using specific digest hashes instead of tags in FROM ensures absolute immutability of the base image.

3

Multi-architecture images use manifests that let Docker pick the correct platform variant automatically.

When NOT to use

FROM is essential for Docker images, but if you need fully custom environments without any base, consider using scratch as a base or alternative container technologies like OCI images or system-level virtualization.

Production Patterns

In production, FROM is used with pinned versions or digests to ensure reproducible builds. Multi-stage builds are common to keep images small and secure by excluding build tools. Platform specification is used for cross-compilation and multi-architecture deployments.

Connections

Layered File Systems

FROM defines the base layers on which additional layers are stacked.

Understanding FROM helps grasp how layered file systems work in containers, enabling efficient storage and sharing.

Version Control Systems

FROM tags and digests are like commits or branches specifying exact versions.

Knowing this connection clarifies why pinning versions in FROM is like locking code to a specific commit for stability.

Building Foundations in Construction

FROM sets the foundation, similar to how construction starts with a solid base before building up.

Recognizing this cross-domain pattern reinforces the importance of a stable base for any complex system.

Common Pitfalls

#1 Using 'FROM ubuntu' without a tag expecting a stable version.

Wrong approach:

FROM ubuntu

Correct approach:

FROM ubuntu:22.04

Root cause:

Misunderstanding that omitting a tag defaults to 'latest', which can change unexpectedly.

#2 Trying to copy files from a previous stage without naming it.

Wrong approach:

FROM golang:1.20
RUN go build -o app
FROM alpine:3.18
COPY /app /app

Correct approach:

FROM golang:1.20 AS builder
RUN go build -o app
FROM alpine:3.18
COPY --from=builder /app /app

Root cause:

Not using stage names in multi-stage builds causes Docker to not find the source files.

#3 Changing FROM line frequently without understanding cache impact.

Wrong approach:

FROM ubuntu:20.04
# build steps
# then change to
FROM ubuntu:22.04
# same build steps

Correct approach:

Pin FROM once and update carefully, knowing it invalidates cache:
FROM ubuntu:22.04
# build steps

Root cause:

Ignoring how FROM affects layer caching leads to slow builds and confusion.

Key Takeaways

FROM is the first instruction in a Dockerfile that sets the base image for building your container.

Choosing the right base image and tag ensures a stable, consistent environment for your application.

Multi-stage builds use multiple FROM instructions to optimize image size and separate build/runtime environments.

Changing the FROM line invalidates cached layers, affecting build speed and reproducibility.

Specifying platform and using digests in FROM helps build images for different hardware and ensures immutability.

Practice

1. What does the FROM instruction do in a Dockerfile?

easy

A. It sets the base image for the Docker build.

B. It copies files from the host to the container.

C. It runs commands inside the container.

D. It exposes ports for the container.

Solution

1. Step 1: Understand the role of FROM

   The FROM instruction defines the starting point or base image for building a Docker image.

2. Step 2: Compare with other instructions

   Other instructions like COPY, RUN, and EXPOSE have different purposes, not setting the base image.

3. Final Answer:

   It sets the base image for the Docker build. -> Option A

4. Quick Check:

   FROM = base image [OK]

Hint: FROM always sets the base image in Dockerfile [OK]

Common Mistakes:

• Confusing FROM with COPY or RUN instructions
• Thinking FROM exposes ports
• Assuming FROM copies files

2. Which of the following is the correct syntax for the FROM instruction to use the Ubuntu 22.04 image?

easy

A. FROM ubuntu/22.04

B. FROM ubuntu-22.04

C. FROM ubuntu:22.04

D. FROM ubuntu@22.04

Solution

1. Step 1: Recall Docker image tag syntax

   The correct format is image_name:tag, so ubuntu:22.04 is valid.

2. Step 2: Check other options

   Options with dashes, slashes, or @ are invalid for tags in FROM instruction.

3. Final Answer:

   FROM ubuntu:22.04 -> Option C

4. Quick Check:

   Use colon for tag in FROM [OK]

Hint: Use colon ':' to specify image tag in FROM [OK]

Common Mistakes:

• Using dash '-' instead of colon ':' for tags
• Using slash '/' incorrectly in image name
• Using '@' instead of ':' for tags

3. Given this Dockerfile snippet:

FROM python:3.12-slim
RUN python --version

What will be the output when building this Docker image?

medium

A. Python 3.11.x

B. Python 3.12.x

C. Error: python command not found

D. Python 2.7.x

Solution

1. Step 1: Identify base image version

   The base image is python:3.12-slim, which includes Python version 3.12.

2. Step 2: Understand RUN command output

   The RUN command executes python --version, which prints the Python version installed in the image.

3. Final Answer:

   Python 3.12.x -> Option B

4. Quick Check:

   FROM python:3.12-slim runs Python 3.12 [OK]

Hint: Tag in FROM matches Python version output [OK]

Common Mistakes:

• Assuming default Python version is 3.11 or 2.7
• Thinking slim images lack Python
• Confusing build output with runtime

4. Identify the error in this Dockerfile snippet:

FROM alpine
FROM ubuntu:20.04
RUN echo "Hello"

medium

A. FROM instruction must be last line.

B. Missing tag for alpine image causes error.

C. Multiple FROM instructions without stage names cause error.

D. There is no error in this Dockerfile snippet.

Solution

1. Step 1: Check multiple FROM usage

   Multiple FROM instructions are allowed for multi-stage builds even without stage names (AS). Earlier stages are discarded unless referenced (by name or index).

2. Step 2: Verify other parts

   FROM alpine defaults to :latest (valid image). The RUN applies to the final stage (ubuntu:20.04) and is syntactically correct.

3. Final Answer:

   There is no error in this Dockerfile snippet. -> Option D

4. Quick Check:

   Multiple FROM without AS is valid [OK]

Hint: Multiple FROM instructions do not require stage names [OK]

Common Mistakes:

• Assuming multiple FROM lines always work without names
• Thinking RUN syntax is wrong here
• Believing FROM must be last line

5. You want to build a multi-stage Dockerfile using node:18 as the build stage (named 'build') and nginx:alpine as the final stage. Which FROM instructions correctly set this up?

hard

A. FROM node:18 AS build
FROM nginx:alpine

B. FROM node:18
FROM nginx:alpine AS build

C. FROM node:18
FROM nginx:alpine

D. FROM node:18 AS build
FROM nginx:alpine AS build

Solution

1. Step 1: Understand multi-stage build syntax

   Use AS to name the build stage, e.g., FROM node:18 AS build.

2. Step 2: Set final stage without conflicting names

   The final stage uses FROM nginx:alpine without a stage name or with a different name.

3. Step 3: Check options

   FROM node:18 AS build FROM nginx:alpine correctly names the build stage and then starts the final stage. Others misuse stage names or omit them incorrectly.

4. Final Answer:

   FROM node:18 AS build FROM nginx:alpine -> Option A

5. Quick Check:

   Use AS to name build stage first [OK]

Hint: Name build stage with AS, final stage without or different name [OK]

Common Mistakes:

• Naming both stages the same
• Placing AS on final stage incorrectly
• Omitting AS for build stage in multi-stage