Docker: Fundamentals

Why Docker? The Problems It Solves

Consider the following scenario: You have built an application that works perfectly on your machine. You hand it to a colleague, and it fails immediately. The culprit? Different Python versions, missing libraries, or conflicting configurations. Docker eliminates this entire class of problems.

Essential Docker Commands

Before running any Docker commands, it helps to understand the mental model: Docker images are like recipes (blueprints), while containers are the actual dishes you create from those recipes. You can make many containers from the same image, and each one runs independently.

# Run an interactive Ubuntu container
docker run -it ubuntu:22.04 bash

# You are now inside a minimal Linux system
cat /etc/os-release && exit

# Run Nginx web server in the background
docker run -d -p 8080:80 --name my-web nginx

# Visit http://localhost:8080, then clean up
docker stop my-web && docker rm my-web

# Dockerfile - save this file, then build with: docker build -t my-app .
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

# Build and run your custom image
docker build -t my-app .
docker run -d -p 5000:5000 my-app

# docker-compose.yml
version: '3.8'
services:
  web:
    build: .
    ports:
      - "5000:5000"
    depends_on:
      - redis
  redis:
    image: redis:alpine

# Start all services with one command
docker-compose up -d

# Stop everything
docker-compose down

Understanding Container Technology

Before diving into Docker’s specific implementation, it helps to understand how containers differ from traditional virtualization. This context will help you make informed decisions about when to use each approach.

Containers vs Virtual Machines

Consider the following when choosing between containers and VMs:

What Containers Guarantee

Containers provide strong guarantees in several areas:

• Application dependencies: All libraries and tools are bundled together, eliminating “missing dependency” errors
• Configuration: Environment settings travel with the container, making deployments reproducible
• Isolation: Each container has its own filesystem and process space, preventing conflicts between applications
• Portability: The same container runs on any machine with Docker installed

What Containers Cannot Guarantee

However, some factors remain outside container control:

• Kernel features: Containers share the host kernel, so a container expecting Linux 5.x features will not work on a host running Linux 4.x
• Hardware access: GPU acceleration, specialized devices, and host-specific resources may behave differently across machines
• Resource limits: CPU and memory constraints vary by host, affecting performance consistency
• Platform differences: A Linux container cannot run natively on Windows without a Linux VM layer

Practical guidance: For maximum portability, avoid dependencies on specific kernel versions or hardware features. When these are unavoidable, document the requirements clearly.

Now that we understand what containers do, let’s briefly look at how Docker implements them. You do not need to memorize these details to use Docker effectively, but understanding the architecture helps when troubleshooting or optimizing performance.

Docker Architecture Overview

Docker uses a layered architecture where each component has a specific responsibility:

Container Runtime Basics

At its core, a container is defined by:

• Filesystem: What files the container can see (its “root filesystem”)
• Namespaces: Isolation boundaries for processes, network, users, and more
• Cgroups: Resource limits for CPU, memory, and I/O
• Security: Capabilities, seccomp profiles, and mandatory access controls

The Open Container Initiative (OCI) standardizes these specifications, allowing containers to run on any compliant runtime.

Note: Most users never interact with these low-level components directly. Docker’s CLI abstracts away this complexity while giving you control when needed.

Docker Network Architecture

Networking is often the trickiest part of containerization. Containers need to communicate with each other, with the host, and with external services, all while maintaining isolation. Docker provides several network drivers for different scenarios.

Network Driver Quick Reference

How Bridge Networking Works

When you run a container without specifying a network, Docker uses the default bridge network. Here is what happens:

1. Docker creates a virtual network interface pair (veth)
2. One end attaches to the container, the other to a bridge on the host
3. The container gets an IP address from Docker’s internal DHCP
4. Containers on the same bridge can communicate by IP
5. For external access, Docker uses NAT and port mapping

Key insight: Containers on the same user-defined bridge network can find each other by container name (automatic DNS). The default bridge does not have this feature, which is why creating custom networks is recommended.

When to Use Each Network Type

• bridge: Development, single-host deployments, isolated applications
• host: Performance-critical applications, when container port must match host port
• overlay: Docker Swarm services spanning multiple hosts
• macvlan: When container must appear as physical device on network (legacy integration)
• none: Security-sensitive workloads that should have no network access