docker overlay 总是没2天就把硬盘吃光了.... 是什么原因呢?

Question

如下,我已经将docker的镜像文件等 通过启动参数制定为/data分区了. 但是跑几天 这140g就会被docker彻底占用完毕.100%. 停止所有容器,docker system prune,就好了,跑几天又占满了. 访问量基本可以忽略不计.

请问是什么原因呢? 该如何解决呢? 谢谢.

使用了 docker compose 进行容器管理

dockerinfo

Containers: 9
 Running: 8
 Paused: 0
 Stopped: 1
Images: 9
Server Version: 17.04.0-ce
Storage Driver: overlay
 Backing Filesystem: xfs
 Supports d_type: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: 
containerd version: 422e31ce907fd9c3833a38d7b8fdd023e5a76e73
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-514.16.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 94.21GiB
Name: lan
ID: PAXF:B5ON:REKS:XKQT:H2NZ:7SRZ:CNZB:DX6E:RARZ:Y52A:YOOZ:CN5X
Docker Root Dir: /data/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Registry Mirrors:
 https://z3sa3ije.mirror.aliyuncs.com/
Live Restore Enabled: false

df -lh

/dev/sda2        50G  4.6G   46G   10% /
devtmpfs         48G     0   48G    0% /dev
tmpfs            48G     0   48G    0% /dev/shm
tmpfs            48G  4.1G   44G    9% /run
tmpfs            48G     0   48G    0% /sys/fs/cgroup
/dev/sda6       140G   67G   74G   48% /data
/dev/sda3        38G 1003M   37G    3% /home
/dev/sda1      1014M  214M  801M   22% /boot
overlay         140G   67G   74G   48% /data/docker/overlay/b5eaf497779b4fd9cee674f3e23e68498fd0e3163432096861c1cd3da7578364/merged
overlay         140G   67G   74G   48% /data/docker/overlay/f829def71e4b9b1d881a4ea4b0a3ab51c693f0e233fef9c0eb17b52976d4a13e/merged
overlay         140G   67G   74G   48% /data/docker/overlay/7ac5ddeb786ea976978930534c177356de132c52c38c039875086b9254f408a8/merged
overlay         140G   67G   74G   48% /data/docker/overlay/64b4dc812120556cf016741723203c55d7434112214469e6dd31873e603ca7ff/merged
overlay         140G   67G   74G   48% /data/docker/overlay/cba97ec068f55cae0cfd044c89d83dee622bfc8043a80563ab29a5b1656039f6/merged
overlay         140G   67G   74G   48% /data/docker/overlay/3a8ec67332c56da299ad5b39b5bf25946f0b5b8e8a97c05e22c7796d0c43c761/merged
shm              64M     0   64M    0% /data/docker/containers/55800384001dc44638f51b71632ca9516cd36280c3b6f118f085590fd6ea646e/shm
shm              64M     0   64M    0% /data/docker/containers/c553d9d019856b3bfe68e25bf7c1b144b977d69fb9187d0d3805b1511815e451/shm
shm              64M  4.0K   64M    1% /data/docker/containers/6ff159d2f5cff658a0d7bf96b5a5c01933715c905e26e62bce31cffa4124606b/shm
shm              64M     0   64M    0% /data/docker/containers/4666af66213c5b1d288782b51a1d8923276e5b94587bec1cc9b75d2120381548/shm
shm              64M     0   64M    0% /data/docker/containers/83ed677a14aa823a116d128021bdf1739dd9bf1845f7804fcc1d0adb6f27f405/shm
shm              64M     0   64M    0% /data/docker/containers/574b2f238406377d35d8802d07722815d8065f0f230a0f3291af2adf8de8a320/shm
overlay         140G   67G   74G   48% /data/docker/overlay/77cb467e19de09b3cba5f9d48cda6a086e989496d953a5ef55cdfb6e6a855d3b/merged
shm              64M     0   64M    0% /data/docker/containers/e1a6e5bab954af04eb49ef2251caa744e9c42e147da1c67ff693bf44784d685c/shm
overlay         140G   67G   74G   48% /data/docker/overlay/80ec06d73e1c0dc140188e3bbf91ebc3a019d6047da37164570c15ada6e6c651/merged
shm              64M     0   64M    0% /data/docker/containers/ad92c2116caade3c8ffd64f02b1644ac44b8bf1c2cd044907a35a3d63d9a0fff/shm
tmpfs           9.5G     0  9.5G    0% /run/user/0

Answer 1

docker ps -a 
docker images -a 

把不需要的删掉

Answer 2

额......后来找到原因了. 其他朋友也可以尝试看看我的方式是否可行.

1. 磁盘被占满后,不急删除docker的占用, 一个一个目录查看实际大小. 找到最大的. 查看到底什么文件大.然后判断当前容器是那个, 找那个容器的原因.

我的实际是因为 有个容器应用 每秒都会报错,但是错误日志没有写到容器外. 没几天磁盘就占完了.