★ FEATURED ARTICLE 1. 为什么容器重启后数据就没了先从OverlayFS说起用 Docker 跑一个数据库容器跑得好好的某天清理环境时一个docker rm下去表数据全没了。这个场景我见过太多次几乎每个刚接触存储卷的人都会踩一遍。原因不在镜像是坏的而在容器文件系统本身的构造Docker 启动容器时镜像层是只读的Docker 会在镜像层之上追加一个可写层平时你对容器内任何文件的修改都会落在这个可写层里。当容器执行docker rm被删除后这个可写层也会跟着容器一起销毁数据自然就没了。这个机制来自联合文件系统OverlayFS / overlay2的工作方式。镜像由多层只读层叠加构成多个容器可以复用同一组镜像层节省磁盘和内存而每个容器独有的可写层只负责记录运行期间的差异。这种设计的优点是镜像共享效率极高缺点是容器本身是一个临时对象生命周期结束数据随之消失。很多人会有个误解容器restart之后文件还在是不是就说明数据保存了其实不是容器停止并不会删除可写层文件当然还在。但只要你把容器删了哪怕只是docker rm可写层和里面的一切就都没了。判断标准非常简单数据是否绑定在容器这个对象上容器删除时是否被连带销毁。如果答案是是那么这份数据本质上就是临时的。那怎么让数据活到容器生命周期之外答案就是 Docker 存储卷Volume。它是一个由 Docker 管理和维护的持久化存储单元生命周期独立于容器。你可以单独创建卷、查看卷、备份卷也可以把同一个卷同时挂载给多个容器。容器可以删卷还在新容器挂载同一个卷数据就回来了。1.1 可写层和卷的分工可写层适合放那些丢了也不可惜的文件比如临时缓存、运行时生成的 socket 文件。真正需要长期保留的数据比如数据库文件、上传的用户内容、配置文件修改记录都应该放进卷里。卷在宿主机上通常是一块由 Docker 管理的目录挂载到容器内的指定路径后容器内对该路径的写入操作实际落在卷对应的宿主机目录中与容器生命周期完全解绑。从这个角度看卷解决的不只是容器删除后数据还在这一件事它还带来一个额外好处多个容器可以共享同一份数据因为卷是宿主机层面的存储不再属于任何一个容器。后续要讲到的多容器共享、备份恢复、跨主机迁移都是建立在卷独立于容器这个核心设计之上的。2. 三种挂载方案的定位差异与选型判断Docker 常用的挂载方案有三种Volume卷、Bind Mount绑定挂载和 tmpfs。很多人一上来就用-v /host/path:/container/path的绑定挂载方式功能上能用但丢掉了 Docker 对卷的管理能力。想选对方案先得把这三者的差异看透。2.1 VolumeDocker 管理的存储单元Volume 是 Docker 推荐的标准方案。你可以先用docker volume create mydata主动创建也可以直接挂在容器上让 Docker 自动创建。它由 Docker 统一维护数据默认存放在/var/lib/docker/volumes/下面有清晰的卷名、驱动类型和元数据信息。最实用的特性是Dockerfile或镜像里如果有VOLUME /data容器启动时会为这个路径自动创建一个匿名卷保证数据不会写到可写层里被误删。Volume 的可移植性也更好。挂载时只需要写卷名不需要关心宿主机上的具体目录在哪。在开发机、测试机、生产机上只要卷名一致挂载配置几乎可以原样复用宿主机的目录路径差异被 Docker 屏蔽掉了。2.2 Bind Mount把宿主机路径直接挂进去Bind Mount 就是把宿主机任意路径直接挂到容器路径里比如-v /home/user/code:/app。它没有卷管理的概念也不会被docker volume ls列出来。优势在于直接和宿主机文件系统交互修改代码、调整配置文件、查看日志容器内外实时同步。所以开发环境调试代码时Bind Mount 非常顺滑。副作用也很明显宿主机目录的权限、SELinux 标签、属主会直接影响容器内访问很容易出现容器里写不进去的权限问题。而且配置里写的是宿主机绝对路径换一台机器就得改路径部署环境稍有不同就容易漏。2.3 tmpfs仅内存的临时挂载tmpfs 挂载只存在内存里性能极高但容器停止后数据就清空重启也不会保留。适合放密码、密钥、临时缓存这类敏感或短生命周期文件。因为它不落盘天然没有磁盘 IO也不会被其它进程扫到宿主机的残留文件。实际使用场景相对窄但在多容器共享临时状态或者追求极致性能时它是个不错的补充选项。2.4 三者对比与选型建议我用一个表把关键差异列出来方便你对照判断方案数据位置生命周期管理方式典型场景VolumeDocker 管理目录独立于容器持久存在docker volume命令直接管理数据库数据、应用持久化文件、多容器共享Bind Mount宿主机任意路径独立于容器与宿主机目录共存无专门管理命令靠路径引用开发调试、配置文件热更新、日志输出tmpfs容器内存随容器停止而清空无持久化仅在运行期间存在临时敏感数据、高频缓存、测试环境选型建议其实可以压缩成一句话生产环境默认用 Volume开发调试用 Bind Mount临时敏感数据用 tmpfs。尤其是数据库这类对权限和稳定性要求高的场景Volume 会让 Docker 帮你处理目录初始化的问题比 Bind Mount 省心得多。3. 卷的完整操作链路创建、挂载、确认、清理操作卷的日常链路可以总结为创建卷、挂载到容器、确认数据落盘、最后按需清理。每一步都有一些小细节单独看都很简单组合起来如果踩了坑就会排查半天。3.1 创建与验证先创建卷docker volume create mydata然后查看现有卷和其他信息docker volume ls docker volume inspect mydatainspect输出信息很关键重点看 Mountpoint。虽然一般不建议直接去宿主机目录翻文件但排查卷占用、确认数据落盘位置时这个路径能帮你快速定位。比如你会发现卷的实际目录是/var/lib/docker/volumes/mydata/_data容器里挂载的/app对这个目录。知道了这条映射关系很多数据去哪了的问题都能一眼看穿。实际使用中我很少单独先create更多是直接在docker run时给一个命名卷Docker 会自动创建。单独create的唯一价值在于可以提前配置卷属性比如设置 NFS 驱动参数、给卷打标签、指定自定义 Mountpoint这些操作没法在run命令里通过短语法完成。3.2-v与--mount两种写法短语法docker run -d --name web -v mydata:/app nginx长语法docker run -d --name web \ --mount typevolume,sourcemydata,target/app \ nginx两者达到的效果基本一样区别在可读性和扩展性。--mount的typevolume,source...,target...结构非常明确再加读写模式、驱动选项也方便适合写进脚本或 Compose 文件里。-v更短常见但字段含义比较隐晦刚接触的人很容易把mydata:/app和/host/path:/container/path混在一起。还有一类是匿名卷。只写容器内路径例如docker run -d --name data -v /app redis这时候 Docker 会生成一个随机名称的卷单独持久存储容器里/app目录的数据。匿名卷的数据确实能保留但卷名是随机字符串用户不直接知道它叫啥下次新容器想复用就麻烦了。它的实际价值是配合镜像中自带的VOLUME指令让容器内的可写数据天然脱离可写层防止误删。真正要手动管理数据时尽量都用命名卷。3.3 确认卷的挂载使用情况容器运行过程中可以用docker inspect查看 Mounts 信息docker inspect web --format {{json .Mounts}}输出里会列出Type、Source、Destination、RW字段。我排查这个容器到底挂载了哪些卷、数据实际写到哪里时就用这个命令。它比翻看历史命令更靠谱因为有些卷可能是镜像自动创建的不 inspect 根本发现不了。如果要看一个卷被哪几个容器引用可以借助docker system df -v它会列出每个卷的使用状态、关联容器 ID。这个命令尤其适合在清理环境前做一次卷占用盘点避免误删还在被使用的数据。3.4 删除卷与清理孤儿卷删除单个卷docker volume rm mydata清理所有未被使用的卷docker volume prune需要注意容器还在运行时正在被它使用的卷是无法直接删除的Docker 会报冲突。另外prune不仅会清理命名卷也会清理所有匿名卷和从容器里隔离出来的孤儿卷。执行之前务必确认这些卷里没有你还需要的残留数据。我见过有人清理环境后才发现旧容器虽然删了但匿名卷里还放着上一个版本的数据库文件结果prune一把全清光了想恢复都没有头绪。所以清理大动作前先做一次备份永远不亏。4. 容器间数据共享从单容器到多容器协作卷最有价值的一个特性是一次创建、多处挂载。同一个卷可以被多个容器同时挂载数据在这几个容器之间天然共享。这种共享能力在很多业务场景里都能用上比如 Nginx 和内容生成服务同时读写同一份静态文件日志收集容器和业务容器共享日志目录。4.1 多容器挂载同一个卷做法就是反复用同一个卷名docker volume create shared-data docker run -d --name app1 --mount sourceshared-data,target/app/data busybox sleep 3600 docker run -d --name app2 --mount sourceshared-data,target/data busybox sleep 3600这个序列执行后app1 容器里写/app/data/hello.txtapp2 容器里直接能读/data/hello.txt。两个目录看上去在不同的容器路径下底层指向的是同一个宿主机目录。但这里有个非常关键的边界Docker 只负责共享目录不负责并发数据同步。两个容器同时写同一个文件时文件锁、并发冲突全部由应用层自己处理。如果只是简单的读多写少场景多个容器共享卷没问题如果是两套进程在写同一个数据库目录或同一个索引文件你一定要被警告轻则数据互相覆盖重则目录结构损坏。我用这种架构跑过日志采集当时的教训是进程必须明确规划好谁写哪个子目录别让两个容器在同一层级抢写。还有一个容易忽略的点多个容器同时挂载同一个卷时如果容器里对同一路径的文件权限、属主不一致就会出现 A 容器写入后 B 容器读不到的情况。本质上是 UID/GID 的问题后面专门会讲。4.2--volumes-from数据卷容器的历史遗产Docker 早期没有成熟的 Named Volume 管理方式时流行过一种数据卷容器模式先创建一个只包含卷的容器其它容器用--volumes-from继承卷定义。docker create --name>docker volume create \ --driver local \ --opt typenfs \ --opt oaddr192.168.1.10,rw \ --opt device:/srv/nfs \ nfsvolume然后把这个卷挂到不同节点的容器上就能实现跨主机共享同一份数据。注意选择网络卷时要接受两个代价一是网络延迟带来的 IO 性能下降二是多数网络文件系统并不提供数据库级别的一致性保证。生产环境的数据库数据卷我强烈建议留在本地 local 卷不要轻易放到 NFS 上除非你能接受极端故障场景下的数据风险。5. 备份、恢复与迁移卷数据的安全线谈到备份很多人第一反应是数据库自己有导出工具dum备份、sql导出都行。这没有错但不够。如果你要迁移整个环境、换机器、升级存储驱动或者碰上 Docker 数据目录本身被破坏逻辑备份可能不够用。卷级物理备份是最后一道安全线。5.1 用临时容器打包卷目录标准做法是挂载卷和备份目录到同一个临时容器里然后用 tar 打包完成后容器自动删除。我用的命令docker run --rm \ -v mydata:/source \ -v $(pwd):/backup \ ubuntu \ tar czf /backup/mydata-backup-$(date %Y%m%d).tar.gz -C /source .命令拆解一下-v mydata:/source把卷挂到容器里当作源目录-v $(pwd):/backup把当前工作目录挂成备份目标ubuntu镜像本身就带 tar不需要额外安装-C /source .表示打包的是/source目录里的内容不是把/source这个目录本身打包进去。这样恢复时直接解压到目标目录就能保持原有层级。其实这也是一个很典型的临时容器用法不要在业务容器里塞一堆运维工具而是启动一个完全干净的工具容器挂上需要的卷完成操作。5.2 恢复到新卷先创建目标卷再把备份文件解压进去docker volume create newdata docker run --rm \ -v newdata:/target \ -v $(pwd):/backup \ ubuntu \ tar xzf /backup/mydata-backup.tar.gz -C /target恢复完成后先不要急着直接跑应用先检查一下文件属主是不是正确。如果你备份时容器内写文件的 UID 是 1000恢复时用 Ubuntu 镜像默认的 root 身份解压那新卷里的文件就变成 root 所有原应用容器可能就写不进去了。解决办法是恢复命令里带上--same-owner或者在挂载时使用--user 1000:1000甚至事后chown -R 1000:1000 /target。这一步很多人会漏等应用启动报 Permission denied 才开始排查已经浪费了不少时间。5.3 从 Bind Mount 迁移到 Volume实际工作中最常见的迁移是从开发用的 Bind Mount 迁到生产环境的 Volume。步骤也不复杂先对挂载目录做一次 tar 打包再创建一个命名卷并解压进去。数据本身没有格式差异关键还是权限和路径的一致性。我记得有一次帮朋友迁移一个内部工具开发机上目录权限是普通用户挂进容器后一切正常迁到生产服务器用 root 解压后容器里以非 root 用户运行时直接没权限写文件。排查了一轮才发现是解压时属主变化了加个chown就解决了。这类权限细节几乎每次迁移都会出现。6. 权限、性能与故障我最常被问到的问题最后聊几个实际使用中高频出现的问题。这些问题在官方文档里都有描述但大部分人是踩过坑之后才会认真看文档所以我把它们集中整理一遍。6.1 容器内 UID 和宿主机 UID 不一致镜像里经常以非 root 用户运行进程比如 nginx 的nginx用户、MySQL 的mysql用户UIP 在容器里可能是 101 或者 999而宿主机上卷目录的属主是 root。于是宿主机文件权限是root:root 755时容器内非 root 进程就写不进去报Permission denied。解决思路有三个把宿主机卷目录的属主改成容器内进程的 UID比如chown -R 1000:1000 /var/lib/docker/volumes/mydata/_data运行容器时用--user $(id -u):$(id -g)让容器进程以宿主机用户身份运行但需要注意镜像里一些需要 root 才能执行的操作可能会失败使用命名卷而不是 Bind Mount因为 Docker 在首次挂载空卷到镜像目录时会尝试把镜像目录的属主和权限复制到卷中很多官方数据库镜像的启动脚本也会在启动时自动修正权限我最终极的建议是优先选命名卷让镜像自身的初始化逻辑处理权限。6.2 挂载目录被清空或覆盖的经典误区很多新手第一次遇到的是把宿主机一个非空目录 bind mount 进容器结果容器里这个目录原本的文件全都不见了。这个不是Docker删了它们而是挂载后宿主机目录把容器目录遮蔽了原来的文件还在镜像层里只是挂载点上暂时看不到。另外一种情况正好相反命名卷首次挂载到容器里的非空目录时如果卷是空的Docker 会把镜像目录里的内容复制进卷如果卷里已有数据就直接用卷数据忽略镜像目录内容。这个初始化复制是新手最震惊的行为之一。我记得有个同事把旧版本的数据库目录挂进新镜像结果发现容器启动后数据目录里文件不是他预想的版本所有的回调都是因为卷里有残留旧数据Docker 不会主动替你清理也不会让新镜像内容覆盖旧卷。所以操作挂载前一定要清楚这个卷是否为空、镜像目标目录里是否有需要保留的数据、两者冲突时哪个优先。这些判断完成比执行命令本身更重要。6.3 卷究竟有没有性能损耗对于 local 驱动而言Volume 本质上是写宿主机磁盘和 Bind Mount 没有本质差距。多一层目录结构、多一道 Docker 管理逻辑带来的性能损耗可以忽略尤其在正常的磁盘性能下完全感知不出来。tmpfs 因为是纯内存性能最高适合高频临时读写。真正需要警惕的是网络卷。NFS、CephFS 这类方案每写一次数据都可能经过网卡、网络协议栈、远端进程延迟比本地磁盘高出一个数量级。而且很多文件锁、fallocate、mmap 这类操作在 NFS 上表现不稳定数据库场景下大概率会出问题。所以我的建议是数据库本地卷用在本地集群级存储给真正需要跨节点共享的业务数据用不要图省事把数据库也塞到网络卷上。6.4 MySQL / PostgreSQL 数据库打卷时的典型坑数据库镜像是卷使用最频繁、也最容易出问题的场景。我见过的问题基本集中在几个地方官方镜像里有内置的VOLUME /var/lib/mysql容器启动时会自动创建匿名卷。你如果手动指定了命名卷就绕过了镜像的默认匿名卷此时要自己确认卷目录权限和初始化流程是否正确。升级镜像大版本时如果挂载目录里已经存在老版本的数据库文件新版本启动会检查元数据版本如果不兼容会直接拒绝启动。这个时候千万别轻易删目录重来正确做法是先做一次完整备份再用官方要求的方式处理版本升级。在某些非 Linux 环境下挂载目录的文件锁行为可能异常数据库启动时报 unable to lock file。这种场景下使用 Docker 管理的卷比直接用宿主机目录更稳。数据库算是卷操作里容错率最低的类型操作前后多做一次备份、多检查一次权限都比事后想办法恢复要省事得多。卷这个东西理解核心逻辑之后并不复杂它是容器外部的一块持久存储生命周期由 Docker 管理和容器解耦。真正让你觉得难的往往是权限、挂载覆盖、清理时机这些边界情况。你能把上面这几个问题都想明白再碰到容器删了数据没了或者挂载后文件不见了这类问题基本一眼就能定位根因。
阅读完成 · 觉得有帮助？
