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.