CN111984280B - 容器兼容、升级方法、装置、设备及存储介质 - Google Patents
容器兼容、升级方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN111984280B CN111984280B CN201910430238.0A CN201910430238A CN111984280B CN 111984280 B CN111984280 B CN 111984280B CN 201910430238 A CN201910430238 A CN 201910430238A CN 111984280 B CN111984280 B CN 111984280B
- Authority
- CN
- China
- Prior art keywords
- container
- command
- management component
- target
- compatible
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 149
- 230000008569 process Effects 0.000 claims abstract description 94
- 238000004891 communication Methods 0.000 claims description 36
- 238000004590 computer program Methods 0.000 claims description 21
- 230000004048 modification Effects 0.000 claims description 11
- 238000012986 modification Methods 0.000 claims description 11
- 238000012544 monitoring process Methods 0.000 claims description 3
- 230000004044 response Effects 0.000 claims description 3
- 230000009286 beneficial effect Effects 0.000 abstract description 6
- 238000005516 engineering process Methods 0.000 description 12
- 238000010586 diagram Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 230000008859 change Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000004744 fabric Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 238000000547 structure data Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请实施例提供一种容器兼容、升级方法、装置、设备及存储介质。本申请实施例提供的容器兼容方法中，第一容器管理组件在接收到针对宿主机上的容器下发的命令时，确定该命令指向的目标容器；在确定该目标容器为待兼容的容器时，可根据该命令对应的容器兼容逻辑对目标容器执行该命令。在这种实施方式中，第一容器管理组件实现了对目标容器的兼容，降低了容器的管理过程对容器管理组件和容器之间的兼容性的依赖，有利于提升容器的管理效率。
Description
技术领域
本申请涉及互联网技术领域，尤其涉及一种容器兼容、升级方法、装置、设备及存储介质。
背景技术
随机计算机技术的发展，应用程序容器化技术逐渐成熟。应用程序容器化，是指将应用程序及其运行所依赖的数据打包到可移植的容器中，由该容器向应用程序提供近似于完整系统的运行环境。
通常，容器引擎通过容器管理组件在宿主机上创建、运行并且管理容器。容器管理组件对容器的管理操作较多地依赖于其与容器之间的兼容程度。
在一些典型的应用场景中，不同类型的容器引擎或不同版本的同类容器引擎创建的容器运行在同一台宿主机上。在这种场景中，如何克服容器管理组件和容器之间的兼容性问题，以有效地对宿主机上的不同容器进行有效管理，成为了亟待解决的技术问题。
发明内容
本申请的多个方面提供一种容器兼容、升级方法、装置、设备及存储介质，用以有效地对不同类型的容器引擎或不同版本的同类容器引擎创建的容器进行管理。
本申请实施例提供一种容器兼容方法，包括：第一容器管理组件响应针对宿主机上的容器下发的命令，确定所述命令指向的目标容器；在确定所述目标容器为待兼容的容器时，根据所述命令对应的容器兼容逻辑，对所述目标容器执行所述命令。
本申请实施例还提供一种容器兼容装置，包括：命令获取模块，用于响应针对宿主机上的容器下发的命令，确定所述命令指向的目标容器；命令兼容模块，用于在确定所述目标容器为待兼容的容器时，根据所述命令对应的容器兼容逻辑，对所述目标容器执行所述命令。
本申请实施例还提供一种容器兼容设备，包括：存储器和处理器；
所述存储器用于存储一条或多条计算机指令；所述处理器用于执行所述一条或多条计算机指令以用于：响应针对宿主机上的容器下发的命令，确定所述命令指向的目标容器；在确定所述目标容器为待兼容的容器时，根据所述命令对应的容器兼容逻辑，对所述目标容器执行所述命令。
本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现本申请实施例提供的由容器兼容设备执行的容器兼容方法。
本申请实施例还提供一种容器升级设备，包括：存储器和处理器；所述存储器用于存储一条或多条计算机指令；所述处理器用于执行所述一条或多条计算机指令以用于：响应宿主机上的第二容器管理组件升级为第一容器管理组件的操作，在所述宿主机上确定由所述二容器管理组件创建的容器，作为待升级的容器；根据设定的容器兼容逻辑对所述待升级的容器进行管理，以接收针对所述待升级的容器下发的命令；若所述命令指示重新发布所述待升级的容器上的应用任务，则创建用于承载重新发布的所述应用任务的容器，以替换所述待升级的容器。
本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现本申请实施例提供的容器升级方法。
本申请实施例提供的容器兼容方法中，第一容器管理组件在接收到针对宿主机上的容器下发的命令时，确定该命令指向的目标容器；在确定该目标容器为待兼容的容器时，可根据该命令对应的容器兼容逻辑对目标容器执行该命令。在这种实施方式中，第一容器管理组件实现了对目标容器的兼容，降低了容器的管理过程对容器管理组件和容器之间的兼容性的依赖，有利于提升容器的管理效率。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1a为本申请一示例性实施例提供的Docker容器的架构示意图；
图1b为本申请一示例性实施例提供的容器兼容方法的流程示意图；
图2为本申请另一示例性实施例提供的容器兼容方法的流程示意图；
图3为本申请又一示例性实施例提供的容器兼容方法的流程示意图；
图4为本申请又一示例性实施例提供的容器兼容方法的流程示意图；
图5a为本申请又一示例性实施例提供的容器兼容方法的流程示意图；
图5b为本申请一示例性实施例提供的应用场景实例的示意图；
图5c为本申请另一示例性实施例提供的应用场景实例的示意图；
图6是本申请一示例性实施例提供的容器兼容装置的结构示意图；
图7是本申请一示例性实施例提供的容器兼容设备的结构示意图；
图8是本申请另一示例性实施例提供的容器兼容设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
应用程序容器化技术逐渐成熟，目前，市场上涌现出多种多样类型的容器引擎，例如Docker容器引擎、Rkt容器引擎、kubernetes容器引擎、pouchcontainer容器引擎等。通常，容器引擎可通过容器管理组件在宿主机中管理完整的容器生命周期。在一些典型的应用场景中，该容器管理组件可实现为Containerd。
Containerd是一个面向容器工业标准的容器管理运行时。容器引擎可通过Containerd调用Linux、Windows、Solaris以及其它操作系统上特定的功能，执行容器镜像的传输和存储操作、容器的执行和管理操作、容器的存储和网络等操作。
为便于理解本申请实施例提供的技术方案，以下将以Docker容器引擎作为示例，对容器引擎的结构及其功能进行说明。
Docker容器引擎是目前应用较为广泛的容器引擎之一，如图1a所示，Docker容器引擎使用的是客户端(Client)-服务器(Sever)的C/S架构模式。其中Docker Client，相当于C/S架构模式中的客户端，用于和用户进行交互；Docker daemon作为Docker容器的守护进程，相当C/S架构模式中的服务器，用于和Docker Client交互，并管理Docker镜像(image)和Docker容器(container)。其中，Docker镜像是用于创建Docker容器的模板，Docker容器是独立运行的一个或一组应用程序。
在图1a所示的架构中，Containerd作为容器管理组件，为Docker daemon提供了统一的接口，其一方面可根据Docker daemon的指令，创建、运行和管理Docker容器；另一方面，Containerd作为Docker daemon和Docker容器之间的中间交流件，可将Docker daemon和Docker容器隔离开，降低二者之间的相互影响。Containerd可以管理shim，并通过shim实现对容器的管理。
其中，shim(垫片)是容器的运行时载体，每一个容器分别对应一个shim，且受该shim管理。不同版本的Containerd创建的容器对应不同版本的shim，例如，Containerd的1.0版本(以下简称Containerd1.0)创建的容器对应1.0版本的shim(以下简称shim1.0),Containerd的0.2版本(以下简称Containerd0.2)创建的容器对应0.2版本的shim(以下简称shim0.2)。
Containerd在创建、运行或者管理容器时，会先拉起一个shim进程，再通过该shim进程调用运行时runC创建、运行或者管理容器。runC是容器运行时，可直接创建和运行Docker容器。其中，不同版本的shim使用不同版本的runC创建或者运行容器。例如，shim1.0使用runC1.0-rc4创建或者运行容器，shim0.2使用run1.0-rc2创建或者运行容器。
通常，不同容器引擎或者不同版本的同类容器引擎，基于不同版本的容器管理组件Containerd管理容器的生命周期。例如，pouchcontainer容器引擎基于Containerd1.0管理pouch容器的生命周期；Docker容器引擎的17版本基于Containerd0.2管理17版本的Docker容器的生命周期；Docker容器引擎18版本的基于Containerd1.0管理18版本的Docker容器的生命周期。
其中，不同版本的Containerd按照特定的通信机制与其创建的容器进行通信。例如，Containerd1.0与其创建的pouch容器进行通信时，Containerd1.0可采用基于套接字(socket)的通信方式启动pouch容器对应的shim1.0进程。又例如，Containerd0.2与其创建的17版本的Docker容器进行通信时，Containerd0.2可直接启动17版本的Docker容器对应的shim0.2进程。
基于上述，当不同类型的容器引擎或不同版本的同一容器引擎创建的容器运行在同一台宿主机上时，容器管理组件与容器对应的shim之间可能存在通信机制不匹配的问题，进而导致容器管理组件与容器之间的兼容性较差，无法对不同类型的容器进行有效管理。在本申请一些实施例中，提供了一种解决方案，以下结合附图，详细说明本申请各实施例提供的技术方案。
图1b为本申请一示例性实施例提供的容器兼容方法的流程示意图，如图1b所示，该方法包括：
步骤101、响应针对宿主机上的容器下发的命令，第一容器管理组件确定命令指向的目标容器。
步骤102、在确定目标容器为待兼容的容器时，根据该命令对应的容器兼容逻辑，对目标容器执行该命令。
在本实施例中，宿主机指的是运行有容器的计算机设备，第一容器管理组件，安装并运行在该宿主机上。第一容器管理组件，可实现为容器引擎中的Containerd。本实施例在此不限制Containerd的版本，可以是Containerd的0.2版本、Containerd的1.0版本，或者其他版本，视实际应用场景而定。
其中，针对宿主机上的容器下发的命令，用以指示第一容器管理组件根据该命令对宿主机上的容器进行管理。该命令可以是用户下发的，也可以是其他设备、应用或者进程在特定事件的触发下生成，并传递至第一容器管理组件的。
其中，命令指向的目标容器，可理解为，该命令针对目标容器下发，用于对目标容器进行管理。通常，该命令可携带命令指向的目标容器的识别标识，以指示针对宿主机上的哪个或者哪些容器进行管理。例如，该命令可携带目标容器的名称、身份识别号(identification，ID)等；又例如，该命令可携带下发命令的用户的账户名、用户的生物特征等，以借助用户和容器的对应关系，确定命令指向的目标容器，本实施例不做限制。
基于上述识别标识，第一容器管理组件可确定命令指向的目标容器。在确定命令指向的目标容器后，可判断该目标容器是否为待兼容的容器。
通常，第一容器管理组件可直接对其创建的容器进行管理；待兼容的容器，可认为是：与第一容器管理组件的通信机制不匹配的容器。通常，第一容器管理组件的通信机制与第一容器管理组件创建的容器的通信机制相匹配，与待兼容的容器的通信机制不匹配。为便于第一容器管理组件代为管理该待兼容的容器，本实施例中，提供了容器兼容逻辑。
在本实施例中，容器兼容逻辑，用于向第一容器管理组件提供管理该待兼容的容器的方法。其中，不同的命令，可对应不同的容器兼容逻辑，以使得第一容器管理组件根据不同的兼容逻辑，执行针对目标容器的不同命令。基于此，在接收到指向目标容器的命令时，第一容器管理组件可根据该命令对应的容器兼容逻辑，对目标容器执行该命令。
本实施例中，第一容器管理组件在接收到针对宿主机上的容器下发的命令时，确定该命令指向的目标容器；在确定该目标容器为待兼容的容器时，可根据该命令对应的容器兼容逻辑对目标容器执行该命令。在这种实施方式中，第一容器管理组件实现了对目标容器的兼容，降低了容器的管理过程对容器管理组件和容器之间的兼容性的依赖，有利于提升容器的管理效率。
图2为本申请另一示例性实施例提供的容器兼容方法的流程示意图，如图2所示，该方法包括：
步骤201、第一容器管理组件查询宿主机上的容器运行目录下的各级子目录，并根据各级子目录的名称，确定运行在宿主机上的由第二容器管理组件创建的容器，作为待兼容的容器。
步骤202、第一容器管理组件从该容器运行目录下获取待兼容的容器的元数据添加至内存中。
步骤203、第一容器管理组件响应针对宿主机上的容器下发的命令，确定该命令指向的目标容器。
步骤204、第一容器管理组件从该命令中确定目标容器的识别标识，并在待兼容的容器的元数据中查询是否存在与目标容器的识别标识匹配的元数据。
步骤205、第一容器管理组件在待兼容的容器的元数据中存在与目标容器的识别标识匹配的元数据时，确定该目标容器为待兼容的容器。
步骤206、第一容器管理组件启动与第二容器管理组件对应的shim进程，并通过该shim进程对目标容器执行该命令。
在步骤201中，宿主机上的容器运行目录，指的是宿主机上用于存放运行中的容器的相关数据的目录。通常，容器在宿主机上运行时，会在该容器运行目录下生成各自对应的各级子目录。例如，第二容器管理组件创建的容器在宿主机上运行时，会在该容器运行目录下生成与第二容器管理组件对应的一级子目录，在该级子目录下生成管理子目录，并在该管理子目录下生成与运行中的第二容器管理组件创建的容器对应的子目录。
接下来，以第二容器管理组件实现Containerd的0.2版本为例，对宿主机上的容器运行目录进行示例性说明。通常，宿主机上的容器运行目录为“/var/run”目录。
假设，宿主机上运行着Containerd的0.2版本创建的容器，则可生成“/var/run”的子目录：“/var/run/Docker”，接着，在该子目录下生成管理子目录“/var/run/Docker/libContainerd”。假设，Containerd的0.2版本创建的ID＝001和ID＝002的Docker容器运行在宿主机上，则可分别生成子目录：
“/var/run/Docker/libContainerd/containerID＝001/”
“/var/run/Docker/libContainerd/containerID＝002/”
基于上述，第一容器管理组件可在宿主机上查询容器运行目录下的各级子目录，并根据各级子目录的名称，确定宿主机上运行的哪些容器为第二容器管理组件创建的容器。
其中，第二容器管理组件指的是与第一容器管理组件不同的容器管理组件。可选地，第二容器管理组件，可以包括一种容器管理组件，也可以包括多种不同的容器管理组件。例如，假设宿主机上运行的第一容器管理组件为pouchcontainer容器引擎使用的容器管理组件，当宿主机上同时运行着Docker容器和Rkt容器时，第二容器管理组件可包括Docker容器引擎使用的容器管理组件和Rkt容器引擎使用的容器管理组件。换言之，第一容器管理组件可将运行在宿主机上的Docker容器和Rkt容器，作为待兼容的容器。再例如，假设宿主机上运行的第一容器管理组件为Rkt容器引擎使用的容器管理组件，当宿主机上同时运行着18版本的Docker容器引擎创建的18版本的Docker容器和17版本的Docker容器引擎创建的17版本的Docker容器时，第二容器管理组件可包括18版本的Docker容器引擎使用的容器管理组件和17版本的容器引擎使用的容器管理组件。
在步骤202中，可选地，运行在宿主机上的容器，会在各自对应的子目录下存放各自的元数据。例如，运行在宿主机上的ID＝001的Docker容器，其元数据的存放目录为：
/run/Docker/libContainerd/containerID＝001/Metadata，其中，Metadata指的是ID＝001的Docker容器的元数据。
基于此，第一容器管理组件在确定宿主机上运行的待兼容的容器后，可从待兼容的容器对应的子目录下可获取其元数据，并添加至内存中。进而，第一容器管理组件可基于元数据，对该待兼容的容器进行管理。
可选地，待兼容的容器的元数据，可包括：容器ID、主机名(hostname)、挂载目录、设备(device)、命名空间(namespace)、控制组(cgoups)、权限、环境变量、用户身份标识(UID)、容器的init进程的进程标识符中的一种或多种，本实施例包含但不限于此。
需要说明的是，通常，待兼容的容器的元数据的格式为第二容器管理组件能够识别的格式匹配。当该待兼容的容器由第一容器管理组件代为管理时，可预先对该待兼容的容器的元数据进行格式修改，使其格式与第一容器管理组件能够识别的格式匹配，以使得第一容器管理组件能够识别这些元数据，并利用这些元数据管理该待兼容的容器，不再赘述。
在步骤203中，可选地，该命令可由用户下发。在本实施例中，针对宿主机上的容器下发的命令包括但不限于：exec命令、restart命令、rm命令、start命令、unpause命令；其中，exec命令，用于对运行中的容器执行命令，restart命令用于重启一个或多个容器，rm命令用于移除一个或多个容器，start命令用于启动一个或多个已创建或已停止的容器，unpause命令用于取消暂停一个或多个已暂停的容器。
基于前述实施例的记载，当第一容器管理组件所在的容器引擎实现为客户端(Client)-服务器(Sever)的C/S架构模式时，第一容器管理组件相当于服务器一侧的组件。用户可通过客户端下发针对宿主机上的容器的命令，再由客户端向第一容器管理组件传递该命令。
可选地，客户端在获取用户下发的命令时，可一并获取命令指向的目标容器的识别标识。在向第一容器管理组件发送该命令时，可携带目标容器的识别标识，进而，第一容器管理组件可根据目标容器的识别标识，确定该命令指向的目标容器。其中，目标容器的识别标识，可包括：目标容器的名称、ID，或者下发命令的用户的账户名、用户的生物特征等，本实施例包含但不限于此。
接着，在步骤204以及步骤205中，第一容器管理组件可在已添加至内存的待兼容的容器的元数据中，查询是否存在与目标容器的识别标识匹配的元数据。若在待兼容的容器的元数据中查询到了与目标容器的识别标识匹配的元数据，则可确定该目标容器为待兼容的容器。
例如，若目标容器的识别标识为目标容器的ID，则第一容器管理组件可在前述步骤获取的待兼容的容器的元数据中，查询是否存在与该目标容器的ID匹配的容器ID；若存在，则认为该目标容器为待兼容的容器。又例如，若目标容器的识别标识为下发命令的用户的账户名，则第一容器管理组件可在前述步骤获取的待兼容的容器的元数据中，查询是否存在与该目标容器的ID匹配的UID；若存在，则认为该目标容器为待兼容的容器。
接下来，在步骤206中，由于待兼容的容器由第二容器管理组件创建，因此，第一容器管理组件可启动与第二容器管理组件对应的shim进程，并通过该shim进程对目标容器执行该命令。
可选地，第一容器管理组件通过该shim进程对目标容器执行该命令的一种方式，包括：第一容器管理组件获取该命令对应的命令描述文件；可选地，命令描述文件可以是客户端生成的JSON(JavaScript Object Notation，JS对象简谱)格式的文件。接着，将该命令描述文件写入该宿主机上的第一指定目录下，以使该shim进程读取该命令描述文件并调用对应的容器运行时执行该命令。
可选地，该第一指定目录可以为前述步骤记载的用于存放该待兼容的容器的元数据的目录。例如，用户针对ID＝001的容器下发命令时，客户端可根据该命令，生成命令描述文件process.json发送至第一容器管理组件。第一容器管理组件可将该process.json放置到宿主机上存放ID＝001的容器的元数据的目录下：
/run/Docker/libContainerd/containerID＝001/Metadataprocess.json
进而，shim进程可从该目录下读取命令描述文件process.json，并根据该process.json中的描述调用容器运行时runC执行命令。
进一步可选地，第一容器管理组件还可在该第一指定目录下写入通信配置信息。基于此，该shim进程可在第一指定目录下读取该通信配置信息，并根据该通信配置信息提供的通信通道返回对目标容器执行该命令的反馈数据。可选地，该第一指定目录可以为前述步骤记载的用于存放该待兼容的容器的元数据的目录。
在一些示例性的实施例中，shim进程可通过命名管道返回对目标容器执行该命令的反馈数据。在这种实施方式中，该通信配置信息可实现为命名管道对应的fifo文件。fifo文件以一种特殊设备文件形式存在于文件系统中，用于在不相关的进程之间交换数据。通常，该fifo文件由客户端提供，shim进程可基于该fifo文件与客户端通信，并向客户端返回执行该命令后的反馈结果，以供用户查看。
本实施例中，第一容器管理组件可查询宿主机上的容器运行目录下的各级子目录，并根据各级子目录的名称，确定运行在宿主机上的由第二容器管理组件创建的容器，作为待兼容的容器。当接收到针对宿主机上的容器下发的命令时，确定该命令指向的目标容器；在确定该目标容器为待兼容的容器时，启动与第二容器管理组件对应的shim进程，并通过该shim进程对目标容器执行该命令。在这种实施方式中，第一容器管理组件实现了对目标容器的兼容，降低了容器的管理过程对容器管理组件和容器之间的兼容性的依赖，有利于提升容器的管理效率。
上述实施例可应用在如下典型的应用场景中：用户通过第二容器管理组件在计算机设备上创建了多个第二容器，并在多个第二容器上发布了不同的业务。同时，用户在计算机上运行第二容器管理组件，以管理多个第二容器。
随着用户的需求发生变化，用户新的业务需要发布在第一容器管理组件创建的第一容器上。于是，用户通过第一容器管理组件在计算机设备上创建了多个第一容器，并在计算机设备上运行第一容器管理组件，以管理多个第一容器。在这种情况下，计算机上仍旧运行着多个第二容器。基于本实施例提供的容器兼容方案，用户可从计算机上卸载第二容器管理组件，并可通过计算机上运行的第一容器管理组件，代为管理第二容器。基于此，用户可在保留已经发布业务的多个第二容器的同时，高效率地管理计算机上的不同容器。
在上述场景中，可选地，第一容器管理组件可实现为Containerd1.0，第一容器可实现为pouch容器或者18版本的Docker容器；第二容器管理组件可实现为Containerd0.2，第二容器可实现为17版本的Docker容器。基于此，实现了通过pouchcontainer容器引擎或者Docker容器引擎的18版本对17版本的Docker容器的动态兼容过程。
以下将结合其他类型的命令，对本申请实施例提供的容器兼容方法进行进一步说明。
图3为本申请又一示例性实施例提供的容器兼容方法的流程示意图，如图3所示，该方法包括：
步骤301、第一容器管理组件查询宿主机上的容器运行目录下的各级子目录，并根据各级子目录的名称，确定运行在宿主机上的由第二容器管理组件创建的容器，作为待兼容的容器。
步骤302、第一容器管理组件从该容器运行目录下获取待兼容的容器的元数据添加至内存中。
步骤303、第一容器管理组件响应针对宿主机上的容器下发的命令，确定该命令指向的目标容器。
步骤304、第一容器管理组件从该命令中确定目标容器的识别标识，并在待兼容的容器的元数据中查询是否存在与目标容器的识别标识匹配的元数据。
步骤305、第一容器管理组件在待兼容的容器的元数据中存在与目标容器的识别标识匹配的元数据时，确定该目标容器为待兼容的容器。
步骤306、若该命令指示停止运行目标容器，则第一容器管理组件根据目标容器的元数据，确定目标容器的init进程的进程标识符。
步骤307、第一容器管理组件根据目标容器的init进程的进程标识符，向目标容器对应的init进程发送进程结束信号。
步骤308、第一容器管理组件监听目标容器的运行状态，并在监听到目标容器停止运行时，结束目标容器的生存周期。
其中步骤301-步骤305的可选实施方式可参考前述实施例的记载，此处不赘述。
在步骤306-308中，可选地，该命令可实现为针对目标容器的stop(停止)命令。第一容器管理组件已将待兼容的容器的元数据添加至内容中，故而，当第一容器管理组件接收到针对待兼容的容器下发的停止运行目标容器的命令时，可从目标容器的元数据中，确定目标容器的init进程的进程标识符(Process Identification，PID)。
例如，第一容器管理组件获取到了目标容器的容器ID，则可在待兼容的容器的元数据中，确定与该容器ID匹配的元数据；接着，从与该容器ID匹配的元数据中确定目标容器的init进程的PID。基于该PID，可直接向宿主机上与该PID对应的init进程发送结束信号。
可选地，在本实施例中，第一容器管理组件可实时监听目标容器的运行状态，并在监听到目标容器停止运行时，结束目标容器的生存周期。
在本实施例中，第一容器管理组件可根据用户停止运行目标容器的命令，结束目标容器的生存周期，实现了对目标容器的生存周期进行兼容，降低了容器的管理过程对容器管理组件和容器之间的兼容性的依赖，有利于提升容器的管理效率。
上述实施例可应用在如下典型的应用场景中：用户通过第二容器管理组件在计算机设备上创建了多个第二容器，并在多个第二容器上发布了不同的业务。
随着用户的需求发生变化，用户希望逐步将计算机上运行的第二容器全部升级为第一容器。于是，用户在计算机设备上运行了第一容器管理组件。
当用户针对原本发布在第二容器上的业务存在重新发布的需求时，用户需中断业务，并通过第一容器管理组件向该业务对应的第二容器发送停止运行命令。此时，第一容器管理组件，可采用上述实施例记载的容器兼容方法，向第二容器的init进程发送停止信号，并在监听到第二容器停止运行时，结束第二容器的生存周期。当用户重新发布业务时，第一容器管理组件可为用户创建第一容器。基于此，在用户无感知的情况下，将承载用户的业务第二容器升级到了第一容器。当所有的第二容器上的业务均被用户重新发布时，实现了将计算机上所有的第二容器升级为第一容器的效果，而这个升级的过程，不需要主动中断用户的业务，避免对用户带来业务上的损失。
在上述场景中，可选地，第一容器管理组件可实现为Containerd1.0，第一容器可实现为pouch容器或者18版本的Docker容器；第二容器管理组件可实现为Containerd0.2，第二容器可实现为17版本的Docker容器。基于此，通过pouchcontainer容器引擎或者Docker容器引擎的18版本实现了对17版本的Docker容器执行停止运行命令。
图4为本申请又一示例性实施例提供的容器兼容方法的流程示意图，如图4所示，该方法包括：
步骤401、第一容器管理组件查询宿主机上的容器运行目录下的各级子目录，并根据各级子目录的名称，确定运行在宿主机上的由第二容器管理组件创建的容器，作为待兼容的容器。
步骤402、第一容器管理组件从该容器运行目录下获取待兼容的容器的元数据添加至内存中。
步骤403、第一容器管理组件响应针对宿主机上的容器下发的命令，确定该命令指向的目标容器。
步骤404、第一容器管理组件从该命令中确定目标容器的识别标识，并在待兼容的容器的元数据中查询是否存在与目标容器的识别标识匹配的元数据。
步骤405、第一容器管理组件在待兼容的容器的元数据中存在与目标容器的识别标识匹配的元数据时，确定该目标容器为待兼容的容器。
步骤406、若该命令指示更新目标容器的配置，则第一容器管理组件获取该命令对应的配置数据。
步骤407、第一容器管理组件对该配置数据进行格式修改，以使目标容器的运行时识别该配置数据。
步骤408、第一容器管理组件调用目标容器的运行时根据格式修改后的配置数据更新目标容器的配置。
其中步骤401-步骤405的可选实施方式可参考前述实施例的记载，此处不赘述。
在步骤406-408中，可选地，该命令可实现为针对目标容器的update(升级)命令。若该命令指示更新目标容器的配置，可由客户端根据用户需要更新的配置生成配置数据，并将该配置数据传递给第一容器管理组件。
可选地，在一些示例性的实施例中，该配置数据可实现为一个runtime-spec的结构体，该结构体中，描述了容器需要更新的具体配置。其中，客户端生成的runtime-spec的结构体的格式，与第一容器管理组件的运行过时能够识别的格式相匹配，但是与第二容器管理组件对应的运行时能够识别的格式不匹配。因此，在本实施例中，可对客户端传过来的runtime-spec的结构体进行格式修改。
例如，当第一容器管理组件为pouchcontainer容器引擎中的Containerd的1.0版本时，客户端生成的结构体为runtime-spec1.0格式；当第二容器管理组件为Docker容器引擎中的Containerd的0.2版本时，Containerd的0.2版本对应的运行时能够识别的结构体为runtime-spec0.2的格式。因此，为了使Containerd的0.2版本的运行时能够识别第一容器管理组件的客户端生成的配置数据，可预先将runtime-spec1.0的格式修改为runtime-spec0.2的格式。
在本实施例中，第一容器管理组件在接收到更新目标容器的配置的命令时，对命令对应的配置数据的格式进行修改，并调用目标容器的运行时根据格式修改后的配置数据更新目标容器的配置，实现了对目标容器的配置更新的过程进行兼容，降低了容器的管理过程对容器管理组件和容器之间的兼容性的依赖，有利于提升容器的管理效率。
图5a为本申请一示例性实施例提供的容器升级方法的流程示意图，如图5a所示，该方法包括：
步骤501、响应宿主机上的第二容器管理组件升级为第一容器管理组件的操作，第一容器管理组件在宿主机上确定由二容器管理组件创建的容器，作为待升级的容器。
步骤503、第一容器管理组件根据设定的容器兼容逻辑对待升级的容器进行管理，以接收针对待升级的容器下发的命令。
步骤503、若命令指示重新发布待升级的容器上的应用任务，则第一容器管理组件创建用于承载重新发布的应用任务的容器，以替换待升级的容器。
在本实施例中，第一容器管理组件和第二容器管理组件可以是不同容器引擎下的容器管理组件，也可以是同一容器引擎下的不同版本的容器管理组件，本实施例对此不做限制。
宿主机上的第二容器管理组件升级为第一容器管理组件后，第二容器管理组件创建的容器仍运行在宿主机上。为便于第一容器管理组件对宿主机上的容器进行管理，可将第二容器管理组件创建的容器进行升级。本实施例为描述方便，将宿主机上运行的由第二容器管理组件创建的容器描述为待升级的容器。
在对该待升级的容器进行升级的过程中，为确保发布在待升级的容器上的应用任务不被中断，第一容器管理组件可按照设定的容器兼容逻辑对待升级的容器进行管理，以接收针对待升级的容器下发的命令。其中，第一容器管理组件按照设定的容器兼容逻辑对待升级的容器进行管理的可选实施方式可参考前述各实施例的记载，此处不再赘述。
可选地，当针对该待升级的容器下发的命令指示重新发布该待升级的容器上的应用任务时，第一容器管理组件可创建新的容器，该新的容器用于替代该待升级的容器来承载重新发布的应用任务。应当理解，基于本方案，当宿主机上所有待升级的容器上发布的应用任务均重新发布时，宿主机上的所有待升级的容器均可被升级为第一容器管理组件创建的新的容器。
在本实施例中，宿主机上的第二容器管理组件升级为第一容器管理组件后，第一容器管理组件可根据设定的容器兼容逻辑对该待升级的容器进行管理。在管理的过程中，当待升级的容器上发布的应用任务被重新发布时，第一容器管理组件可为重新发布的应用任务创建新的容器，进而，实现了容器的平滑升级。在这种升级的过程中，不需要主动中断用户的发布的应用任务，降低了对用户造成的损失。
需要说明的是，图2、图3、图4以及图5a对应的实施例可单独执行，也可以组合执行，本实施例不做限制。以下将结合图5b,以一个具体的应用场景，对图2、图3、图4以及图5a对应的实施例结合得到的技术方案进行说明。
在一种典型的应用场景中，第一容器管理组件可实现为pouchcontainer容器引擎所使用的Containerd1.0或18版本的Docker容器引擎所使用的Containerd1.0，第二容器管理组件为17版本的Docker容器引擎所使用的Containerd0.2。
在一种业务需求下，用户在第一计算设备上运行了Docker容器引擎的17版本，并通过Containerd0.2在第一计算设备上创建了多个17版本的Docker容器(以下简称旧版本Docker容器)；接着，在多个旧版本Docker容器上发布了不同的业务，并通过Containerd0.2管理多个旧版本Docker容器。
随着用户的业务需求发生变化，用户希望逐步将第一计算设备上运行的旧版本Docker容器全部升级为pouch容器。于是，用户在第一计算设备设备上运行了pouchcontainer容器引擎，基于Containerd1.0创建了pouch容器，并卸载了Containerd0.2，以释放第一计算设备的内存。
如图5b所示，在这种情况下，第一计算设备上仍旧运行着多个旧版本Docker容器。基于本实施例提供的容器兼容方案，用户可通过第一计算设备上运行的Containerd1.0，查找第一计算设备上运行的旧版本Docker容器，并将旧版本Docker容器的元数据添加至内存中。
当Containerd1.0接到针对某一旧版本Docker容器的exec命令时，基于exec命令对应的兼容逻辑，可将exec命令对应的描述文件和fifo文件放在“/run/Docker/libContainerd/containerID/”目录下，并启动Containerd0.2的shim0.2进程。进而，该shim0.2进程可读取该exec命令对应的描述文件，调用对应的runC1.0-rc2对该旧版本Docker容器执行exec命令，并通过fifo文件提供的通信通道返回执行exec命令的结果。
当用户存在修改第一计算设备上的某一旧版本Docker容器的配置的需求时，可通过pouchcontainer容器引擎的客户端输入配置需求。pouchcontainer容器引擎的客户端根据用户输入的配置需求生成runtime-spec1.0格式的结构体数据，并将runtime-spec1.0发送给Containerd1.0。Containerd1.0基于update命令对应的兼容逻辑，将runtime-spec1.0修改为runtime-spec0.2，并将runtime-spec0.2发送给该旧版本Docker容器对应的runC1.0-rc2，以使runC1.0-rc2对该旧版本Docker容器的配置进行更新。
当用户针对原本发布在某一旧版本Docker容器上的业务存在重新发布的需求时，用户可通过pouchcontainer容器引擎的客户端中断业务，并通过pouchcontainer容器引擎的客户端发送针对该旧版本Docker容器的stop命令。pouchcontainer容器引擎的客户端将stop命令发送给Containerd1.0。Containerd1.0，可基于stop命令对应的兼容逻辑，确定该旧版本Docker容器的init进程的PID，并向该旧版本Docker容器的init进程发送停止信号。与此同时，Containerd1.0可在监听到该旧版本Docker容器停止运行时，结束该旧版本Docker容器的生存周期，从第一计算设备上删掉该该旧版本Docker容器。
当用户重新发布业务时，Containerd1.0可为用户创建pouch容器来承载用户重新发布的业务。基于此，在用户无感知的情况下，将承载用户业务旧版本Docker容器升级到了pouch容器。当第一计算设备上所有的旧版本Docker容器上的业务均被用户重新发布时，即可实现将第一计算设备上所有的旧版本Docker容器升级为pouch容器的技术效果，而这个升级的过程，不需要主动中断用户的业务，可避免对用户带来业务上的损失。
在另一种业务需求下，用户在第二计算设备上运行了Docker容器引擎的17版本，并通过Containerd0.2在第二计算设备上创建了多个17版本的Docker容器(以下简称旧版本Docker容器)；接着，在多个旧版本Docker容器上发布了不同的业务，并通过Containerd0.2管理多个旧版本Docker容器。
随着用户的业务需求发生变化，用户希望逐步将第二计算设备上运行的旧版本Docker容器全部升级为新版本Docker容器。于是，用户在第二计算设备设备上运行了18版本的Docker容器引擎，基于Containerd1.0创建了新版本Docker容器，并卸载了Containerd0.2，以释放第二计算设备的内存。
如图5c所示，在这种情况下，第二计算设备上仍旧运行着多个旧版本Docker容器。基于上述各个实施例提供的容器兼容方案，用户可通过第二计算设备上运行的Containerd1.0，兼容旧版本Docker容器，不再赘述。
当用户重新发布业务时，Containerd1.0可为用户创建新版本Docker容器来承载用户重新发布的业务。基于此，在用户无感知的情况下，将承载用户业务旧版本Docker容器升级到了新版本Docker容器。当第二计算设备上所有的旧版本Docker容器上的业务均被用户重新发布时，即可实现将第二计算设备上所有的旧版本Docker容器升级为新版本Docker容器的技术效果，而这个升级的过程，不需要主动中断用户的业务，可避免对用户带来业务上的损失。
需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤201至步骤204的执行主体可以为设备A；又比如，步骤201和202的执行主体可以为设备A，步骤203的执行主体可以为设备B；等等。
另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如201、202等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。
图6是本申请一示例性实施例提供的容器兼容装置的结构示意图，如图6所示，该装置包括：命令获取模块601、命令兼容模块602。
命令获取模块601，用于响应针对宿主机上的容器下发的命令，确定该命令指向的目标容器；命令兼容模块602，用于在确定该目标容器为待兼容的容器时，根据该命令对应的容器兼容逻辑，对该目标容器执行该命令。
进一步可选地，如图6所示，该装置还包括：容器查询模块603，用于：查询该宿主机上的容器运行目录下的各级子目录；根据该各级子目录的名称，确定运行在该宿主机上的由第二容器管理组件创建的容器，作为该待兼容的容器；从该容器运行目录下获取该待兼容的容器的元数据添加至内存中。
进一步可选地，命令兼容模块602还用于：从该命令中确定该目标容器的识别标识；在该待兼容的容器的元数据中查询是否存在与该目标容器的识别标识匹配的元数据，若存在，则确定该目标容器为待兼容的容器。
进一步可选地，命令兼容模块602在根据该命令对应的容器兼容逻辑，对该目标容器执行该命令时，具体用于：启动与该第二容器管理组件对应的shim进程；通过该shim进程对该目标容器执行该命令。
进一步可选地，命令兼容模块602在通过该shim进程对该目标容器执行该命令时，具体用于：获取该命令对应的命令描述文件；将该命令描述文件写入该宿主机上的第一指定目录下，以使该shim进程读取该命令描述文件并调用对应的容器运行时执行该命令。
进一步可选地，命令兼容模块602还用于：在该第一指定目录下写入通信配置信息，以使该shim进程读取该通信配置信息并根据该通信配置信息提供的通信通道返回对该目标容器执行该命令的反馈数据。
进一步可选地，命令兼容模块602在根据该命令对应的容器兼容逻辑，对该目标容器执行该命令时，具体用于：若该命令指示停止运行该目标容器，则根据该目标容器的元数据，确定该目标容器的init进程的进程标识符；根据该目标容器的init进程的进程标识符，向该目标容器对应的init进程发送进程结束信号。
进一步可选地，命令兼容模块602还用于：监听该目标容器的运行状态，并在监听到该目标容器停止运行时，结束该目标容器的生存周期。
进一步可选地，命令兼容模块602在根据该命令对应的容器兼容逻辑，对该目标容器执行该命令时，具体用于：若该命令指示更新该目标容器的配置，则获取该命令对应的配置数据；对该配置数据进行格式修改，以使该目标容器的运行时识别该配置数据；调用该目标容器的运行时根据格式修改后的配置数据更新该目标容器的配置。
进一步可选地，该第一容器管理组件为Containerd的1.0版本，该第二容器管理组件为Containerd的0.2版本。
本申请实施例提供的容器兼容装置中，第一容器管理组件在接收到针对宿主机上的容器下发的命令时，确定该命令指向的目标容器；在确定该目标容器为待兼容的容器时，可根据该命令对应的容器兼容逻辑对目标容器执行该命令。在这种实施方式中，第一容器管理组件实现了对目标容器的兼容，降低了容器的管理过程对容器管理组件和容器之间的兼容性的依赖，有利于提升容器的管理效率。
图7是本申请一示例性实施例提供的容器兼容设备的结构示意图，如图7所示，该容器兼容设备包括：存储器701以及处理器702。
存储器701，用于存储计算机程序，并可被配置为存储其它各种数据以支持在容器兼容设备上的操作。这些数据的示例包括用于在容器兼容设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。
处理器702，与存储器701耦合，用于执行存储器701中的计算机程序，以用于：响应针对宿主机上的容器下发的命令，确定该命令指向的目标容器；在确定该目标容器为待兼容的容器时，根据该命令对应的容器兼容逻辑，对该目标容器执行该命令。
进一步可选地，处理器702还用于：查询该宿主机上的容器运行目录下的各级子目录；根据该各级子目录的名称，确定运行在该宿主机上的由第二容器管理组件创建的容器，作为该待兼容的容器；从该容器运行目录下获取该待兼容的容器的元数据添加至内存中。
进一步可选地，处理器702还用于：从该命令中确定该目标容器的识别标识；在该待兼容的容器的元数据中查询是否存在与该目标容器的识别标识匹配的元数据，若存在，则确定该目标容器为待兼容的容器。
进一步可选地，处理器702在根据该命令对应的容器兼容逻辑，对该目标容器执行该命令时，具体用于：启动与该第二容器管理组件对应的shim进程；通过该shim进程对该目标容器执行该命令。
进一步可选地，处理器702在通过该shim进程对该目标容器执行该命令时，具体用于：获取该命令对应的命令描述文件；将该命令描述文件写入该宿主机上的第一指定目录下，以使该shim进程读取该命令描述文件并调用对应的容器运行时执行该命令。
进一步可选地，处理器702还用于：在该第一指定目录下写入通信配置信息，以使该shim进程读取该通信配置信息并根据该通信配置信息提供的通信通道返回对该目标容器执行该命令的反馈数据。
进一步可选地，处理器702在根据该命令对应的容器兼容逻辑，对该目标容器执行该命令时，具体用于：若该命令指示停止运行该目标容器，则根据该目标容器的元数据，确定该目标容器的init进程的进程标识符；根据该目标容器的init进程的进程标识符，向该目标容器对应的init进程发送进程结束信号。
进一步可选地，处理器702还用于：监听该目标容器的运行状态，并在监听到该目标容器停止运行时，结束该目标容器的生存周期。
进一步可选地，处理器702在根据该命令对应的容器兼容逻辑，对该目标容器执行该命令时，具体用于：若该命令指示更新该目标容器的配置，则获取该命令对应的配置数据；对该配置数据进行格式修改，以使该目标容器的运行时识别该配置数据；调用该目标容器的运行时根据格式修改后的配置数据更新该目标容器的配置。
进一步可选地，该第一容器管理组件为Containerd的1.0版本，该第二容器管理组件为Containerd的0.2版本。
进一步，如图7所示，该容器兼容设备还包括：通信组件703、显示器704、电源组件705、音频组件706等其它组件。图7中仅示意性给出部分组件，并不意味着容器兼容设备只包括图7所示组件。
本实施例中，第一容器管理组件在接收到针对宿主机上的容器下发的命令时，确定该命令指向的目标容器；在确定该目标容器为待兼容的容器时，可根据该命令对应的容器兼容逻辑对目标容器执行该命令。在这种实施方式中，第一容器管理组件实现了对目标容器的兼容，降低了容器的管理过程对容器管理组件和容器之间的兼容性的依赖，有利于提升容器的管理效率。
相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由容器兼容设备执行的各步骤。
图8是本申请一示例性实施例提供的容器升级设备的结构示意图，如图8所示，该容器兼容设备包括：存储器801以及处理器802。
存储器801，用于存储计算机程序，并可被配置为存储其它各种数据以支持在容器兼容设备上的操作。这些数据的示例包括用于在容器兼容设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。
处理器802，与存储器801耦合，用于执行存储器801中的计算机程序，以用于：响应宿主机上的第二容器管理组件升级为第一容器管理组件的操作，所述第一容器管理组件在所述宿主机上确定由所述二容器管理组件创建的容器，作为待升级的容器；所述第一容器管理组件根据设定的容器兼容逻辑对所述待升级的容器进行管理，以接收针对所述待升级的容器下发的命令；若所述命令指示重新发布所述待升级的容器上的应用任务，则所述第一容器管理组件创建用于承载重新发布的所述应用任务的容器，以替换所述待升级的容器。
进一步，如图8所示，该容器兼容设备还包括：通信组件803、显示器804、电源组件805、音频组件806等其它组件。图8中仅示意性给出部分组件，并不意味着容器兼容设备只包括图8所示组件。
本实施例中，宿主机上的第二容器管理组件升级为第一容器管理组件后，第一容器管理组件可根据设定的容器兼容逻辑对该待升级的容器进行管理。在管理的过程中，当待升级的容器上发布的应用任务被重新发布时，第一容器管理组件可为重新发布的应用任务创建新的容器，进而，实现了容器的平滑升级。在这种升级的过程中，不需要主动中断用户的发布的应用任务，降低了对用户造成的损失。
相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由容器升级设备执行的各步骤。
在图7以及图8对应的实施例中，存储器，可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。
在图7以及图8对应的实施例中，通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件可基于近场通信(NFC)技术、射频识别(RFID)技术、红外数据协会(IrDA)技术、超宽带(UWB)技术、蓝牙(BT)技术和其他技术来实现。
在图7以及图8对应的实施例中，显示器包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。该触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与该触摸或滑动操作相关的持续时间和压力。
在图7以及图8对应的实施例中，电源组件，用于为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。
Claims (15)
1.一种容器兼容方法，其特征在于，包括：
第一容器管理组件响应针对宿主机上的容器下发的命令，确定所述命令指向的目标容器；
在确定所述目标容器为待兼容的容器时，根据所述命令对应的容器兼容逻辑，对所述目标容器执行所述命令；
所述方法还包括：查询所述宿主机上的容器运行目录下的各级子目录；
根据所述各级子目录的名称，确定运行在所述宿主机上的由第二容器管理组件创建的容器，作为所述待兼容的容器；
从所述容器运行目录下获取所述待兼容的容器的元数据添加至内存中。
2.根据权利要求1所述的方法，其特征在于，还包括：
从所述命令中确定所述目标容器的识别标识；
在所述待兼容的容器的元数据中查询是否存在与所述目标容器的识别标识匹配的元数据，若存在，则确定所述目标容器为待兼容的容器。
3.根据权利要求1所述的方法，其特征在于，根据所述命令对应的容器兼容逻辑，对所述目标容器执行所述命令，包括：
启动与所述第二容器管理组件对应的shim进程；
通过所述shim进程对所述目标容器执行所述命令。
4.根据权利要求3所述的方法，其特征在于，通过所述shim进程对所述目标容器执行所述命令，包括：
获取所述命令对应的命令描述文件；
将所述命令描述文件写入所述宿主机上的第一指定目录下，以使所述shim进程读取所述命令描述文件并调用对应的容器运行时执行所述命令。
5.根据权利要求4所述的方法，其特征在于，还包括：
在所述第一指定目录下写入通信配置信息，以使所述shim进程读取所述通信配置信息并根据所述通信配置信息提供的通信通道返回对所述目标容器执行所述命令的反馈数据。
6.根据权利要求1所述的方法，其特征在于，根据所述命令对应的容器兼容逻辑，对所述目标容器执行所述命令，包括：
若所述命令指示停止运行所述目标容器，则根据所述目标容器的元数据，确定所述目标容器的init进程的进程标识符；
根据所述目标容器的init进程的进程标识符，向所述目标容器对应的init进程发送进程结束信号。
7.根据权利要求6所述的方法，其特征在于，还包括：
监听所述目标容器的运行状态，并在监听到所述目标容器停止运行时，结束所述目标容器的生存周期。
8.根据权利要求1所述的方法，其特征在于，根据所述命令对应的容器兼容逻辑，对所述目标容器执行所述命令，包括：
若所述命令指示更新所述目标容器的配置，则获取所述命令对应的配置数据；
对所述配置数据进行格式修改，以使所述目标容器的运行时识别所述配置数据；
调用所述目标容器的运行时根据格式修改后的配置数据更新所述目标容器的配置。
9.根据权利要求1-8任一项所述的方法，其特征在于，所述第一容器管理组件为Containerd的1.0版本，所述第二容器管理组件为Containerd的0.2版本。
10.一种容器兼容装置，其特征在于，包括：
命令获取模块，用于响应针对宿主机上的容器下发的命令，确定所述命令指向的目标容器；
命令兼容模块，用于在确定所述目标容器为待兼容的容器时，根据所述命令对应的容器兼容逻辑，对所述目标容器执行所述命令；
容器查询模块，用于：查询所述宿主机上的容器运行目录下的各级子目录；根据所述各级子目录的名称，确定运行在所述宿主机上的由第二容器管理组件创建的容器，作为所述待兼容的容器；从所述容器运行目录下获取所述待兼容的容器的元数据添加至内存中。
11.一种容器升级方法，其特征在于，包括：
响应宿主机上的第二容器管理组件升级为第一容器管理组件的操作，所述第一容器管理组件在所述宿主机上确定由所述第二容器管理组件创建的容器，作为待升级的容器；
所述第一容器管理组件根据设定的容器兼容逻辑对所述待升级的容器进行管理，以接收针对所述待升级的容器下发的命令；
若所述命令指示重新发布所述待升级的容器上的应用任务，则所述第一容器管理组件创建用于承载重新发布的所述应用任务的容器，以替换所述待升级的容器；
其中，在所述宿主机上确定由所述第二容器管理组件创建的容器，作为待升级的容器，包括：查询所述宿主机上的容器运行目录下的各级子目录；根据所述各级子目录的名称，确定运行在所述宿主机上的由第二容器管理组件创建的容器，作为所述待升级的容器。
12.一种容器兼容设备，其特征在于，包括：存储器和处理器；
所述存储器用于存储一条或多条计算机指令；
所述处理器用于执行所述一条或多条计算机指令以用于：响应针对宿主机上的容器下发的命令，确定所述命令指向的目标容器；在确定所述目标容器为待兼容的容器时，根据所述命令对应的容器兼容逻辑，对所述目标容器执行所述命令；以及，查询所述宿主机上的容器运行目录下的各级子目录；根据所述各级子目录的名称，确定运行在所述宿主机上的由第二容器管理组件创建的容器，作为所述待兼容的容器；从所述容器运行目录下获取所述待兼容的容器的元数据添加至内存中。
13.一种存储有计算机程序的计算机可读存储介质，其特征在于，计算机程序被执行时能够实现权利要求1-9任一项所述的容器兼容方法。
14.一种容器升级设备，其特征在于，包括：存储器和处理器；
所述存储器用于存储一条或多条计算机指令；
所述处理器用于执行所述一条或多条计算机指令以用于：响应宿主机上的第二容器管理组件升级为第一容器管理组件的操作，在所述宿主机上确定由所述第二容器管理组件创建的容器，作为待升级的容器；根据设定的容器兼容逻辑对所述待升级的容器进行管理，以接收针对所述待升级的容器下发的命令；若所述命令指示重新发布所述待升级的容器上的应用任务，则创建用于承载重新发布的所述应用任务的容器，以替换所述待升级的容器；
其中，所述处理器在所述宿主机上确定由所述第二容器管理组件创建的容器，作为待升级的容器时，具体用于：查询所述宿主机上的容器运行目录下的各级子目录；根据所述各级子目录的名称，确定运行在所述宿主机上的由第二容器管理组件创建的容器，作为所述待升级的容器。
15.一种存储有计算机程序的计算机可读存储介质，其特征在于，计算机程序被执行时能够实现权利要求11所述的容器升级方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910430238.0A CN111984280B (zh) | 2019-05-22 | 2019-05-22 | 容器兼容、升级方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910430238.0A CN111984280B (zh) | 2019-05-22 | 2019-05-22 | 容器兼容、升级方法、装置、设备及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111984280A CN111984280A (zh) | 2020-11-24 |
| CN111984280B true CN111984280B (zh) | 2024-05-17 |
Family
ID=73437198
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910430238.0A Active CN111984280B (zh) | 2019-05-22 | 2019-05-22 | 容器兼容、升级方法、装置、设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111984280B (zh) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112882793B (zh) * | 2021-02-19 | 2023-03-24 | 杭州谐云科技有限公司 | 一种容器资源共享的方法和系统 |
| CN113296807B (zh) * | 2021-05-12 | 2023-10-31 | 阿里巴巴新加坡控股有限公司 | 数据更新方法 |
| CN113220645B (zh) * | 2021-05-31 | 2022-07-05 | 技德技术研究所(武汉)有限公司 | 一种Linux兼容Android的文件显示方法及装置 |
| CN113590146B (zh) * | 2021-06-04 | 2023-10-27 | 聚好看科技股份有限公司 | 服务器及容器升级方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107341073A (zh) * | 2017-06-08 | 2017-11-10 | 北京优帆科技有限公司 | 一种实现容器主机兼容虚拟主机镜像文件的方法及装置 |
| CN107608757A (zh) * | 2017-08-29 | 2018-01-19 | 华为技术有限公司 | 一种基于容器的隔离处理方法及相关设备 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2990405A1 (en) * | 2015-06-22 | 2016-12-29 | Draios Inc. | Monitoring of applications isolated in containers |
| US9898354B2 (en) * | 2016-03-21 | 2018-02-20 | Microsoft Technology Licensing, Llc | Operating system layering |
-
2019
- 2019-05-22 CN CN201910430238.0A patent/CN111984280B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107341073A (zh) * | 2017-06-08 | 2017-11-10 | 北京优帆科技有限公司 | 一种实现容器主机兼容虚拟主机镜像文件的方法及装置 |
| CN107608757A (zh) * | 2017-08-29 | 2018-01-19 | 华为技术有限公司 | 一种基于容器的隔离处理方法及相关设备 |
Non-Patent Citations (1)
| Title |
|---|
| 基于容器的Web运行环境轻量级虚拟化方法;肖伟民;邓浩江;胡琳琳;郭志川;;计算机应用研究;20171017(第06期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111984280A (zh) | 2020-11-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111984280B (zh) | 容器兼容、升级方法、装置、设备及存储介质 | |
| JP7018463B2 (ja) | アプリケーションコンテナを使用するコードおよび従属データの送達の管理 | |
| CN112019475B (zh) | 无服务器架构下的资源访问方法、设备、系统及存储介质 | |
| US8370826B2 (en) | Automatically managing versioning of mashup widgets | |
| CN105468362B (zh) | 应用部署方法和云计算系统 | |
| US10956191B2 (en) | Systems and methods for customizing and programming a cloud-based management server | |
| CN108984170B (zh) | H5页面多语言渲染方法及装置 | |
| US10977062B2 (en) | System for starting virtual machine using mirror image file stored in units of a distributed block storage system mapped to units of a logical volume | |
| CN105335187B (zh) | 一种应用的处理方法及装置 | |
| US20080295110A1 (en) | Framework for Startup of Local Instance of Remote Application | |
| KR20130069555A (ko) | 가상 애플리케이션 확장 포인트 | |
| US20130194630A1 (en) | Management system, image forming apparatus, management system control method, and image forming apparatus control method | |
| US10715603B2 (en) | Systems and methods for sharing application data between isolated applications executing on one or more application platforms | |
| US9965299B2 (en) | Information processing apparatus, method for controlling the same, and storage medium | |
| US20230205503A1 (en) | Method for dynamically integrating application programs, and software system and machine using the same | |
| CN110688174A (zh) | 容器启动方法、存储介质和电子设备 | |
| JP2015180991A (ja) | 画像形成装置、画像形成装置の制御方法およびプログラム | |
| CN114168111A (zh) | 组件化路由实现方法、设备、产品及存储介质 | |
| CN114385164A (zh) | 页面生成与渲染方法、装置、电子设备及存储介质 | |
| CN103984621B (zh) | 日志分离方法和系统 | |
| US10817281B2 (en) | Packaged application resources for mobile applications | |
| CN111340705B (zh) | 一种拼图软件的应用方法、装置及系统 | |
| US10831538B2 (en) | Optimized management of application resources for mobile applications | |
| JP2021184235A5 (zh) | ||
| CN110968401A (zh) | 基于Quartz的任务调度方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |