Module 2 Lesson 1: The Docker Architecture

Docker uses a Client-Server architecture. When you type a command into your terminal, you are talking to a program (the Client) that then talks to another program (the Server) that does the heavy lifting.

1. The Three Main Components

A. The Docker Client (docker CLI)

The client is what you interact with. When you run docker run, the client sends this command to the dockerd (the daemon).

• Analogy: The remote control for your TV.

B. The Docker Host (The Daemon / Server)

The host runs the Docker Daemon (dockerd). It listens for requests from the client and manages all the objects:

• Images: The "Blueprint" of your app.
• Containers: The "Running Instance" of that blueprint.
• Networks & Volumes: The "WiFi" and "Hard Drive" of the containers.

C. The Registry (Docker Hub)

A registry is where images are stored. Docker Hub is the world's largest public registry. When you "Pull" an image, you are downloading it from a registry to your host.

---

2. The Relationship: Image vs. Container

This is the most important concept to master.

• Image: A read-only template with instructions for creating a Docker container. Imagine a Class in programming or a Recipe for a cake.
• Container: A runnable instance of an image. Imagine an Object in programming or the Actual Cake.

Key Fact: You can start 1,000 containers from a single image. They all start identical, but once running, they can have different data (just like 100 people using the same recipe might add different toppings).

---

3. How a Command Travels

When you run docker run -it ubuntu /bin/bash:

1. Client: "Hey Daemon, run an Ubuntu container."
2. Daemon: "Do I have the Ubuntu image locally?"
   • If No: The Daemon "Pulls" it from Docker Hub.
3. Daemon: Creates a new container from that image.
4. Daemon: Allocates a network and a storage layer.
5. Daemon: Executes /bin/bash inside the container and streams the output back to your Client.

Visualizing Docker Architecture

sequenceDiagram
    participant User
    participant Client as Docker Client
    participant Daemon as Docker Daemon
    participant Registry as Docker Hub
    
    User->>Client: docker run ubuntu
    Client->>Daemon: Run ubuntu container
    Daemon->>Daemon: Check local images
    
    alt Image not found locally
        Daemon->>Registry: Pull ubuntu image
        Registry->>Daemon: Download image
    end
    
    Daemon->>Daemon: Create container from image
    Daemon->>Daemon: Allocate network & storage
    Daemon->>Daemon: Start container process
    Daemon->>Client: Stream output
    Client->>User: Display result

---

4. Summary Table

Term	What it is	Analogy
Client	The User Interface	Remote Control
Daemon	The Execution Engine	The TV itself
Image	Dead / Static File	The Recipe
Container	Live / Active Process	The Cake
Registry	The Storage Library	The Cookbook

---

Exercise: The Path of the Pull

1. If you are on a plane with no WiFi, can you run docker run alpine if you have never run it before? Why or why not?
2. Imagine you edit a file inside a running container. Does that change the Image? (Hint: Think about the "Blueprint" vs. "Building").
3. Why does Docker move the "Daemon" to its own process instead of just running everything in the terminal?

---

Summary

Docker isn't just one program; it's a conversation between a Client, a Daemon, and a Registry. Understanding this flow is the key to troubleshooting when things (like "Image not found") go wrong.

Next Lesson: We get Docker running on your machine: Docker installation.