How Docker Works: Architecture & Containers

What Is a Container? Start Here.

Forget the jargon for a moment. A container is like a shrink-wrapped box containing everything your app needs to run: the code, the Python interpreter, the database driver, even the specific version of Linux libraries.

When you ship a physical product, you put it in a box. The box protects it during transport. A software container works the same way—it isolates your application from the outside world. Inside the container, your app thinks it owns the entire computer. Outside, multiple containers share the same machine without interfering with each other. Think of it this way: your laptop might have Python 3.9 installed, but a container might need Python 3.11. Both versions run side-by-side without conflict.

The magic happens because Docker uses Linux kernel features called namespaces and cgroups. Namespaces create isolated views of system resources—each container sees its own file system, network interfaces, and process IDs. Cgroups limit how much CPU and memory each container can use. Together, they isolate containers with minimal overhead, which is why Docker is so much faster than traditional virtual machines.

Docker vs. Virtual Machines: Why Containers Win

Before Docker, teams used virtual machines (VMs) to isolate applications.

A VM is heavy. It emulates an entire computer—it needs its own operating system, which eats ~2GB of RAM and takes minutes to boot. If you run 10 VMs on one server, you're running 10 operating systems. Docker containers share the host's operating system kernel, so each container uses only ~5-15MB of RAM and starts in milliseconds. A single server can run 50+ containers where it might run only 3-4 VMs.

Here's the practical difference:

• Virtual Machine: Host OS + Hypervisor + Guest OS + App. 3-5 minutes to start. Hundreds of MB per instance.
• Docker Container: Host OS + Docker Engine + App. ~50ms to start. 5-15MB per instance.
• Winner: Containers for speed and density. VMs for maximum isolation if you need to run Windows apps on a Linux server.

We'll dive deeper into this comparison in our Docker vs Virtual Machines guide, but the short version: containers let you pack more applications on less hardware.

The Docker Architecture: Layers You Should Know

Docker's architecture has three key parts: the Docker Engine, images, and containers.

The Docker Engine is software that runs on your computer or server. It manages images and runs containers. When you type a Docker command, it talks to the Engine, which does the actual work. The Engine includes a daemon (a background process) and a CLI (command-line interface). You don't need to know about this to use Docker, but it's good to know something is managing containers behind the scenes.

A Docker image is a blueprint. It's a read-only template that says: "To run my app, start with Ubuntu Linux, install Python 3.11, copy my code, and run this command." Images are built in layers. Each instruction in a Dockerfile creates a new layer. This layering system is crucial—Docker caches layers, so rebuilding an image is fast. If only your code changed, Docker reuses the layers for the OS and dependencies.

A Docker container is a running instance of an image. You can create 100 containers from one image, just like you can print 100 copies of a blueprint. Each container has its own file system, network, and isolated process space, but they all share the host's operating system kernel through namespaces and cgroups.

Building a Docker Image: The Dockerfile Explained

This is where Docker gets concrete.

A Dockerfile is a text file with instructions. Each instruction creates a layer. Here's a real example:

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Breaking this down:

• FROM python:3.11-slim — Start with Python 3.11. Docker pulls this pre-made image from Docker Hub (think of it as GitHub for images). This is Layer 1.
• WORKDIR /app — Set the working directory inside the container to /app. Layer 2.
• COPY requirements.txt . — Copy requirements.txt from your computer into the container. Layer 3.
• RUN pip install -r requirements.txt — Install Python packages. This layer captures the installed packages. Layer 4.
• COPY . . — Copy your entire application code into the container. Layer 5.
• CMD ["python", "app.py"] — When the container starts, run this command. Layer 6.

When you build this image with docker build -t myapp ., Docker executes each instruction, creates each layer, and stacks them. The beauty: if you rebuild and only Layer 5 (your code) changed, Docker reuses Layers 1-4 from cache. No need to reinstall Python or packages.

Each layer is immutable. Once created, it never changes. This immutability makes Docker reliable and predictable.

How Containers Run: Namespaces and cgroups in Action

This is the technical heart of Docker, explained simply.

When Docker starts a container, it uses Linux kernel features to isolate it. Namespaces create separate views of resources. There are six types:

• PID namespace: Each container sees its own process IDs. Your app thinks it's PID 1 (the main process), even though the host sees it differently.
• Network namespace: Each container gets its own network interfaces, IP address, and port space. Two containers can both use port 80 without conflict.
• Mount namespace: Each container has its own file system. It can't see files outside its designated directories.
• IPC namespace: Isolates inter-process communication.
• UTS namespace: Each container has its own hostname.
• User namespace: Maps user IDs inside the container to different IDs on the host, adding security.

Then there are cgroups (control groups). These limit resources. You can tell Docker: "This container gets maximum 512MB RAM and 0.5 CPU cores." The kernel enforces these limits. One container can't starve others by hogging memory.

Together, namespaces and cgroups create isolation with minimal overhead. That's why Docker containers are so fast and efficient compared to virtual machines.

Container Networking: How Containers Talk to Each Other

By default, Docker creates a bridge network.

Imagine a private network switch inside your computer. Each container plugs into this switch and gets an internal IP address (like 172.17.0.2). Containers can ping each other by name. A web server container named "api" can reach a database container named "postgres" by calling "postgres:5432" without knowing its IP.

Docker also supports three other networking modes: host (container shares the host's network), overlay (for containers across multiple servers), and macvlan (containers get their own MAC addresses). For beginners, the default bridge network is enough.

Port publishing is how the outside world reaches containers. If your web server listens on port 80 inside the container, you can publish it to port 8080 on the host. External traffic goes to port 8080 → Docker routes it to port 80 inside the container. This isolation means you can run five different web servers, each on port 80 inside their containers, all published to different host ports (8080, 8081, 8082, etc.).

Running Your First Container: Commands That Work

You don't need to build an image to run a container.

Docker Hub hosts millions of pre-made images. Let's run a simple one:

docker run -d -p 8080:80 --name webserver nginx

This command:

• run — Start a new container
• -d — Run in the background (detached)
• -p 8080:80 — Map port 8080 on your computer to port 80 in the container
• --name webserver — Give the container a friendly name
• nginx — The image to use (Docker downloads it from Docker Hub if you don't have it locally)

Now visit http://localhost:8080 in your browser, and you'll see the Nginx welcome page. The web server is running inside a container. To stop it: docker stop webserver. To see running containers: docker ps. To see all containers (running and stopped): docker ps -a.

That's the basic workflow. Build or pull an image, run a container, map ports, and interact with it.

Docker Compose: Managing Multiple Containers

Real applications need multiple services. A typical app has a web server, a database, a cache, a message queue.

Running them individually with docker run commands gets messy fast. Docker Compose solves this with a YAML file. You define all services, networks, and volumes in one file, then start everything with one command: docker-compose up. All containers start in the correct order and connect to each other automatically. Check out our full guide on Docker Compose for Multi-Container Apps for details, but know that Compose is the standard tool for local development and small deployments.

Container Orchestration: What Kubernetes Does

Docker Compose works great on one machine. But what if you need to run 100 containers across 10 servers?

That's where orchestration comes in. Kubernetes (often called K8s) automatically manages containers across clusters. It handles scaling (spin up 10 more containers if traffic spikes), load balancing (distribute traffic evenly), and failure recovery (restart containers that crash). Learn more in our Kubernetes and Container Orchestration guide, but the key point: Docker containers are the building blocks, and orchestrators like Kubernetes manage them at scale.

Frequently Asked Questions