Volume on Liangweidong's blog

Docker 进阶与运维：网络模式、Volume 与镜像加速实战

Thu, 20 Jun 2019 00:00:00 +0800

装好 Docker 引擎只是入门。真正决定一台主机能不能稳定跑生产容器的，是网络、存储和镜像拉取这三件事。这一篇围绕"网络模式 + 存储卷 + 镜像代理 + 常见排障"四个高频主题，把零散的运维笔记整理成可复用的参考。

阅读对象：已经能跑 docker run 的开发者、想把 Docker 用于生产环境或本地自建集群的运维同学 覆盖范围：bridge / host / none / container / 自定义网络 + Volume 生命周期 + Docker Hub / ghcr / GCR / k8s / Quay 代理 + 故障排查

一、为什么需要关注网络与存储

跑一个 hello-world 很简单，但一旦要把 Docker 真正"用起来"，就会撞到这些问题：

容器之间怎么互访？同一个 Pod 里的两个 sidecar 容器能直接 localhost 通信吗？
数据库的数据在容器里，删容器数据就没了——怎么持久化？
怎么让外部用户访问容器内的服务？
不同机器上的容器怎么互联？
国内服务器拉 Docker Hub 镜像慢到秒级超时，K8s 节点拉 CoreDNS 镜像也卡怎么办？
私有仓库（ghcr.io / gcr.io / quay.io）在国内怎么拉？

这些问题的答案，藏在网络模式、Volume、镜像代理三个核心机制里。

When to use：

单机多容器互访 → bridge / 自定义网络

容器需要"绑定宿主机端口"的高性能场景 → host 网络

强隔离、不能联网的安全沙箱 → none 网络

数据库、需要长期保存的日志 → Volume（命名卷）/ bind mount

跨主机容器互联（Swarm / k8s）→ overlay 网络（本文不展开）

国内服务器拉镜像 → 镜像代理（dockerproxy / ghcr.nju.edu.cn 等）

二、容器网络基础：docker0 网桥与 veth pair

Docker 启动时会在宿主机上创建一个叫 docker0 的虚拟网桥（默认子网 172.17.0.0/16）。所有以 bridge 模式启动的容器都会接到这张网桥上，通过这张网桥 + iptables NAT 表与宿主机通信。

可以用 ifconfig（或 ip a）看到 docker0：

1
2
3
4
5


$ ifconfig
docker0 Link encap:Ethernet HWaddr 02:42:xx:xx:xx:xx
 inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 ...

核心机制（veth pair）：

容器内看到的 eth0 并不是真正的网卡，而是一对 veth pair 设备的一端
另一端放在宿主机，挂到 docker0 网桥上
数据从一端进，另一端出，等同于一根虚拟网线

可以用 brctl show（来自 bridge-utils 包）查看网桥上挂了哪些 veth：

1
2
3


$ brctl show docker0
bridge name bridge id STP enabled interfaces
docker0 8000.0242xxxxxx no vethxxxxxx

重要结论：docker0 网桥对外是不可见的，外部网络无法通过 Container-IP 直接访问容器。要让外部访问，必须做端口映射（-p 参数）。

三、四种网络模式详解

Docker 在安装时会自动创建三个网络：bridge（默认）、none、host：

1
2
3
4
5


$ docker network ls
NETWORK ID NAME DRIVER SCOPE
xxxxx bridge bridge local
xxxxx host host local
xxxxx none null local

创建容器时通过 --net / --network 指定：

模式	指定方式	核心特点	典型场景
bridge	`--net=bridge`（默认）	独立 netns，分配 IP，通过 docker0 + NAT 通信	90% 场景
host	`--net=host`	共享宿主机 netns，无独立 IP	高性能网络服务、监控 agent
none	`--net=none`	仅有 lo 回环，无任何网络	强隔离、离线批处理
container	`--net=container:NAME`	共享另一个容器的 netns	sidecar 模式紧密协作

3.1 bridge 模式（默认）

1
2
3
4
5


# 随机端口映射（大写 P）
docker run -itd --name test1 -P nginx

# 指定端口映射（小写 p）
docker run -itd --name test2 -p 44541:80 nginx

访问路径：

1

外部网络 → 宿主机 IP:宿主机端口 → iptables DNAT → 容器 IP:容器端口

可以用 iptables -t nat -vnL 看到 Docker 自动添加的 DNAT 规则：

1
2
3
4


$ iptables -t nat -vnL
Chain DOCKER (2 references)
 pkts bytes target prot opt in out source destination
 0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:44541 to:172.17.0.2:80

等价类比：bridge 模式 ≈ VMware 里的 NAT 模式——容器有独立 IP、能上网，但需要端口映射才能被外部访问。

3.2 host 模式

容器不创建自己的网卡，直接使用宿主机的 IP 和端口。

1

docker run -itd --name test-host --net=host nginx

优势：

没有 NAT 转换，性能最佳
适合需要"处理大量端口"的服务（如 nginx 反代、Kafka、Prometheus exporter）

代价：

容器与宿主机共用网络栈，端口冲突会直接报错
-p / --publish 参数被忽略，会出现 WARNING: Published ports are discarded when using host network mode

注意：host 网络驱动只支持 Linux 宿主机。Docker Desktop for Mac / Windows / Windows Server 上的 Docker 不支持 host 模式。

在 Swarm 集群里也可以使用 host 网络：

1

docker service create --network host nginx

控制流量（swarm manager 相关）仍走 overlay 网络，但 swarm 服务容器本身使用 Docker 守护进程的主机网络和端口发送数据——这意味着如果一个服务容器绑定到 80 端口，那么在给定的集群节点上只能运行一个该服务容器。

3.3 none 模式

容器有独立的 Network Namespace，但 Docker 不会给它配置任何网络。

没有 eth0、没有 IP、没有路由
只有 lo 回环网卡
完全不能上网

典型场景：安全沙箱、离线批处理任务（如敏感数据脱敏、纯计算作业）。

3.4 container 模式

新创建的容器共享指定容器的 netns，而不是和宿主机共享。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 查看已有容器的 PID
$ docker inspect -f '{{.State.Pid}}' 5ace523962fc
14685

# 验证 net namespace
$ ls -l /proc/14685/ns
... net -> net:[4026532649] # 就是这个 net namespace ID

# 创建新容器并共享
$ docker run -itd --name test3 --net=container:5ace523962fc centos bash

# 验证新容器的 net namespace 一致
$ docker inspect -f '{{.State.Pid}}' 2b7af7c8842d
15832
$ ls -l /proc/15832/ns
... net -> net:[4026532649] # 跟前面一样

特性：

两个容器共享 IP、端口范围
网络之外（文件系统、进程、用户）仍然隔离
两个容器的进程可以通过 lo 通信

典型场景：sidecar 模式——主容器和 sidecar 容器（如日志收集器、监控 agent、Service Mesh proxy）共用 netns，方便在 localhost 上互调。

四、自定义网络：指定 IP / 子网

直接用默认 bridge 模式，不能给容器指定固定 IP：

1
2
3


# 报错：只能在自定义网络指定 IP
$ docker run -itd --name test4 --network bridge --ip 172.17.0.5 centos:7 /bin/bash
Error response from daemon: User specified IP address is supported only when connecting to networks with user configured subnets.

正确做法：先自定义网络，再指定 IP 启动。

1
2
3
4
5
6
7
8


# 1. 创建自定义网络（指定子网 + 网卡名）
docker network create \
 --subnet=172.18.0.0/16 \
 --opt "com.docker.network.bridge.name"="docker1" \
 mynetwork

# 2. 用指定 IP 启动容器
docker run -itd --name test5 --net mynetwork --ip 172.18.0.10 centos /bin/bash

参数说明：

--subnet：定义子网范围
--opt "com.docker.network.bridge.name"="docker1"：让 ifconfig -a 看到的是 docker1，而不是 br-110eb56a0b22 这种随机名
mynetwork：网络名，docker network ls 里的 NAME 列

Why 用自定义网络：

容器 DNS 自动解析（容器名 → IP），默认 bridge 不支持
可以在创建时规划 IP 段
适合需要稳定网络拓扑的复杂部署

配套的清理命令：当自定义网络不再需要时：

1
2
3
4
5
6


# 临时把容器从指定网络断开（排查网络问题很有用）
docker network disconnect -f bridge <container_name>

# 禁用并删除 docker0 网桥
ifconfig docker0 down
brctl delbr docker0

注意：手工 brctl delbr docker0 之后，下次 daemon 启动（未指定 -b 参数）会自动重建 docker0。要真正控制默认网桥，需要在 daemon.json 里写：
1
2
3
4
{
 "iptables": false,
 "bridge": ""
}

五、存储卷（Volume）：让数据活过容器生命周期

容器的文件系统是临时的——docker rm 时容器层全部销毁。任何需要持久化的数据，都必须挂载到 Volume 或 bind mount。

5.1 Volume 操作四件套

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 创建
docker volume create mydata

# 查看
docker volume ls

# 删除单个
docker volume rm mydata

# 清理（删所有未挂载的 volume —— 危险）
docker volume prune

5.2 两种挂载方式

1
2
3
4
5


# 1. 命名卷（推荐，Docker 自动管理）
docker run -d -v mydata:/var/lib/mysql mysql:5.7

# 2. bind mount（直接挂主机目录，运维最常用）
docker run -d -v /host/path:/container/path nginx

维度	Volume	Bind Mount
路径	Docker 管理（默认 `/var/lib/docker/volumes/`）	任意宿主机路径
迁移	`docker volume` 命令一键迁移	手动 rsync
权限	Docker 自动设	手动 chmod
适用	数据库、共享数据	配置文件、日志、特殊路径

5.3 关键避坑

docker volume prune 会删所有未挂载的卷——生产环境跑这个命令之前必须 docker volume ls 确认
bind mount 时容器内 UID 与宿主机不一致会导致权限问题——用 user: "1000:1000" 显式指定
Volume 在多容器间共享非常合适（如配置中心、日志聚合），但不能用 tmpfs 替代——重启数据就没了

5.4 配合清理

1
2
3
4
5


# 只删除未使用的网络
docker network prune -f

# 删除 12 小时前创建的网络
docker network prune -a --filter "until=12h"

六、镜像代理与加速

国内服务器拉 Docker Hub 镜像默认会非常慢甚至超时。除了 daemon.json 里配 registry-mirrors，还可以直接用镜像代理拉特定 registry 的镜像。

6.1 Docker Hub 镜像代理

场景	官方命令	代理命令
用户镜像	`docker pull stilleshan/frpc:latest`	`docker pull dockerproxy.com/stilleshan/frpc:latest`
根镜像（library）	`docker pull nginx:latest`	`docker pull dockerproxy.net/library/nginx:latest`

dockerproxy.com 和 dockerproxy.net 是两个常用的镜像代理。根镜像（library/xxx）必须显式写 library/——这是和用户镜像最大的区别。

6.2 GitHub Container Registry (ghcr.io)

2019 年 9 月 GitHub 即将开放公开测试的 ghcr.io，配合 GitHub Actions 的 docker push 流程，越来越多的开源项目（包括很多 K8s 生态组件）开始把镜像推到 ghcr 而非 Docker Hub。

1
2
3
4
5


# 官方
docker pull ghcr.io/username/image:tag

# 代理
docker pull ghcr.dockerproxy.com/username/image:tag

南京大学的 ghcr 加速：ghcr.nju.edu.cn 是高校里对 ghcr 比较稳定的镜像（南大信管系维护）。速度通常比走 dockerproxy 更快，适合学术 / 教学环境。

6.3 Google Container Registry (gcr.io) 与 k8s.gcr.io

K8s 自身组件（coredns、kube-proxy、etcd 等）都托管在 k8s.gcr.io（2018 年起）或新地址 registry.k8s.io（2019 年开始迁移）。国内拉这些镜像几乎必走代理：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# GCR 官方
docker pull gcr.io/username/image:tag

# GCR 代理
docker pull gcr.dockerproxy.com/username/image:tag

# K8s 镜像（CNCF 仓库，从 k8s 1.11 开始 CoreDNS 取代 kube-dns 成为默认 DNS）
docker pull k8s.gcr.io/coredns:1.6.5
docker pull registry.k8s.io/coredns:1.6.5

# 代理
docker pull k8s.dockerproxy.com/coredns:1.6.5

CoreDNS 1.6.5 是 2019 年中比较常用的稳定版本——CNI 插件、KubeDNS 替换等场景都会用到。

6.4 Quay.io

Red Hat 系镜像（coreos/etcd 旧版本、Operator Framework 等）大多托管在 Quay：

1
2
3
4
5


# 官方
docker pull quay.io/username/image:tag

# 代理
docker pull quay.dockerproxy.com/username/image:tag

6.5 加速效果对比

1
2
3


# 测速（删本地缓存后用 time 计时）
docker rmi node:latest
time docker pull node:latest

直连 Docker Hub：~1m14s（国内典型）
用镜像代理：~5-15s（视镜像大小）

注意：公开镜像代理可能因合规或运营原因失效。生产环境建议自建 mirror（用 registry 镜像 + 反代），或者用云厂商（阿里云 ACR、DaoCloud）的企业级加速服务。

七、常见问题与排障

7.1 WARNING: IPv4 forwarding is disabled

容器网络不通，dockerd 启动时打这条警告。生产环境装完 Docker 必须先修这个：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 临时启用
sysctl -w net.ipv4.ip_forward=1

# 永久（任选其一）
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# 或
echo "net.ipv4.ip_forward=1" >> /usr/lib/sysctl.d/00-system.conf

# 生效
sysctl -p

# 验证
sysctl net.ipv4.ip_forward
# 期望输出：net.ipv4.ip_forward = 1

7.2 unknown or invalid runtime name: docker-runc

从老版本（Docker 18.06 之前）升级到 Docker 18.09+ 后，runtime 名从 docker-runc 改为 runc，老容器的 hostconfig.json 还引用老名字，导致容器起不来。

1
2
3
4
5


# 批量替换
grep -rl 'docker-runc' /var/lib/docker/containers/ | xargs sed -i 's/docker-runc/runc/g'

systemctl stop docker
systemctl start docker

7.3 live-restore：让容器在 daemon 重启时不停机

升级 Docker daemon 或 daemon 崩溃时，默认会停掉所有正在运行的容器。开启 live-restore 可让容器继续运行：

1
2
3


{
 "live-restore": true
}

1
2
3


systemctl daemon-reload
sudo systemctl reload docker.service # 注意是 reload 不是 restart
docker info | grep -i live # 验证：Live Restore Enabled: true

之后 systemctl restart docker 时，容器不会停。

多机同步：在 K8s 集群里，可以用脚本批量同步 daemon.json：

1
2
3
4
5


for NODE in master2 master3 worker1 worker3 worker4 worker5 worker6 worker7 worker8 worker9; do
 echo $NODE
 scp /etc/docker/daemon.json $NODE:/etc/docker/
 ssh root@$NODE "systemctl daemon-reload && systemctl reload docker && systemctl restart docker"
done

7.4 network disconnect：容器临时断网

1
2


# 临时把容器从指定网络断开
docker network disconnect -f bridge <container_name>

排查网络问题时很有用——能快速判断"是容器问题还是网络问题"。

八、核心要点 / 常见坑

把这一篇的要点压缩成 8 条：

bridge 模式是默认（90% 场景），host 模式换性能换隔离，none 模式是沙箱
端口映射必须用 -p——bridge 模式下不映射外部访问不了
容器共享 netns用 container 模式，sidecar 利器
指定固定 IP必须用自定义网络，默认 bridge 不支持
数据持久化用 Volume，docker volume prune 是危险命令
bind mount vs Volume：配置/日志用 bind mount，数据库用 Volume
国内拉镜像必须用代理或 mirror——dockerproxy 系列、ghcr.nju.edu.cn、阿里云、DaoCloud 都要会
live-restore 是 daemon 升级不停机的关键配置

九、小结

网络模式：4 种核心模式（bridge / host / none / container）+ 自定义网络，理解 veth pair 是关键
存储卷：Volume 管数据生命周期，bind mount 管配置文件，两手都要硬
镜像代理：dockerproxy 系列覆盖 Docker Hub / GCR / k8s.gcr.io / Quay，ghcr.nju.edu.cn 补足 ghcr
排障思路：先看 docker info 状态、再看 journalctl -u docker 日志、最后看 iptables 和 netns

下一步：单机 Docker 玩熟之后，下一步就是 Swarm / Kubernetes 的多机编排——那时网络（overlay / flannel / calico）、存储（Rexray / CSI）、调度（scheduler）都会变成新的核心议题。在 2019 年的 K8s 生态里，CoreDNS 已经取代 kube-dns 成为默认 DNS，ghcr.io 即将开放公开测试，镜像分发的格局正在重写——提前理解这些变化能少踩很多坑。

参考资料

Docker Volume 深度实践：命名卷、bind mount 与跨主机挂载

Tue, 15 Dec 2015 00:00:00 +0800

容器的文件系统是临时的——docker rm 时容器层全部销毁。任何需要持久化的数据，都必须挂载到 Volume 或 bind mount。这一篇把 Volume 的生命周期、Copy-on-Write 机制、跨主机挂载、共享卷在容器间传文件、清理策略一次性收齐。

阅读对象：需要把数据库 / 上传文件 / 配置中心等状态放到容器里的开发者、运维同学 覆盖范围：volumes vs bind mounts vs tmpfs + 命名卷操作 + Copy-on-Write + docker-compose 卷写法 + NFS / SSHFS / vieux 跨主机 + 共享卷传文件 + 清理策略

一、为什么需要 Volume

容器分层结构：

镜像层（Image Layer）：只读、共享，多个容器可共用
容器层（Container Layer）：读写、临时，容器销毁就消失

如果数据写在容器层，docker rm 那一刻数据就没了。Volume 就是把数据"挂"到宿主机文件系统上，绕开容器层，让数据活过容器生命周期。

二、三种挂载方式

Docker 1.9+（2015-11 GA）正式引入了 named volume（命名卷），与 bind mount、tmpfs 并列为三种挂载类型：

类型	路径	持久化	性能	适用
Volume	Docker 管理（默认 `/var/lib/docker/volumes/`）	是	优	数据库、上传文件、共享数据
bind mount	任意宿主机路径	是	优	配置文件、特殊路径、debug
tmpfs	宿主机内存	否（重启丢）	极优	敏感数据、临时缓存

When to use：

Volume（推荐）：数据库、长期存储——Docker 帮你管理路径、迁移、备份

bind mount：配置文件、日志、需要直接编辑宿主机文件的场景

tmpfs：密码、token、不想落盘的临时缓存

三、Volume 操作

3.1 命名卷的生命周期

1
2
3
4
5
6
7
8


# 创建（指定名字）
docker volume create data_volume

# 列出
docker volume ls

# 看详情
docker volume inspect data_volume

inspect 输出：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[
 {
 "CreatedAt": "2022-07-28T11:02:14+08:00",
 "Driver": "local",
 "Labels": null,
 "Mountpoint": "/var/lib/docker/volumes/data_volume/_data",
 "Name": "data_volume",
 "Scope": "local"
 }
]

关键字段：

Driver: local：默认驱动，只能用于当前 Docker 主机上的容器

Scope: local：本地范围（要跨主机挂载需要用其他 driver）

Mountpoint：数据在宿主机上的实际位置

3.2 隐式创建（run 时指定卷名）

如果不显式 docker volume create，docker run -v name:/path 会自动创建：

1

docker run -it --rm --name nginx -p 8080:80 -v demo-earthly:/usr/share/nginx/html nginx

3.3 Dockerfile 中声明

1
2
3
4


FROM nginx:latest

RUN echo "<h1>Hello from Volume</h1>" > /usr/share/nginx/html/index.html
VOLUME /usr/share/nginx/html

构建并运行：

1
2
3
4


docker build -t demo-earthly .
docker run -p 8080:80 demo-earthly
docker volume ls
# 输出随机卷名：20879e3f0bfaf0eed63cb7f37c4b9545084a703f888a230b8aedc2082c836281

每次启动新容器都会创建新卷（匿名卷），内容是 /usr/share/nginx/html。

3.4 删除

1
2
3
4
5
6
7
8


# 删指定卷
docker volume rm data_volume

# 删所有未挂载的卷
docker volume prune

# 删 dangling 镜像 + 未挂载卷（危险）
docker system prune -af --volumes

重要约束：docker volume rm 不能删正在被容器或服务使用的卷。docker volume prune 默认不会删正在使用的卷，但加 -f 也不会绕过这个保护——保护在 daemon 层。

四、Copy-on-Write 机制

docker build 时每条指令构建一层，只读。docker run 时构建一个读写容器层。

修改容器内某个文件时：

如果该文件在镜像层（只读），Docker 会从镜像层"复制"一份到容器层
容器层是读写层，修改只在容器层生效
容器销毁，容器层消失，修改也没了——这就是为什么需要 Volume

典型场景：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 容器内
echo "new content" > /etc/nginx/nginx.conf

# 容器外看
docker exec -it <container> cat /etc/nginx/nginx.conf
# 输出 "new content"

# 删容器
docker rm -f <container>

# 启动新容器
docker run -d nginx

# 新容器内的 /etc/nginx/nginx.conf 是默认的
# 原因：刚才的"new content"在容器层里，随容器销毁而消失

重要结论：容器层的修改不能跨容器共享。要让数据持久 + 跨容器共享，必须 Volume / bind mount。

五、bind mount vs Volume

5.1 语法对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Volume（短语法）
docker run -d -v mydata:/var/lib/mysql mysql:5.7

# bind mount（短语法）
docker run -d -v /host/path:/container/path nginx

# 长语法（--mount）— 更显式
docker run -d \
 --mount type=volume,source=mydata,target=/var/lib/mysql \
 mysql:5.7

docker run -d \
 --mount type=bind,source=/host/path,target=/container/path \
 nginx

5.2 长语法参数说明

参数	含义
`type`	`volume` / `bind` / `tmpfs`
`source` / `src`	卷名 / 宿主机路径
`destination` / `dst` / `target`	容器内路径
`readonly` / `ro`	是否只读挂载
`volume-opt`	额外 mount 选项（可多次）

5.3 实战：初始化数据到 Volume

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 创建两个卷
docker volume create test_nginx_html
docker volume create test_nginx_conf

# 准备数据到宿主机
sudo cp -r /home/nginx/html/* /var/lib/docker/volumes/test_nginx_html/_data
sudo cp /home/nginx/conf/my_custom.conf /var/lib/docker/volumes/test_nginx_conf/_data

# 启动容器，volume 自动挂载
docker run -d \
 --restart=always \
 -p 8080:8080 \
 --name test_nginx \
 --mount src=test_nginx_html,dst=/app \
 --mount src=test_nginx_conf,dst=/opt/bitnami/nginx/conf/server_blocks \
 bitnami/nginx:latest

Why 直接 cp 到 _data：volume 在宿主机上的真实路径是 /var/lib/docker/volumes/<name>/_data，容器启动前预先填数据是常见模式。也可以用 docker cp 复制到运行中的容器目录，但已挂载的 volume 路径会变。

六、docker-compose 里的卷

6.1 bind mount 写法

1
2
3
4
5
6
7
8


version: "3.2"
services:
 web:
 image: nginx:latest
 ports:
 - "8080:80"
 volumes:
 - ./target:/usr/share/nginx/html

6.2 命名卷 + 多容器共享

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


version: "3.2"
services:
 web:
 image: nginx:latest
 ports:
 - "8080:80"
 volumes:
 - html_files:/usr/share/nginx/html
 web1:
 image: nginx:latest
 ports:
 - "8081:80"
 volumes:
 - html_files:/usr/share/nginx/html

volumes:
 html_files:

docker compose up 时自动创建 <project_name>_html_files 命名卷，html_files 在 web 和 web1 之间共享。

6.3 引用已存在的卷

1
2
3


volumes:
 html_files:
 external: true

要先用 docker volume create html_files 创建，compose 才不会报错说找不到。

七、跨主机挂载：NFS

默认的 local driver 只能在当前主机用。Docker 1.9+ 内置支持 NFS 挂载（用 local driver 即可），不需要装额外插件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 安装 NFS 客户端
apt install nfs-common # Debian/Ubuntu
yum install -y nfs-utils # CentOS/RHEL

# 创建 NFS 卷
docker volume create --driver local \
 --opt type=nfs \
 --opt o=addr=10.0.0.10,rw \
 --opt device=:/path/to/dir \
 nfs_volume

挂载到容器：

1
2
3
4


docker run -d -it \
 --name myapp \
 --mount source=nfs_volume,target=/data \
 myapp:latest

docker-compose 写法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


version: "3.2"
services:
 myapp:
 image: myapp:latest
 ports:
 - "8080:8080"
 volumes:
 - type: volume
 source: nfs_volume
 target: /data
 volume:
 nocopy: true

volumes:
 nfs_volume:
 driver_opts:
 type: "nfs"
 o: "addr=10.0.0.10,nolock,soft,rw"
 device: ":/path/to/dir"

Why 推荐 nolock,soft：网络抖动时 hard 会卡住进程、nolock 减少锁竞争、soft 失败会返回错误而不是 hang。

八、用 volume driver 把数据存到其他主机

Docker Volume Plugins 生态丰富：vieux/sshfs（已停更）、Azure File Storage、AWS EFS、S3 driver、GlusterFS、Ceph、IPFS…

重要：vieux/sshfs plugin 已经停更，生产不要用——新的容器场景推荐自建 NFS 或云厂商文件存储。

历史 demo（演示用）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 安装 sshfs 插件
docker plugin install --grant-all-permissions vieux/sshfs

# 用 sshfs 创建卷
docker volume create --driver vieux/sshfs \
 -o sshcmd=user@10.32.2.134:/home/user/sshvolume \
 -o password=yourpassword \
 mysshvolume

# 挂载到容器
docker run -id \
 --name testcon \
 --mount type=volume,volume-driver=vieux/sshfs,source=mysshvolume,target=/world \
 ubuntu /bin/bash

九、共享卷在容器间复制文件

Volume 的天然优势：多容器可同时挂载。可以用这个特性在容器间传文件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. 创建共享卷
docker volume create shared_data

# 2. 容器 A 写文件到卷
docker run -it --name=writer \
 --mount source=shared_data,destination=/data \
 ubuntu bash
# 在容器内
root@ded392c589ea:/# touch /data/demo.txt

# 3. 容器 B 读同一卷
docker run -it --name=reader \
 --mount source=shared_data,destination=/data \
 ubuntu bash
# 在容器内
root@feef37293ea5:/# ls /data
# 输出：demo.txt

典型场景：CI 流水线里"build 容器产出 artifacts → 测试容器拿同一份 artifacts 跑测试"，共享卷是干净的解法。

十、清理无用的卷

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 只删 dangling 卷
docker volume ls -f "dangling=true" -q | xargs --no-run-if-empty docker volume rm

# 一键清（删所有未挂载的卷 + dangling 镜像 + 停止的容器）
docker system prune -af --volumes

# 找出最大的卷 / 目录，定位"占空间元凶"
du -sh * | sort -hr | head

# 清理 2 天前的文件
find ./ -mtime +1 | xargs rm -rf

十一、要点回顾

Volume / bind mount / tmpfs 三选一，数据库用 Volume、配置用 bind mount、敏感数据用 tmpfs
容器层是临时的——任何持久化数据必须挂到卷或宿主机目录
Copy-on-Write决定了"修改容器内文件 ≠ 改镜像"——重启后默认文件
docker volume rm 不能删正在使用的卷——保护在 daemon 层
NFS 跨主机用内置 local driver 即可，不需要装额外插件
共享卷传文件是多容器协作的"原始"模式
vieux/sshfs 已停更——生产场景用云厂商文件存储或自建 NFS

十二、小结

Volume 是 Docker 持久化的"地基"。理解了：

三种挂载类型——volume / bind mount / tmpfs 的取舍
Copy-on-Write——容器层为什么不能持久化
NFS 跨主机——单机 → 多机的进阶
共享卷传文件——容器间协作的底层模式

剩下的就是"挑对的存储后端"：本地 SSD 给数据库、NFS / EFS / Ceph 给共享文件、S3 兼容给对象存储。

下一步：理解了单机 Volume，下一步是 Kubernetes 的 PV / PVC / StorageClass——把"申请存储"变成声明式 API，配合 CSI 驱动对接各种后端（NFS / Ceph / 云盘）。K8s 的存储抽象在 1.21+ 进入 GA，是云原生存储的事实标准。