★ FEATURED ARTICLE 1. 项目概述为什么数据卷不是“可选配件”而是容器运行的基石你刚用docker run -it ubuntu:22.04启动一个容器往/app/data目录里存了三份日志、两个配置文件、一套用户上传的图片——然后随手敲了docker stop和docker rm。等你再docker run起一个新容器发现/app/data下空空如也。这不是 bug是 Docker 的默认设计逻辑容器生命周期一结束它内部所有改动包括你辛辛苦苦写进去的数据就随风而散。这在测试环境很清爽在生产环境就是灾难现场。这就是我们今天要深挖的核心问题Docker 容器数据持久化之 Data Volume数据卷与容器数据共享1。关键词非常明确——“数据卷”、“持久化”、“容器共享”。它不讲镜像构建、不聊网络策略、不碰编排工具只聚焦一件事让数据活下来且能被多个容器安全、高效、可管理地共同使用。这个能力直接决定你能不能把 MySQL、PostgreSQL、Redis、Elasticsearch 这类有状态服务真正跑在容器里也决定你能不能让 Web 应用容器和日志收集容器读写同一份日志文件更决定你能不能在 CI/CD 流水线中把构建产物从一个构建容器传递给下一个部署容器。我做过不下二十个容器化迁移项目凡是跳过数据卷这一环、直接用-v /host/path:/container/path绑定挂载硬上生产的90% 在三个月内都遇到过权限错乱、路径不存在、宿主机磁盘爆满却查不到源头、或者升级镜像后配置文件被覆盖等事故。而那些从第一天就规划好 volume 生命周期、命名规范、备份策略的团队系统稳定运行三年以上是常态。所以这不是一个“学了有用”的知识点而是一个“不学必踩坑”的生存技能。本文面向所有已能写 Dockerfile、会docker run和docker ps的中级使用者目标是让你合上文章就能独立设计 volume 方案、写出健壮的docker-compose.yml、排查 95% 的 volume 相关故障并理解每一步操作背后的 Linux 文件系统原理和 Docker daemon 的调度逻辑。2. 核心设计思路拆解为什么不用 bind mount为什么 volume 是唯一正解2.1 三种挂载方式的本质区别决定了你的数据命运Docker 提供三种将数据带入容器的方式bind mount绑定挂载、tmpfs mount内存挂载和 volume数据卷。很多人以为只是写法不同-v /host:/contvs-v myvol:/cont其实它们在内核层面、权限模型、生命周期管理和可移植性上完全是三个物种。Bind mount本质是 Linux 的mount --bind命令封装。Docker daemon 把宿主机上某个绝对路径比如/data/mysql直接映射进容器的某个目录。它的优点是路径完全可控、调试方便缺点极其致命提示宿主机路径必须提前存在且权限需手动对齐容器内 UID/GID路径硬编码导致镜像无法跨环境复用开发机/home/user/app和生产服务器/opt/app完全不同Docker 无法管理其生命周期——你删容器/data/mysql还在但没人知道它属于哪个服务更可怕的是如果宿主机路径被误删或磁盘损坏数据永久丢失Docker 甚至不会报错。Tmpfs mount纯内存文件系统数据只存在于 RAM 中容器停止即清空。适用于存放 session、临时缓存、密钥文件避免落盘。但它和“持久化”完全背道而驰本文不展开。Volume数据卷这才是 Docker 为“持久化”量身定制的解决方案。它由 Docker daemon 全权管理存储在宿主机的特定目录下通常是/var/lib/docker/volumes/但你永远不应该、也不需要直接操作这个路径。Docker 通过 volume 名称如myapp-db-data来抽象和定位数据。它的核心优势是与宿主机路径解耦你只管起名myapp-db-dataDocker 自动分配物理位置镜像可无修改地从开发环境推到测试、预发、生产生命周期自治docker volume create myapp-db-data创建docker volume rm myapp-db-data删除docker volume ls查看一切命令化、可脚本化多容器共享天然支持两个甚至十个容器可以同时挂载同一个 volumeDocker 内部自动处理文件锁、inode 一致性基于底层文件系统如 ext4/xfs 的原子操作备份与迁移标准化docker run -v myapp-db-data:/data -v $(pwd):/backup alpine tar czf /backup/vol-backup.tar.gz -C /data .一行命令完成打包无需关心物理路径。我曾在一个电商项目里把 MySQL 的/var/lib/mysql从 bind mount 改为 named volume。改造前每次上线新版本都要人工登录服务器检查/data/mysql权限是否被重置MySQL 容器以mysql用户启动但宿主机目录常属root改造后只需在docker-compose.yml里声明volumes: [mysql-data:/var/lib/mysql]Docker 自动创建 volume 并赋予正确权限CI 流水线一键部署零人工干预。2.2 Volume 的底层实现不是“黑盒”而是可验证的 Linux 机制很多教程把 volume 描绘成 Docker 的魔法黑盒其实它非常透明。当你执行docker volume create myvolDocker daemon 做了三件事在/var/lib/docker/volumes/下创建子目录myvol/_data注意_data是固定后缀不可省略设置该目录的 owner 为root:root但赋予755权限即其他用户可读可执行但不可写将该目录的 inode 信息注册进 Docker 的元数据库/var/lib/docker/volumes/metadata.db。然后当你docker run -v myvol:/app/data nginxDocker 实际调用的是 Linux 的mount --bind /var/lib/docker/volumes/myvol/_data /var/lib/docker/overlay2/xxx/merged/app/data。也就是说volume 本质就是一次受控的 bind mount但控制权完全交给了 Docker daemon而非用户。这个认知至关重要。它解释了为什么 volume 比 bind mount 更安全Docker 确保了_data目录的初始权限和归属且禁止你直接rm -rf /var/lib/docker/volumes/myvol虽然技术上可行但会破坏 Docker 的元数据一致性后续docker volume ls可能显示异常。也解释了为什么 volume 不能跨 Docker daemon 使用——因为/var/lib/docker/volumes/是 daemon 的私有领地换一台机器这个路径下的数据对新 daemon 来说就是一堆“孤儿文件”。实操验证很简单开一个终端执行docker volume create testvol然后sudo ls -la /var/lib/docker/volumes/testvol/你会看到清晰的_data目录和metadata.json文件。再docker run -v testvol:/data alpine ls -la /data对比输出就能确认数据确实落到了那个_data目录下。这种“眼见为实”的验证比死记硬背概念管用十倍。2.3 为什么“容器数据共享”必须基于 volumebind mount 的共享陷阱“让两个容器读写同一份数据”听起来简单但 bind mount 在此场景下会埋下深坑。假设你用 bind mount 让 Nginx 和 PHP-FPM 容器共享/www# 错误示范bind mount 共享 docker run -d -v /host/www:/www nginx docker run -d -v /host/www:/www php-fpm表面看没问题但隐患重重权限地狱Nginx 容器通常以nginx用户UID 101运行PHP-FPM 以www-data用户UID 33运行。宿主机/host/www目录若属root两者都无写权限若属www-dataNginx 又写不了。你不得不chmod 777 /host/www这在生产环境是严重安全违规。路径漂移开发时你用/home/dev/www测试环境用/opt/www每次部署都要改命令极易出错。清理黑洞docker stop docker rm两个容器后/host/www还在但没人记得它属于哪个已废弃的服务半年后磁盘告警才发现是“幽灵目录”。而 volume 共享则干净利落# 正确方案named volume 共享 docker volume create web-content docker run -d -v web-content:/usr/share/nginx/html nginx docker run -d -v web-content:/var/www/html php-fpm此时Docker 自动确保web-content/_data目录对两个容器内的进程都具备正确权限实际是通过chown和chmod在容器启动时动态调整细节见后文。你只需记住web-content这个名字所有环境保持一致。更重要的是当服务下线docker volume rm web-content一条命令彻底清理不留痕迹。我在某内容平台做静态资源服务化时就吃过 bind mount 共享的大亏。前端团队和后端团队各自维护一份/static目录因权限不一致Nginx 偶尔返回 403排查三天才发现是宿主机目录属主被另一个容器的启动脚本意外修改。换成 volume 后问题根除且docker volume inspect web-content能清晰看到谁在使用它运维审计一目了然。3. 核心细节解析与实操要点从创建到权限每一个参数都有讲究3.1 Volume 创建的三种方式命令行、Compose、API选对场景Volume 创建绝非只有docker volume create一种方式不同场景应匹配不同方法否则事倍功半。docker volume create命令行方式适合一次性、交互式操作或 CI/CD 中初始化环境。它支持关键参数--driver指定驱动默认local即本地文件系统。高级场景可用vieux/sshfs驱动挂载远程 SFTP 目录或cloudstor驱动对接云存储但本文聚焦基础。--opt传驱动选项。对local驱动最常用的是ouid1001,gid1001设置_data目录的 UID/GID但强烈不建议在创建时硬编码原因见 3.2 节。--label打标签如--label envprod --label servicedb便于后续docker volume ls --filter labelenvprod过滤这是大型集群必备的元数据管理手段。示例为生产数据库创建带标签的 volumedocker volume create \ --label envprod \ --label servicemysql \ --label backupdaily \ mysql-prod-datadocker-compose.yml中声明这是现代应用的标准做法将 volume 定义与服务定义绑定实现基础设施即代码IaC。它比命令行更强大因为支持external: true引用已有 volume或driver_opts精细控制。version: 3.8 services: db: image: mysql:8.0 volumes: - mysql-data:/var/lib/mysql # 使用名为 mysql-data 的 volume environment: MYSQL_ROOT_PASSWORD: example app: image: myapp:latest volumes: - mysql-data:/app/db-data # 同一 volume 被 app 容器共享 volumes: mysql-data: # 这里声明 volumeDocker Compose 会自动创建 driver: local driver_opts: o: uid999,gid999 # 注意此处设置的是容器内进程的 UID/GID非宿主机 labels: - envprod关键点volumes:顶层键定义 volumeservices.service.volumes键挂载它。mysql-data在这里既是逻辑名也是物理 volume 名Composed 会确保它被创建。API 方式POST /volumes/create适用于需要集成到自研运维平台的场景。请求体 JSON 与docker volume create参数一一对应。例如用 curl 创建curl -X POST http://localhost:2375/v1.41/volumes/create \ -H Content-Type: application/json \ -d {Name:api-cache,Labels:{env:staging}}这种方式将 volume 管理纳入统一 API 体系适合 DevOps 团队构建自动化流水线。选择原则个人学习、快速验证用命令行团队协作、生产部署必须用 Compose平台级集成用 API。混用会导致状态不一致——比如 Compose 声明了mysql-data但你又用docker volume create mysql-data手动创建Docker 会报错“volume already exists”。3.2 权限问题为什么chown不是万能解药真正的 rootless 解法这是 Docker volume 最令人头疼、也最容易被错误解答的问题容器内进程如 MySQL以非 root 用户运行但 volume 的_data目录默认属root:root导致容器启动失败或无写权限。网上流传最多的“解决方案”是docker run -v myvol:/data ubuntu chown -R 999:999 /data这不仅是低效的更是危险的。为什么因为chown命令本身需要 root 权限而你让容器以非 root 用户启动根本执行不了chown。更糟的是即使你用--user root启动chown也只在当前容器生命周期内生效下次重启_data目录权限又变回root:root。真正的解法分三层按推荐顺序排列最佳实践在 Dockerfile 中USER之前RUN chown这是最优雅、最符合容器哲学的方式。在构建镜像时就将 volume 挂载点的默认权限设好FROM mysql:8.0 # 创建数据目录并设置属主MySQL 默认 UID/GID 是 999 RUN mkdir -p /var/lib/mysql \ chown -R 999:999 /var/lib/mysql \ chmod -R 755 /var/lib/mysql USER 999:999 # 切换到非 root 用户这样无论 volume 是新建还是复用容器启动时/var/lib/mysql目录的权限和属主都已就绪。Docker daemon 在挂载 volume 时会保留_data目录的权限而容器内进程以 UID 999 启动自然拥有完全控制权。次选方案使用--user参数配合driver_opts仅限 Compose如果无法修改镜像如使用官方 MySQL 镜像可在 Compose 中利用driver_opts的o选项在 volume 创建时就设定_data目录的属主volumes: mysql-data: driver_opts: o: uid999,gid999 # 注意这是设置宿主机 _data 目录的 UID/GID然后容器仍以USER 999启动完美匹配。但要注意o选项的值必须是宿主机上真实存在的 UID/GID否则创建 volume 会失败。因此这要求你的宿主机和容器内用户 ID 规划一致适合标准化运维环境。最后手段Entrypoint 脚本动态修复当以上都不适用如老旧镜像、复杂权限逻辑才考虑编写entrypoint.sh#!/bin/sh # entrypoint.sh if [ ! -z $MYSQL_DATA_DIR ]; then # 确保数据目录属主正确 chown -R 999:999 $MYSQL_DATA_DIR chmod -R 755 $MYSQL_DATA_DIR fi exec $然后在docker run时挂载并指定docker run -v mysql-data:/var/lib/mysql \ --entrypoint /entrypoint.sh \ -e MYSQL_DATA_DIR/var/lib/mysql \ mysql:8.0这增加了启动延迟且每次容器启动都执行chownIO 开销大仅作兜底。我在线上 MySQL 集群中强制推行第一种方案。所有自研数据库镜像Dockerfile 开头必有RUN mkdir chown并文档化 UID/GID 标准统一用 999。这样无论是开发、测试还是生产docker-compose up一键拉起从不因权限报错。而那些依赖entrypoint.sh的项目平均每月要处理两次因chown失败导致的启动超时告警。3.3 Volume 的命名、标签与生命周期管理别让 volume 成为“数据垃圾场”一个没管理的 Docker 环境docker volume ls输出几十上百个 volume名称如a1b2c3d4,f5g6h7i8全是随机字符串没人知道哪个是数据库哪个是日志哪个是临时测试。这就是典型的“数据垃圾场”。专业运维必须建立 volume 命名和标签规范。命名规范强制采用project-service-purpose格式全部小写用短横线连接。例如ecommerce-mysql-prod-dataecommerce-redis-prod-cacheecommerce-nginx-staging-staticci-jenkins-workspace禁止使用myvol,data1,testvol这类无意义名称。命名即文档看到名字就应知道其归属、环境和用途。标签Label规范推荐docker volume create --label或 Compose 的labels是元数据管理的利器。必打标签包括env:dev/test/staging/prodservice:mysql/redis/nginx/appbackup:none/daily/weekly/critical决定备份策略owner:team-frontend/team-backend明确责任团队查询示例docker volume ls --filter labelenvprod --filter labelservicemysql瞬间列出所有生产 MySQL volume。生命周期管理必须Volume 不是“创建即永恒”。必须制定清理策略自动清理在 CI/CD 流水线末尾添加docker volume rm $(docker volume ls -q --filter labelenvtemp)清理临时 volume。定期审计每周执行docker volume ls -q --filter danglingtrue查找“悬空 volume”无容器引用结合docker volume inspect name确认是否可删。备份策略对backupcritical的 volume每日凌晨用tar打包并上传至对象存储对backupdaily的保留最近 7 天。我在某金融客户项目中曾发现一个prod-mysql-datavolume 占用 2TB但docker ps显示无容器在使用它。docker volume inspect发现其CreatedAt是两年前Labels里owner字段为空。最终确认是旧版部署脚本 Bug 导致 volume 创建后未被挂载。若无标签和定期审计这 2TB 磁盘空间将永远“静默占用”。4. 实操过程与核心环节实现从零开始搭建一个可共享的 WordPress 环境4.1 需求分析与架构设计为什么需要两个 volume我们要部署一个高可用 WordPress 站点包含wordpress容器运行 PHPApache处理业务逻辑mysql容器存储用户、文章、插件等结构化数据nginx容器可选作为反向代理提供 HTTPS 和静态资源缓存。核心需求MySQL 数据必须持久化避免容器重启后数据库清空WordPress 的wp-content目录必须持久化插件、主题、上传的图片都在此且需被nginx容器共享以直接提供静态文件服务所有 volume 必须可跨环境迁移开发、测试、生产使用同一套 Compose 文件。因此我们需要两个 volumewp-mysql-data专用于 MySQL 的/var/lib/mysqlwp-content用于 WordPress 的/var/www/html/wp-content并被nginx容器挂载。架构图文字描述[宿主机] ├── /var/lib/docker/volumes/wp-mysql-data/_data → 被 mysql 容器挂载 └── /var/lib/docker/volumes/wp-content/_data → 被 wordpress 和 nginx 容器同时挂载注意wp-contentvolume 是共享的关键。它让wordpress容器负责动态内容生成PHPnginx容器负责静态文件分发HTML/CSS/JS/IMG两者通过 volume 交换数据完全解耦性能和可维护性远超单容器方案。4.2 编写 production-ready 的 docker-compose.yml以下是一个经过生产环境验证的docker-compose.yml包含 volume 声明、服务定义、网络配置和关键注释version: 3.8 # 定义网络隔离服务 networks: wp-network: driver: bridge ipam: config: - subnet: 172.20.0.0/16 # 定义 volume这是全文核心 volumes: # MySQL 数据卷生产环境专用带标签 wp-mysql-data: driver: local driver_opts: o: uid999,gid999 # MySQL 容器内 UID/GID 为 999 labels: - envprod - servicemysql - backupcritical # WordPress 内容卷被 wordpress 和 nginx 共享 wp-content: driver: local labels: - envprod - servicewordpress - servicenginx - backupdaily services: # MySQL 服务 db: image: mysql:8.0 restart: unless-stopped networks: - wp-network environment: MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD} MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: ${DB_PASSWORD} volumes: - wp-mysql-data:/var/lib/mysql:rw # rw 表示读写可省略默认 command: --default-authentication-pluginmysql_native_password --character-set-serverutf8mb4 --collation-serverutf8mb4_unicode_ci healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -u, root, -p$${DB_ROOT_PASSWORD}] timeout: 20s retries: 10 # WordPress 服务 wordpress: image: wordpress:6.4-php8.2-apache restart: unless-stopped networks: - wp-network environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_NAME: wordpress WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: ${DB_PASSWORD} WORDPRESS_CONFIG_EXTRA: | define(WP_DEBUG, false); define(WP_MEMORY_LIMIT, 512M); volumes: - wp-content:/var/www/html/wp-content:rw # 共享内容卷 # 注意WordPress 镜像默认将 /var/www/html 作为 DocumentRoot # 但只有 wp-content 需要持久化其余wp-admin, wp-includes随镜像更新 depends_on: db: condition: service_healthy # Nginx 服务反向代理 静态文件服务 nginx: image: nginx:1.25-alpine restart: unless-stopped networks: - wp-network ports: - 80:80 - 443:443 volumes: - wp-content:/var/www/html/wp-content:ro # 只读挂载安全第一 - ./nginx.conf:/etc/nginx/nginx.conf:ro # 自定义 Nginx 配置 - ./ssl:/etc/nginx/ssl:ro # SSL 证书 depends_on: - wordpress关键细节说明volumes:顶层定义wp-mysql-data和wp-content被明确定义Docker Compose 会在docker-compose up时自动创建如果不存在。挂载模式wordpress对wp-content是rw读写nginx是ro只读。这是安全最佳实践——Nginx 只需读取静态文件不应有写权限。depends_on与healthcheck确保wordpress容器只在db健康后启动避免 WordPress 启动时连不上数据库报错退出。环境变量DB_ROOT_PASSWORD和DB_PASSWORD通过.env文件注入避免密码硬编码。4.3 一键部署与验证从零到可访问网站的完整流程现在让我们走一遍真实部署流程。假设你已在服务器上安装 Docker 和 Docker Compose。步骤 1准备环境# 创建项目目录 mkdir -p ~/wordpress-prod cd ~/wordpress-prod # 创建 .env 文件填入密码生产环境请用更安全的方式如 HashiCorp Vault cat .env EOF DB_ROOT_PASSWORDStrongRootPass123! DB_PASSWORDStrongAppPass456! EOF # 创建 Nginx 配置文件简化版仅 HTTP cat nginx.conf EOF events { worker_connections 1024; } http { upstream php { server wordpress:80; } server { listen 80; server_name localhost; # 静态文件直接由 Nginx 服务不转发给 PHP location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { root /var/www/html; expires 1y; add_header Cache-Control public, immutable; } # 其他请求转发给 WordPress location / { proxy_pass http://php; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } } EOF # 创建 SSL 目录占位生产环境放真实证书 mkdir -p ssl步骤 2启动服务# 启动-d 后台运行 docker-compose up -d # 查看状态 docker-compose ps # 输出应类似 # Name Command State Ports # ----------------------------------------------------------------------------------------------------------------- # wordpress-prod-db-1 docker-entrypoint.sh --def ... Up (healthy) 3306/tcp # wordpress-prod-nginx-1 /docker-entrypoint.sh ngin ... Up 0.0.0.0:80-80/tcp, 0.0.0.0:443-443/tcp # wordpress-prod-wordpress-1 docker-entrypoint.sh apach ... Up 80/tcp步骤 3验证 volume 是否生效# 查看 volume 列表确认两个 volume 已创建 docker volume ls | grep wp- # 检查 wp-content volume 的物理路径 docker volume inspect wp-content | jq .[0].Mountpoint # 输出类似/var/lib/docker/volumes/wp-content/_data # 进入 wordpress 容器确认挂载点 docker exec -it wordpress-prod-wordpress-1 sh -c ls -la /var/www/html/wp-content # 应看到 plugins/, themes/, uploads/ 等标准目录且属主为 www-data (UID 33) # 进入 nginx 容器确认只读挂载 docker exec -it wordpress-prod-nginx-1 sh -c touch /var/www/html/wp-content/test.txt # 应报错touch: /var/www/html/wp-content/test.txt: Read-only file system步骤 4访问网站并上传测试浏览器打开http://your-server-ip进入 WordPress 安装向导。完成安装后登录后台上传一张图片到媒体库。查看uploads目录docker exec -it wordpress-prod-wordpress-1 sh -c ls -la /var/www/html/wp-content/uploads/ # 应看到年月目录和上传的图片直接通过 Nginx 访问该图片 URL如http://ip/wp-content/uploads/2024/06/test.jpg应能正常加载——证明wp-contentvolume 已被nginx容器成功读取。整个过程你没有碰过任何宿主机的/var/lib/docker/volumes/路径所有操作都通过 volume 名称抽象完成。这就是 Docker volume 设计的精妙之处开发者只关注逻辑Docker 负责物理。5. 常见问题与排查技巧实录那些年我们踩过的 volume 坑5.1 “Permission denied” 错误90% 的根源在这里现象容器启动失败日志显示mkdir: cannot create directory /var/lib/mysql: Permission denied或Cant open and lock privilege tables: Table mysql.user doesnt exist。排查路径docker logs container-name确认错误关键词docker volume inspect vol-name查看Mountpointsudo ls -la Mountpoint检查宿主机目录权限和属主docker exec -it container-name id查看容器内进程 UID/GID对比步骤 3 和 4如果 UID/GID 不匹配就是权限问题。根治方案如前所述优先在 Dockerfile 中RUN chown若用 Compose检查driver_opts.o是否设置了正确的 UID/GID绝对不要在宿主机上手动sudo chownvolume 目录这会破坏 Docker 的元数据一致性。我曾帮一个团队解决持续一周的 MySQL 启动失败问题。最终发现他们用的是一台 Ubuntu 22.04 服务器其mysql用户 UID 是 123而官方 MySQL 镜像内置的mysql用户 UID 是 999。driver_opts.o写成了ouid123,gid123但镜像内进程仍以 UID 999 运行导致权限不匹配。解决方案是要么修改宿主机用户 UID不推荐要么在 Dockerfile 中chown推荐要么换用bitnami/mysql镜像其 UID 可配置。5.2 “No space left on device”不是磁盘真满了而是 volume 占用失控现象docker run报错no space left on device但df -h显示磁盘还有 50% 空闲。真相Docker 的 overlay2 存储驱动其元数据和镜像层也占用/var/lib/docker空间。而 volume 数据就放在/var/lib/docker/volumes/下它和 overlay2 共享同一块磁盘分区。排查命令# 查看各 volume 占用空间需要进入 volume 目录 sudo du -sh /var/lib/docker/volumes/* | sort -hr | head -10 # 查看 overlay2 占用镜像、容器层 sudo du -sh /var/lib/docker/overlay2/* | sort -hr | head -10 # 查看整体 docker 目录大小 sudo du -sh /var/lib/docker/解决方案立即清理docker system prune -a -f慎用会删所有未使用的镜像、容器、网络、volume更安全的是docker volume rm unused-vol长期治理为 volume 设置backup标签编写定时脚本对backupnone的 volume每周自动docker volume ls -q --filter labelbackupnone | xargs docker volume rm磁盘分离生产环境将/var/lib/docker挂载到一块独立 SSD 上与系统盘分离避免相互影响。某客户曾因一个未清理的 CI 构建 volumeci-build-cache增长到 1.2TB导致整个 Docker daemon 崩溃。事后我们为其建立了 volume 容量监控当du -sh /var/lib/docker/volumes/超过 80%自动触发告警并
阅读完成 · 觉得有帮助？
