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

2024-05-12 02:12

本文主要是介绍05-10 周五 FastBuild 容器启动引起超时问题定位与解决,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

05-10 周五 FastBuild 容器启动超时问题
时间版本修改人描述
2024年5月11日16:45:33V0.1宋全恒新建文档
2024年5月11日22:37:21V1.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目录下的所有文件,包括bashdash

10.200.88.53/xyy-zhejianglab.com/123:1

image-20240510200146027
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

image-20240510200515738

思考

/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目录下的所有文件,包括bashdash

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 格式。


  1. 使用 RUN 命令来安装应用程序和包,并创建新的镜像层。
  2. 如果Docker镜像的目的是运行一个应用程序或服务,例如运行 MySQL,那么应该优先使用 Exec 格式的 ENTRYPOINT 命令。CMD 可以为 ENTRYPOINT 提供额外的默认参数,并且这些默认参数可以被 docker run 命令行替换。
  3. 如果你想为容器设置默认的启动命令,可以使用 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"
CMDEntrypoint启动方式
/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_metaexcept 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 表示容器的动态配置,可以根据需要在创建容器时进行调整。
image-20240511171735546

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的问题。文章包含了完整的分析过程,教训是惨痛的,程序还是需要健壮的,多亏了之前的全局捕获异常,可以很好的将这个异常传达给上层。

这篇关于05-10 周五 FastBuild 容器启动引起超时问题定位与解决的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/981315

相关文章

springboot3.4和mybatis plus的版本问题的解决

《springboot3.4和mybatisplus的版本问题的解决》本文主要介绍了springboot3.4和mybatisplus的版本问题的解决,主要由于SpringBoot3.4与MyBat... 报错1:spring-boot-starter/3.4.0/spring-boot-starter-

在 Spring Boot 中使用异步线程时的 HttpServletRequest 复用问题记录

《在SpringBoot中使用异步线程时的HttpServletRequest复用问题记录》文章讨论了在SpringBoot中使用异步线程时,由于HttpServletRequest复用导致... 目录一、问题描述:异步线程操作导致请求复用时 Cookie 解析失败1. 场景背景2. 问题根源二、问题详细分

解读为什么@Autowired在属性上被警告,在setter方法上不被警告问题

《解读为什么@Autowired在属性上被警告,在setter方法上不被警告问题》在Spring开发中,@Autowired注解常用于实现依赖注入,它可以应用于类的属性、构造器或setter方法上,然... 目录1. 为什么 @Autowired 在属性上被警告?1.1 隐式依赖注入1.2 IDE 的警告:

解决java.lang.NullPointerException问题(空指针异常)

《解决java.lang.NullPointerException问题(空指针异常)》本文详细介绍了Java中的NullPointerException异常及其常见原因,包括对象引用为null、数组元... 目录Java.lang.NullPointerException(空指针异常)NullPointer

Android开发中gradle下载缓慢的问题级解决方法

《Android开发中gradle下载缓慢的问题级解决方法》本文介绍了解决Android开发中Gradle下载缓慢问题的几种方法,本文给大家介绍的非常详细,感兴趣的朋友跟随小编一起看看吧... 目录一、网络环境优化二、Gradle版本与配置优化三、其他优化措施针对android开发中Gradle下载缓慢的问

关于Nginx跨域问题及解决方案(CORS)

《关于Nginx跨域问题及解决方案(CORS)》文章主要介绍了跨域资源共享(CORS)机制及其在现代Web开发中的重要性,通过Nginx,可以简单地解决跨域问题,适合新手学习和应用,文章详细讲解了CO... 目录一、概述二、什么是 CORS?三、常见的跨域场景四、Nginx 如何解决 CORS 问题?五、基

python安装whl包并解决依赖关系的实现

《python安装whl包并解决依赖关系的实现》本文主要介绍了python安装whl包并解决依赖关系的实现,文中通过图文示例介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面... 目录一、什么是whl文件?二、我们为什么需要使用whl文件来安装python库?三、我们应该去哪儿下

MySQL安装时initializing database失败的问题解决

《MySQL安装时initializingdatabase失败的问题解决》本文主要介绍了MySQL安装时initializingdatabase失败的问题解决,文中通过图文介绍的非常详细,对大家的学... 目录问题页面:解决方法:问题页面:解决方法:1.勾选红框中的选项:2.将下图红框中全部改为英

Java中实现订单超时自动取消功能(最新推荐)

《Java中实现订单超时自动取消功能(最新推荐)》本文介绍了Java中实现订单超时自动取消功能的几种方法,包括定时任务、JDK延迟队列、Redis过期监听、Redisson分布式延迟队列、Rocket... 目录1、定时任务2、JDK延迟队列 DelayQueue(1)定义实现Delayed接口的实体类 (

Nginx启动失败:端口80被占用问题的解决方案

《Nginx启动失败:端口80被占用问题的解决方案》在Linux服务器上部署Nginx时,可能会遇到Nginx启动失败的情况,尤其是错误提示bind()to0.0.0.0:80failed,这种问题通... 目录引言问题描述问题分析解决方案1. 检查占用端口 80 的进程使用 netstat 命令使用 ss