Docker architecture (client, daemon, registry) - Step-by-Step Execution

Process Flow - Docker architecture (client, daemon, registry)

User runs Docker Client

↓

Docker Client sends commands

↓

Docker Daemon receives commands

↓

Daemon builds, runs containers

↓

Daemon pulls/pushes images

↓

Docker Registry stores images

User uses Docker Client to send commands to Docker Daemon, which manages containers and interacts with Docker Registry to store or retrieve images.

Execution Sample

Docker

docker pull nginx
# Client sends pull command
# Daemon contacts Registry
# Image downloaded locally

Shows how Docker Client requests an image pull, Daemon fetches it from Registry, and stores it locally.

Process Table

Step	Component	Action	Result	Next Step
1	User	Runs 'docker pull nginx'	Command sent to Docker Client	Docker Client sends command to Daemon
2	Docker Client	Receives user command	Sends API request to Docker Daemon	Docker Daemon processes request
3	Docker Daemon	Receives pull request	Contacts Docker Registry for 'nginx' image	Registry responds with image data
4	Docker Registry	Receives request	Sends image layers to Daemon	Daemon downloads image layers
5	Docker Daemon	Downloads image layers	Stores image locally	Pull complete, ready to run container
6	Docker Client	Notifies user	'nginx' image pulled successfully	User can run container now

💡 Image 'nginx' fully downloaded and stored locally; pull command completed

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	Final
Command	None	'docker pull nginx'	'docker pull nginx' sent	'nginx' image layers downloading	'nginx' image stored locally
Image Local Storage	Empty	Empty	Empty	Partial layers stored	Complete 'nginx' image stored

Key Moments - 3 Insights

Why does the Docker Client not download the image directly?

Docker Client only sends commands; the Docker Daemon handles downloading and storing images, as shown in steps 2 and 3 of the execution table.

What role does the Docker Registry play in the pull process?

The Registry stores images and sends image data to the Daemon when requested, as seen in step 4 where the Registry sends image layers.

When is the image available locally to run containers?

After the Daemon downloads and stores all image layers locally, shown in step 5, the image is ready to use.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the Docker Daemon contact the Registry?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Check the 'Action' column for when the Daemon contacts the Registry (Step 3).

According to the variable tracker, what is the state of 'Image Local Storage' after Step 4?

A Empty

B Complete 'nginx' image stored

C Partial layers stored

D 'docker pull nginx' sent

💡 Hint

Look at the 'Image Local Storage' row under 'After Step 4' in the variable tracker.

If the Docker Client failed to send the command, which step would not occur?

A Step 1

B Step 2

C Step 3

D Step 6

💡 Hint

Step 2 depends on the Client sending the command; if it fails, Daemon never receives it.

Concept Snapshot

Docker architecture has three main parts:
- Docker Client: User interface sending commands
- Docker Daemon: Background service managing containers and images
- Docker Registry: Remote storage for images
Client sends commands to Daemon, which pulls/pushes images from/to Registry and runs containers.

Full Transcript

Docker architecture consists of three parts: the Client, Daemon, and Registry. The user runs commands on the Docker Client, which sends these commands to the Docker Daemon. The Daemon manages container lifecycle and image storage. When pulling an image, the Daemon contacts the Docker Registry to download image layers and stores them locally. Once the image is fully downloaded, the user can run containers from it. This flow separates user commands from container management and image storage, making Docker efficient and modular.