Linux Docker主机构建镜像时执行yes | docker image prune是否安全？

你的担忧是否成立？ #

完全成立。docker image prune默认会清理悬空镜像——包括docker build过程中生成的、还没被最终成品镜像关联的中间层镜像。如果并行构建时，某个构建任务的中间层还处于未被引用的状态，刚好遇上prune命令执行，这些中间层就会被删除，直接导致对应的构建失败。

频繁构建场景下的安全清理方案 #

结合你无法查看/var/lib/docker目录、难以统一管控构建参数的环境限制，推荐以下几种安全可行的方案：

1. 给清理命令加时间过滤，避开活跃构建 #

使用docker image prune的过滤参数，只清理创建时间超过指定时长的悬空镜像，这样能避开正在进行的构建（一般构建不会持续数小时）。例如清理创建超过4小时的悬空镜像：

yes | docker image prune -a --filter "until=4h"

如果用docker system prune清理全量冗余资源，同样可以加过滤条件：

yes | docker system prune -a --filter "until=4h"

这种方式能大幅降低和并行构建的冲突概率，适合加到cron定时任务中，比如每2小时执行一次也不会有太大风险。

2. 配置Docker后台自动清理（Docker 17.06+支持） #

通过修改Docker守护进程配置，让Docker自动在后台清理老旧的悬空资源，无需手动执行prune命令。新建或修改/etc/docker/daemon.json文件，添加以下配置：

{
  "cleanup-images": {
    "enabled": true,
    "prune-filters": ["until=24h"]
  }
}

修改后重启Docker服务生效：

systemctl restart docker

该配置会让Docker自动清理24小时前的悬空镜像，全程自动化，且不会干扰正在进行的构建任务。

3. 从源头减少垃圾生成（退而求其次的规范方案） #

虽然你提到难以追踪所有构建仓库，但可以通过以下方式尽量降低冗余资源的产生：

• 给团队提供统一的构建脚本模板，把--rm=true --force-rm参数固定在脚本里，要求所有人通过脚本执行构建；
• 如果是CI/CD环境，直接在流水线配置中强制添加这些清理参数，从构建源头减少中间层残留。

4. 空间阈值触发清理（临时缓解方案） #

如果担心定时任务仍有冲突风险，可以写一个简单的监控脚本，当/var/lib/docker所在分区的磁盘使用率超过阈值（比如80%）时，再自动执行带过滤条件的清理命令。示例脚本如下：

#!/bin/bash
# 获取/var/lib/docker所在分区的使用率（去掉%符号）
DISK_USAGE=$(df -h /var/lib/docker | awk 'NR==2 {print $5}' | sed 's/%//')
# 使用率超过80%时执行清理
if [ "$DISK_USAGE" -ge 80 ]; then
  yes | docker image prune -a --filter "until=4h"
fi

将这个脚本加到cron中，比如每10分钟检查一次，既能避免频繁执行清理，又能在空间快满时及时处理。

内容的提问来源于stack exchange，提问作者Leonid