1. 容器一删数据就没了先搞懂持久化解决什么问题很多人第一次用 Docker 时都会遇到这个场景容器跑得好好的项目里也存了一些文件结果执行 docker rm 后再次启动发现里面空空如也或者干脆换了一台机器说好的数据一样都找不回来。这不是操作失误而是容器数据模型的默认行为。Docker 容器基于镜像启动镜像是只读的运行时会额外生成一个可写层进程写入的文件都落在这个可写层上。容器删除时这个可写层跟着销毁宿主机上不会留下任何业务数据。这个设计本身是为了让容器保持无状态、可重建。但如果容器里运行的是数据库、文件服务、应用配置等有状态服务就得想办法把数据从容器生命周期中剥离出来。Docker 给出的解决方案是不同形式的挂载常用的一共四类Volume、Bind Mount、Tmpfs、NFS。前两类解决“数据该落在宿主机哪里”的问题第三类解决“数据能不能放内存提高性能”的问题第四类解决“多台机器如何共享同一份数据”的问题。很多人习惯直接写 -v却不知道自己挂的到底是卷还是路径更不知道四者的边界。这篇文章我把它们全部过一遍每个都带上实操命令、验证流程和排障思路你可以直接照着跑一遍。2. Volume最省心的持久化方案Docker 官方默认推荐2.1 Volume 的底层形态与优势Volume 是 Docker 在宿主机上专门维护的一块存储本质是一个真实目录默认位于 /var/lib/docker/volumes/卷名/_data。你不需要关心这个路径只需要通过 docker volume 命令去操作它。Volume 和容器可写层最大的区别是生命周期独立Docker 停止、删除、重启Volume 都还在重新启动一个容器再挂载同一个 Volume数据原样可见。为什么官方一直推荐 Volume两个原因是最核心的。第一是解耦Docker 负责目录创建、权限分配、空间回收你不用自己去宿主机上规划路径备份和迁移也有标准招式。第二是可共享同一个 Volume 可以同时挂到多个容器容器之间通过它交换文件比手工拷贝文件可靠得多。还有一点容易被忽略Docker 对 Volume 的读写实现经过专门优化在资源隔离和性能稳定性上比直接绑定宿主目录更可控尤其在桌面级虚拟化环境下表现更明显。2.2 完整实操创建、挂载、验证、删除后的数据恢复先创建一个命名 Volumedocker volume create appdata其实不显式创建也行docker run -v appdata:/data 时 Docker 会自动建立但显式创建的好处是可以在挂载前检查它的配置。执行docker volume inspect appdata输出里有一个 Mountpoint 字段指向宿主机真实路径。记住一点不要手动去那个路径里写东西Docker 管的目录结构在版本升级时可能变化手动操作容易踩坑。接下来挂载进容器验证持久化docker run -d --name demo --mount typevolume,srcappdata,dst/data busybox sleep 3600 docker exec demo sh -c echo hello /data/test.txt然后删除这个容器docker rm -f demo重新启动一个新容器挂载同一个 Volumedocker run -d --name demo2 --mount typevolume,srcappdata,dst/data busybox sleep 3600 docker exec demo2 cat /data/test.txt你会看到 hello 还在。这个步骤就是持久化最直白的验证容器 ID 换了Volume 没换数据就还在。日常维护中我建议把这一组命令当成“挂载体检”每次改动挂载方式后都跑一遍确认数据不丢再继续。2.3 备份与迁移Volume 怎么打包带走Volume 所在的目录在 Docker 私有路径下直接复制整个 /var/lib/docker/volumes 并不安全因为 Docker 内部结构可能变化。官方推荐的备份方式是用一个临时容器挂载目标卷再用 tar 打包。示例命令docker run --rm -v appdata:/data -v $(pwd):/backup busybox tar czf /backup/appdata.tar.gz -C /data .这里关键在参数顺序-C /data 先把工作目录切进数据目录然后打包当前目录 .这样解压出来的文件直接就是数据内容不会多一层 /data 前缀。恢复时反过来docker run --rm -v appdata:/data -v $(pwd):/backup busybox tar xzf /backup/appdata.tar.gz -C /data如果要把 Volume 迁移到另一台宿主机把 tar 包传过去再执行同样的恢复命令即可。数据库容器我尤其建议把备份脚本化定时执行别等出问题再手工救。2.4 权限、空间管理和使用边界Volume 默认以 root 权限被 Docker 创建挂载进容器后目录属主取决于镜像里有没有预设。如果容器进程以普通用户运行而镜像没有把挂载目录的属主改成该用户就会出现“写入 Permission denied”。解决办法是在镜像里提前 mkdir 并 chown或者用一次临时容器把属主改掉docker run --rm -v appdata:/data busybox chown -R 1000:1000 /data之后正式容器用 --user 1000:1000 启动。这种问题在数据库、日志采集类镜像里非常常见先确认镜像默认用户再设计卷的属主能省不少排查时间。空间上要记住删除容器不会删除 Volume磁盘被占满时用 docker system df 查看各类占用再用 docker volume rm 或 docker volume prune 清理。匿名 Volume 是磁盘的大头临时验证时尽量用 --rm 启动容器共享数据一律给命名卷。3. Bind Mount宿主机路径直通容器本地开发的首选3.1 Bind 的本质是路径映射不是数据卷Bind Mount 把宿主机上已经存在的目录或文件直接绑定到容器内的目标路径。容器里读写这个路径本质上就是读写宿主机的原路径中间没有 Docker 管理的数据层。它和 Volume 最大的差别就在于此Volume 是 Docker 创建并管理的数据目录Bind Mount 是你指定宿主机绝对路径、Docker 只做映射的裸目录。这个方式最适合本地开发。比如代码在 /home/me/project 下启动容器时挂到 /app宿主机上改代码容器里立刻生效很多热加载框架靠这个实现即时刷新。生产场景也常见把应用日志目录绑定到宿主机 /var/log/apps日志采集工具直接扫宿主机目录不需要进容器取日志。总之凡是需要“宿主机侧直接看到内容、直接修改内容”的场合Bind Mount 无可替代。3.2 -v 与 --mount 的差异和只读挂载Bind Mount 有两种写法。常用的是docker run -d --name dev -v /home/me/project:/app 镜像更明确的是docker run -d --name dev --mount typebind,src/home/me/project,dst/app 镜像两者效果基本一致但有个非常容易踩的坑用 -v 时如果宿主机路径不存在Docker 会以 root 身份自动创建目录用 --mount 时不会直接报错。自动创建在某些场景是便利但在生产环境是隐患目录属主变成 root权限 755宿主机普通用户或容器内非 root 进程再去写就会遇到权限拒绝。我的习惯是 Bind 一律用 --mount并且提前手动建好目录避免静默创建带来一堆奇怪问题。只读挂载也很常用。把配置目录挂进容器时最怕容器内进程把宿主机配置改乱。挂成只读docker run -d --name dev --mount typebind,src/home/me/project,dst/app,ro 镜像加上 ro 之后容器内对路径的任何写入都会返回 read-only file system宿主机侧仍然可以正常修改。如果你的镜像里有进程非要写这个目录挂上后再排查会更容易报错信息非常直白。3.3 双向同步、权限与 SELinux最容易踩的两个坑Bind Mount 的双向可见性带来一个常见认知错误以为容器内外的用户是隔离的。实际上在默认配置下同一宿主机上的容器内 root 和宿主机 root 是同一个 uid 0所以容器内进程可以随意修改宿主机绑定目录。反过来宿主机目录如果设置成 700 且属主是某个专门用户容器内其他 uid 又读不了。两边会互相影响不是简单的“容器是沙箱”。遇到 Permission denied别急着 chmod 777。正确排查顺序是先在容器里执行 id 看进程 uid再 ls -ln 看宿主机目录属主确认两者有没有交集。比如宿主机目录属主是 1000:1000容器内进程是 uid 999两边都会异常。解决办法是在镜像里固定运行用户或者启动时用 --user 1000:1000让两边一致。如果宿主机开启了 SELinux还会遇到一种“权限看着正常但就是打不开”的假象。文件读写权限都对容器里 open 却失败大概率是 SELinux 标签不对。Docker 提供两个标签参数z 表示共享允许多个容器或进程共享该目录Z 表示私有只有当前容器能用。示例docker run -d --name dev -v /home/me/project:/app:z 镜像注意加 z 或 Z 会修改宿主机目录的 SELinux 属性影响范围不止当前容器生产环境要评估好再执行。3.4 什么场景适合 Bind什么场景别硬上适合用 Bind Mount 的场景很明确本地开发时源码热加载把宿主机的时区文件、DNS 配置、证书文件直接挂给容器日志目录集中输出方便宿主机采集CI 流程里把构建产物挂进容器做验证调试镜像时临时塞一个目录进去检查文件。不适合 Bind 的场景也有一个典型数据库数据文件。数据库对文件锁、fsync、权限非常敏感Bind Mount 更容易被宿主机侧的误操作牵连比如宿主机误删目录、权限被顺手改掉、磁盘空间被其他业务挤爆这些问题在数据库容器里都会被放大。数据共享优先考虑 Volume跨主机才上 NFS。这不是硬性禁令而是我踩过坑之后的排序。4. Tmpfs数据放内存速度快但绝不持久4.1 Tmpfs 到底是把数据放到了哪里Tmpfs 是内存文件系统数据不写磁盘而是放在内核内存和 swap 里。它和其他三种方式完全不同没有宿主机物理目录Docker 只是为容器提供一个“像目录一样”的内存视图。容器停止、删除后Tmpfs 里的数据自动消失。严格来说它不属于持久化但在讨论容器存储时总会被放在一起比较因为很多时候你纠结的不是“要不要持久化”而是“能不能不落盘”。典型场景是缓存、锁文件、临时会话、敏感数据临时处理。比如应用上传的文件先落在一个临时目录处理完就删除用 Tmpfs 能避免这些临时文件反复写磁盘减少存储磨损也降低数据残留风险。再比如高频读写的小文件磁盘 I/O 是瓶颈放内存里性能提升非常明显。我自己做压测时也喜欢把临时结果写到 Tmpfs清理成本为零。4.2 挂载实操与两个关键参数用 --tmpfs 写起来最简单docker run -d --name cache --tmpfs /tmp:rw,size100m,mode1777 镜像用 --mount 表达更清晰docker run -d --name cache --mount typetmpfs,dst/tmp,tmpfs-size104857600,tmpfs-mode1777 镜像两个关键参数必须理解。第一个是 size单位是字节100m 对应 104857600 字节。如果不指定内核默认大小可能是宿主机内存的一半这个值对容器来说太大很容易把内存吃没。我每次用 Tmpfs 都会强制指定 size宁小勿大根据容器内实际写入量评估留出安全余量。第二个是 mode默认是 1777和 /tmp 类似粘滞位让所有用户都能创建文件但不能删别人的文件。如果目录只给单进程使用可以把 mode 收紧到 0700 或 0755。还有一点Tmpfs 只支持目录挂载不支持单文件。另外它没有宿主机路径docker inspect 里看不到 Volume 那样的 Mountpoint因为数据在内存里。4.3 Tmpfs 的风险边界与适用场景最大的风险是无界增长。如果应用逻辑里向 Tmpfs 写入异常数据且没有清理内存会被逐步占满进而拖垮整台宿主机的其他进程。这个事故我见过不止一次容器里看起来一切正常宿主机 free -m 的 available 数字肉眼可见地往下掉最后触发 OOM。所以三个习惯要养成第一所有 Tmpfs 挂载都指定 size第二容器内临时目录要定期清理或由应用自清理第三上线前压测时盯一下内存水位。什么时候不要用 Tmpfs需要跨容器共享的目录不能只用 Tmpfs因为它的生命周期跟着容器走容器删了数据就没了需要落盘审计的数据也不行比如业务日志、交易流水必须写持久化存储。Tmpfs 的定位就是“高性能临时存储”永远不要指望它保存重要数据。5. NFS 挂载跨宿主机共享存储的正确姿势5.1 为什么单机方案满足不了多节点场景Volume 和 Bind Mount 都局限在单台宿主机内。如果容器分布在多台机器上而它们要读写同一份数据比如多个应用实例共用一份上传文件目录或者多个日志采集器写同一个归档目录就必须引入网络共享存储。NFS 是同类方案里最成熟、最通用的主流系统都自带客户端不依赖特定云厂商配置也相对简单。虽然现在有各种分布式存储但 NFS 依然是 Docker 生态里最原生的网络存储形式。Docker 本身支持通过 Volume 机制直接挂载 NFS这也是我在多节点场景下优先推荐的方式。它比在宿主机上先 mount 再 bind 进容器更干净生命周期由 Docker 管理迁移和排障也更统一。5.2 搭建 NFS 服务端并完成客户端测试先准备一台 NFS 服务端。以常见 Linux 发行版为例安装软件包通常叫 nfs-kernel-server 或 nfs-utils。安装完配置导出目录编辑 /etc/exports/export/share 10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash)解释几个选项。rw 表示可读写sync 要求服务端写入磁盘后才返回数据更安全no_subtree_check 是性能优化no_root_squash 表示客户端 root 用户访问时保留 root 权限。这个选项要慎重如果你完全信任内网环境用它可以减少权限困惑如果不信任就保留默认的 root_squash但要注意容器内进程如果以 root 运行写入的文件可能被映射成 nobody容器读回来时权限又会出问题。我的建议是测试环境可以直接用 no_root_squash生产环境单独设计账号和目录权限。配置完成后执行exportfs -ra systemctl restart nfs-server客户端宿主机先安装 nfs-common 或 nfs-utils然后测试连通性showmount -e 10.0.0.10 mkdir -p /mnt/test mount -t nfs 10.0.0.10:/export/share /mnt/test在 /mnt/test 里写一个文件再去服务端 /export/share 确认说明 NFS 通路正常。这一步必须做否则后面 Docker 挂载失败时你分不清是 Docker 的问题还是 NFS 本身的问题。5.3 让 Docker 挂载 NFS 的两种方式第一种是宿主机先挂载 NFS再用 Bind Mount 挂进容器。这种方式直观、排错容易但宿主机重启后如果 NFS 没有自动挂载容器启动时看到的就是一个空目录应用就会默默把数据写到错误的地方。生产环境建议用 systemd 挂载单元或 /etc/fstab 保证开机挂载。如果你同时希望宿主机路径也可见这种最合适。第二种是让 Docker 直接用 Volume 机制挂载 NFS。先创建一个 volumedocker volume create --driver local \ --opt typenfs \ --opt device:/export/share \ --opt oaddr10.0.0.10,rw,nfsvers4 \ sharedvol然后容器挂载这个 volumedocker run -d --name app \ --mount typevolume,srcsharedvol,dst/data \ 镜像关键点在于 --opt typenfs它告诉 volume driver local 去调用内核的 NFS 客户端而不是直接使用本地目录。device 里冒号前面不需要写主机名因为地址在 o 参数里指定。nfsvers4 建议显式写避免客户端默认版本和服务端不一致导致挂载失败。这种方式创建出来的 volume 由 Docker 管理其他容器可以直接按名字挂载同一个卷。5.4 NFS 性能、锁与权限的常见坑NFS 挂载后性能取决于网络质量和大文件还是小文件。顺序读写大文件非常接近本地磁盘随机小文件场景则会被网络往返时延严重拖慢。如果你的应用大量创建小文件先做性能测试再上生产不要等到线上再发现。锁问题上NFS v3 的锁定协议没有 v4 可靠多容器并发写同一个数据库文件是灾难性的。数据库、消息队列这类强一致性组件尽量不要放 NFS。共享目录更适合保存静态文件、上传文件、日志等“写后读多”的数据。权限排查路径和 Bind 类似但多了一个 root_squash 因素。遇到 Permission denied 时按顺序检查NFS 服务端导出选项、客户端是否挂载成功、容器内用户身份、目录属主、SELinux 标签。每一步都能用一条命令验证定位速度会快很多。6. 四类挂载方式特性对比与选型决策6.1 一张表格看清四个方案挂载方式数据持久性数据位置多容器共享跨主机共享性能特点备份复杂度典型场景Volume持久宿主机 Docker 管理目录支持默认不支持可配合网络驱动中稳定需 tar 打包数据库数据、应用状态Bind Mount持久宿主机指定路径支持默认不支持接近本地磁盘直接复制文件开发热加载、日志目录直出Tmpfs不持久容器内存不支持不支持极快内存级无需备份临时缓存、敏感临时数据NFS 挂载持久远端共享存储支持支持受网络限制按网络存储备份多副本共享目录、集群存储注意一个容易混淆的点Volume 默认不跨主机但它可以配合 local driver 的 NFS 类型达到跨主机效果这正是第 5.3 节操作的做法。表格里写“默认不支持”是为了帮助你理解四类方式的原始边界。6.2 四步选型决策路径我自己的选型逻辑可以压缩成四步直接套用第一步问自己数据到底要不要脱离容器保存。如果数据只是容器运行期间的临时产物、缓存、锁文件先考虑 Tmpfs别急着写 Volume。第二步如果需要持久化再问数据是否需要跨主机共享。如果多个宿主机上的容器都要读写同一份数据直接进入 NFS 方案。第三步如果是单机持久化问自己希望路径由 Docker 管理、方便迁移备份还是希望路径就在宿主机上、想直接编辑。前者选 Volume后者选 Bind Mount。第四步从运维角度复核数据库优先 Volume开发环境优先 Bind临时高性能优先 Tmpfs多机统一视图优先 NFS。配套一个真实场景典型 Web 应用里代码目录用 Bind 挂载方便本地开发上传文件目录用 NFS 挂载应对多实例数据库目录用 Volume 保存临时上传目录用 Tmpfs 加速。四种方式在一个应用里可以并存互不冲突。理解各自定位之后组合起来会比只用一种方案灵活得多。6.3 实战中反复出现的坑提前排掉第一个坑把数据库目录直接 Bind 到宿主路径。数据库对文件锁和 fsync 非常敏感宿主侧任何误操作、磁盘压力都会被放大。我见过不止一次因为宿主机根分区写满数据库容器瞬间崩掉的情况。数据库老老实实用命名 Volume备份恢复都按 Volume 的标准做。第二个坑Tmpfs 不限制 size。无界内存文件系统会拖垮整台宿主机任何 Tmpfs 挂载都必须写 tmpfs-size压测时盯内存水位。第三个坑NFS 挂载后容器显示“写入成功”但另一台机器看不到数据。常见原因是挂载点没有真正落到 NFS 上比如 bind 的宿主路径虽然是个目录但其实没挂成 NFS。排查时先 mount | grep nfs确认挂载链完整再查业务逻辑。第四个坑删除容器时顺手加 -v。docker rm -v 会删除容器关联的匿名卷如果你的数据放在命名 Volume 里不受影响但匿名卷里的内容会彻底消失。如果多个容器共享一个匿名卷删除其中一个时带 -v等于把其他容器也在用的数据一并删掉。共享数据一律用命名 Volume并明确约定谁负责删除。第五个坑SELinux 标签导致的权限假象。宿主机上 ls 权限一切正常容器内读取失败先去查 SELinux不要盲目 chmod 777。z 和 Z 标签能解决大部分问题但你要知道它修改的是文件的 SELinux 属性影响是持久的。7. 常见问题排查速查7.1 容器里写文件宿主机却找不到先查 docker inspect 容器的 Mounts 字段看挂载类型和 Source 路径。如果是 volume文件在默认路径 /var/lib/docker/volumes/卷名/_data 下不要去宿主机业务目录找。如果是 bindSource 就是你指定的宿主路径确认容器内写的是不是确实挂到的那个目标路径。很多人容器里写 /app/data宿主机找的是 /app目录多了嵌套自然找不到。7.2 容器启动后目录权限异常按顺序检查三件事容器内用户 id 是否和宿主机目录属主匹配挂载类型是 volume 还是 bindvolume 初始属主是不是 root是否启用 SELinux 且目录标签不正确。不要一上来 chmod 777先把原因定位尤其是生产环境权限已经被改乱的话后续排障成本会很高。7.3 磁盘被 Volume 占满用 docker system df 查看各部分占用。Volume 删除容器后不会被清理需要 docker volume rm 或 docker volume prune。匿名 volume 是磁盘占用的大头养成习惯临时验证用 --rm 启动容器并避免创建匿名卷共享数据必给命名卷。日志类容器还要注意宿主机磁盘监控要覆盖 /var/lib/docker否则卷增长时容易被忽略。7.4 NFS 挂载失败但手动 mount 正常最常见是 Docker 的挂载参数和服务端导出格式不匹配。检查 --opt device 是不是 :/export/share 这种格式--opt o 里的 addr 是否可访问nfsvers 是否匹配。另一个高频原因是宿主机防火墙放行了普通 mount 测试但 Docker daemon 使用的挂载端口不通。遇到这种情况先在宿主机手动执行完全相同的 mount 命令逐条对比参数再看 dmesg 里的具体报错。提示所有涉及生产数据的挂载变更先备份再操作。这类问题排查起来并不难但没有备份的话任何一个误删都可能把几周的数据送走。我个人现在的习惯是数据库和应用状态一律命名 Volume开发调试直接 Bind临时高 I/O 缓存用 Tmpfs多机共享统一 NFS。这个原则帮我在好几个项目里少踩了很多坑。现在每遇到一个存储需求我先跑一遍第 6.2 节那条决策路径再写 docker run 命令基本上不会再出现“数据消失了”“权限炸了”这种低级事故。最后再分享一个不算技巧但很有用的习惯任何挂载方案变更先在测试机上完整跑一遍创建、写入、重启、删除、恢复的循环确认数据不丢再上生产。这个习惯值回很多次折腾。