在使用docker一段时间后突然出现某个容器进程挂掉，然后再去重新启动都会失败，这是可能需要看看是不是docker把磁盘占满了。下面详细介绍一下我遇到docker占满磁盘的一次经历。
某天上午测试突然反馈内网测试环境业务出现问题，功能不能正常使用，于是赶紧查看日志定位，发现是zookeeper连接异常了，zookeeper是使用docker部署，一般不会出现问题。
执行docker ps 命令发现 zookeeper已经挂掉了，然后执行 docker ps -a 查看zookeeper的容器id，接着执行docker start <zookeerper 容器id> ，发现zookeeper已经起不来了
2. 查看zookeeper的日志
在/var/lib/docker/containers目录下 感觉容器id找对应的log，根据error异常百度发现是磁盘满了
-
查看服务器的磁盘使用情况
执行df命令
[root@apollo containers]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg-root 15971232 12841532 2295348 100% /
/dev/sda1 487634 195848 262090 43% /boot
tmpfs 800900 0 800900 0% /run/user/0
/dev/sdb 103080888 61464 97760160 1% /data2
overlay 15971232 12841532 2295348 100%
/var/lib/docker/overlay2/7f45979e4ea63e8a4a8c8228c3177d33b26215462301fdccb4eb456e4d753c54/merged
所有的overlay 的Use% 都提示100% ，根目录/ 的Use%也提示100%，确实磁盘占满了
4.一层一层查看那个文件夹或文件占用磁盘最多
在根目录下执行命令
du -h --max-depth=1一层一层查看，发现/var/lib/docker占用的磁盘空间最多
- 清理docker 占用的磁盘
经查看最大的文件夹有/var/lib/docker/volumes，/var/lib/docker/overlay2，/var/lib/docker/containers
containers中存放了所有的容器的日志，可以用容器的id找到对应的目录，如果容器已经停止或删除，可以直接删除对应的文件夹。
volumes，overlay2 占用的磁盘空间最多，很明显就是要删除这个两个目录下面的东西，但是这里对应的文件夹无法和容器id对应上来，所以不能随便删除。只能先使用docker的命令来删除。
先执行 docker system prune命令 ,发现清理出来一些空间了。
$ docker system prune
WARNING! This will remov
-
all stopped containers
-
all networks not used by at least one container
-
all dangling images
-
all build cache
然后执行docker volume prune，删除没有使用的数据卷，但是还有很多的空间占用
$ docker volume pruneWARNING! This will remove all local volumes not used by at least one container.
详细查看volume文件夹
执行
du -h --max-depth=1
查看里面占用磁盘最多的一个文件夹打开进入一看，原来是数据库，原来根源是数据库占用将近一半的磁盘空间，于是清理了一下数据库，磁盘空间释放了一半出来了。
详细查看overlay2 文件夹
overlay2也占用了不少的空间，经过排除 一个容器可能会关联多个 overlay2 下面的目录，无从下手，放弃了。
最后记录几个有用的命令:
docker system df ----查看Docker占用分布
docker builder prune 清理构建缓存
docker system prune 清理关闭的容器、无用的数据卷和网络，以及dangling镜像（即无tag的镜像)
docker system prune -a 命令，这会删除所有未使用的镜像
注意：
- 在使用清理命令之前，请确保不会意外删除仍在使用的资源。
- 清理操作是不可逆的，一旦执行，删除的资源将无法恢复。
- docker stats ---可以查看docker容器的内存占用
docker stats ---- Display a live stream of container(s) resource usage statistics
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
5f10308a7d93 zookeeper 0.12% 68.73MiB / 7.79GiB 0.86% 1.5kB / 0B 5.97MB / 32.8kB 38
70062327fc72 apollo-portal 0.17% 402.8MiB / 7.79GiB 5.05% 5.5GB / 3.94GB 86.5MB / 24.6kB 53
808793d179ee apollo-admin 0.16% 442.1MiB / 7.79GiB 5.54% 18.1GB / 16.1GB 118MB / 24.6kB 59
7feade55a442 apollo-configser 1.16% 452.7MiB / 7.79GiB 5.68% 84.5GB / 53.6GB 158MB / 24.6kB 96
89f85b83a29b mysql 1.10% 659.9MiB / 7.79GiB 8.27% 77.4GB / 124GB 16.1GB / 2.31TB 178
CONTAINER ID and Name ：the ID and name of the container
CPU % and MEM % ：the percentage of the host’s CPU and memory the container is using
MEM USAGE / LIMIT：the total memory the container is using, and the total amount of memory it is allowed to use
NET I/O：The amount of data the container has sent and received over its network interface
BLOCK I/O：The amount of data the container has read to and written from block devices on the host
PIDs：the number of processes or threads the container has created
关于控制DOCKER自动生成日志json-file的大小
容器长时间运行后，会生成大量的logs日志，这样能有效控制容器自动生成日志。
vim /etc/docker/daemon.json
{
"registry-mirrors": ["https://0v0l236l.mirror.aliyuncs.com"],
"insecure-registries":["192.168.0.42:5000","192.168.0.129:8050"],
"log-driver":"json-file", #日志存储格式
"log-opts":{
"max-size" :"10m","max-file":"3" #日志大小及副本数
}
}
扩展资料：
https://docs.docker.com/engine/reference/commandline/stats/?spm=a2c6h.13066369.0.0.7c314e3c1ttce3
评论区