1.4 Docker 架构五大件：调度室、岸桥与堆场
1.4 Docker 架构五大件：调度室、岸桥与堆场
本节摘要：Docker 由五个角色构成——Client（客户端）、Daemon（守护进程）、Registry（镜像仓库）、Image（镜像）、Container（容器）。本节给全册建立坐标系：五大件各自站在码头的哪个位置、如何协作，以及新手最容易踩的职责误解。
一句话先立坐标
有了历史纵深，本节把镜头拉近，看清 Docker 内部的分工。这是全册的坐标系：此后每一章的内容都能在这张图上找到位置——镜像与构建是"货与装箱"（第 3 章），容器与生命周期是"起吊与在船"（第 4 章），网络与数据是"泊位与堆场管理"（第 5 章）。
图 1-2：Docker 架构五大件的码头全景
五大件各自的岗位
Client：调度室的对讲机。 你敲的 docker 命令就是客户端。它自己不构建任何东西、不运行任何东西，只负责把你的指令翻译成 API 请求发给 Daemon，再把结果回显到终端。所以会出现一个反直觉的现象：客户端与服务端版本可以不同，甚至可以不在同一台机器——在办公电脑上通过远程连接操作服务器上的 Docker，是完全支持的用法。
Daemon：中控室监工。 守护进程是真正干活的角色，负责构建镜像、管理镜像与容器的存储、维护网络、响应 API。它常驻后台（所以叫守护进程）。新手最典型的误解是"docker 命令就是 Docker"——不对，命令只是对讲机，对讲机喊破了喉咙，中控不在线（Daemon 没启动）什么也不会发生。你大概率已经见过那个经典报错：
# Daemon 未启动时执行任何命令 docker ps # 输出： # Cannot connect to the Docker daemon at unix:///var/run/docker.sock # Is the docker daemon running?
看到这串报错不要去查命令拼写，去启动 Docker 服务（Linux 用 systemctl 启动 docker 服务，桌面版打开 Docker Desktop 应用即可）。
Registry：堆场。 存放镜像、支持上传下载的服务。最大的公共堆场是 Docker Hub，企业内网里也常自建私有堆场（第 3.5 节会亲手搭一个）。堆场与中控之间的两个动词要记牢：pull 从堆场提货到本地，push 把本地货推上堆场。镜像名称里的仓库地址前缀（如自建堆场的内网域名）决定了这次操作发生在哪个堆场。
Image：待装的货。 镜像是只读的分层文件系统叠加体，包含运行应用所需的一切。它是"静态的货"——不被运行、可以被复制、可以被版本化。同一个镜像可以同时起若干个容器，就像同一张图纸可以造若干条一样的箱子。
Container：船上的箱子。 容器是镜像的运行实例：在只读层之上叠加一层可写层，配好隔离的进程空间与网络，然后跑起来。容器是"动态的、有生命周期的"——启动、运行、暂停、销毁。容器里发生的写操作只落在可写层，容器一删，可写层就没了——这个事实是第 5 章数据卷存在的全部理由。
一次 docker run 的完整旅程
把五大件串成一条流水线，回看第 1.1 节那条 docker run hello-world 背后发生了什么：
# 一条命令，五站旅程 docker run hello-world
- Client 把请求发往本机 Daemon（第 1 站：调度室喊话）。
- Daemon 检查本地镜像存储：hello-world 这批货在不在堆位上？
- 本地没有 → Daemon 联系默认 Registry，把镜像层拉回本地（第 2、3 站：去堆场提货入库）。
- Daemon 基于 Image 创建容器：叠可写层、分配命名空间、按需接网线（第 4 站：装箱起吊）。
- 容器内进程启动，输出经 Daemon 流回 Client，打印到你的终端（第 5 站：回电）。
这条链路值得背下来：日后排查任何 Docker 问题，都可以先问一句"卡在哪一站了"——是客户端没连上中控（Daemon 没起），还是堆场没货（镜像名拼错），还是箱子起吊后立刻沉底（进程秒退，第 4 章详解）。
再排掉新手期的三个高频误解。误解一：docker 命令在容器里跑。 恰恰相反，命令在宿主机上跑，容器里通常连 docker 都没装——客户端永远在箱外喊话。误解二：镜像仓库就是存代码的。 仓库存的是构建好的镜像层，不是源码；源码在装箱单的构建上下文里，跟堆场无关。误解三：一台机器只能有一套 Daemon。 引擎确实以守护进程为中枢，但客户端可以通过连接配置指向别的机器的中控——远端调度是原生能力，配置一次即可日常使用：
# 查看客户端默认连接的中控位置 docker context ls # NAME DESCRIPTION DOCKER ENDPOINT # default * Current DOCKER_HOST based config unix:///var/run/docker.sock # （unix 套接字是本机默认通道；改用远程地址即可跨机调度，此处不展开实操）
排障演练：当场验明五大件
架构图要落到命令上才算数。一条 docker version 就能亲眼看到客户端与服务端是两个独立进程——客户端一栏永远打印得出来（命令本身活着），服务端一栏能否打印，取决于中控室是否应答：
# 五大件体检第一步：看对讲机与中控室是否同时在线 docker version # 输出（节选）： # Client: # Version: 26.1.4 # Server: # Engine: # Version: 26.1.4
服务端一栏空缺或直接报错，说明请求卡在第一站（连接）；两栏都正常但后续命令失败，再往后查提货（镜像）与起吊（容器）。顺手调出中控室的运行档案：
# 中控室的全貌：在管箱子数、库存镜像数、存储驱动 docker info # 输出（节选）： # Containers: 3 # Running: 2 # Images: 41 # Storage Driver: overlay2
两条命令合计不到十秒，却应成为日后一切排障的第一步——先确认五大件各就各位，再谈具体故障。存储驱动一栏此刻只需眼熟，第 3 章讲分层存储时会回来对表。
本节要点回顾
- 五大件：Client 只传话，Daemon 真干活，Registry 存镜像，Image 是只读的货，Container 是运行中的箱子。
- 客户端与服务端分离：命令连不上 Daemon 报 "Cannot connect to the Docker daemon"，先查服务状态再查命令。
- 镜像是静态分层，容器是动态实例；同一镜像可起多容器，互不影响。
- 容器的写入只落可写层，容器删除即丢失——为第 5 章的数据卷埋下伏笔。
- 排障先定位"卡在哪一站"：连接、提货、起吊、回传。
五大件到齐。下一节跳出软件行业，去看上世纪海运码头那场如出一辙的革命——看完你会明白，为什么标准化总能战胜定制化。