docker 磁盘清理 相关

用户在使用 Docker 部署业务一段时间后，可能会发现宿主节点的磁盘容量持续增长，甚至将磁盘空间耗尽进而引发宿主机异常，进而对业务造成影响。 本文先对 Docker 的空间分析与清理进行说明，然后对容器的磁盘容量限制与使用建议做简要说明。

典型问题场景

用户发现 Docker 宿主机的磁盘空间使用率非常高。通过 du 逐层分析，发现是 Volume 或 overlay2 等目录占用了过高空间。示例如下：

# 根据使用的存储驱动的不同，相应目录会有所不同：
[root@node3 docker] # du -h --max-depth=1 |sort
104K ./network
13M ./image
20K ./plugins
24G ./overlay2 # 这个目录占用了非常高的磁盘磁盘空间
25G .
283M ./volumes
4.0K ./swarm
4.0K ./tmp
4.0K ./trust
518M ./containers

空间使用分析

遇到此类问题，可以参阅如下步骤进行空间分析，定位占用过高空间的业务来源。

分析 Docker 空间分布

Docker 的内置 CLI 指令 docker system df ，可用于查询镜像（Images）、容器（Containers）和本地卷（Local Volumes）等空间使用大户的空间占用情况。 示例输出如下：

[root@node3 docker]# docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 17 12 2.713 GB 1.144 GB (42%)
Containers 15 12 10.75 GB 0 B (0%)
Local Volumes 8 4 282.9 MB 241.8 MB (85%)

查看空间占用细节

可以进一步通过 -v 参数查看空间占用细节，以确定具体是哪个镜像、容器或本地卷占用了过高空间。示例输出如下：

[root@node3 docker]# docker system df -v
# 镜像的空间使用情况
Images space usage:

REPOSITORY TAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE CONTAINERS
busybox latest 6ad733544a63 5 days ago 1.129 MB 0 B 1.129 MB 1
nginx latest b8efb18f159b 3 months ago 107.5 MB 107.5 MB 0 B 4
ubuntu latest 14f60031763d 3 months ago 119.5 MB 0 B 119.5 MB 0
alpine 3.3 606fed0878ec 4 months ago 4.809 MB 0 B 4.809 MB 0
tutum/curl latest 01176385d84a 3 years ago 224.4 MB 0 B 224.4 MB 1

# 容器的空间使用情况
Containers space usage:

CONTAINER ID IMAGE COMMAND LOCAL VOLUMES SIZE CREATED STATUS NAMES
d1da451ceeab busybox "ping 127.0.0.1" 0 10.7 GB About an hour ago Up About an hour dstest
956ae1d241e8 nginx:latest "nginx -g 'daemon ..." 0 26 B 3 months ago Up 3 months localTest_restserver_2
74973d237a06 nginx:latest "nginx -g 'daemon ..." 0 2 B 3 months ago Up 3 months

# 本地卷的空间使用情况
Local Volumes space usage:

VOLUME NAME LINKS SIZE
83ba8747f4172a3c02a15f85b71e1565affca59f01352b4a94e0d28e65c26d1c 0 830 B
a479c303b278f1442f66644f694a554aac630e72b7a27065a11ef85c4d87b648 0 22.16 MB
79a25b6376e0d6587d8f4f24e08f9467981f04daad14bf3353a12d727d065503 1 18.83 MB

空间清理

自动清理

可以通过 Docker 内置的 CLI 指令 docker system prune 来进行自动空间清理。

Tips ：

不同状态的镜像

• 已使用镜像（used image）： 指所有已被容器（包括已停止的）关联的镜像。即 docker ps -a 看到的所有容器使用的镜像。
• 未引用镜像（unreferenced image）：没有被分配或使用在容器中的镜像，但它有 Tag 信息。
• 悬空镜像（dangling image）：未配置任何 Tag （也就无法被引用）的镜像，所以悬空。这通常是由于镜像 build 的时候没有指定 -t 参数配置 Tag 导致的。比如:

REPOSITORY TAG IMAGE ID CREATED SIZE
< none> <none> 6ad733544a63 5 days ago 1.13 MB # 悬空镜像（dangling image）

挂起的卷（dangling Volume)
类似的，dangling=true 的 Volume 表示没有被任何容器引用的卷。

docker system prune 自动清理说明：

• 该指令默认会清除所有如下资源：

  • 已停止的容器（container）
  • 未被任何容器所使用的卷（volume）
  • 未被任何容器所关联的网络（network）
  • 所有悬空镜像（image）。
• 该指令默认只会清除悬空镜像，未被使用的镜像不会被删除。
• 添加 -a 或 --all 参数后，可以一并清除所有未使用的镜像和悬空镜像。
• 可以添加 -f 或 --force 参数用以忽略相关告警确认信息。
• 指令结尾处会显示总计清理释放的空间大小。

操作示例：

[root@node3 docker] # docker system prune --help

Usage: docker system prune [OPTIONS]

Remove unused data

Options:
-a, --all Remove all unused images not just dangling ones
-f, --force Do not prompt for confirmation
--help Print usage
[root@node3 docker] # docker system prune -a
WARNING! This will remove:
- all stopped containers
- all volumes not used by at least one container
- all networks not used by at least one container
- all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Deleted Containers:
c09c31c49491ee7f2324160e43947917940221b4e6cc1274906def640a7a631f
2aa0180e1a0f4c2c64349a6ed969651052373e7a9471050dce9015701cf1b957
6d18003b06823c5d76d807a319387b06680fc93d0a32bc29c1cea4c07e8d515d

Deleted Volumes:
a479c303b278f1442f66644f694a554aac630e72b7a27065a11ef85c4d87b648
79a25b6376e0d6587d8f4f24e08f9467981f04daad14bf3353a12d727d065503

Deleted Images:
untagged: tutum/curl:latest
untagged: tutum/curl@sha256:b6f16e88387acd4e6326176b212b3dae63f5b2134e69560d0b0673cfb0fb976f
deleted: sha256: 01176385d84aeb1d40ed18c6d3f952abf40d2d2b4aa98fcf0a8a4b01010fb9a9
deleted: sha256:c84f85637212412c1d46d1dd50f789df2c3b44678ee3fee6a820888e734f9b5a
untagged: test:lastest
deleted: sha256: 794ff09332586a091514eb3d1c44990244e57e34adc71d4b4334c0674a1377e9
deleted: sha256: 636a1e7769d2242556243e9a21fb96bb878ab5b94c41ff485667252c968b375e

Total reclaimed space: 1.565 GB

手工清理

网络清理

网络配置通常占用的空间非常低，略过。

镜像清理

如果通过 docker system df 分析，是镜像占用了过高空间。则可以根据业务情况，评估相关镜像的使用情况。对于悬空和未使用的镜像， 可以使用如下指令手工清理：

# 删除所有悬空镜像，但不会删除未使用镜像：
docker rmi $(docker images -f "dangling=true" -q)

# 删除所有未使用镜像和悬空镜像。
# 【说明】：轮询到还在被使用的镜像时，会有类似"image is being used by xxx container"的告警信息，所以相关镜像不会被删除，忽略即可。
docker rmi $(docker images-q)

卷清理

如果通过 docker system df 分析，是卷占用了过高空间。则可以根据业务情况，评估相关卷的使用情况。对于未被任何容器调用的卷（-v 结果信息中，"LINKS" 显示为 0），可以使用如下指令手工清理：

# 删除所有未被任何容器关联引用的卷：
docker volume rm $(docker volume ls -qf dangling= true)

# 也可以直接使用如下指令，删除所有未被任何容器关联引用的卷（但建议使用上面的方式）
# 【说明】轮询到还在使用的卷时，会有类似"volume is in use"的告警信息，所以相关卷不会被删除，忽略即可。
docker volume rm $(docker volume ls -q)

容器清理

如果通过 docker system df 分析，是某个容器占用了过高空间。则可以根据业务情况，评估相关容器的业务归属并进行处理。对于已停止或其它异常状态的容器，可以结合  -f 或 --filter 筛选器，使用类似如下指令来手工清理：

# 删除所有已退出的容器
docker rm -v $(docker ps -aq -f status=exited)
# 删除所有状态为 dead 的容器
docker rm -v $(docker ps -aq -f status=dead)

更多关于 ps 指令支持的筛选器信息，可以参阅官方文档。

在用空间资源分析

对于还在使用的空间资源，可以参阅如下说明做进一步排查分析。

镜像空间分析

如果某个镜像占用了过高空间，则可以通过如下方式做进一步空间分析：

1. 通过 docker system df 获取占用过高空间的镜像信息。
2. 基于相应镜像创建测试容器。
3. exec 进入容器后，结合 du 等 shell 指令做进一步空间分析，定位出占用最高空间的目录或文件。
4. 结合业务情况做进一步处理，重新 build 镜像。

示例：

[root@node3] # docker exec -it dstest sh
/ # du -h | head
8.0K ./root
32.0K ./etc
4.0K ./usr/sbin
8.0K ./usr
10.0G ./home/java/logs
10.0G ./home/java
10.0G ./home
1.1M ./bin
0 ./dev/shm
0 ./dev/mqueue

容器空间分析

如果某个运行中的容器占用了过高空间，则可以通过如下方式做进一步空间分析：

Tips ：

容器的只读层与镜像层的空间占用情况
一个容器的占用的总空间，包含其最顶层的读写层（writable layer）和底部的只读镜像层（base image layer，read-only）。更多相关说明，可以参阅官方文档。
可以通过 docker ps 的 -s 参数来分别显示二者的空间占用情况，进而判断相应容器的空间占用主要是来自原始镜像，还是运行中产生。

示例：

# 如下容器的原始镜像占用了 422MB 空间，实际运行过程中只占用了 2B 空间：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES SIZE
ac39128ccbc0 registry.aliyuncs.com/acs-sample/wordpress: 4.6 "/entrypoint.sh ap..." 3 months ago Up 11 days 0.0.0.0:32779->80/tcp Web_web_4 2 B (virtual 422 MB)

容器空间占用的分析步骤：

1. 通过 docker system df 获取占用过高空间的容器信息。
2. 通过前述 -s 参数确认到底是底层镜像，还是运行过程中产生的数据占用了过高空间。
3. exec 进入容器，结合 du 等 shell 指令做进一步空间分析，定位出占用最高空间的目录或文件。
4. 结合业务情况做进一步处理。