运行命令“yes”是否安全|在构建另一个映像时，在Linux Docker主机上执行“Docker映像修剪”？

unguejic 于 2023-02-11 发布在 Docker

关注(0)|答案(3)|浏览(140)

bounty将在3天后过期。回答此问题可获得+150的声誉奖励。Leonid正在寻找来自声誉良好来源的答案：我喜欢一个“参考”的答案，又名链接到适当的信息来源。谢谢。

在工作中，有一个Docker主机，它有一个非常小的/var/lib/docker，当一些docker build命令连续失败时，它会很快填满，特别是因为并非所有的docker build命令都使用以下标志：--no-cache --force-rm --rm=true，其要点（在我的理解中）是尝试在成功或不成功的构建后删除额外的垃圾，如果你访问url https://docs.docker.com/engine/reference/commandline/build/并向下滚动，你可以找到这些标志。
我们遇到的一个问题是，并不是每个人都使用--no-cache --force-rm --rm=true标志来执行docker build，而且很难追踪到它（很傻，我知道）但也可能有一些其他原因填充/var/lib/docker，我们还没有抓住。它不会给予我们的权限，以查看该目录内更好地理解，但是我们能够运行docker image prune或docker system prune，这似乎是解决我们问题的一个很好的解决方案，除了我们现在手动运行它，每当事情变坏时。
我们正在考虑通过以下方法提前解决这个问题：a）几乎每次构建映像后都运行yes | docker image prune。我之所以写“差不多”，是因为很难跟踪构建映像的每个repo（成功与否），但这是另一个故事。即使这个命令有一些副作用（如打破别人的并发docker build在同一Docker主机上，它只会偶尔运行一次，因此冲突的可能性很低。我们讨论的另一种方法几乎是盲目地将yes | docker image prune添加到每2小时运行一次的cron作业中。如果此命令具有潜在的负面副作用，则损坏的可能性更大。
为什么我甚至认为另一个docker build可能会崩溃？嗯，我不知道这是一个事实，否则我就不会问这个问题了。为了更好地理解所谓的图像，我们有时会在一个坏的docker build后结束，我读了这篇经常被引用的文章：https://projectatomic.io/blog/2015/07/what-are-docker-none-none-images/
我的理解是，一个尚未完成的docker build最终会在磁盘上留下一些映像，它可以在最后根据标志来清理这些映像。然而，如果某个东西（比如并行发出的命令yes | docker image prune）删除了一些中间映像层，那么整个构建也会失败。

**这是真的吗？**如果是真的，那么在构建许多映像时保持/var/lib/docker干净的好方法是什么？

我不是一个经常使用S.O.的人，所以如果这个问题违反了一些规则，请提出改进的方法。

docker

来源：https://stackoverflow.com/questions/75351795/is-it-safe-to-run-the-command-yes-docker-images-prune-on-a-linux-docker-host

3条答案

按热度按时间

6rqinv9w1#

我尝试用下面的脚本重现所描述的行为。这个想法是并行启动几个docker build进程。在此期间也并行运行几个docker system prune进程。
停靠文件：

FROM centos:7
RUN echo "before sleep"
RUN sleep 10
RUN echo "after sleep"
RUN touch /myfile

test.sh:

#!/bin/bash
    
docker build -t test1 --no-cache . &
docker build -t test2 --no-cache . &
docker build -t test3 --no-cache . &
docker build -t test4 --no-cache . &
sleep 5
echo Prune!
docker system prune -f &
docker system prune -f &
sleep 15
docker run --rm test1 ls -la /myfile
docker run --rm test2 ls -la /myfile
docker run --rm test3 ls -la /myfile
docker run --rm test4 ls -la /myfile

运行bash test.sh时，我获得了成功的构建和修剪。第二个修剪过程中出现异常：Error response from daemon: a prune operation is already running，这意味着prune识别此冲突情况。
在Docker版本19.03.12，主机系统centos 7上进行测试

赞(0）回复(0）举报 2023-02-11

7rtdyuoh2#

docker image prune（不带-a选项）将仅删除悬挂图像，而不会删除未使用的图像。
如“What is a dangling image and what is an unused image?“中所述
悬挂图像是指没有标签的图像，也没有指向它们的子图像（例如，使用不同版本FROM busybox:latest的旧图像）。
它们之前可能有一个标记指向它们，但该标记后来发生了更改。
或者它们可能从未有过标记（例如，没有包括标记选项的Docker构建的输出）。
由docker build生成的中间图像不应被视为悬空，因为它们有一个子图像指向它们。
因此（待测试），在构建映像时使用yes | docker image prune应该是安全的。
另外，Buildkit现在是Linux上的默认值（moby v23.0.0），这样做是为了避免对其余API（中间映像和容器）产生副作用：
BuildKit的核心是一个低级构建（LLB）定义格式。LLB是一个中间二进制格式，允许开发人员扩展BuildKit。〉LLB定义了一个内容寻址依赖关系图，可用于将非常复杂的构建定义放在一起。