Terabyte Systems

How Does Docker Containerization Work?

By Sarah Mitchell • • 10 min read
docker containers devops cloud infrastructure

Docker transformed how we build, ship, and run applications by introducing lightweight containerization to the mainstream. After implementing Docker in production environments for over a decade, I’ve seen firsthand how it solves the classic “it works on my machine” problem while providing unprecedented deployment flexibility. This deep dive explains exactly how Docker achieves application isolation without the overhead of virtual machines.

Understanding Containerization

Containerization packages applications with their complete runtime environment—code, dependencies, libraries, and configuration—into a single executable unit. Unlike virtual machines that virtualize hardware, containers virtualize the operating system, sharing the host kernel while maintaining process isolation.

The Key Difference from Virtual Machines

When I migrated production workloads from VMs to containers in 2018, we saw a 60% reduction in resource overhead. Here’s why:

Virtual Machines:

  • Full OS per instance
  • Hypervisor overhead
  • Gigabytes of disk space per VM
  • Minutes to boot
  • Hardware virtualization

Containers:

  • Shared host OS kernel
  • Minimal overhead (process isolation)
  • Megabytes of disk space per container
  • Seconds to start
  • OS-level virtualization

This fundamental difference makes containers ideal for microservices architectures where you need hundreds or thousands of isolated application instances running on the same infrastructure.

Docker’s Core Architecture

Docker’s architecture consists of several components working together to create the containerization magic:

Docker Engine

The Docker Engine is the heart of the system, implementing a client-server architecture:

# Docker daemon (dockerd) runs as a background service
# Docker CLI communicates via REST API

docker run -d --name webserver nginx:latest
# Client sends API request to daemon
# Daemon pulls image and creates container

The daemon (dockerd) manages:

  • Images
  • Containers
  • Networks
  • Volumes
  • Build operations

When you execute docker run, the daemon checks for the image locally, pulls it from a registry if needed, creates a container from that image, allocates a filesystem, mounts a read/write layer, sets up networking, and executes the specified command.

Images and Layers

Docker images use a layered filesystem based on the Union File System (UnionFS). Each instruction in a Dockerfile creates a new layer:

FROM ubuntu:22.04              # Layer 1: Base OS
RUN apt-get update && \        # Layer 2: Package updates
    apt-get install -y python3
COPY app.py /app/              # Layer 3: Application code
CMD ["python3", "/app/app.py"] # Layer 4: Metadata only

Layers are read-only and immutable. When you run a container, Docker adds a thin read-write layer on top. This design enables:

Image Sharing: Multiple containers can share the same base layers, saving disk space. In production, I’ve seen 50 containers based on the same Ubuntu image occupy only slightly more space than a single instance.

Efficient Updates: Rebuilding an image only recreates changed layers. If you update app.py, only Layer 3 needs rebuilding—the base OS and packages remain cached.

Version Control: Each layer has a cryptographic hash, making images tamper-evident and enabling precise version tracking.

Linux Kernel Features Behind Docker

Docker leverages three critical Linux kernel features to provide isolation. Understanding these is essential for debugging container issues and optimizing performance.

Namespaces: Process Isolation

Namespaces create isolated views of system resources. Docker uses six namespace types:

# Create a new container and inspect its namespaces
docker run -d --name test nginx
docker inspect test | grep Pid
# Shows container's main process ID

# Check namespaces on host
ls -l /proc/<PID>/ns/
# mnt    -> Mount namespace (filesystem)
# pid    -> Process ID namespace
# net    -> Network namespace
# ipc    -> Inter-process communication
# uts    -> Hostname namespace
# user   -> User ID namespace

PID Namespace: The container’s process thinks it’s PID 1, but on the host, it has a different PID. This prevents containers from seeing or signaling host processes.

Network Namespace: Each container gets its own network stack—network interfaces, routing tables, firewall rules. When implementing service discovery, I use this to assign each container a unique IP while they all run on the same host.

Mount Namespace: Containers have isolated filesystems. The container sees only its own filesystem tree, unaware of the host’s filesystem structure.

Control Groups (cgroups): Resource Management

Cgroups limit and isolate resource usage—CPU, memory, disk I/O, network bandwidth. This prevents noisy neighbor problems where one container consumes all resources.

# Limit container to 512MB RAM and 50% of one CPU core
docker run -d --name limited \
  --memory="512m" \
  --cpus="0.5" \
  nginx

# Inspect actual limits
docker inspect limited | grep -A 5 "Memory\|Cpu"

In production, I always set memory limits after an incident where an unbounded container consumed 32GB RAM and crashed our orchestration system. Cgroups also enable advanced features like memory swappiness control and CPU pinning for latency-sensitive applications.

Union Filesystem: Layered Storage

Docker supports multiple storage drivers implementing union filesystem functionality:

  • overlay2: Current default, best performance on modern kernels (4.0+)
  • devicemapper: Legacy, used on older RHEL/CentOS
  • btrfs/zfs: Copy-on-write filesystems with advanced features
# Check active storage driver
docker info | grep "Storage Driver"

# overlay2 creates these layers:
# /var/lib/docker/overlay2/<container-id>/
#   ├── diff/      # Container's writable layer
#   ├── lower      # Read-only image layers
#   └── merged/    # Combined view (what container sees)

The overlay2 driver uses copy-on-write: when a container modifies a file from a read-only layer, the entire file is copied to the writable layer before modification. For large files, this can impact performance, which is why I mount volumes for database files or large media.

Container Networking

Docker networking creates isolated network environments while enabling communication between containers and external services.

Network Modes

Docker provides several networking modes, each suited for different use cases:

# Bridge network (default): Containers get private IPs
docker run -d --name web nginx
# Container gets IP like 172.17.0.2

# Host network: Container uses host's network directly
docker run -d --network host --name web-host nginx
# Container binds directly to host ports

# None: No networking
docker run -d --network none --name isolated alpine
# Complete network isolation

Bridge Networking: The default mode creates a private network (docker0 bridge) with NAT to the host. Containers communicate via container names thanks to Docker’s embedded DNS server (127.0.0.11).

In production microservices, I use custom bridge networks for logical service grouping:

# Create separate networks for different tiers
docker network create frontend
docker network create backend

docker run -d --name api --network backend app:latest
docker run -d --name web --network frontend nginx
docker network connect frontend api  # API joins both networks

Port Mapping

Port mapping (publishing) allows external access to containerized services:

# Map host port 8080 to container port 80
docker run -d -p 8080:80 --name web nginx

# Docker sets up iptables rules:
# DNAT: Translate 8080 -> container IP:80
# MASQUERADE: NAT outgoing traffic

When debugging connectivity issues, I check these iptables rules: iptables -t nat -L -n | grep <container-port>.

Docker Volumes: Persistent Storage

By default, container filesystems are ephemeral—data disappears when containers stop. Volumes provide persistent storage.

Volume Types

# Named volume (managed by Docker)
docker volume create appdata
docker run -v appdata:/app/data myapp

# Bind mount (host directory)
docker run -v /host/path:/container/path myapp

# tmpfs mount (memory-only, no persistence)
docker run --tmpfs /tmp:rw,size=1g myapp

Volumes vs Bind Mounts: Volumes are managed by Docker in /var/lib/docker/volumes/ and work across different host platforms. Bind mounts depend on the host filesystem structure. In production, I use volumes for portability and bind mounts only during development for live code reloading.

For database containers, volumes are critical:

# PostgreSQL with persistent data
docker run -d \
  --name postgres \
  -v pgdata:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret \
  postgres:15

# Data survives container recreation
docker stop postgres && docker rm postgres
docker run -d --name postgres -v pgdata:/var/lib/postgresql/data postgres:15
# Database state preserved

Security Considerations

Container security requires a layered approach. Containers share the host kernel, so a kernel exploit in a container can compromise the host.

Security Best Practices

Run as Non-Root User:

FROM ubuntu:22.04
RUN useradd -m -u 1000 appuser
USER appuser
CMD ["./app"]

Read-Only Root Filesystem:

docker run --read-only --tmpfs /tmp myapp
# Container cannot modify its filesystem
# Prevents malware persistence

Security Profiles: Docker applies AppArmor or SELinux profiles by default on supported systems. These restrict container capabilities even if running as root.

Capability Dropping: By default, Docker drops many Linux capabilities. Never add capabilities like CAP_SYS_ADMIN unless absolutely necessary:

# Bad: overly permissive
docker run --privileged nginx

# Good: minimal capabilities
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx

When I audited our production containers, I found several running with --privileged, which essentially disables all isolation. We reduced our attack surface by 90% by removing this flag and adding only necessary capabilities.

Performance Optimization

Container performance comes down to understanding the overhead Docker introduces and optimizing the critical paths.

Build Optimization

Order Dockerfile instructions from least to most frequently changing:

# Wrong: Code changes invalidate dependency layer
FROM node:18
COPY . /app
RUN npm install

# Right: Dependencies cached separately
FROM node:18
COPY package*.json /app/
RUN npm install
COPY . /app

This reduced our CI build times from 8 minutes to 2 minutes by caching the node_modules layer.

Multi-Stage Builds

Separate build and runtime environments:

# Build stage
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o server

# Runtime stage
FROM alpine:3.18
COPY --from=builder /app/server /server
CMD ["/server"]

Our Go microservice images dropped from 800MB to 15MB using this pattern, reducing registry bandwidth and deployment time.

Resource Limits

Always set resource limits in production. I learned this after a memory leak in one container caused system-wide OOM kills:

docker run -d \
  --memory="1g" \
  --memory-reservation="750m" \
  --cpus="1.5" \
  --pids-limit="200" \
  myapp

Container Lifecycle Management

Understanding the container lifecycle is essential for production operations:

# States: created -> running -> paused -> stopped -> removed
docker create nginx           # Created but not started
docker start <container>      # Start existing container
docker pause <container>      # Freeze process execution
docker unpause <container>    # Resume
docker stop <container>       # SIGTERM, then SIGKILL after grace period
docker kill <container>       # Immediate SIGKILL
docker rm <container>         # Delete container

# Check container state
docker inspect <container> | grep Status

Graceful Shutdown: When stopping containers, Docker sends SIGTERM to PID 1, waits for the grace period (default 10s), then sends SIGKILL. Your application should handle SIGTERM for clean shutdown:

import signal
import sys

def handle_sigterm(signum, frame):
    print("Shutting down gracefully...")
    # Close database connections, flush buffers
    sys.exit(0)

signal.signal(signal.SIGTERM, handle_sigterm)

Integration with Orchestration

While Docker handles single-host containerization, production environments require orchestration for multi-host deployments, scaling, and high availability.

Kubernetes is the de facto standard orchestrator. It uses Docker (or containerd directly) as the container runtime while adding:

  • Automatic container placement across nodes
  • Self-healing (restart failed containers)
  • Horizontal scaling
  • Service discovery and load balancing
  • Rolling updates with rollback

Docker Compose works for simpler multi-container applications on a single host:

version: '3.8'
services:
  web:
    image: nginx
    ports: ["8080:80"]
    depends_on: [api]
  api:
    build: ./api
    environment:
      DB_HOST: postgres
  postgres:
    image: postgres:15
    volumes: [pgdata:/var/lib/postgresql/data]
volumes:
  pgdata:

For production, I recommend Kubernetes for critical workloads and Docker Compose for development environments or simple deployments.

Troubleshooting Common Issues

From years of running containers in production, here are the most common issues and solutions:

Container Immediately Exits: Check logs and ensure CMD/ENTRYPOINT runs a foreground process:

docker logs <container>
# Common mistake: CMD ["/app/start.sh"]
# start.sh exits immediately
# Solution: Ensure script runs foreground process or exec

Network Connectivity: Verify DNS resolution and network connectivity:

docker exec <container> ping api.service
docker exec <container> nslookup api.service

Disk Space Issues: Clean up unused images and volumes:

docker system df           # Show disk usage
docker system prune -a     # Remove all unused resources
docker volume prune        # Remove unused volumes

Performance Problems: Check resource limits and kernel parameters:

docker stats              # Real-time resource usage
cat /proc/sys/fs/file-max # Check file descriptor limits

Conclusion

Docker’s containerization works through a sophisticated combination of Linux kernel features—namespaces for isolation, cgroups for resource management, and union filesystems for efficient storage. Understanding these fundamentals enables you to design better container architectures, debug production issues, and optimize performance.

The key takeaways from implementing Docker at scale:

  • Containers are processes with enhanced isolation, not lightweight VMs
  • Image layering enables efficient storage and fast deployments
  • Proper resource limits prevent noisy neighbor problems
  • Security requires multiple layers of defense
  • Container orchestration (Kubernetes) is essential for production at scale

For further learning, explore the official Docker documentation, review the Open Container Initiative (OCI) specifications, and experiment with containerd, the underlying container runtime. The Linux kernel documentation on namespaces and cgroups provides deep technical details. For security best practices, consult the CIS Docker Benchmark and Docker’s security documentation.

Thank you for reading! If you have any feedback or comments, please send them to [email protected] or contact the author directly at [email protected].