Docker 概述与架构原理

2.1 Docker Client（客户端 CLI）#

概念：用户与 Docker 交互的命令行程序，例如 docker run 中的 docker 就是客户端。

原理：客户端本身不做任何容器操作，主要把容器管理命令翻译成 Engine API 请求；构建等子命令还会调用相应组件。客户端与守护进程通过本地 unix:///var/run/docker.sock 通信，也可通过 -H 参数连接远程守护进程：

1
# 连接到远程机器的守护进程
2
docker -H ssh://user@192.168.1.10 ps
3
# 查看当前客户端 / 服务端信息
4
docker version
5
docker info

2.2 Docker Daemon（守护进程 dockerd）#

概念：常驻后台的服务进程，是 Docker 的”大脑”。

原理：它监听 REST API 请求，负责管理所有 Docker 对象（镜像、容器、网络、卷），并在需要时调用 containerd 执行真正的容器操作。containerd 通过 shim 进程管理容器进程。Docker 默认会在守护进程退出时停止容器；需要在符合限制的环境中启用 live-restore，才能在 daemon 不可用时保留容器运行。官方说明

1
# 查看守护进程与运行环境信息
2
docker info
3
# 在容器内查看（了解它跑在哪个内核上）
4
docker run --rm alpine uname -r

2.3 containerd（容器运行时管理器）#

概念：一个工业级容器运行时管理器，CNCF 毕业项目，同时被 Kubernetes（通过 CRI）和 Docker 使用。

原理：containerd 负责镜像的下载与解包、容器存储、以及调用低层运行时启动容器。它实现了 OCI（Open Container Initiative）规范中的镜像与运行时标准，把”如何管理容器生命周期”与”具体怎么启动进程”两层分离。

2.4 runc（低层运行时）#

概念：真正与内核打交道的程序，目前 Docker 默认的低层运行时。

原理：runc 根据 OCI 运行时规范，调用 Linux 内核的两个关键能力创建隔离环境：

• namespaces（命名空间）：让进程拥有独立的 PID、Network、Mount、UTS、IPC、User 视图——容器里看到的”自己是 1 号进程""自己有网卡”，都是命名空间制造的幻觉；
• cgroups（控制组）：限制并统计容器可用的 CPU、内存、磁盘 IO 等资源。

1
# 查看默认低层运行时（一般是 runc）
2
docker info | grep -i runtime
3
# 查看容器实际使用的 cgroup
4
docker run -d --name demo --memory 128m alpine sleep 3600
5
docker inspect demo --format '{{.HostConfig.Memory}}'

小结：dockerd（管理）→ containerd（生命周期管理）→ runc（执行）→ 内核（隔离）。各层按接口分工，替换运行时需要满足兼容性和部署条件，并非任意组件都能直接互换。

2.5 Registry（镜像仓库）#

概念：存放和分发镜像的服务，公开的有 Docker Hub，私有常见 Harbor、AWS ECR 等。

1
docker pull nginx            # 从默认仓库 Docker Hub 拉取
2
docker login                 # 登录（访问私有仓库需要）
3
docker push myname/app:v1    # 推送本地镜像到仓库

3.1 概念#

镜像是只读的模板，包含运行一个应用所需的全部内容：代码、运行时、库、环境变量、配置。镜像是”类”，容器是”实例”。

3.2 原理：分层与联合文件系统#

镜像由多层只读层堆叠而成。RUN、COPY、ADD 等会形成文件系统层；CMD、ENTRYPOINT 等记录配置元数据，不新增文件系统层：

• 层之间用 UnionFS（联合文件系统） 叠加，对外表现为一个完整文件系统；
• 层是可共享、可缓存的：多个镜像共用同一基础层时只存一份；
• 容器启动时，Docker 在最上层再加一层可写层；修改文件采用 Copy-on-Write（写时复制）——先复制再修改，绝不动下层。

3.3 构建上下文（Build Context）：docker build 到底在哪执行？#

先回答一个高频疑问：是不是必须在 Dockerfile 所在的文件夹里执行 docker build？

准确答案是：可以在任意目录执行，只要正确指定构建上下文路径和 Dockerfile 路径。 看这条命令：

1
docker build -t myapp:v1 .
2
#                        ↑ 这个 . 是"构建上下文路径"，不是"Dockerfile 的位置"

它背后发生的事是：

1. 构建器根据 . 确定本地构建上下文，并应用 .dockerignore；
2. 默认使用的 BuildKit 按需传输和处理构建所需文件；旧式构建器才通常把整个上下文打包传给 daemon；
3. 普通 COPY / ADD 的本地源以这个上下文为根，不能通过 ../ 读取其外部文件；COPY --from 则可读取其他构建阶段、镜像或命名上下文。

三种典型用法

1
# ① 最常用：Dockerfile 在当前目录，上下文 = 当前目录
2
cd /home/user/myapp
3
docker build -t myapp:v1 .
4

5
# ② Dockerfile 放在子目录，上下文仍是项目根目录（推荐的工程组织方式）
6
docker build -f docker/Dockerfile -t myapp:v1 .
7

8
# ③ 无上下文，从标准输入读 Dockerfile（此时只能用 ADD 远程 URL，不能 COPY 本地文件）
9
docker build -t myapp:v1 - < Dockerfile

三个必踩的坑

1
# ❌ 1. 不要把系统根目录当构建上下文，避免暴露无关文件并增加扫描成本
2
cd / && docker build -t x .

1
# ❌ 2. COPY 不能跳出上下文
2
# 不能借 ../ 读取上下文外文件；报错或路径规范化行为依构建器而异
3
COPY ../config.yml /app/

1
# ❌ 3. 不写 .dockerignore，COPY . . 可能带入 node_modules、.git 等无关文件

.dockerignore 放在上下文根目录，语法类似 .gitignore：

1
.git
2
node_modules
3
dist
4
*.log
5
Dockerfile
6
.dockerignore

它既缩小传输体积，又避免本地依赖覆盖镜像内的依赖、导致构建缓存失效。

3.4 操作：用 Dockerfile 构建镜像#

1
# 示例 Dockerfile：构建一个极简 Node.js 应用镜像
2
# 基础镜像层
3
FROM node:20-alpine
4
# 设置工作目录
5
WORKDIR /app
6
# 先只拷贝依赖清单，利于缓存
7
COPY package*.json ./
8
# 安装依赖
9
RUN npm install
10
# 拷贝应用源码
11
COPY . .
12
# 声明端口（仅文档作用）
13
EXPOSE 3000
14
# 启动命令
15
CMD ["node", "server.js"]

1
docker build -t myapp:v1 .        # 构建，-t 指定名称:标签
2
docker images                     # 查看本地镜像
3
docker history myapp:v1           # 查看构建历史（含不产生文件系统层的元数据指令）
4
docker inspect myapp:v1           # 查看镜像元数据
5
docker rmi myapp:v1               # 删除镜像
6
docker image prune                # 清理悬空镜像

镜像命名格式：[仓库地址/]仓库名/镜像名:标签，缺省时仓库为 docker.io/library。

1
docker tag myapp:v1 myname/myapp:latest   # 打新标签
2
docker save -o myapp.tar myapp:v1         # 导出镜像为 tar 包
3
docker load -i myapp.tar                  # 导入 tar 包

4.1 概念#

容器是镜像的运行实例。它在宿主机上就是一个普通进程（带着一堆隔离），被命名空间、cgroup 包裹，拥有独立的文件系统、网络栈与进程视图。

4.2 原理：生命周期状态机#

几个易混的细节：

• docker stop 先发 SIGTERM 优雅退出，超时后才 SIGKILL（默认 10 秒，可用 -t 调整）；
• docker restart 先停止再启动；强制删除运行中容器用的是 docker rm -f；
• 前台运行（不 -d）时，按 Ctrl-C 相当于给 PID 1 发送 SIGINT。

4.3 操作与命令行#

1
# 创建并启动容器：-d 后台、--name 命名、-p 端口映射
2
docker run -d --name myapp -p 3000:3000 myapp:v1
3

4
docker ps                       # 查看运行中的容器
5
docker ps -a                    # 查看所有容器（含已停止）
6
docker logs -f myapp            # 跟随查看日志
7
docker exec -it myapp sh        # 进入容器执行命令（排障利器）
8
docker top myapp                # 查看容器内进程
9
docker stats                    # 实时查看资源占用（依赖 cgroups）
10
docker cp myapp:/app/log.txt ./ # 与容器互拷文件
11

12
docker pause myapp              # 暂停（冻结）
13
docker unpause myapp            # 恢复
14
docker restart myapp
15
docker stop myapp
16
docker start myapp
17
docker rm -f myapp              # 删除容器（-f 先杀后删）
18
docker container prune          # 清理所有已停止容器

排障流程口诀：先 logs 看应用，再 exec 进容器查环境，最后 inspect 看配置。

5.1 概念与原理#

Docker 通过 veth 虚拟网卡 + 网桥 + iptables/NFTables 搭建虚拟网络。主要驱动类型：

要点：普通 bridge 网络中的容器通常可经 NAT 出网，是否可达还受路由和防火墙影响；同一 bridge 内的容器默认可按 IP 互访，不同 bridge 默认隔离；容器间推荐加入同一个自定义 bridge 网络——此时可直接用容器名/服务名通信（内嵌 DNS），而默认 docker0 网络不支持按名字解析。

5.2 操作与命令行#

1
# 创建自定义网络，并指定子网
2
docker network create -d bridge --subnet 172.20.0.0/16 app-net
3

4
# 在指定网络中启动容器
5
docker run -d --name web --network app-net myapp:v1
6
docker run -d --name db --network app-net -e POSTGRES_PASSWORD=dev-only-change-me postgres:16
7

8
# 在 web 容器里直接用名字访问 db（内嵌 DNS）
9
docker exec web ping -c 2 db
10

11
# 管理命令
12
docker network ls                 # 列出网络
13
docker network inspect app-net    # 查看网络详情与成员
14
docker network connect app-net old-container   # 动态接入
15
docker network disconnect app-net old-container
16
docker network rm app-net         # 删除（需先断开成员）
17

18
# 端口映射
19
docker run -d -p 8080:80 nginx    # 宿主机8080 -> 容器80
20
docker run -d -P nginx            # -P 随机映射所有 EXPOSE 端口
21
docker port <container>           # 查看端口映射关系

6.1 概念与原理#

容器被删除后，它的可写层随之消失，需要持久化的数据必须放到宿主机侧的挂载上。Docker 提供三种挂载：

新写法推荐 --mount type=volume,src=myvol,dst=/data 形式，语法更明确，比短写法 -v 更不易出错。

6.2 操作与命令行#

1
# ---- Volume 卷 ----
2
docker volume create pgdata            # 创建命名卷
3
docker volume ls                       # 列出卷
4
docker volume inspect pgdata           # 查看卷（含宿主机路径）
5
docker volume rm pgdata                # 删除卷
6
docker volume prune                    # 清理无用卷
7

8
# 挂载卷：给 Postgres 持久化数据
9
docker run -d --name pg \
10
  -v pgdata:/var/lib/postgresql/data \
11
  -e POSTGRES_PASSWORD=secret postgres:16
12

13
# ---- Bind mount：开发时共享源码（改动即时生效）----
14
docker run -d -p 3000:3000 \
15
  -v "$PWD":/app \
16
  -w /app node:20 node server.js
17

18
# ---- tmpfs：内存文件系统 ----
19
docker run -d --tmpfs /cache alpine sleep 3600
20

21
# ---- 查看容器挂载情况 ----
22
docker inspect pg --format '{{json .Mounts}}'
23

24
# ---- 容器间共享同一卷 ----
25
docker run -d --name writer -v share:/data alpine sh -c "echo hi > /data/f.txt; sleep 3600"
26
docker run --rm -v share:/data alpine cat /data/f.txt

7.1 概念#

Registry 是镜像的”GitHub”。本地 Docker 称为缓存，远程仓库才是源头。完整镜像名是 [仓库地址]/[命名空间/]镜像名:标签。

7.2 命令行#

1
docker search nginx              # 搜索官方仓库镜像
2
docker pull nginx:alpine         # 显式拉取 alpine 标签；未写标签时才默认 latest
3
docker login                     # 登录 Docker Hub
4
docker tag myapp:v1 myname/myapp:1.0.0    # 打上自己的仓库标签
5
docker push myname/myapp:1.0.0   # 推送
6
docker logout                    # 退出登录
7

8
# 用容器镜像名区分官方与个人镜像
9
docker pull nginx                          # docker.io/library/nginx
10
docker pull myname/myapp:1.0.0             # docker.io/myname/myapp

9.1 先分清三个角色#

关键认知：docker build 时 COPY . /app 已经把源码烤进镜像了，所以生产服务器既不需要 git，也不需要 Node/Python/编译器，它只需要 docker pull + docker run。这正是容器化的价值所在。

9.2 两种部署方案对比#

9.3 方案 A 命令：构建一次，到处运行#

1
# ===== 本地开发机 或 CI（GitHub Actions / GitLab CI）：只在这里 build 一次 =====
2
docker build -t myrepo/myapp:1.0.0 .
3
docker push myrepo/myapp:1.0.0
4

5
# ===== 生产服务器：只 pull 和 run，绝不 build =====
6
docker pull myrepo/myapp:1.0.0
7
docker run -d -p 3000:3000 --name app myrepo/myapp:1.0.0
8

9
# 回滚：把 tag 换成上个版本，重启容器即可
10
docker pull myrepo/myapp:0.9.0
11
docker rm -f app
12
docker run -d -p 3000:3000 --name app myrepo/myapp:0.9.0

9.4 方案 B 命令：服务器上拉代码构建#

1
# ===== 服务器上 =====
2
git pull origin main            # 先更新源码
3
docker compose up -d --build     # 然后构建并创建/更新服务容器
4

5
# 等价的手动写法
6
docker build -t myapp:latest .
7
docker run -d -p 3000:3000 --name app myapp:latest

简单直接，适合个人项目和内网机器；代价是服务器要承担构建资源消耗，并维护构建器及源码；语言依赖可以安装在构建容器中。

9.5 bind mount 在”开发”与”生产”中的定位#

很多人会把上一节的挂载方式和部署流程搞混。bind mount 是运行时行为，和 build、Registry 没有任何关系——它不打包、不上传、不构建，只是把宿主机的目录”借”给容器读写。

三条实践准则：

1. 生产环境不要 bind mount 代码：镜像里已经有代码了，再挂宿主机目录会覆盖镜像内容，“镜像版本”就失去意义了——这是常见反模式；
2. 生产用 volume 挂数据：数据库文件、用户上传、日志等（见第 6 节），因为容器删除后可写层会一起消失；
3. 开发用 bind mount 挂源码：配合 nodemon、vite 等热重载工具，改一行代码立即生效，不用反复 build。

1
# 开发环境典型写法：挂源码 + 热重载
2
docker run -d -p 3000:3000 -v "$PWD":/app -w /app node:20 npm run dev
3

4
# 生产环境典型写法：代码在镜像里，只挂数据卷
5
docker run -d -p 3000:3000 -v pgdata:/var/lib/postgresql/data myrepo/myapp:1.0.0

9.6 一句话总结#

代码走 git，成品走镜像仓库；build 只做一次（本地或 CI），服务器只 pull + run；bind mount 是”运行时把宿主机目录借给容器”，不参与构建和分发。

容器#

镜像#

网络与存储#