Dockerfile的构建挂起或花费很长时间？ [英] Build of Dockerfile hangs or taking long?

问题描述

我有这个Dockerfile：

I have this Dockerfile:

FROM fedora:28

# create new user
RUN adduser --home /home/rpi-user rpi-user

# install things needed for yocto
RUN dnf -y install make wget bzip2 python unzip perl patch \
     diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
     ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat \
     findutils which SDL-devel xterm cpio file hostname rpcgen

# run the commands that follow as rpi-user
USER rpi-user

# clone yocto/poky and raspberrypi layer
RUN git clone git://git.yoctoproject.org/poky /home/rpi-user/poky
RUN cd /home/rpi-user/poky; git clone https://github.com/agherzan/meta-raspberrypi.git

# set up oe build environment and add meta-raspberrypi to bblayers.conf
# modify machine name and add options to local.conf
WORKDIR /home/rpi-user/poky
ENV LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8
COPY local.conf.append /tmp/
RUN ls -l
RUN . ./oe-init-build-env rpi-build; \
        cd conf; perl -0777 -pi -e 's/(BBLAYERS \?= "Provided more updates.[^"]*)"/\1\/home\/rpi-user\/poky\/meta-raspberrypi \\\n  "/g' bblayers.conf; \
        sed -i 's/\(MACHINE ??= \).*$/\1"raspberrypi3"/g' local.conf; \
        cat /tmp/local.conf.append >> local.conf; \
        cd ../; bitbake -DDDv rpi-basic-image;
RUN echo "[!] Build complete."

执行 docker build -t bla / rpi。结果导致我的终端挂起（最后6行）：

Doing a docker build -t bla/rpi . results in my terminal hanging with (the last 6 lines):

NOTE: Running noexec task 3294 of 3294 (/home/rpi-user/poky/meta-raspberrypi/recipes-core/images/rpi-basic-image.bb:do_build)
DEBUG: Teardown for bitbake-worker
DEBUG: Teardown for bitbake-worker
NOTE: Tasks Summary: Attempted 3294 tasks of which 5 didn't need to be rerun and all succeeded.

Summary: There were 5 WARNING messages shown.

直接在同一台计算机的终端上运行完全相同的命令，我就能构建一个映像没有挂。仅当使用docker（且仅此特定Dockerfile）时，我的构建才会挂起。我几乎可以肯定这与内存有关。

Running the exact same commands directly on a terminal on the same machine, I am able to build an image without a hang. Only when using docker (and only this specific Dockerfile) does my build hang. I am almost certain it is memory related.

我通常使用脚本删除基本上由 docker rmi< images> 组成的任何docker剩余物。 ， docker rm< containers> 和 docker系统修剪--volumes -f ，此处，如果有兴趣。使用上述脚本无法解决我的问题（删除容器，图像和卷无法解决挂起问题）。然后我删除了 / var / lib / docker 并重置了docker daemon，但还是没有运气。

I usually use a script to remove any docker left overs which basically consists of a docker rmi <images>, docker rm <containers> and docker system prune --volumes -f, here it is if interested. Using said script did not fix my issue (removing of containers, images and volumes did not fix the hang). I then removed /var/lib/docker and reset docker daemon, but still no luck.

有什么建议吗？

正在寻找在 docker stats 的状态下，当docker构建我的Dockerfile时，我看到我的cpu使用率一直超过％100（就像成千上万！）。 dmesg -w 显示如下消息：

Looking at docker stats while docker was building my Dockerfile, I saw that my cpu usage percentage was constantly over %100 (like in the thousands!). A dmesg -w shows messages like this:

[ 4409.558822] mce: CPU1: Core temperature above threshold, cpu clock throttled (total events = 3471)
[ 4409.558823] mce: CPU7: Core temperature above threshold, cpu clock throttled (total events = 3471)
[ 4409.558825] mce: CPU0: Package temperature above threshold, cpu clock throttled (total events = 4603)
[ 4409.558826] mce: CPU6: Package temperature above threshold, cpu clock throttled (total events = 4603)

更有趣的是，当运行docker build时，运行 docker stats 挂起， docker stats 中该docker / image的条目消失，而 dmesg 显示：

What is even more interesting is that with docker stats running, when the docker build hangs, the entry for that docker/image in docker stats goes away, and dmesg shows:

[ 4701.032315] docker0: port 1(veth0ef04d2) entered disabled state
[ 4701.032481] veth2578e04: renamed from eth0
[ 4701.130810] docker0: port 1(veth0ef04d2) entered disabled state
[ 4701.135113] device veth0ef04d2 left promiscuous mode
[ 4701.135137] docker0: port 1(veth0ef04d2) entered disabled state

我认为这是退出docker构建后应该看到的内容？运行 ps aux | grep -i docker ，我仍然看到该进程正在运行：

Which I assume is what I should see upon the exiting of a docker build? Running a ps aux | grep -i docker, I still see the process running:

<user>    6281  0.9  0.1 1961860 27800 pts/1   Sl+  09:17   0:35 docker -D build -t bam/rpi .

所以docker似乎认为构建已完成（ docker stats 删除了相应的条目），但是Linux仍然看到docker build正在运行（ ps aux 仍显示该过程）。什么啊

So it seems docker thinks the build is done (docker stats removes the respective entry) but linux still sees the docker build running (ps aux still shows the process). What the?

除非从位标记中缺少我，否则我无法从bitbake中获得更多的对象。 docker stats 没有显示我所期望的任何内存问题。

I am not able to get more "deets" from bitbake, unless there is a flag I am missing. docker stats did not show any memory issues as I was expecting.

哇，显然是 docker ps -a 也会显示容器已退出（与 docker stats 一致）：

Wow, apparently a docker ps -a shows the container as exited also (in agreement with docker stats):

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                      PORTS               NAMES
3ea12a369089        22be583f7349        "/bin/sh -c '. ./oe-…"   About an hour ago   Exited (0) 13 minutes ago                       nifty_gauss

我以为它不会变得更有趣，但确实如此。在我的 ps aux中| grep -i docker ，我看到一个有趣的过程：

I thought it couldn't get more interesting, but it did. In my ps aux | grep -i docker, I see an interesting process:

root      7775 19.2  1.1 2170612 181216 ?      Sl   10:13   4:04 docker-untar /var/lib/docker/overlay2/f3aade16d0d44ef61037ca5fc7ac0690f66b1894578141add2197fe7f8cdd402/diff

那是什么？它会去皮吗？可能要花一些时间。也许我应该再等一下这个挂起（我会）。此过程的 stat 列不断从 Rl 更改为 Sl 然后返回。

What is that? Is it untaring something? That can take a while. Maybe I should wait some more for this hang (I will). This process' stat column is constantly changing from Rl to Sl and back. Weird.

所以我等了。 docker-unar进程现在消失了，但是构建仍然挂起。现在当我执行 docker ps -a 时，我看到以下内容：

So I waited. The docker-untar process is now gone, but the build is still hanging. Now when I do a docker ps -a, i see this:

3ea12a369089        22be583f7349        "/bin/sh -c '. ./oe-…"   2 hours ago         Removal In Progress                           nifty_gauss

有趣，还会再等。

等待中的回报。泊坞窗映像相当笨拙地成功构建。

The waiting paid off. The docker image has, rather clumsily, successfully built.

为什么使用docker花费这么长时间（比在没有docker的同一台机器上
上运行的时间长大约4倍）来构建基于arm的二进制文件？

推荐答案

我的 docker构建占用大量资源的原因比直接在主机上执行命令要花更多的时间，是因为执行 bitbake 命令的 RUN 之后，我不是清理我的图层！

The reason my docker build was taking much more time than executing the commands on the host directly is because after the RUN that executes the bitbake command, I am not cleaning up my layer!

您可能知道，每个 RUN 命令都是一个图层，每个图层都由<$自动缓存c $ c> docker ，以便在以后没有更改的情况下使用。这意味着docker必须压缩，删除和缓存我的图层，包括所有克隆的内容以及运行 bitbake 的所有输出/工件。因此，与让docker摆脱所有不必要的麻烦相比，我手动将其删除：

As you may know, each RUN command is a layer, and each layer is auto-cached by docker to make use of later if no changes occurred. That means docker has to tar, remove and cache my layer including all the stuff that was cloned and all the outputs/artifacts of running bitbake. So rather than have docker struggle with all this unwanted stuff, I removed it manually:

RUN . ./oe-init-build-env rpi-build && \
        cd conf && perl -0777 -pi -e 's/(BBLAYERS \?= "[^"]*)"/\1\/home\/rpi-user\/poky\/meta-raspberrypi \\\n  "/g' bblayers.conf && \
        sed -i 's/\(MACHINE ??= \).*$/\1"raspberrypi3"/g' local.conf && \
        cat /tmp/local.conf.append >> local.conf && \
        cd ../ && bitbake -DDDDvvv rpi-basic-image && mv tmp/deploy /home/rpi-user/ && rm -rf *

请注意此 RUN中的最后两个bash命令（ mv 和 rm ）。

一个人也可以删除克隆。

One could also remove the clones.

这篇关于Dockerfile的构建挂起或花费很长时间？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！