现在很多服务都喜欢用docker部署，快捷方便。经常出现服务器只跑了三四个容器，根分区却接近100%。docker ps看上去很正常，真正占空间的可能是一份持续刷新的日志，也可能是长期累积的镜像层和构建缓存。
这时不要进入/var/lib/docker手工删除目录。Docker仍在管理其中的层、元数据和文件句柄，删错后可能让容器无法启动。下面从文件系统开始，把占用拆开看。
系统提示磁盘满，至少有两种情况。df -hT看容量，df -ih看inode。容量接近100%，通常要找大文件；inode接近100%，常见原因是数量庞大的小文件。两者处理方法不同。接着查看Docker Root Dir，确认Docker数据到底放在哪个挂载点。服务器改过data-root，或者使用Docker Desktop、containerd镜像存储时，路径未必是/var/lib/docker。
先跑这四条：
-
`df -hT` -
`df -ih` -
`docker info –format ‘{{.DockerRootDir}}’` -
`findmnt -T /var/lib/docker`
如果Docker根目录不在告警分区，继续删镜像没有意义，应回到该分区查日志、数据库或其他目录。容量高而inode正常，下面继续拆Docker占用；inode高，则优先统计小文件集中在哪个目录。
docker system df -v会拆出镜像、容器可写层、数据卷和构建缓存。docker ps --size只显示容器可写层，不能代表容器的全部占用。日志、挂载卷和部分元数据不在这个数字里，所以“容器只有几百MB”与“系统盘被占满”可以同时发生。
这几项放在一起看：
-
`docker system df -v` -
`docker ps –size` -
`docker image ls` -
`docker volume ls`
看到较大的RECLAIMABLE，只说明Docker找到了候选对象，不等于可以直接删除。镜像可能用于回滚，停止的容器也可能保留了现场。若这里的总量并不大，重点转向容器日志和Docker目录之外的文件。
Docker默认的json-file驱动会持续记录容器的标准输出和错误输出。应用出现报错循环、调试日志未关闭，或者健康检查频繁失败时，一个容器就可能写出几十GB。Docker官方不建议用外部工具直接修改这些日志文件，因为守护进程仍在管理文件句柄和轮转状态。
日志从这里找：
-
`docker inspect -f ‘{{.HostConfig.LogConfig.Type}} {{.LogPath}}’ <容器>` -
`sudo du -ah /var/lib/docker/containers | sort -h | tail` -
`docker logs –since 10m <容器>`
某个日志明显偏大时，先看最近十分钟输出，找到反复出现的报错，再处理应用配置或日志级别。只清文件却不处理刷屏原因，磁盘很快还会满。日志体积正常，则继续核对构建缓存、数据卷和宿主机上的其他目录。
构建缓存和悬空镜像通常容易重新生成，数据卷可能装着数据库、上传文件或配置。清理动作应从可重新构建的对象开始。执行前查看命令将处理的内容，并确认业务是否依赖旧镜像回滚。docker system prune --volumes会把未被容器引用的卷纳入清理，不能把“当前未挂载”理解成“里面没有数据”。
清理前逐项确认：
-
`docker builder prune –filter ‘until=168h’` -
`docker image prune` -
`docker container prune` -
`docker volume inspect <卷名>`
释放空间后，重新运行df -hT和docker system df -v。数字下降多少，应能与刚才处理的对象对应。发现陌生卷或用途不明的停止容器时，宁可暂缓，也不要为了多释放几GB把唯一数据删掉。
可以在/etc/docker/daemon.json里给json-file设置大小和保留数量。配置值要写成字符串。修改后检查JSON，重启Docker，再观察业务容器是否恢复。Docker官方说明，新默认值只影响之后创建的容器；已经存在的容器通常需要重新创建。
修改顺序：
-
备份 /etc/docker/daemon.json -
配置 max-size 与 max-file -
`systemctl restart docker` -
重建容器后再次 docker inspect
重建一个低风险容器后，用docker inspect确认日志选项。看到max-size和max-file才算配置落到容器上。最后给磁盘容量和inode加告警，避免业务再次被写满的根分区拖停。
