容器数据卷：别把数据留在容器里

容器删了，数据跟着没了——这是新手在 Docker 上交的第一笔学费。根源在镜像分层机制：运行时的写入都在容器顶部的可写层，docker rm 删容器时，可写层一并被清掉。 一、先理解为什么会丢 镜像只读、容器可写，这个设计让容器可以随时重建、随时回滚，代价是可写层不能当存储用。数据库容器跑半年，数据文件全写在容器层，某天升级版本时删掉旧容器再起新容器，旧数据一去不返。所以规矩只有一条：有状态的数据一律放容器之外，这件事在第一次部署时就要做对。 二、bind mount：挂宿主机目录 -v /opt/app/data:/var/lib/mysql 把宿主机的具体目录映射进容器。优点是直观，数据就在指定路径下，备份工具直接对准它；缺点是路径与宿主机耦合，迁移时目录结构要跟着走，容器内外用户权限不一致时偶尔要手动处理属主。 三、named volume：命名卷 先 docker volume create app_data 声明，再 -v app_data:/var/lib/mysql 挂进容器。数据实际存放在 /var/lib/docker/volumes/ 下，由 Docker 统一管理，不绑定具体目录，迁移和权限处理都省心。docker-compose 文件底部 volumes 段声明的就是这种。 四、怎么选 数据库和应用产生的核心数据，两种方式都行，团队习惯上命名卷用得多；配置文件、需要在宿主机直接编辑的文件，bind mount 更顺手。同一个容器里两种混用完全正常：配置走 bind mount，数据走命名卷。 五、一份自查清单 docker inspect 容器名 查看 Mounts 字段：凡是没有挂载、又在持续产生数据的（数据库、用户上传目录），尽快补挂载。迁移窗口内先停写入，把旧数据拷进新挂载点，再重建容器验证读写正常。 数据卷配置是一次性工作，配好之后升级、迁移都从容。检查清单从上到下过一遍，五分钟的事，换来的是夜里能睡整觉；反过来，这里省下的十分钟，迟早加倍还回去。