Docker镜像、容器与卷：分层、隔离与持久化一次讲清

很多人把镜像、容器和卷混为一谈，结果一删容器数据就丢，或者把密码写进镜像带到生产环境。本文用一个最常见的场景把三者分开：镜像是只读模板，容器是运行中的实例，卷是独立于容器生命周期的持久化存储。先把这层关系理清，后面的命令才不会用错。镜像采用分层结构，每一次构建指令都会产生一层只读层，相同的底层可以被多个镜像复用，因此拉取和构建都很快。查看本地镜像可以用 docker images，查看某一镜像由哪些层组成可以用 docker history。写 Dockerfile 时要尽量把变化慢的依赖安装放在前面，把经常变化的业务代码放在后面，这样缓存命中率更高，构建时间也会明显缩短。容器是从镜像启动的读写实例，启动后会在镜像层之上叠加一层可写层。容器里产生的文件默认都写在这一层，容器删除后可写层也随之消失，这就是为什么把数据库文件直接放在容器里非常危险。启动一个测试容器可以用 docker run -d --name demo nginx，查看运行状态用 docker ps，停止并删除用 docker stop demo 和 docker rm demo。卷就是为了解决持久化问题。卷由 Docker 管理，保存在宿主机上，不随容器删除而消失，多个容器也可以挂载同一个卷。创建卷用 docker volume create mydata，挂载时用 docker run -d -v mydata:/data nginx，数据会写入卷而不是容器可写层。除了命名卷，还有绑定挂载，它把宿主机某个目录直接映射进容器，适合本地开发时实时看到代码变化，但生产环境更推荐命名卷，因为它与宿主机路径解耦，也更容易备份和迁移。做一个最小验证：先创建卷并启动容器写入文件，删除容器后再用同一个卷启动新容器，文件仍然存在，这就证明数据已经脱离了容器生命周期。备份时不要直接拷贝运行中的数据库文件，先用数据库自带的导出工具，或者把卷挂载到一个临时容器里打包。恢复时同样先创建新卷，再把备份解压进去，最后启动应用容器挂载新卷。常见的三个误区值得警惕：第一，把配置和密码写进镜像，镜像一旦分发就很难收回；第二，把日志和上传文件留在容器可写层，重启或重建后就找不回来；第三，以为删除容器就是清理干净，实际上孤儿卷会越积越多，需要定期用 docker volume ls 和 docker volume prune 检查，但清理前一定要确认没有重要数据。总结一张检查清单：镜像只读且不含敏感信息，容器随时可删可重建，数据只放在卷里并有备份，开发用绑定挂载，生产用命名卷。按照这个顺序去设计，Docker 的部署就会既轻量又可靠。