Docker Architecture

Docker uses a client-server architecture. The docker command you type is the client. The long-running background service, dockerd, is the daemon. The daemon does the heavy work: building images, running containers, managing networks, managing volumes, and talking to registries.

Architecture Map

User
 |
 v
Docker CLI / Docker Compose / SDK
 |
 | Docker Engine API
 | local UNIX socket or remote network connection
 v
Docker daemon: dockerd
 |
 +--> images
 +--> containers
 +--> networks
 +--> volumes
 +--> registry pull/push
 |
 v
container runtime layer
 |
 v
Linux kernel features
 |
 v
container process

Key Insight: The Docker CLI does not run containers by itself. It sends API requests to the Docker daemon, and the daemon coordinates the work.

Core Components

Component	Role
Docker client	Command-line or API client used by humans and tools
Docker daemon (dockerd)	Background service that manages Docker objects and handles API requests
Docker Engine API	API used by the client to talk to the daemon
Images	Read-only packages used to create containers
Containers	Running instances of images
Networks	Connectivity between containers, host, and outside systems
Volumes	Persistent storage managed outside the container writable layer
Registries	Remote systems that store and distribute images

Docker Daemon Service

The Docker daemon is the engine process. On Linux servers, it commonly runs as a background service. On Docker Desktop, the daemon is managed by Docker Desktop.

docker command
     |
     v
Docker Engine API request
     |
     v
dockerd
     |
     +--> create container
     +--> pull image
     +--> build image
     +--> create network
     +--> attach volume

The daemon listens for API requests and manages Docker objects:

• images
• containers
• networks
• volumes
• plugins
• build cache

The client and daemon can run on the same machine, which is the common local setup. They can also be separated, where a local client talks to a remote daemon.

Warning: Protect access to the Docker daemon socket. A user or process that can control the daemon can usually control containers, images, mounts, and potentially sensitive host resources.

Docker Client

The Docker client is what you interact with:

docker run nginx
docker build -t my-app:1.0 .
docker pull redis
docker push registry.example.com/team/api:1.0

Each command becomes an API request to the daemon.

docker run nginx
      |
      v
client sends "create/start container" request
      |
      v
dockerd performs the work

Docker Compose is also a Docker client. It reads a Compose file and sends multiple Docker API requests to create networks, volumes, and containers for a multi-container application.

Docker Registries

A registry stores container images.

Common examples:

• Docker Hub
• private Docker registries
• cloud registries such as Amazon ECR, Azure Container Registry, and Google Artifact Registry
• self-hosted registries inside an organization

The important hierarchy is:

Registry
  |
  +-- Repository
        |
        +-- Image tags
        +-- Image digests

Example image reference:

registry.example.com/team/api:1.0
|------------------| |------| |---|
     registry       repository tag

If no registry is specified, Docker uses its default registry configuration, commonly Docker Hub.

Registry vs Repository vs Tag

Term	Meaning
Registry	Server or service that stores images
Repository	Named collection of related images inside a registry
Tag	Human-friendly label for an image version, such as 1.0 or latest
Digest	Content-addressed identifier for an exact image

Tip: Tags are convenient, but digests are more precise. A tag can be moved; a digest identifies a specific image content.

What Happens During docker run

docker run nginx
      |
      v
Docker client sends request to dockerd
      |
      v
dockerd checks local image store
      |
      +-- image exists locally -> use it
      |
      +-- image missing -> pull from registry
                           |
                           v
                     store image layers locally
      |
      v
dockerd creates container filesystem and config
      |
      v
runtime starts container process
      |
      v
app runs

The container is defined by both:

• the image
• runtime options, such as ports, environment variables, volumes, network, command override, and resource limits

What Happens During Build and Push

Dockerfile + build context
      |
      | docker build -t registry.example.com/team/api:1.0 .
      v
local image
      |
      | docker push registry.example.com/team/api:1.0
      v
registry repository

Build creates an image from a Dockerfile and build context. Push uploads the image layers and metadata to a registry so another machine can pull and run it.

Local Image Store

Docker keeps downloaded and built images locally. This avoids downloading the same layers every time.

Local Docker host
 
+----------------------------------+
| containers                       |
+----------------------------------+
| local image store                |
+----------------------------------+
| Docker daemon                    |
+----------------------------------+
| host OS                          |
+----------------------------------+

When images change, Docker can reuse unchanged layers and only fetch or build what is different.

Docker Desktop Note

On Linux, Docker Engine runs directly on the Linux host. On macOS and Windows, Docker Desktop provides the Linux container environment needed to run Linux containers and manages the daemon for you.

This is why the architecture feels the same from the CLI:

docker command
    |
    v
Docker Desktop managed environment
    |
    v
dockerd + runtime
    |
    v
Linux container process

Mental Model

CLI:       asks for work
Daemon:    performs and coordinates work
Image:     packaged filesystem and metadata
Container: running instance of an image
Registry:  remote image storage
Runtime:   starts the isolated process
Kernel:    enforces isolation and resource controls

TL;DR

• Docker is client-server: docker talks to dockerd.
• dockerd is the daemon service that builds images, runs containers, and manages Docker objects.
• The client and daemon communicate through the Docker Engine API.
• Registries store images; repositories group related images; tags label image versions.
• docker run may pull an image, create a container, configure networking/storage, and start the process.
• Protect daemon access because controlling Docker can mean controlling powerful host-level behavior.

Resources

Docker: What is Docker? Official architecture overview covering client, daemon, registries, and Docker objects.

dockerd CLI reference Official Docker daemon reference.

Docker: What is a registry? Official explanation of registries, repositories, and image publishing.

Docker: What is an image? Official explanation of image packages, immutability, and layers.

Protect the Docker daemon socket Official Docker guidance for securing daemon access.