Docker Architecture: End-to-End

Visualizing how Docker builds, ships, and runs applications using the Client-Server architecture.

1. Docker Client (CLI)

Where you issue commands. The client talks to the Docker Daemon via a REST API.

$ docker build -t myapp .
$ docker run -d -p 80:80 myapp
$ docker push myapp:1.0

Role

Sends instructions to the Docker Host.

API Request
▼
2. Docker Host (The Engine)

The machine running the Docker Daemon.

Docker Daemon (dockerd)

Listens for API requests and manages Images, Containers, Networks, and Volumes.

Images
Immutable layers
Containers
Running instances
Networks
Connectivity
Volumes
Persistent data
How they fit together
Image (build) → Container (run) → Network (talk)
Volume (persist) → mounts into Container
Images (Blueprints)

Read-only templates used to create containers.

App Code
Libraries
Base OS (Alpine)

Built from Dockerfile

Containers (Running)

Runnable instances of an image.

R/W Layer
App Code
Libraries
Base OS (Alpine)

Image + Writeable Layer

Pull / Push
▼
3. Registry

Stores and distributes Docker images (public or private).

e.g., Docker Hub, AWS ECR, Google Artifact Registry.

nginx 1.23 latest
myapp v1.0

Actions

PULL PUSH

Virtual Machines vs. Containers

Virtual Machine
More isolation, more overhead
Container
Lightweight, fast startup
App
App
Bins / Libs
Bins / Libs
Guest OS
per VM
No Guest OS
uses host kernel
Hypervisor
shared across VMs
Docker Engine
shared across containers
Shared foundation: Host OS kernel + hardware

VMs duplicate the OS per workload; containers share the host kernel and isolate at the process/filesystem level.

Port Publishing (Why you need -p host:container)

Containers live behind Docker’s networking boundary. Publishing a port creates a controlled route from your host into the container.

Browser / App

You hit a host port.

localhost:9000
▼
Docker Engine

Publishes a host port to a container port.

-p 9000:80
▼
Container

Your app listens on its internal port.

nginx:80