首先，运行docker images查看图像列表，并将IMAGE HASH ID复制到剪贴板中。

运行docker rmi -f <镜像>

记住选项-f是强制删除。

根据文档，下面的命令将删除超过48小时的图像。

$ docker image prune --all --filter until=48h

Occasionally I have run into issues where Docker will allocate and continue to use disk space, even when the space is not allocated to any particular image or existing container. The latest way I generated this issue accidentally was using "docker-engine" centos build instead of "docker" in RHEL 7.1. What seems to happen is sometimes the container clean-ups are not completed successfully and then the space is never reused. When the 80GB drive I allocated as / was filled with /var/lib/docker files I had to come up with a creative way to resolve the issue.

这是我想到的。首先解决磁盘满的错误:

Stop docker: systemctl Stop docker 分配一个新的驱动器挂载为say /mnt/docker。 移动/var/lib/docker目录下的所有文件到/mnt/docker目录下。我使用命令: rsync -aPHSx——remove-source-files /var/lib/docker/ /mnt/docker/ 将新驱动器挂载到/var/lib/docker。

此时，我不再有磁盘满的错误，但我仍然浪费了大量的空间。接下来的步骤就是解决这个问题。

Start Docker: systemctl Start Docker 保存所有图片: 码头工人节省$(码头工人图片| sed - e ' / ^ <无> / d ' - e / ^库/ d - e的年代 ,[ ][ ]*,:,' - e ' s ,[ ].*,,') > / 根/ docker.img 卸载码头工人。 删除/var/lib/docker中的所有内容: Rm -rf /var/lib/docker/[cdintv]* 重新安装码头工人 启用docker: systemctl Enable docker 启动docker: systemctl Start docker 恢复图片: Docker load < /root/docker.img 启动任何需要运行的持久容器。

这使我的磁盘使用量从docker的67 GB下降到6 GB。

我不建议日常使用。但是，当docker由于软件错误或意外重启而失去使用磁盘空间的跟踪时，运行它是有用的。

@VonC已经给出了一个非常好的答案，但为了完整起见，这里有一个我一直在使用的小脚本——如果你有一些差事，它也会破坏任何Docker进程:

#!/bin/bash

imgs=$(docker images | awk '/<none>/ { print $3 }')
if [ "${imgs}" != "" ]; then
   echo docker rmi ${imgs}
   docker rmi ${imgs}
else
   echo "No images to remove"
fi

procs=$(docker ps -a -q --no-trunc)
if [ "${procs}" != "" ]; then
   echo docker rm ${procs}
   docker rm ${procs}
else
   echo "No processes to purge"
fi

请参阅docker系统修剪的官方参考

Docker系统修剪将删除:

所有停止的集装箱 所有网络不被至少一个容器使用 所有悬挂的图像 所有构建缓存

Docker系统prune -a也会做同样的事情，但是除了删除所有悬浮图像之外，它还会更广泛地删除:

没有至少一个与之关联的容器的所有映像

什么是悬空图像?

Docker映像由多个层组成，当从Dockerfile生成整个容器映像时，这些层被包装在父“容器层”中。悬浮图像是与任何其他标记图像没有关系的层，因此在任何构建的新容器中都不会有任何用途。它们不再起作用，而是消耗磁盘空间。

例如，悬浮图像可以通过以下过程创建:

从Dockerfile中构建一个命名image my-image，不指定任何标签:

FROM ubuntu:latest
CMD ["echo", "Hello World"]

docker build -t my-image

docker images

REPOSITORY   TAG       IMAGE ID
my-image     latest    7ed6e7202eca   <--- created, not dangling
ubuntu       latest    825d55fb6340

更新Dockerfile:

FROM ubuntu:latest
CMD ["echo", "Hello, World!"]

使用以前的名称重新构建映像，不指定任何标记:

docker build -t my-image

docker images

REPOSITORY   TAG       IMAGE ID
my-image     latest    da6e74196f66   <--- replacement layer
<none>       <none>    7ed6e7202eca   <--- previous layer, now dangling
ubuntu       latest    825d55fb6340

构建创建了一个新的my-image层。正如我们所看到的，最初创建的层仍然在那里，但它的名称和标签被设置为<none>:<none>。这个层永远不可能与任何docker容器层相关联，这意味着它是“悬空的”。

没有至少一个关联容器的图像是什么?

未使用的映像意味着它没有被分配或在容器中使用。例如，docker ps -a将列出所有运行和停止的容器。这些容器使用的任何映像都是“已用映像”。

当运行docker系统prune -a时，它将删除未使用和悬挂的图像。与至少一个容器相关联的任何映像都不会受到影响。

如果你自己构建这些修剪过的映像(从其他一些较旧的基础映像)，请谨慎使用上述基于docker image prune的可接受解决方案，因为该命令是生硬的，并将尝试删除最新映像所需的所有依赖关系(该命令可能应该重命名为docker image*s* prune)。

我为我的docker映像构建管道(其中有每日构建和标签=日期YYYYMMDD格式)提出的解决方案是:

# carefully narrow down the image to be deleted (to avoid removing useful static stuff like base images)
my_deleted_image=mirekphd/ml-cpu-py37-vsc-cust

# define the monitored image (tested for obsolescence), which will be usually the same as deleted one, unless deleting some very infrequently built image which requires a separate "clock"
monitored_image=mirekphd/ml-cache

# calculate the oldest acceptable tag (date)
date_week_ago=$(date -d "last week" '+%Y%m%d')

# get the IDs of obsolete tags of our deleted image
# note we use monitored_image to test for obsolescence
my_deleted_image_obsolete_tag_ids=$(docker images --filter="before=$monitored_image:$date_week_ago" | grep $my_deleted_image | awk '{print $3}')

# remove the obsolete tags of the deleted image
# (note it typically has to be forced using -f switch)
docker rmi -f $my_deleted_image_obsolete_tag_ids