fogserv.cloud fogserv.cloud

Docker Concepts - Understanding Containers

Status: Active
Last Updated: 2026-01-30
Category: Containers - Fundamentals
Prerequisites: kb/basics/linux-fundamentals
Time: 2-3 hours
Tags: docker, containers, virtualization, concepts, architecture

Summary

Understand what containers are, why they exist, and how Docker revolutionized application deployment. Learn the fundamental concepts before touching any commands - a solid mental model makes everything else easier.

🎯 What You'll Learn

By the end of this article, you'll be able to:

🤔 The Problem Docker Solves

"Works on My Machine" Syndrome

Classic scenario:

Developer:  "The app works fine on my laptop!"
QA:         "I can't get it to run in the test environment."
Ops:        "It crashes in production with a weird dependency error."

Why This Happens:

Docker's Solution: Package the entire application environment together.

📦 What is a Container?

The Simple Definition

Container: A lightweight, standalone package that includes everything needed to run an application:

Key Concept: Containers share the host OS kernel but provide isolated user spaces.

Containers vs Traditional Deployment

Traditional Deployment:

Physical Server
├── Operating System
└── Application 1
    ├── Dependencies
    ├── Conflicts with other apps
    └── Hard to move to another server

Container Deployment:

Physical Server
├── Operating System
├── Docker Engine
├── Container 1 (App + Dependencies)
├── Container 2 (App + Dependencies)
└── Container 3 (App + Dependencies)
     ↑ Each isolated, no conflicts

🖥️ Containers vs Virtual Machines

The Key Difference

Virtual Machines:

Physical Hardware
├── Host OS
├── Hypervisor (VMware, VirtualBox, Hyper-V)
├── VM 1
│   ├── Guest OS (full Ubuntu install) ← 2GB+ RAM
│   └── Application
├── VM 2
│   ├── Guest OS (full CentOS install) ← 2GB+ RAM
│   └── Application

Containers:

Physical Hardware
├── Host OS
├── Docker Engine
├── Container 1 (App + libs) ← 50MB
├── Container 2 (App + libs) ← 30MB
└── Container 3 (App + libs) ← 100MB
     ↑ Share host OS kernel

Comparison Table

Feature Virtual Machines Containers
Startup Time Minutes Seconds
Disk Size GBs MBs
Performance Slower (overhead) Near-native
Isolation Strong (full OS) Process-level
Portability Heavy (VM image) Lightweight
OS Diversity Can run different kernels Must match host kernel
Resource Usage Heavy Light

When to Use VMs:

When to Use Containers:

🏗️ Docker Architecture

The Three Main Components

1. Docker Client (docker command):

2. Docker Daemon (dockerd):

3. Docker Registry (Docker Hub, Harbor):

Visual Architecture:

┌──────────────────────────────────────────────────┐
│  Docker Client (docker CLI)                      │
│  $ docker run nginx                              │
└─────────────────┬────────────────────────────────┘
                  │ REST API
┌─────────────────▼────────────────────────────────┐
│  Docker Daemon (dockerd)                         │
│  ┌─────────────────────────────────────────┐    │
│  │  Container Management                    │    │
│  │  ├── nginx (running)                     │    │
│  │  ├── postgres (running)                  │    │
│  │  └── redis (stopped)                     │    │
│  ├─────────────────────────────────────────┤    │
│  │  Image Management                        │    │
│  │  ├── nginx:latest                        │    │
│  │  ├── postgres:15                         │    │
│  │  └── redis:7                             │    │
│  ├─────────────────────────────────────────┤    │
│  │  Network Management                      │    │
│  │  Volume Management                       │    │
│  └─────────────────────────────────────────┘    │
└─────────────────┬────────────────────────────────┘
                  │
┌─────────────────▼────────────────────────────────┐
│  Docker Registry (Docker Hub)                    │
│  - Public images: nginx, postgres, redis         │
│  - Your private images                           │
└──────────────────────────────────────────────────┘

🎨 Key Docker Concepts

1. Images (The Blueprint)

Image: Read-only template used to create containers.

Think of it like:

Image Characteristics:

Example Images:

nginx:latest        # Web server
postgres:15         # Database
node:20-alpine      # Node.js runtime
python:3.11-slim    # Python runtime
ubuntu:22.04        # Base OS

2. Containers (Running Instance)

Container: Running instance of an image.

Lifecycle:

Image → Create → Start → Running → Stop → Remove
         ↓         ↓        ↓        ↓       ↓
       Exists   Exists   Active   Exists  Gone

Container Characteristics:

One Image, Many Containers:

nginx:latest (image)
  ├── nginx-web1 (container - running)
  ├── nginx-web2 (container - running)
  └── nginx-test (container - stopped)

3. Dockerfile (The Recipe)

Dockerfile: Text file with instructions to build an image.

Simple Example:

# Start from existing image
FROM python:3.11-slim

# Set working directory
WORKDIR /app

# Copy requirements file
COPY requirements.txt .

# Install dependencies
RUN pip install -r requirements.txt

# Copy application code
COPY . .

# Command to run
CMD ["python", "app.py"]

Builds Into: Your custom image that can create containers.

4. Volumes (Persistent Data)

Problem: Containers are ephemeral - data disappears when deleted.

Solution: Volumes - persistent storage outside container.

Types:

1. Named Volumes (managed by Docker)
   docker volume create mydata
   
2. Bind Mounts (link to host directory)
   /home/user/data → /app/data in container
   
3. tmpfs (in-memory, temporary)
   Fast but lost on stop

5. Networks (Container Communication)

Containers need to communicate:

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│   Web App    │─────▶│   Database   │      │    Redis     │
│  Container   │      │  Container   │◀─────│  Container   │
└──────────────┘      └──────────────┘      └──────────────┘
        ↑                                            ↑
        └────────────── Same Network ───────────────┘

Network Types:

6. Registry (Image Distribution)

Registry: Storage and distribution system for images.

Public Registries:

Private Registries:

Image Naming:

[registry-host]/[namespace]/[repository]:[tag]

Examples:
nginx:latest                              # Docker Hub (default)
docker.io/nginx:latest                    # Explicit Docker Hub
ghcr.io/username/myapp:v1.0              # GitHub
harbor.example.com/production/api:latest  # Self-hosted

🔄 Docker Image Layers

Understanding Layered Filesystem

Each Dockerfile instruction creates a layer:

FROM ubuntu:22.04           # Layer 1: Base OS (80MB)
RUN apt-get update          # Layer 2: Package updates (20MB)
RUN apt-get install nginx   # Layer 3: Nginx install (15MB)
COPY app.conf /etc/nginx/   # Layer 4: Config (1KB)

Resulting Image:

┌──────────────────────────┐
│ Layer 4: Config (1KB)    │ ← Top (newest)
├──────────────────────────┤
│ Layer 3: Nginx (15MB)    │
├──────────────────────────┤
│ Layer 2: Updates (20MB)  │
├──────────────────────────┤
│ Layer 1: Ubuntu (80MB)   │ ← Bottom (base)
└──────────────────────────┘
Total: ~115MB

Benefits of Layers:

  1. Caching: Unchanged layers reused (faster builds)
  2. Sharing: Common base layers shared between images
  3. Efficiency: Only changed layers downloaded/uploaded

Example Efficiency:

Image A: ubuntu + python + app1
Image B: ubuntu + python + app2

They share ubuntu and python layers!
Only app1 and app2 are unique.

🐋 Docker vs Podman

What is Podman?

Podman: "Pod Manager" - Docker alternative with key differences.

Created By: Red Hat
Philosophy: Daemonless, rootless, Kubernetes-compatible

Key Differences

Feature Docker Podman
Daemon Yes (dockerd) No (daemonless)
Root Required Yes (historically) No (rootless default)
CLI Compatibility Original Drop-in replacement
Pods Support No (single containers) Yes (Kubernetes pods)
Image Format OCI-compatible OCI-compatible
Docker Compose Built-in podman-compose (separate)
Systemd Integration Limited Excellent
Enterprise Docker EE (commercial) Free/open-source

Podman Advantages

1. Daemonless:

Docker:  CLI → Daemon (runs as root) → Containers
Podman:  CLI → Directly manage containers

2. Rootless by Default:

# Run as regular user (no sudo)
podman run nginx

# Docker requires root or docker group
sudo docker run nginx  # or add user to docker group

3. Pod Support (like Kubernetes):

# Create pod with multiple containers
podman pod create --name webapp

# Add containers to pod
podman run --pod webapp nginx
podman run --pod webapp postgres

4. Systemd Integration:

# Generate systemd unit files
podman generate systemd --new --name myapp > myapp.service

# Enable container as service
systemctl --user enable myapp.service

When to Use Podman vs Docker

Use Docker When:

Use Podman When:

The Good News: Commands are nearly identical!

# Docker
docker run nginx
docker build -t myapp .
docker ps

# Podman (same commands!)
podman run nginx
podman build -t myapp .
podman ps

# Even create alias
alias docker=podman

🎯 When to Use Containers

Perfect Use Cases

1. Microservices Architecture:

┌──────────┐  ┌──────────┐  ┌──────────┐
│ Frontend │  │ Auth API │  │  Orders  │
│Container │  │Container │  │ Container│
└──────────┘  └──────────┘  └──────────┘
Each service in own container, independent scaling

2. Development Environments:

# Need Postgres 15? One command:
docker run -d postgres:15

# Done testing? Delete:
docker rm -f postgres

# No system pollution!

3. CI/CD Pipelines:

Build → Test → Package → Deploy
 ↓       ↓        ↓         ↓
Container at each stage, consistent environment

4. Application Isolation:

App A needs Python 3.8
App B needs Python 3.11
No problem - different containers!

5. Easy Scaling:

# Need 5 web servers?
docker-compose up --scale web=5

When NOT to Use Containers

1. GUI Applications (traditionally):

2. Kernel-Level Work:

3. Massive State:

4. Windows-Specific Apps (on Linux):

🧠 Mental Models

Think of Docker As...

Shipping Containers:

Physical Shipping Container:
- Standardized size
- Contains anything
- Works on any ship/truck/train
- Isolated contents

Docker Container:
- Standardized format (OCI)
- Contains any application
- Runs on any Docker host
- Isolated processes

Recipe Book:

Dockerfile = Recipe
Image = Prepared meal (frozen)
Container = Heated and served meal
Registry = Recipe collection

Housing:

Image = House blueprint
Container = Actual house built from blueprint
Registry = Blueprint library
Volume = Furniture (persistent stuff)
Network = Roads connecting houses

🚀 The Docker Workflow

Typical Development Cycle:

1. Write Dockerfile (define environment)
   ↓
2. Build image (docker build)
   ↓
3. Run container locally (docker run)
   ↓
4. Test and iterate
   ↓
5. Push to registry (docker push)
   ↓
6. Pull on servers (docker pull)
   ↓
7. Run in production (docker run)

Key Insight: Same image runs everywhere!

💡 Core Principles

1. Immutability:

2. Disposability:

3. Separation of Concerns:

4. Single Process Per Container:

5. Build Once, Run Anywhere:

🔗 What's Next?

Now that you understand container concepts:

Installation:

Hands-On:

Building Images:

📚 Resources

Official Documentation:

Learning:

Reference:

📝 Change Log

2026-01-30

Next Article: docker-installation - Get Docker and Podman installed!

Choose Theme

Your selection is saved locally.

Neural Cacophony
Aperture v2
Flux v1
Mosaic Chaos
Nexus v1
Nexus Zest
Prism v2
Synapse