05-10 周五 FastBuild 容器启动引起超时问题定位与解决

思影影思

已于 2024-05-11 22:55:51 修改

阅读量890

点赞数 9

文章标签：重构

于 2024-05-11 22:41:48 首次发布

本文链接：https://blog.csdn.net/lk142500/article/details/138732524

版权

05-10 周五 FastBuild 容器启动超时问题

时间	版本	修改人	描述
2024年5月11日16:45:33	V0.1	宋全恒	新建文档
2024年5月11日22:37:21	V1.0	宋全恒	完成解决方案的撰写，包括问题分析，docker命令

简介

关于FastBuild的优化，已经撰写了多个博客，具体如下所示：

博客	描述
04-22 周日阿里云-瑶光上部署FastBuild过程(配置TLS、自定义辅助命令)-CSDN博客	记录了部署FastBuild的完整过程，基本流程
04-25 周四 FastBuild重构实践-TLS、全局捕获异常、一键配置-CSDN博客	记录了第一次优化的过程，完成配置文件移入数据库
05-08 周三 FastBuild FastAPI 引入并发支持和全局捕获异常-CSDN博客	记录了并发支持和全局捕获异常。解决拉取和check解耦问题以及超时问题。

问题

问题1 容器启动时/bin/bash不存在

可以使用

docker run -it --rm [image_name] ls /bin

这将列出容器中/bin目录下的所有文件，包括bash或dash。

10.200.88.53/xyy-zhejianglab.com/123:1

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker inspect d94e2b46e87b
[
    {
        "Id": "sha256:d94e2b46e87b3df99b8371a632b467fe5cc39dae04f882991af1ed1b8353c336",
        "RepoTags": [
            "10.200.88.53/xyy-zhejianglab.com/123:1"
        ],
        "RepoDigests": [
            "10.200.88.53/xyy-zhejianglab.com/123@sha256:2625be6a2bc2aedfe4d91961b2037e557b0d1739a9c87677c184421c7d215d77"
        ],
        "Parent": "",
        "Comment": "",
        "Created": "2021-06-08T12:33:13.003229175Z",
        "Container": "3b0058616208c2df9bf5122ca6d3d2c3eef81ab200b17693a2578dbec7db56d3",
        "ContainerConfig": {
            "Hostname": "3b0058616208",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/sh",
                "-c",
                "#(nop) ",
                "CMD [\"/bin/sh\" \"-c\" \"/bin/cp -rf /jacocoagent.jar /tmp/\"]"
            ],
            "Image": "sha256:c83155cc95491342b169187489dfe5b9b32157adce169144b51a65f4e9a552bd",
            "Volumes": null,
            "WorkingDir": "/",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {}
        },
        "DockerVersion": "19.03.1",
        "Author": "cuisj@isyscore.com",
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/sh",
                "-c",
                "/bin/cp -rf /jacocoagent.jar /tmp/"
            ],
            "Image": "sha256:c83155cc95491342b169187489dfe5b9b32157adce169144b51a65f4e9a552bd",
            "Volumes": null,
            "WorkingDir": "/",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": null
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 5866405,
        "VirtualSize": 5866405,
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/e6ec3bebc8c50e24ef8786628813c76df51885d0009b8ee48cf51f21effbcad1/diff",
                "MergedDir": "/var/lib/docker/overlay2/b4f143ad6a63d5641c51350dc152d27e7831bcff5e127055dfd6a73c63b71d7e/merged",
                "UpperDir": "/var/lib/docker/overlay2/b4f143ad6a63d5641c51350dc152d27e7831bcff5e127055dfd6a73c63b71d7e/diff",
                "WorkDir": "/var/lib/docker/overlay2/b4f143ad6a63d5641c51350dc152d27e7831bcff5e127055dfd6a73c63b71d7e/work"
            },
            "Name": "overlay2"
        },
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:50644c29ef5a27c9a40c393a73ece2479de78325cae7d762ef3cdc19bf42dd0a",
                "sha256:7aec0e78f86e45c647f9166c795e14a4025e698d082f506fc84027cea786c1f0"
            ]
        },
        "Metadata": {
            "LastTagTime": "0001-01-01T00:00:00Z"
        }
    }
]

问题2 Container is not running

思考

/bin/bash不存在

这个问题是不存在的，因为容器的启动使用了镜像默认的entrypoint和cmd。但是如果代码写死了直接使用/bin/bash来启动容器，则是有问题的，应该先判断/bin/bash的存在。这是问题解决初期的思路。

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker run -it --rm d94e2b46e87b /bin/bash
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown.

可以使用

docker run -it --rm [image_name] ls /bin

这将列出容器中/bin目录下的所有文件，包括bash或dash。

10.200.88.53/xyy-zhejianglab.com/123:1

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker run -it d94e2b46e87b ls /bin
arch           echo           kill           netstat        sh
ash            ed             link           nice           sleep
base64         egrep          linux32        pidof          stat
bbconfig       false          linux64        ping           stty
busybox        fatattr        ln             ping6          su
cat            fdflush        login          pipe_progress  sync
chgrp          fgrep          ls             printenv       tar
chmod          fsync          lzop           ps             touch
chown          getopt         makemime       pwd            true
conspy         grep           mkdir          reformime      umount
cp             gunzip         mknod          rev            uname
date           gzip           mktemp         rm             usleep
dd             hostname       more           rmdir          watch
df             ionice         mount          run-parts      zcat
dmesg          iostat         mountpoint     sed
dnsdomainname  ipcalc         mpstat         setpriv
dumpkmap       kbd_mode       mv             setserial

启动方式

注：在容器启动时通过entrypoint和cmd配合，可以探测/bin/bash的存在。下面描述了cmd和entrypoint的作用

cmd和entrypoint作用

CMD：设置容器启动后默认执行的命令及其参数。不过，CMD 指定的命令可以通过 docker run 命令行参数来覆盖。它主要用于为容器设定默认启动行为。如果 Dockerfile 中有多个 CMD 指令，只有最后一个生效。
ENTRYPOINT：配置容器启动时运行的命令，功能上与 CMD 类似，但有一个关键区别——即使在 docker run 时指定了其他命令，ENTRYPOINT 也不会被忽略，而是会与这些命令结合使用（除非使用 --entrypoint 覆盖）。当容器作为应用程序或服务运行时，推荐使用 ENTRYPOINT，并且最好采用 Exec 格式。

使用 RUN 命令来安装应用程序和包，并创建新的镜像层。
如果Docker镜像的目的是运行一个应用程序或服务，例如运行 MySQL，那么应该优先使用 Exec 格式的 ENTRYPOINT 命令。CMD 可以为 ENTRYPOINT 提供额外的默认参数，并且这些默认参数可以被 docker run 命令行替换。
如果你想为容器设置默认的启动命令，可以使用 CMD 命令。用户可以在 docker run 命令行中覆盖这个默认命令。

docker:RUN CMD ENTRYPOINT区别_docker run entrypoint-CSDN博客这个文章描述的比较清楚，CMD和EntryPOINT指令

docker中的run/cmd/entrypoint的区别详解_docker_脚本之家比较清楚的演示了作用

CMD 可以被覆盖。

CMD 可以为ENtrypoint 提供参数

注，镜像设置了entrypoint之后，docker run之后的命令相当于提供给entrypoint的参数，这个在docker中的run/cmd/entrypoint的区别详解_docker_脚本之家有清晰的演示。

entrypoint中的参数始终会被使用，而cmd的额外参数可以在容器启动时动态替换掉。

探测/bin/bash存在，启动镜像容器结论

如果镜像中已经配置了entrypoint，可以通过如下的方式

docker run --entrypoint /bin/ls f45dbefbae90  "/bin"

CMD	Entrypoint	启动方式
无	无	/bin/bash存在，用CMD指定/bin/bash即可 2.使用/bin/sh, 启动 3. 报错
无	有	判断存在用entrypoint指定/bin/ls,cmd指定"/bin"判断bash是否存在。 docker run -it --entrypoint /bin/ls d94e2b46e87b “/bin”
有	无
有	有

CMD 是容器启动时如果没有指定命令时的默认行为，它的灵活性较高，易于被 docker run 后的命令覆盖。
ENTRYPOINT 更像是容器的核心功能定义，常用于定义容器的主应用程序，并且能接收 docker run 的参数，这样可以确保容器启动时总是执行预期的程序，并且可以处理任何额外的参数。

总结:

无论什么镜像，我们直接使用entrypoint 和CMD来获取/bin/bash是否存在，如果不存在，要用sh.

即无论镜像的元数据，即entrypoint和cmd配置与否，我们可以通过指定entrypoint和cmd来按照我们预期的方式来探测镜像中/bin/bash的存在，进而确定启动容器的方式是使用/bin/sh还是/bin/bash

oot@iZ1pp06qu51oiqqddsrnuvZ:~# docker images |  grep f45
10.200.88.53/songquanheng-zhejianglab.com/python                   <none>                                                       6de34f45a879   4 days ago          7.57GB
10.200.88.53/framework/jax                                         0.4.8-python3.8.10-ubuntu18.04-cuda11.7-cudnn8-ssh-jupyter   f45dbefbae90   12 months ago       8.3GB

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker run --entrypoint /bin/ls f45dbefbae90  "/bin"
bash
bunzip2
bzcat
bzcmp
bzdiff
bzegrep
bzexe
zmore
znew

其实简单一点，如果镜像配置了Entrypoint，则CMD即作为entrypoing的参数，而entrypoint是可执行程序的路径。CMD作为参数，如果没有设置entrypoint,则cmd自身即为可执行的命令，而且在docker run时可以灵活的指定。

注，经过思考，发现问题的关键并不在于这个方向，即启动容器的方式，关键在于镜像之前的配置，导致容器的启动无法长时间运行。

结论

经过仔细的思考发现，由于FastBuild要判断镜像默认启动中，是否包含了sshd服务和jupyterlab服务，倘若我们通过覆盖entrypoint和cmd的方式，来修改了容器启动的方式，则服务判断是无法进行的。

根据上面的结论，可以得到如下的结果，即，无法覆盖entrypoint和cmd。

问题进而转化为，如何解决超时问题，超时问题是因为系统内部启动容器，结果镜像启动容器的命令是类似cp文件的命令，容器执行完了命令，自动停止了，不在处于运行状态，导致系统无法和容器交互获取其中容器的python，pip等环境，因此，是镜像自身的问题，因此，我们可以通过捕获异常的方式来提示用户，该镜像问题。

解决方式

问题代码修改

    def collect_image_info(self, image_name):
        image_meta = self.get_image_meta(image_name)
        container = self.get_image_container(image_name)

        print(f"启动容器, 镜像名称: {image_name}, 容器id: {container.short_id}")
        extractor = ArtifactExtractor(image_name, container, image_meta)
        descriptor = extractor.get_image_descriptor()
        print("镜像类型: " + image_meta["Architecture"])
        print("镜像大小: " + str(round(float(image_meta["Size"]) / 1000000000, 2)) + "G")
        return descriptor, image_meta

代码修改为

    def collect_image_info(self, image_name):
        try:
            image_meta = self.get_image_meta(image_name)
            command, entrypoint = self.get_cmd_entrypoint(image_meta)
            container = self.get_image_container(image_name)
            print(f"{image_name}镜像的command:{command}, entrypoint:{entrypoint}")
            print(f"启动容器, 镜像名称: {image_name}, 容器id: {container.short_id}")
            extractor = ArtifactExtractor(image_name, container, image_meta)
            descriptor = extractor.get_image_descriptor()
            print("镜像类型: " + image_meta["Architecture"])
            print("镜像大小: " + str(round(float(image_meta["Size"]) / 1000000000, 2)) + "G")
            return descriptor, image_meta
        except APIError as err:
            print(f"在镜像环境收集时失败，镜像自有的启动命令command:{command}, entrypoint: {entrypoint}")
            raise FBException(15005, f"镜像启动命令command:{command}, entrypoint: {entrypoint}需要保证容器在环境探测过程中保持运行状态"
                                     f"请检查镜像启动命令是否正确，错误信息:{err}")

可以看出，主要是将上述问题代码添加try，捕获异常APIError，这样系统出现了这个异常之后，通过捕获重新抛出了FBException，而这被全局捕获异常处理的方式告诉给前端，即解决了超时问题。

解决问题中Config和ContainerConfig

下述内容记录了通过镜像元数据读取entrypoint和cmd的过程，这样方便在提示中正确的提示用户，是镜像出问题了。顺道解决超时问题

在Docker镜像的元数据中，Config 和 ContainerConfig 表示镜像的配置和容器的配置。它们的区别在于：

Config：

Config 指的是镜像的配置。这个配置是在构建镜像时定义的，并保存在镜像的元数据中。它包含了构建镜像时使用的各种指令，比如 CMD、ENTRYPOINT、ENV 等。这些配置会影响到使用该镜像创建的所有容器。
ContainerConfig：

ContainerConfig 指的是容器的配置。这个配置是在创建容器时指定的，并保存在容器的元数据中。它包含了在创建容器时传递给 Docker 引擎的各种参数，比如 CMD、ENTRYPOINT、ENV 等。与镜像的配置不同，容器的配置可以覆盖镜像的配置，允许用户在创建容器时对容器的行为进行定制。
因此，Config 表示镜像的静态配置，而 ContainerConfig 表示容器的动态配置，可以根据需要在创建容器时进行调整。

docker命令

下述命令是定位解决两个问题的方式

打印系统中的所有镜像:tag

docker 获取镜像名称和tag

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker images --format "{{.Repository}}:{{.Tag}}" | grep -v none
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715413002:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715412764:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715411659:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715411501:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715410460:1
10.200.88.53/liuyangyang-zhejianglab.com/ui_test_image1715409964:1

不能覆盖镜像的启动的信息，因为要根据启动的信息判断服务的存在。

docker run --entrypoint /bin/ls -it  /bin

打印系统所有镜像的entrypoint和cmd

root@iZ1pp06qu51oiqqddsrnuvZ:~# docker images --format "{{.Repository}}:{{.Tag}}" | grep -v none | xargs -I {} docker inspect --format='{{range .Config.Cmd}}{{.}} {{end}}|{{range .Config.Entrypoint}}{{.}} {{end}}' {}
|/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
|/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
|/bin/sh -c /usr/bin/supervisord -c /etc/supervisor/supervisord.conf 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
|/bin/sh -c /workspace/env_entrypoint.sh 
|/bin/sh -c /usr/bin/supervisord -c /etc/supervisor/supervisord.conf 
/bin/bash |
|/bin/bash -c bash run.sh 
|/bin/bash -c bash run.sh 
|/bin/bash -c bash run.sh 
|/bin/bash -c bash run.sh 
bash |
bash |
/bin/bash |
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
/bin/bash |/bin/sh -c /opt/conda/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |
/bin/bash |
/bin/bash |
/bin/bash |
|/bin/bash -c MASTER_HOST=`cat /etc/volcano/master.host | tr "\n" ","`;
WORKER_HOST=`cat /etc/volcano/worker.host | tr "\n" ","`;
mkdir -p /var/run/sshd; /usr/sbin/sshd;
mkdir -p /etc/mpi/;
cp /etc/volcano/master.host /etc/mpi/hostfile;
echo >> /etc/mpi/hostfile;
cat /etc/volcano/worker.host >> /etc/mpi/hostfile;
echo >> /etc/mpi/hostfile;
echo -e 'jupyter lab --ip=* --port=8888 --no-browser --notebook-dir=/home --allow-root' > /tmp/run.sh;bash /tmp/run.sh
 
|/bin/sh -c /usr/bin/supervisord -c /etc/supervisor/supervisord.conf 
|/bin/bash -c bash start.sh 
|/bin/sh -c /workspace/env_entrypoint.sh 
|/bin/bash -c MASTER_HOST=`cat /etc/volcano/master.host | tr "\n" ","`;
WORKER_HOST=`cat /etc/volcano/worker.host | tr "\n" ","`;
mkdir -p /var/run/sshd; /usr/sbin/sshd;
mkdir -p /etc/mpi/;
cp /etc/volcano/master.host /etc/mpi/hostfile;
echo >> /etc/mpi/hostfile;
cat /etc/volcano/worker.host >> /etc/mpi/hostfile;
echo >> /etc/mpi/hostfile;
echo -e 'jupyter lab --ip=* --port=8888 --no-browser --notebook-dir=/home --allow-root' > /tmp/run.sh;bash /tmp/run.sh
 
/bin/bash |/bin/bash -c /etc/init.d/ssh start && sleep infinity 
|/bin/bash /alphadrug/run.sh 
|/bin/bash /alphadrug/run.sh 
|/bin/bash -c /etc/init.d/ssh start && sleep 365d 
/bin/bash |
/bin/bash |
/bin/bash |
bash |/bin/bash -c bash start.sh 
bash |/bin/bash -c bash start.sh 
|/bin/sh -c /usr/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
|/bin/sh -c /usr/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
|/bin/bash -c /etc/init.d/ssh start && sleep infinity 
/bin/bash |
/bin/bash |/bin/bash -c /usr/local/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |/bin/bash -c /usr/local/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |/bin/bash -c /usr/local/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |/bin/sh -c /opt/conda/bin/supervisord -c /etc/supervisord.d/supervisord.conf 
/bin/bash |
/bin/sh -c /bin/cp -rf /jacocoagent.jar /tmp/ |

总结

通过这个问题解决的过程，解决了在交互过程中而导致内部服务器错误，前端无法接收到后端响应，而出现的Bad Request的问题。文章包含了完整的分析过程，教训是惨痛的，程序还是需要健壮的，多亏了之前的全局捕获异常，可以很好的将这个异常传达给上层。

思影影思

关注

9
点赞
踩
30

收藏

觉得还不错? 一键收藏
1
评论
05-10 周五 FastBuild 容器启动引起超时问题定位与解决

博客描述04-22 周日阿里云-瑶光上部署FastBuild过程(配置TLS、自定义辅助命令)-CSDN博客记录了部署FastBuild的完整过程，基本流程04-25 周四 FastBuild重构实践-TLS、全局捕获异常、一键配置-CSDN博客记录了第一次优化的过程，完成配置文件移入数据库05-08 周三 FastBuild FastAPI 引入并发支持和全局捕获异常-CSDN博客记录了并发支持和全局捕获异常。解决拉取和check解耦问题以及超时问题。
复制链接

扫一扫