Docker Fundamentals

What is a Container? (Demystified)

The Core Mental Model: A container is not a mini-virtual machine. There is no guest operating system kernel or hypervisor. A container is simply a standard Linux process isolated by the host kernel.

When you run docker run -d -p 80:80 nginx, the Linux host starts a regular process called nginx. However, the Docker daemon wraps that process inside three Linux kernel isolation primitives:

Linux Namespaces: Controls what the process can SEE (its own private process tree, network interfaces, and filesystem).
Control Groups (cgroups): Controls what the process can CONSUME (maximum CPU percentage, memory limits, and I/O rates).
OverlayFS Union Filesystem: Layers read-only image layers under a thin read-write scratch layer.

Docker Under the Hood: Kernel Internals & Architecture

Demystifying Containers: "A Container is Just an Isolated Linux Process"

Containers are not virtual machines. There is no hypervisor and no guest OS. A container is a standard Linux process isolated by the kernel using three foundational primitives: Namespaces (what it can see), Cgroups (what it can consume), and OverlayFS (how its filesystem is layered).

PID Namespace — Process Isolation

The container process sees itself as PID 1, while on the host OS it has a normal PID (e.g. 14230). Cannot see host processes.

The 3 Foundations of Linux Container Isolation

1. Linux Namespaces (Visibility & Scoping)

Namespaces provide process-level virtualization by creating independent partitions for system resources:

Namespace	Linux Flag	What It Isolates	Container Behavior
PID	`CLONE_NEWPID`	Process IDs	The container process sees itself as `PID 1`. It cannot see any other process running on the host or other containers.
NET	`CLONE_NEWNET`	Network stack	Container gets its own private `lo` loopback (127.0.0.1), IP routing table, and virtual ethernet pair (`veth`) attached to `docker0` bridge.
MNT	`CLONE_NEWNS`	Filesystem mount points	Roots the container into its private filesystem, hiding `/home`, `/etc`, and `/var` of the host.
IPC	`CLONE_NEWIPC`	Inter-process communication	Prevents container processes from accessing shared memory segments, semaphores, or message queues of the host.
UTS	`CLONE_NEWUTS`	Hostname and domain	Allows setting a container-specific hostname (`--hostname web-01`) without modifying the host machine's name.
USER	`CLONE_NEWUSER`	User and group IDs	Maps container `root` (UID 0) to an unprivileged UID (e.g. UID 10001) on the host, preventing host root escalation.

2. Control Groups (cgroups) (Resource Guardrails)

While namespaces prevent a container from snooping on the host, cgroups prevent a "noisy neighbor" container from crashing the host:

docker run -m 512m --cpus="1.5" creates a cgroup directory in /sys/fs/cgroup/memory/docker/<container_id>.
If memory usage exceeds 512MB, the Linux kernel's Out-Of-Memory (OOM) killer terminates that container process without affecting the host or other containers.

3. OverlayFS (Layered Union Mount & Copy-on-Write)

Docker images are built as immutable, stacked layers using a union filesystem:

LowerDir (Read-Only): The immutable base OS (e.g., Alpine/Debian) and installed runtime packages.
UpperDir (Read/Write): A thin ephemeral layer created when the container starts. Any new files or edits are written here (Copy-on-Write).
MergedDir: The unified filesystem view that the container process actually sees.

OverlayFS Architecture:
┌────────────────────────────────────────────────────────┐
│ MergedDir: Unified view presented to container process │
├────────────────────────────────────────────────────────┤
│ UpperDir: Ephemeral Read-Write layer (/tmp, modified)  │
├────────────────────────────────────────────────────────┤
│ LowerDir Layer 3: COPY app.jar (Read-Only)             │
│ LowerDir Layer 2: RUN apt-get install (Read-Only)      │
│ LowerDir Layer 1: FROM debian:bookworm (Read-Only)     │
└────────────────────────────────────────────────────────┘

The Container Runtime Hierarchy (Under the Hood)

When you execute docker run, Docker delegates execution down a modular stack governed by Open Container Initiative (OCI) standards:

User CLI: "docker run"
    │
    ▼ REST API / Unix Socket (/var/run/docker.sock)
[ Docker Daemon (dockerd) ]
    │ (High-level: manages networking, volumes, CLI parsing)
    ▼ gRPC
[ containerd ]
    │ (Supervises containers, image pulls, storage snapshots)
    ▼
[ containerd-shim ] ──(Surrogate parent process; enables daemonless containers)
    │
    ▼ CLI invocation
[ runc ] ──(Low-level OCI runtime: invokes clone(), unshare(), pivot_root)
    │
    ▼ (runc exits after spawning)
[ Container Process (e.g. nginx PID 1) ]

Why containerd-shim exists: The shim acts as a lightweight daemonless babysitter process. It holds stdout/stderr pipes open and waits on the container's exit code. This allows dockerd and containerd to crash or be upgraded without terminating running containers!

Containers vs Virtual Machines

Virtual Machines vs Docker Containers vs Kubernetes Orchestration

STACK LAYERS (TOP TO BOTTOM):

Container 1 / Container 2 / Container 3 (App Bin/Libs)

Container Runtime Engine (dockerd / containerd / runc)

Host Linux OS Kernel (Shared cgroups, Namespaces, Syscalls)

Physical Bare-Metal Hardware (CPU, RAM, NIC, SSD)

Docker Containers: Lightweight Kernel Process Isolation

Containers are not virtual machines! They are regular Linux processes isolated by kernel Namespaces, cgroups, and capabilities.

Boot Time: Sub-second (instant process fork).
Isolation: Kernel-level sandboxing (shared kernel).
Overhead: Near-zero — only application memory used.

Image Naming and Tags

docker.io / library / ubuntu : 24.04
    ↑           ↑        ↑       ↑
Registry  Namespace  Image   Tag/version

# Examples:
ubuntu                          # docker.io/library/ubuntu:latest
nginx:1.25                      # docker.io/library/nginx:1.25
mycompany/myapp:1.0.0           # docker.io/mycompany/myapp:1.0.0
123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:v2  # AWS ECR

Tag Best Practices

Tag	Use	Risk
`latest`	Development only	Unpredictable — changes silently
`1.0.0` (semver)	Production ✅	Immutable reference
`sha256:abc123...`	Pinned exact version ✅	Most explicit, never changes

# Always tag with version + latest for production images
docker build -t myapp:1.2.3 -t myapp:latest .

# Pull by digest (guaranteed immutable)
docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2

Container Lifecycle

           docker create
Image  ──────────────────→  Created
                               │
              docker start     │
                               ↓
                            Running ←──── docker restart
                               │
       docker pause            ↓
                            Paused
                               │
       docker unpause          ↓
                            Running
                               │
       docker stop (SIGTERM)   │
       docker kill  (SIGKILL)  ↓
                            Stopped/Exited
                               │
       docker rm               ↓
                            Removed (deleted)

Shortcut: docker run = docker create + docker start

Registries

Public Registries

Registry	URL	Notes
Docker Hub	`hub.docker.com`	Default, largest public registry
GitHub Container Registry	`ghcr.io`	Integrated with GitHub Actions
Google Container Registry	`gcr.io`	Google Cloud
Amazon ECR Public	`public.ecr.aws`	AWS public images

Private Registries

Registry	Notes
Amazon ECR	Private, per AWS account
Google Artifact Registry	Private, replaces GCR
Azure Container Registry	Private, Azure
Harbor	Self-hosted, open source
Nexus Repository	Self-hosted, enterprise

# Login to Docker Hub
docker login

# Login to AWS ECR
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin \
  123456789.dkr.ecr.us-east-1.amazonaws.com

# Tag for ECR
docker tag myapp:1.0.0 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:1.0.0

# Push
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:1.0.0

Key Concepts Summary

Term	Definition
Image	Immutable, layered snapshot of a filesystem + config. Blueprint.
Container	Running (or stopped) instance of an image. Has writable layer.
Dockerfile	Text file with instructions to build an image.
Registry	Remote repository for storing and distributing images.
Layer	Read-only filesystem diff. Multiple layers make up an image.
Tag	Human-readable label pointing to a specific image version.
Digest	Content-addressable SHA256 hash — uniquely identifies an image.
Volume	Persistent storage that survives container restarts.
Network	Virtual network connecting containers.
Docker Compose	Tool for defining multi-container apps in YAML.

Interview Questions

What is a container and how does it differ from a virtual machine?
What are Docker image layers and why do they matter for build performance?
What is the difference between an image and a container?
Why is using the latest tag bad practice in production?
What are Linux namespaces and cgroups? How do they relate to containers?
What happens to data in a container's writable layer when the container is removed?
What is a container registry and name three examples.
Explain the Docker client-daemon architecture.