一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

容器运行方法、装置、设备及存储介质与流程

2021-11-25 00:56:00 来源:中国专利 TAG:


1.本技术实施例涉及计算机技术领域,特别涉及一种容器运行方法、装置、设备及存储介质。


背景技术:

2.目前,开发人员可通过开源应用容器引擎(docker)打包应用以及依赖包至可移植容器中,使其运行在任何环境。嵌套容器(dockerindocker)是指在开发过程中,开发人员需在某一容器内进行镜像构建或运行其他容器的技术。
3.在容器运行时,需基于镜像文件运行。而在嵌套容器运行场景中,容器共享主机上的docker的守护进程(docker daemon),由于容器的隔离性,其仅能获取docker daemon所在主机的镜像文件。
4.然而,在嵌套容器运行过程存在需要获取被嵌套容器中部分镜像文件的情况,而由于权限问题被嵌套容器中镜像文件无法成功获取,进而导致嵌套容器运行的失败。


技术实现要素:

5.本技术实施例提供了一种容器运行方法、装置、设备及存储介质。所述技术方案如下:
6.一方面,本技术实施例提供了一种容器运行方法,所述方法包括:
7.启动文件缓存容器,所述文件缓存容器由第一容器启动;
8.响应于所述第一容器的嵌套容器构建指令,将目标镜像文件存储至所述文件缓存容器,所述嵌套容器构建指令用于指示在所述第一容器中构建第二容器,所述目标镜像文件用于支持所述第二容器的运行;
9.响应于所述第二容器的运行指令,在所述文件缓存容器中获取所述目标镜像文件,并基于所述目标镜像文件运行所述第二容器。
10.另一方面,本技术实施例提供了一种容器运行装置,所述装置包括:
11.启动模块,用于启动文件缓存容器,所述文件缓存容器由第一容器启动;
12.存储模块,用于响应于所述第一容器的嵌套容器构建指令,将目标镜像文件存储至所述文件缓存容器,所述嵌套容器构建指令用于指示在所述第一容器中构建第二容器,所述目标镜像文件用于支持所述第二容器的运行;
13.运行模块,用于响应于所述第二容器的运行指令,在所述文件缓存容器中获取所述目标镜像文件,并基于所述目标镜像文件运行所述第二容器。
14.另一方面,本技术实施例提供了一种计算机设备,所述计算机设备包括处理器和存储器;所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上述方面所述的容器运行方法。
15.另一方面,本技术实施例提供了一种计算机可读存储介质,所述计算机可读存储
介质中存储有至少一条计算机程序,所述计算机程序由处理器加载并执行以实现如上述方面所述的容器运行方法。
16.根据本技术的一个方面,提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备实现上述方面的各种可选实现方式中提供的容器运行方法。
17.本技术实施例中,通过启动文件缓存容器,当在第一容器内构建第二容器时即在嵌套容器的场景下,则将运行第二容器所需的位于第一容器之内的目标镜像文件存储至文件缓存容器,当第二容器运行时,可直接在文件缓存容器中获取目标镜像文件,进而基于目标镜像文件运行第二容器,避免因无法在第一容器中获取目标镜像文件而导致第二容器运行的失败,提高容器运行成功率。
附图说明
18.为了更清楚地说明本技术实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本技术的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
19.图1是本技术一个示例性实施例提供的容器部署架构的架构示意图;
20.图2是本技术一个示例性实施例提供的容器运行方法的流程图;
21.图3是本技术另一个示例性实施例提供的容器运行方法的流程图;
22.图4是本技术一个示例性实施例提供的获取目标镜像文件的结构示意图;
23.图5是本技术另一个示例性实施例提供的容器运行方法的流程图;
24.图6是本技术一个示例性实施例提供的启动文件缓存容器的流程图;
25.图7是本技术一个示例性实施例提供的容器运行装置的结构框图;
26.图8是本技术一个示例性实施例提供的计算机设备的结构框图。
具体实施方式
27.为使本技术的目的、技术方案和优点更加清楚,下面将结合附图对本技术实施方式作进一步地详细描述。
28.在本文中提及的“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
29.如图1所示,docker采用客户端与服务端分离的方式进行部署。其中,docker客户端101(dockerclient)是docker的命令行工具,其与docker守护进程102(dockerdaemon)进行通信,向指定的docker守护进程发送容器构建、运行等请求。docker守护进程102用于接收并处理docker客户端101的请求,进行容器管理的进程。当构建镜像时,docker客户端101向docker守护进程102发送构建镜像命令(dockerbuild),docker守护进程102进行镜像的构建;当拉取镜像时,docker客户端101向docker守护进程102发送拉取镜像命令(dockerpull),docker守护进程102在仓库103中拉取镜像;当运行容器时,docker客户端
101向docker守护进程102发送运行容器命令(dockerrun),docker守护进程102基于镜像运行容器(containers)。
30.相关技术中,可能需在docker容器(container)内进行docker的构建与运行,即存在嵌套容器。而嵌套容器与被嵌套的容器共享主机(dockerhost)的dockerdaemon,而主机中dockerdaemon仅可访问主机中的文件系统,而被嵌套容器对其他容器不可见。以图1为例,主机中的dockerdaemon仅可访问主机中的镜像文件105,而无法访问docker容器104中的镜像文件。当在docker容器104中构建容器时,将产生嵌套容器,在运行docker容器104中容器时,可能需获取docker容器104中的镜像文件,而由于权限问题,主机中dockerdaemon无法成功获取docker容器104的镜像文件,造成容器运行失败。
31.图2示出了本技术一个示例性实施例提供的容器运行方法的流程图。本实施例以该方法用于安装有docker的计算机设备为例进行说明,该方法包括如下步骤:
32.步骤201,启动文件缓存容器,文件缓存容器由第一容器启动。
33.本技术实施例中,第一容器是指被嵌套的容器,即在第一容器中进行容器的构建与运行。
34.在一种可能的实施方式中,通过第一容器内的dockerclient向主机的dockerdaemon发送容器启动命令,dockerdaemon将根据容器启动命令启动文件缓存容器,其中,文件缓存容器用于存储第一容器新建的镜像文件。
35.相关技术中,第一容器对其他容器不可见,造成无法获取第一容器中的镜像文件,而由于文件缓存容器是由第一容器启动,因此,在启动过程中可设置文件缓存可被其他容器访问,进而获取其中存储的镜像文件。
36.步骤202,响应于第一容器的嵌套容器构建指令,将目标镜像文件存储至文件缓存容器,嵌套容器构建指令用于指示在第一容器中构建第二容器,目标镜像文件用于支持第二容器的运行。
37.可选的,嵌套容器构建指令用于指示在第一容器中构建第二容器,即本技术实施例中,第二容器指嵌套的容器,其位于第一容器之内。且对第一容器以及第二容器的管理操作均通过主机中的docker daemon执行。
38.由于在第二容器的运行过程中,可能需要获取第一容器内的镜像文件,而docker daemon其仅能访问主机的文件系统,即仅可获取主机中的镜像文件,无法获取第一容器内的镜像文件,因此,为使第二容器在运行过程中,可获取到第一容器内的目标镜像文件,本技术实施例中,将第二容器运行所需的目标镜像文件存储在文件缓存容器中,从而便于第二容器获取目标镜像文件,其中,目标镜像文件是第一容器内的镜像文件。
39.可选的,文件缓存容器与第一容器相对应,即文件缓存容器仅用于存储唯一第一容器中的镜像文件。示意性的,当在第一容器a1中构建第二容器时,则将第一容器a1中的目标镜像文件存储至文件缓存容器a2中,文件缓存容器a2由第一容器a1启动;而当在第一容器b1中构建第二容器时,则将第一容器b1中的目标镜像文件存储至文件缓存容器b2中,文件缓存容器b2由第一容器b1启动。
40.步骤203,响应于第二容器的运行指令,在文件缓存容器中获取目标镜像文件,并基于目标镜像文件运行第二容器。
41.可选的,第二容器在运行时,将向dockerdaemon发送运行指令,而在此过程中,由
于目标镜像文件已存储至文件缓存容器,而文件缓存容器可被访问,因此,将在文件缓存容器中获取第二容器所需的目标镜像文件,进而基于该目标镜像文件运行第二容器。
42.可选的,目标镜像文件是运行第二容器所需的全部镜像文件或部分镜像文件。
43.本技术实施例中,通过启动文件缓存容器,当在第一容器内构建第二容器时即在嵌套容器的场景下,则将运行第二容器所需的位于第一容器之内的目标镜像文件存储至文件缓存容器,当第二容器运行时,可直接在文件缓存容器中获取目标镜像文件,进而基于目标镜像文件运行第二容器,避免因无法在第一容器中获取目标镜像文件而导致第二容器运行的失败,提高容器运行成功率。
44.为确保成功获取文件缓存容器中的目标镜像文件,在一种可能的实施方式中,在启动文件缓存容器时,为文件缓存容器设置启动参数,从而在后续获取文件缓存容器中的目标镜像文件时,可基于文件缓存容器的启动参数获取,下面将采用示例性实施例进行说明。
45.请参考图3,其示出了本技术一个示例性实施例提供的容器运行方法的流程图。本实施例以该方法用于安装有docker的计算机设备为例进行说明,该方法包括如下步骤:
46.步骤301,响应于第一容器的容器启动指令,启动文件缓存容器,容器启动指令中包含目标名称以及目标路径,目标名称用于标识文件缓存容器,目标路径为文件缓存容器的开放路径。
47.本技术实施例中,文件缓存容器由第一容器启动,其中,第一容器中的dockerclient发起容器启动指令。由于可能存在多个容器,为后续成功在文件缓存容器中获取目标镜像文件,需对文件缓存容器设置标识,可选的,可通过为文件缓存容器设置固定的容器名称,作为文件缓存容器的唯一标识,即容器启动指令中包含目标名称,将目标名称作为文件缓存容器的容器名称。
48.可选的,容器启动指令中还包含目标路径,用于指示开放文件缓存容器的目标路径,即文件缓存容器的目标路径的访问权限为开放状态,其他容器可基于目标路径读取文件缓存容器中的文件。
49.示意性的,容器启动指令可为docker run
‑‑
rm

d
‑‑
name=filestore

v/workspace
‑‑
entrypoint=sleep busybox 7200,其中,包含目标名称filestore以及目标路径workspace。
50.步骤302,响应于嵌套容器构建指令,将目标镜像文件存储至文件缓存容器的目标路径中。
51.当接收到嵌套容器构建指令且第一容器创建目标镜像文件后,则将目标镜像文件存储至文件缓存容器的目标路径下,便于后续基于目标路径读取目标镜像文件。
52.可选的,可通过dockercp命令将第一容器中的目标镜像文件拷贝至文件缓存容器的目标路径下。
53.结合上述示例,当第一容器创建目标镜像文件/workspace/test.txt之后,则将/workspace/test.txt存储至文件缓存容器filestore的目标路径workspace中,即docker cp/workspace/test.txt filestore:/workspace。
54.步骤303,响应于第二容器的运行指令,基于目标名称确认文件缓存容器。
55.可选的,第二容器的运行指令中包含文件缓存容器的目标名称,当接收到第二容
器的运行指令时,dockerdeamon即根据运行指令中目标名称确认文件缓存容器,在容器名称为目标名称的文件缓存容器中获取目标镜像文件。
56.示意性的,运行指令中包含docker run
‑‑
volumes

from=filestore

,指示在文件缓存容器filestore中获取目标镜像文件。
57.步骤304,基于目标路径从文件缓存容器中读取目标镜像文件。
58.当确定文件缓存容器后,在文件缓存容器中读取目标镜像文件,在读取过程中,由于文件缓存容器的目标路径为开放状态,因此,可基于目标路径在文件缓存容器中读取目标镜像文件。
59.示意性的,如图4所示,第一容器中docker client 401发起容器启动指令,主机中dockerdaemon 402接收到容器启动指令后,启动文件缓存容器filestore403,并将文件缓存容器filestore403的目标路径设置为对其他容器可见。当第一容器创建第二容器404所需的目标镜像文件时,将目标镜像文件存储至文件缓存容器filestore 403中,而当接收到docker client 401发送的运行第二容器404的运行指令时,dockerdaemon402在文件缓存容器filestore 403中获取目标镜像文件,将目标镜像文件挂载到第二容器404中,完成目标镜像文件的获取。
60.步骤305,基于目标镜像文件运行第二容器。
61.在基于目标镜像文件运行第二容器的过程中,首先需构建第二容器的镜像文件,目标镜像文件可为第二容器所需的全部镜像文件,也可为部分镜像文件。当目标镜像文件为第二容器所需的全部镜像文件时,可直接基于目标镜像文件构建第二容器的镜像文件,进而基于构建得到的第二容器的镜像文件运行第二容器。
62.而当目标镜像文件仅为第二容器所需的部分镜像文件时,其他所需镜像文件则可在主机所在的文件系统中获取,或在容器仓库中获取得到。进而基于全部所需的镜像文件构建得到第二容器的镜像文件,基于该镜像文件运行第二容器。
63.示意性的,可通过dockerbuild命令构建第二容器的镜像文件,如通过命令docker build

tmyharbor.catfile.test.构建得到第二容器的镜像文件,基于该镜像文件运行第二容器,即docker run
‑‑
volumes

from=filestore
‑‑
rm

d
‑‑
name=testl

v/var/run/dockersock/var/run/docker.sock myharbor.catile.test。
64.可选的,当构建第二容器的镜像文件后,还可将第二容器的镜像文件存储至仓库中,便于后续的获取与使用。示意性的,通过docker push myharbor.catfile.test命令,将镜像myharbor.catfile.test存储至仓库。
65.步骤306,获取容器镜像文件,容器镜像文件由第二容器在运行过程中打印得到。
66.由于可能存在文件缓存容器异常或目标镜像文件中未成功存储至文件缓存容器等异常情况,导致第二容器运行时,无法成功获取目标镜像文件,即存在目标镜像文件挂载失败的情况。因此,在一种可能的实施方式中,获取容器镜像文件,根据容器镜像文件判断目标镜像文件是否挂载成功。
67.可选的,容器镜像文件是第二容器基于构建的镜像文件运行过程中打印输出的文件,其包含第二容器运行过程中全部镜像文件。
68.步骤307,响应于容器镜像文件中包含目标镜像文件,确定目标镜像文件挂载成功。
69.获取容器镜像文件后,即可检测容器镜像文件中是否包含目标镜像文件,若包含,则表明目标镜像文件挂载成功,即第二容器可正常运行。
70.而当容器镜像文件中不包含目标镜像文件时,则表明目标镜像文件挂载失败,将显示错误信息,用于提示未成功挂载目标镜像文件。
71.步骤308,停止并删除文件缓存容器。
72.由于文件缓存容器在运行过程中将持续占用cpu资源,为降低对资源的占用,当基于目标镜像文件运行第二容器后,将停止运行文件缓存容器,避免对cpu资源的持续占用。
73.可选的,可通过dockerstop命令,停止文件缓存容器。结合上述示例,通过向dockerdaemon发送dockerstopfilestore命令,即可停止文件缓存容器filestore的运行。
74.且文件缓存容器占用一定的存储空间,因此,在一种可能的实施方式中,当停止文件缓存容器的运行后,即可将文件缓存容器删除,避免文件缓存容器持续保留,造成存储空间的浪费。可选的,可通过在容器启动指令中设置目标参数,用于指示当文件缓存容器停止运行时,自动删除文件缓存容器,其中目标参数可为

rm参数,即如容器启动指令docker run
‑‑
rm

d
‑‑
name=filestore

v/workspace
‑‑
entrypoint=sleep busybox 7200所示,其中,包含

rm参数,当文件缓存容器filestore停止运行时将被删除。
75.在一种可能的实施方式中,容器运行流程如图5所示:
76.步骤501,运行第一容器。
77.步骤502,响应于第一容器的容器启动指令,启动文件缓存容器。
78.可选的,容器启动指令可为docker run
‑‑
rm

d
‑‑
name=filestore

v/workspace
‑‑
entrypoint=sleep busybox 7200。
79.步骤503,第一容器创建目标镜像文件。
80.即echo"test">>/workspace/test txt。
81.步骤504,将目标镜像文件存储至文件缓存容器。
82.即docker/workspace/test txt flestore/workspace。
83.步骤505,响应于第二容器的运行指令,在文件缓存容器中获取目标镜像文件,并基于目标镜像文件运行第二容器。
84.运行指令可为:docker run
‑‑
volumes

from=filestore
‑‑
rm

d
‑‑
name=testl

v/var/run/dockersock/var/run/docker.sock myharbor.catile.test。
85.步骤506,确定容器镜像文件中是否包含目标镜像文件,若是,则执行步骤507,若否,则执行步骤508。
86.步骤507,目标镜像文件挂载成功。
87.步骤508,目标镜像文件挂载失败。
88.步骤509,停止运行文件缓存容器。
89.即docker stop filestore。
90.本实施例中,为文件缓存容器设置固定的目标名称,并开放文件缓存容器的目标路径,当目标镜像文件存储至文件缓存容器中时,可基于目标名称确定文件缓存容器,并基于目标路径从文件缓存容器中读取目标镜像文件,确保成功挂载目标镜像文件。
91.且本实施例中,在基于目标镜像文件运行第二容器后,即停止文件缓存容器的运行,且进一步删除文件缓存容器,避免文件缓存容器对cpu资源以及存储资源的持续占用,
造成不必要的资源浪费,有助于提高资源利用率。
92.在一种可能的应用场景下,可能存在第一容器意外停止运行的情况,而当第一容器意外停止时,文件缓存容器将持续处于运行状态,将会持续占用cpu资源,造成资源的浪费。因此,为避免因异常原因造成文件缓存容器持续运行的情况,在一种可能的实施方式中,在启动文件缓存容器时,为文件缓存容器设置运行时间阈值,可选的,在容器启动指令中设定运行时间阈值。
93.可选的,响应于文件缓存容器的运行时间达到运行时间阈值,停止并删除文件缓存容器。即当文件缓存容器启动后,开始计时,当时间达到运行时间阈值时,即停止文件缓存容器的运行。在文件缓存容器停止后,将进一步被删除。
94.示意性的,容器启动指令docker run
‑‑
rm

d
‑‑
name=filestore

v/workspace
‑‑
entrypoint=sleep busybox 7200中设定运行时间阈值为7200s,即在文件缓存容器filestore运行时间达到2h后,停止文件缓存容器filestore的运行,且由于指令中包含

rm参数,因此,在文件缓存容器停止运行后将被删除。
95.本实施例中,通过为文件缓存容器设定运行时间阈值,在运行时间达到运行时间阈值时,将自动停止文件缓存容器的运行,避免异常造成的文件缓存容器持续运行,导致不必要的资源浪费。
96.相关技术中,由于第一容器的容器名称随机设定,且第一容器对其他容器不可见,因此无法获取第一容器中的目标镜像文件,而当具备第一容器启动参数的修改权限时,则可对第一容器的容器名称进行修改,且可开放第一容器的路径,将该路径设置为对其他容器可见,该种情形下,当接收到第二容器的运行指令时,可直接在第一容器中读取目标镜像文件,无需启动文件缓存容器。因此,在启动文件缓存容器之前,需判断是否可以修改第一容器的启动参数,该方式可包括如下步骤:
97.步骤一,响应于第一容器启动参数的修改指令,修改所述第一容器的名称为目标名称且开放所述第一容器的目标路径。
98.可选的,第一容器启动参数即为第一容器的容器名称以及第一容器的开放路径。当接收到第一容器启动参数的修改指令时,将对第一容器的容器名称进行修改,将其修改为固定的目标名称;且开放第一容器的目标路径,使其他容器可基于目标路径读取第一容器中的目标镜像文件。
99.步骤二,响应于第一容器启动参数修改失败,启动文件缓存容器。
100.当不具备第一容器启动参数的修改权限时,第一容器启动参数将修改失败,即无法修改第一容器的容器名称且无法设置第一容器的目标路径对其他容器可见,此时,则需启动文件缓存容器,利用文件缓存容器使第二容器成功挂载目标镜像文件。
101.本实施例中,将第一容器启动参数修改失败时,启动文件缓存容器,而当第一容器启动参数修改成功时,可直接在第一容器中获取目标镜像文件,无需启动文件缓存容器,减少文件缓存容器对资源的占用。
102.在上述实施例中,第一容器与第二容器共享主机中dockerdaemon,而由于主机中dockerdaemon仅可访问主机中文件系统,无法访问第一容器中的镜像文件,因此,通过设置文件缓存容器获取第一容器中的目标镜像文件,进而支持第二容器的运行。而在另一种可能的实施方式中,可在第一容器中建立dockerdaemon,第一容器中的dockerdaemon即可直
接获取第一容器中的目标镜像文件,无需建立文件缓存容器。下面将以示例性实施例进行说明。结合上述实施例,启动文件缓存容器可包括如下步骤:
103.步骤601,确定第一容器的运行环境。
104.可选的,容器可能运行在kubernetes集群中,也可能运行在本地环境。其中,kubernetes(k8s)集群是一个可移植、可扩展的开源平台,用于管理容器化的工作负载可服务,在k8s集群中存在多个容器的部署。在k8s集群中运行第一容器以及在本地环境运行第一容器时,所具备的权限不同,且新建dockerdaemon对其他容器的影响也不同,因此,需首先确定第一容器的运行环境,判断第一容器运行在本地环境,或者,运行在k8s集群中。
105.步骤602,响应于第一容器运行在kubernetes集群中,启动文件缓存容器。
106.当容器运行在k8s集群中时,若在第一容器中新建dockerdaemon,则可能对其余容器产生影响,且需向k8s中的管理节点申请权限,过程较为繁杂,且当无法获取权限时,也无法新建dockerdaemon,影响目标镜像文件的挂载。因此,当容器运行在k8s集群中时,可通过启动文件缓存容器,将第一容器中目标镜像文件存储至文件缓存容器中,使第二容器可成功挂载目标镜像文件。
107.步骤603,响应于第一容器运行在本地,在第一容器中建立容器守护进程,容器守护进程用于获取第一容器中的目标镜像文件。
108.而当第一容器运行在本地时,则不存在对其他容器的影响,可直接通过docker run

privileged的方式在第一容器中新建docker deamon。当接收到第一容器的嵌套容器构建指令时,第一容器中的docker deamon将在第一容器中构建第二容器,且当接收到第二容器的运行指令时,从第一容器中读取目标镜像文件,并基于目标镜像文件运行第二容器,无需构建文件缓存容器。
109.图7是本技术一个示例性实施例提供的容器运行装置的结构框图,该装置包括:
110.启动模块701,用于启动文件缓存容器,所述文件缓存容器由第一容器启动;
111.存储模块702,用于响应于所述第一容器的嵌套容器构建指令,将目标镜像文件存储至所述文件缓存容器,所述嵌套容器构建指令用于指示在所述第一容器中构建第二容器,所述目标镜像文件用于支持所述第二容器的运行;
112.运行模块703,用于响应于所述第二容器的运行指令,在所述文件缓存容器中获取所述目标镜像文件,并基于所述目标镜像文件运行所述第二容器。
113.可选的,所述启动模块701,还用于:
114.响应于第一容器的容器启动指令,启动所述文件缓存容器,所述容器启动指令中包含目标名称以及目标路径,所述目标名称用于标识所述文件缓存容器,所述目标路径为所述文件缓存容器的开放路径;
115.所述存储模块702,还用于:
116.响应于所述嵌套容器构建指令,将所述目标镜像文件存储至所述文件缓存容器的所述目标路径中。
117.可选的,所述运行模块703,包括:
118.确认单元,用于响应于所述第二容器的运行指令,基于所述目标名称确认所述文件缓存容器;
119.读取单元,用于基于所述目标路径从所述文件缓存容器中读取所述目标镜像文
件;
120.运行单元,用于基于所述目标镜像文件运行所述第二容器。
121.可选的,所述装置还包括:
122.获取模块,用于获取容器镜像文件,所述容器镜像文件由所述第二容器在运行过程中打印得到;
123.确定模块,用于响应于所述容器镜像文件中包含所述目标镜像文件,确定所述目标镜像文件挂载成功。
124.可选的,所述装置还包括:
125.第一删除模块,用于停止并删除所述文件缓存容器。
126.可选的,所述容器启动指令中包含运行时间阈值;
127.所述装置还包括:
128.第二删除模块,用于响应于所述文件缓存容器的运行时间达到所述运行时间阈值,停止并删除所述文件缓存容器。
129.可选的,所述装置还包括:
130.修改模块,用于响应于第一容器启动参数的修改指令,修改所述第一容器的名称为目标名称且开放所述第一容器的目标路径;
131.可选的,所述启动模块701,还用于:
132.响应于所述第一容器启动参数修改失败,启动所述文件缓存容器。
133.可选的,所述启动模块701,包括:
134.确定单元,用于确定所述第一容器的运行环境;
135.启动单元,用于响应于所述第一容器运行在kubernetes集群中,启动所述文件缓存容器;
136.可选的,所述装置还包括:
137.建立模块,用于响应于所述第一容器运行在本地,在所述第一容器中建立容器守护进程,所述容器守护进程用于获取所述第一容器中的所述目标镜像文件。
138.本技术实施例中,通过启动文件缓存容器,当在第一容器内构建第二容器时即在嵌套容器的场景下,则将运行第二容器所需的位于第一容器之内的目标镜像文件存储至文件缓存容器,当第二容器运行时,可直接在文件缓存容器中获取目标镜像文件,进而基于目标镜像文件运行第二容器,避免因无法获取目标镜像文件而导致第二容器运行的失败,提高容器运行成功率。
139.需要说明的是:上述实施例提供的装置,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的装置与方法实施例属于同一构思,其实现过程详见方法实施例,这里不再赘述。
140.请参考图8,其示出了本技术一个示例性实施例提供的计算机设备的结构示意图。具体来讲:所述计算机设备800包括中央处理单元(central processing unit,cpu)801、包括随机存取存储器802和只读存储器803的系统存储器804,以及连接系统存储器804和中央处理单元801的系统总线805。所述计算机设备800还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(input/output,i/o系统)806,和用于存储操作系统813、应用
程序814和其他程序模块815的大容量存储设备807。
141.所述基本输入/输出系统806包括有用于显示信息的显示器808和用于用户输入信息的诸如鼠标、键盘之类的输入设备809。其中所述显示器808和输入设备809都通过连接到系统总线805的输入输出控制器810连接到中央处理单元801。所述基本输入/输出系统806还可以包括输入输出控制器810以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地,输入输出控制器810还提供输出到显示屏、打印机或其他类型的输出设备。
142.所述大容量存储设备807通过连接到系统总线805的大容量存储控制器(未示出)连接到中央处理单元801。所述大容量存储设备807及其相关联的计算机可读介质为计算机设备800提供非易失性存储。也就是说,所述大容量存储设备807可以包括诸如硬盘或者驱动器之类的计算机可读介质(未示出)。
143.不失一般性,所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括随机存取记忆体(ram,random access memory)、只读存储器(rom,read only memory)、闪存或其他固态存储其技术,只读光盘(compact disc read

only memory,cd

rom)、数字通用光盘(digital versatile disc,dvd)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然,本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器804和大容量存储设备807可以统称为存储器。
144.存储器存储有一个或多个程序,一个或多个程序被配置成由一个或多个中央处理单元801执行,一个或多个程序包含用于实现上述方法的指令,中央处理单元801执行该一个或多个程序实现上述各个方法实施例提供的方法。
145.根据本技术的各种实施例,所述计算机设备800还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即计算机设备800可以通过连接在所述系统总线805上的网络接口单元811连接到网络812,或者说,也可以使用网络接口单元811来连接到其他类型的网络或远程计算机系统(未示出)。
146.所述存储器还包括一个或者一个以上的程序,所述一个或者一个以上程序存储于存储器中,所述一个或者一个以上程序包含用于进行本技术实施例提供的方法中由计算机设备所执行的步骤。
147.本技术实施例还提供了一种计算机可读存储介质,该计算机可读存储介质存储有至少一条指令,所述至少一条指令由处理器加载并执行以实现如上各个实施例所述的容器运行方法。
148.根据本技术的一个方面,提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述方面的各种可选实现方式中提供的容器运行方法。
149.本领域技术人员应该可以意识到,在上述一个或多个示例中,本技术实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存储在计算机可读存储介质中或者作为计算机可读存储介质上的一个或多个指令
或代码进行传输。计算机可读存储介质包括计算机存储介质和通信介质,其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
150.以上所述仅为本技术的可选实施例,并不用以限制本技术,凡在本技术的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本技术的保护范围之内。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献