CN107515783B - 基于应用容器集群工具的应用容器管控方法及装置 - Google Patents

基于应用容器集群工具的应用容器管控方法及装置 Download PDF

Info

Publication number
CN107515783B
CN107515783B CN201610427672.XA CN201610427672A CN107515783B CN 107515783 B CN107515783 B CN 107515783B CN 201610427672 A CN201610427672 A CN 201610427672A CN 107515783 B CN107515783 B CN 107515783B
Authority
CN
China
Prior art keywords
application container
node
cluster
container
memory occupancy
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
Application number
CN201610427672.XA
Other languages
English (en)
Other versions
CN107515783A (zh
Inventor
阚俊宝
闵庆欢
姜晓东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Cloud Computing Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201610427672.XA priority Critical patent/CN107515783B/zh
Publication of CN107515783A publication Critical patent/CN107515783A/zh
Application granted granted Critical
Publication of CN107515783B publication Critical patent/CN107515783B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G06F9/5088—Techniques for rebalancing the load in a distributed system involving task migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5022—Workload threshold

Abstract

本发明揭示了一种基于应用容器集群工具的应用容器管控方法，其中，所述方法包括：接收来自用户端或应用容器集群工具的输入信息；根据输入信息的内容，调用匹配的预设规则控制应用容器。本发明的基于应用容器集群工具的应用容器管控方法及装置，实现了无需进行命令行操作即可对应用容器进行管控，效率高，且有效地降低了出错的可能，可靠性高。

Description

基于应用容器集群工具的应用容器管控方法及装置
技术领域
本发明涉及计算机领域，尤其是涉及一种基于应用容器集群工具的应用容器管控方法及装置。
背景技术
当前所有云计算主机都采用虚拟化技术实现，其基本原理是将多个高性能的物理主机进行虚拟，实现资源在不同物理平台上的统一，通过资源隔离技术将一个强大的虚拟平台资源切分成多个虚拟主机，每个主机即虚拟为一个服务器。这种虚拟化技术是系统级别的资源虚拟化，即每虚拟出一台主机都需要在其上面安装操作系统。云时代采用标配硬件来降低成本，采用虚拟化手段来满足用户按需分配的资源需求以及保证可用性和隔离性，然而无论是KVM还是Xen都会在资源上造成浪费。
如果采用应用容器引擎，可为用户提供了高效运行环境而非操作系统，开发者可以打包他们的应用以及依赖包至一个可移植的容器中，然后发布到任何流行的Linux机器上，当然，也可以实现虚拟化。然而，当前在对应用容器进行管控时，均需要用户在容器引擎客户端进行命令行操作，其工作效率、可靠性均较低。
发明内容
本发明的目的在于提供一种基于应用容器集群工具的应用容器管控方法及装置。
为实现上述发明目的之一，本发明一实施方式提供了一种基于应用容器集群工具的应用容器管控方法，所述方法包括：
接收来自用户端或应用容器集群工具的输入信息；
根据输入信息的内容，调用匹配的预设规则控制应用容器。
作为本发明一实施方式的进一步改进，所述“根据输入信息的内容，调用匹配的预设规则控制应用容器”步骤，包括：
若接收到的输入信息为应用容器创建请求和创建参数，则调用预设的应用容器创建规则进行处理：
将所述创建参数套用至代码模板中，生成应用文档；
将所述应用文档作为参数调用应用容器集群工具创建镜像文件；
根据所述镜像文件调用应用容器集群工具创建在集群节点下的应用容器。
作为本发明一实施方式的进一步改进，所述创建参数包括：待部署应用的运行环境、容器配置要求，以及待部署应用的网络地址。
作为本发明一实施方式的进一步改进，所述方法还包括：
将所述创建参数存储，并与对应的应用容器信息关联。
作为本发明一实施方式的进一步改进，所述方法包括：
若所述创建参数包括容器创建时间，则在当前时间到达所述容器创建时间时，调用预设的应用容器创建规则创建应用容器。
作为本发明一实施方式的进一步改进，所述方法还包括：
判断应用容器创建请求是否可执行，其中，判断是否可执行的维度至少包括创建应用容器的容器引擎是否能提供达到所述容器配置要求的环境；
若是，则调用预设的应用容器创建规则创建应用容器。
作为本发明一实施方式的进一步改进，所述代码模板中包括资源监控配置，以在创建的应用容器运行时获得应用容器对应的集群节点的运行负荷信息。
作为本发明一实施方式的进一步改进，“根据输入信息的内容，调用匹配的预设规则控制应用容器”步骤，包括：
若接收的输入信息为应用容器集群工具传输的集群节点中监控程序上报的节点运行负荷信息；
则调用预设的应用容器迁移规则进行处理，将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点。
作为本发明一实施方式的进一步改进，“将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点”具体包括：
将节点运行负荷超过第一预设阈值的集群节点中的至少一个应用容器，迁移至节点运行负荷未超过第二预设阈值的集群节点中。
作为本发明一实施方式的进一步改进，“将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点”具体包括：
接收每个应用容器的容器运行负荷信息；
将节点运行负荷超过第一预设阈值的集群节点中容器运行负荷最小的应用容器，迁移至节点运行负荷未超过第二预设阈值且完成迁移后节点负荷未超过第一预设阈值的集群节点中。
作为本发明一实施方式的进一步改进，通过集群节点的CPU使用率判断所述节点运行负荷；通过应用容器的CPU使用率判断容器运行负荷。
作为本发明一实施方式的进一步改进，通过集群节点的内存占用率判断所述节点运行负荷；通过应用容器的内存占用率判断容器运行负荷。
作为本发明一实施方式的进一步改进，所述节点运行负荷信息包括节点的CPU使用率和内存占用率，“将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点”具体包括：
接收每个应用容器的CPU使用率和内存占用率；
当某一集群节点的CPU使用率超过集群节点的第一CPU使用率阈值时，将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值的另一集群节点中；
当某一集群节点的内存占用率超过集群节点的第一内存占用率阈值时，将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值的另一集群节点中；
当某一集群节点的CPU使用率超过集群节点的CPU使用率阈值，且该集群节点的内存占用率超过集群节点的内存占用率阈值时，先将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值的另一集群节点中；若迁移后的该集群节点的内存占用率仍超过集群节点的内存占用率阈值，则将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值的另一集群节点中。
作为本发明一实施方式的进一步改进，所述节点运行负荷信息包括节点的CPU使用率和内存占用率，“将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点”具体包括：
接收每个应用容器的CPU使用率和内存占用率；
当某一集群节点的CPU使用率超过集群节点的第一CPU使用率阈值时，将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一集群节点中；
当某一集群节点的内存占用率超过集群节点的第一内存占用率阈值时，将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存率预设阈值的另一集群节点中；
当某一集群节点的CPU使用率超过集群节点的CPU使用率阈值，且该集群节点的内存占用率超过集群节点的内存占用率阈值时，先将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一集群节点中；若迁移后的该集群节点的内存占用率仍超过集群节点的内存占用率阈值，则将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存占用率阈值的另一集群节点中。
作为本发明一实施方式的进一步改进，其特征在于，根据输入信息的内容，调用匹配的预设规则控制应用容器”步骤，包括：
若接收到的输入信息为应用容器删除请求和请求删除的应用容器名，则调用预设的应用容器删除规则进行处理：
根据请求删除的应用容器名查询对应的应用容器是否存在；
若是，判断与请求删除的应用容器名对应的应用容器的运行状态是否为写状态；
若否，则调用应用容器集群工具删除与请求删除的应用容器名对应的应用容器。
作为本发明一实施方式的进一步改进，“根据输入信息的内容，调用匹配的预设规则控制应用容器”步骤，包括：
根据请求删除的应用容器名查询对应的应用容器是否存在；
若是，判断与请求删除的应用容器名对应的应用容器的运行状态是否为写状态；
若否，则调用应用容器集群工具删除与请求删除的应用容器名对应的应用容器；
将与请求删除的应用容器名对应的创建参数删除或标注。
为实现上述发明目的之一，本发明一实施方式提供了一种基于应用容器集群工具的应用容器管控装置，所述装置包括：
通信模块，用于接收来自用户端或应用容器集群工具的输入信息；
控制模块，用于根据输入信息的内容，调用匹配的预设规则控制应用容器。
作为本发明一实施方式的进一步改进，所述控制模块用于：
若接收到的输入信息为应用容器创建请求和创建参数，则调用预设的应用容器创建规则进行处理：
将所述创建参数套用至代码模板中，生成应用文档；
将所述应用文档作为参数调用应用容器集群工具创建镜像文件；
根据所述镜像文件调用应用容器集群工具创建在集群节点下的应用容器。
作为本发明一实施方式的进一步改进，所述创建参数包括：待部署应用的运行环境、容器配置要求，以及待部署应用的网络地址。
作为本发明一实施方式的进一步改进，所述控制模块还用于：
将所述创建参数存储，并与对应的应用容器信息关联。
作为本发明一实施方式的进一步改进，所述控制模块用于：
若所述创建参数包括容器创建时间，则在当前时间到达所述容器创建时间时，调用预设的应用容器创建规则创建应用容器。
作为本发明一实施方式的进一步改进，所述控制模块用于：
判断应用容器创建请求是否可执行，其中，判断是否可执行的维度至少包括创建应用容器的容器引擎是否能提供达到所述容器配置要求的环境；
若是，则调用预设的应用容器创建规则创建应用容器。
作为本发明一实施方式的进一步改进，所述代码模板中包括资源监控配置，以在创建的应用容器运行时获得应用容器对应的集群节点的运行负荷信息。
作为本发明一实施方式的进一步改进，所述控制模块用于：
若接收的输入信息为应用容器集群工具传输的集群节点中监控程序上报的节点运行负荷信息；
则调用预设的应用容器迁移规则进行处理，将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点。
作为本发明一实施方式的进一步改进，所述控制模块用于：
将节点运行负荷超过第一预设阈值的集群节点中的至少一个应用容器，迁移至节点运行负荷未超过第二预设阈值的集群节点中。
作为本发明一实施方式的进一步改进，所述通信模块用于接收每个应用容器的容器运行负荷信息；所述控制模块用于：
将节点运行负荷超过第一预设阈值的集群节点中容器运行负荷最小的应用容器，迁移至节点运行负荷未超过第二预设阈值且完成迁移后节点负荷未超过第一预设阈值的集群节点中。
作为本发明一实施方式的进一步改进，通过集群节点的CPU使用率判断所述节点运行负荷；通过应用容器的CPU使用率判断容器运行负荷。
作为本发明一实施方式的进一步改进，通过集群节点的内存占用率判断所述节点运行负荷；通过应用容器的内存占用率判断容器运行负荷。
作为本发明一实施方式的进一步改进，所述节点运行负荷信息包括节点的CPU使用率和内存占用率，所述通信模块用于接收每个应用容器的CPU使用率和内存占用率；
所述控制模块具体用于：
当某一集群节点的CPU使用率超过集群节点的第一CPU使用率阈值时，将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值的另一集群节点中；
当某一集群节点的内存占用率超过集群节点的第一内存占用率阈值时，将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值的另一集群节点中；
当某一集群节点的CPU使用率超过集群节点的CPU使用率阈值，且该集群节点的内存占用率超过集群节点的内存占用率阈值时，先将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值的另一集群节点中；若迁移后的该集群节点的内存占用率仍超过集群节点的内存占用率阈值，则将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值的另一集群节点中。
作为本发明一实施方式的进一步改进，所述节点运行负荷信息包括节点的CPU使用率和内存占用率，所述通信模块用于接收每个应用容器的CPU使用率和内存占用率；
所述控制模块具体用于：
当某一集群节点的CPU使用率超过集群节点的第一CPU使用率阈值时，将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一集群节点中；
当某一集群节点的内存占用率超过集群节点的第一内存占用率阈值时，将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存率预设阈值的另一集群节点中；
当某一集群节点的CPU使用率超过集群节点的CPU使用率阈值，且该集群节点的内存占用率超过集群节点的内存占用率阈值时，先将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一集群节点中；若迁移后的该集群节点的内存占用率仍超过集群节点的内存占用率阈值，则将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存占用率阈值的另一集群节点中。
作为本发明一实施方式的进一步改进，所述控制模块用于：
若接收到的输入信息为应用容器删除请求和请求删除的应用容器名，则调用预设的应用容器删除规则进行处理，所述控制模块具体用于：
若接收到的输入信息为应用容器删除请求和请求删除的应用容器名，则调用预设的应用容器删除规则进行处理：
根据请求删除的应用容器名查询对应的应用容器是否存在；
若是，判断与请求删除的应用容器名对应的应用容器的运行状态是否为写状态；
若否，则调用应用容器集群工具删除与请求删除的应用容器名对应的应用容器。
作为本发明一实施方式的进一步改进，所述控制模块用于：
根据请求删除的应用容器名查询对应的应用容器是否存在；
若是，判断与请求删除的应用容器名对应的应用容器的运行状态是否为写状态；
若否，则调用应用容器集群工具删除与请求删除的应用容器名对应的应用容器；
将与请求删除的应用容器名对应的创建参数删除或标注。
相对于现有技术，本发明的基于Docker Swarm的Docker容器管控方法及装置，实现了无需进行命令行操作即可对Docker容器进行管控，效率高，且有效地降低了出错的可能，可靠性高。
附图说明
图1是本发明现有的Docker Swarm的架构图。
图2是本发明一实施方式中基于Docker Swarm的Docker容器管控系统的架构图。
图3是本发明一实施方式中基于应用容器集群工具的应用容器管控方法的流程图。
图4是本发明一实施方式中创建Docker容器的流程图。
图5是本发明一实施方式中迁移Docker容器的流程图。
图6是本发明一实施方式中删除Docker容器的流程图。
图7是本发明一实施方式中基于应用容器集群工具的应用容器管控装置的模块图。
具体实施方式
以下将结合附图所示的具体实施方式对本发明进行详细描述。但这些实施方式并不限制本发明，本领域的普通技术人员根据这些实施方式所做出的结构、方法、或功能上的变换均包含在本发明的保护范围内。
以下通过基于Docker Swarm管理Docker容器为例，详述本发明。其中，容器引擎以Docker为例、应用容器以Docker容器为例、应用容器集群工具以Docker Swarm为例、集群节点以Swram节点为例、应用文档以Dockerfile文档为例、集群管理器以Swarm Manager为例、容器引擎客户端以Docker Client为例。
当然，本发明的技术方案可不仅适用于管理Docker容器，还可适用于管理其他应用容器。
如图1所示，Docker Swarm包括了Swarm Manager和Daemon，其使用标准的DockerAPI接口作为其前端访问入口，各种形式的Docker Client均可以直接与Docker Swarm通信，具体地，各种形式的Docker Client均可以直接与Docker Swarm中的Swarm Manager通信。
Deamon作为调度器(Scheduler)加路由器(router)，其自己不运行容器，只是接受Docker Client发送过来的请求，调度适合的节点来运行Docker容器。
如图2所示，在本发明一实施方式中，基于应用容器集群管理工具的应用容器管控系统，以基于Docker Swarm的Docker容器管控系统为例，包括了Docker Swarm10、与DockerSwarm10的Swarm Manager通信的资源管理装置20，以及与所述资源管理装置20通信的数据库30。其中，所述资源管理装置20可与一个或多个用户端40通信。
所述资源管理装置20可用于实现无需进行命令行操作的对Docker容器的自动化管理，其可分析用户端40或Docker Swarm10发送的输入信息，并根据不同类型的输入信息调用不同的预设规则对Docker容器进行不同的管理，例如创建Docker容器、删除Docker容器、迁移Docker容器等，实现对Docker容器的高效、高可靠性管控。以下将对所述资源管理装置20的管控方法和装置进行详细说明。
如图3所示，在本发明一实施方式中，基于应用容器集群工具的应用容器管控方法，所述方法包括：
接收来自用户端或应用容器集群工具(例如Docker Swarm)的输入信息；
根据输入信息的内容，调用匹配的预设规则控制应用容器(例如Docker容器)。
以下将分别从创建Docker容器、删除Docker容器、迁移Docker容器的管理方式为例进行详细说明。
如图4所示，以创建Docker容器为例：
在本实施方式中，所述“根据输入信息的内容，调用匹配的预设规则控制Docker容器”步骤，包括：
判断所述输入数据的内容，若接收到的输入信息为用户端发送的Docker容器创建请求和创建参数，则调用预设的Docker容器创建规则进行处理：
将所述创建参数套用至代码模板中，生成Dockerfile文档；
将所述Dockerfile文档作为参数调用Docker Swarm创建镜像文件；
根据所述镜像文件调用Docker Swarm创建在Swarm节点下的Docker容器。
在本实施方式中，通过预设的Docker容器创建规则，可自动识别所述创建参数，并将所述创建参数中的值代入代码模板中对应的位置，以自动生成所述Dockerfile文档。
在生成Dockerfile文档后，可将所述Dockerfile文档保存，例如保存至本地，以便后续在创建镜像文件时调取所述Dockerfile文档。所述Dockerfile文档的格式、通过Dockerfile创建镜像文件，以及将通过镜像文件创建Docker容器，是本领域技术人员可通过公知技术掌握的，在此不再赘述。
进一步地，在本实施方式中，在Docker容器创建完成后，根据所述预设的Docker容器创建规则，所述资源管理装置20还将通过Docker Swarm控制创建的Docker容器自动启动。
在本实施方式中，所述创建参数包括：待部署应用的运行环境、容器配置要求，以及待部署应用的网络地址。其中，所述容器配置要求包括待部署应用的所需内存大小、CPU配置等。
进一步地，可将所述创建参数存储，例如存储至数据库30，并与对应的Docker容器信息关联。在所述数据库30中，每条创建参数可如下表所示示例存储：
列名 数据类型 空/非空 Key
resourceId VarChar(64) 非空
userId VarChar(255) 非空
runtimeEnv VarChar(64) 非空
memorySize Int(10) 非空
cpuConfig Int(10) 非空
codeLocation VarChar(255) 非空
handler VarChar(1024) 非空
createTime Datetime 非空
modifyTime Datetime 非空
其中，ResourceId表示创建的Docker容器的Docker容器名；UserId表示创建者的用户ID；RuntimeEnv表示待部署应用的运行环境(操作系统环境)用来确定镜像；MemorySize表示待部署应用的所需内存大小；CpuConfig表示待部署应用的CPU配置；CodeLocation表示待部署应用的网络地址，创建的Docker容器运行时会自动从所述网络地址下载该应用；Handlar表示创建的Docker容器启动时运行的应用名称；CreateTime表示容器创建时间；ModifyTime表示容器修改时间。
可以理解，在本实施方式中，可通过Docker容器名与创建参数信息关联，如此，可通过Docker容器名查找到相应的创建参数，以便在后续迁移Docker容器时使用。
从上表中可以看出，在本实施方式中，所述创建参数还可包括：创建者的用户ID、Docker容器启动时运行的应用名称、容器创建时间、容器修改时间等。
进一步地，若所述创建参数包括容器创建时间，则在当前时间到达所述容器创建时间时，调用预设的Docker容器创建规则创建Docker容器。具体地，在本实施方式中，资源管理装置内会运行一个定时器，并维护一个创建列表，当某个容器创建时间到达时，就会触发该Docker容器的创建流程。
进一步地，所述方法还包括：
判断Docker容器创建请求是否可执行，其中，判断是否可执行的维度至少包括创建Docker容器的Docker是否能提供达到所述容器配置要求的环境，例如容器配置要求中的CPU配置和/或所需内存大小Docker是否能提供；
若是，则调用预设的Docker容器创建规则创建Docker容器；若否，则反馈创建失败信息至用户端。
在本实施方式中，判断是否可执行的维度还可包括，创建者的用户ID、待部署应用的网络地址等。例如，当创建者的用户ID在资源管理装置20中没有注册或没有激活时，返回创建失败信息；当待部署应用的网络地址为无效URL时，返回创建失败信息。
进一步地，所述代码模板中包括资源监控配置，以在创建的Docker容器运行时获得Docker容器对应的Swarm节点的运行负荷信息。如此，在创建并启动Docker容器时，对应所述资源监控配置的后台程序可运行，以实现监控Swarm节点的运行负荷，从而及时地进行Docker容器的迁移。关于Docker容器的迁移，下述将结合图6具体说明。
在本实施方式中，所述资源管理装置20中管控的Docker容器的状态包括：创建中、启动中、运行中、更新中、停止中、已停止、删除中、已删除。其中已创建、运行中、已停止、已删除为稳定状态，其他则为临时状态，稳定状态下的Docker容器可接受管控，如删除、迁移等；而临时状态下的Docker容器则不能接受管控。
如图5所示，以删除Docker容器为例：
“根据输入信息的内容，调用匹配的预设规则控制Docker容器”步骤，包括：
若接收到的输入信息为用户端发送Docker容器删除请求和请求删除的Docker容器名，则调用预设的Docker容器删除规则进行处理，具体包括：
根据请求删除的Docker容器名查询对应的Docker容器是否存在；
若是，判断与请求删除的Docker容器名对应的Docker容器的运行状态是否为写状态(例如在临时状态下)；若否，则反馈删除失败信息至用户端；
若是，则不允许删除；若否，则调用Docker Swarm删除与请求删除的Docker容器名对应的Docker容器。
可以理解，请求删除的Docker容器可通过是通过上述方式创建的Docker容器，也可是通过其他方式创建的Docker容器，例如通过传统方式创建的Docker容器。若是通过上述方式创建的Docker容器，则可通过查询数据库30确定请求删除的Docker容器是否存在；若是通过其他方式创建的Docker容器，则可通过在Docker中直接查询Docker容器的容器名来确定请求删除的Docker容器是否存在。
进一步地，若待删除的Docker容器是通过上述方式创建的，则将与请求删除的Docker容器名对应的创建参数删除或标注，例如，在数据库30中将对应的创建参数删除或标注为“已删除”。
如图6所示，以迁移Docker容器为例：
“根据输入信息的内容，调用匹配的预设规则控制Docker容器”步骤，包括：
若接收的输入信息为应用容器集群工具传输的Swarm节点中监控程序上报的节点运行负荷信息；
则调用预设的Docker容器迁移规则进行处理，将节点运行负荷过载的Swarm节点中的至少一个Docker容器迁移至另一Swarm节点。
其中，迁移Docker容器的过程可参照上述创建Docker容器和删除Docker容器的方式。因每个Docker容器在创建时都保存了对应的创建参数，故可根据Docker容器的Docker容器名查找到对应的创建参数，以在另外的Swarm节点中创建该Docker容器，在创建Docker容器并启动后，即可停止并删除原先Swarm节点下的Docker容器。
进一步地，为避免在两个运行负荷都过载的Swarm节点间迁移Docker容器，本实施方式中，“将节点运行负荷过载的Swarm节点中的至少一个Docker容器迁移至另一Swarm节点”具体包括：
将节点运行负荷超过第一预设阈值(即表示过载)的Swarm节点中的至少一个Docker容器，迁移至节点运行负荷未超过第二预设阈值的Swarm节点中。
其中，所述第一预设阈值与所述第二预设阈值可相同，也可不同。在本实施方式中，所述第一预设阈值大于所述第二预设阈值，以尽可能避免完成迁移后，迁入Docker容器的Swarm节点的运行负荷超过了第一预设阈值的情况。
所述节点运行负荷和所述容器运行负荷可仅考虑Swarm节点和Docker容器的CPU使用率，在这种情况下，通过Swarm节点的CPU使用率判断所述节点运行负荷；通过Docker容器的CPU使用率判断容器运行负荷(所述Docker容器的容器运行负荷信息由所述资源管理装置20主动向所述Docker Swarm请求获得)。例如，当某一Swarm节点的CPU使用率超过第一预设阈值(此时为对应CPU使用率的阈值，例如80％)时，则符合迁移条件，将该CPU使用率超过第一阈值的Swarm节点下的至少一个Docker容器迁移至CPU使用率未超过第二预设阈值的另一Swarm节点中。
所述节点运行负荷和所述容器运行负荷可仅考虑Swarm节点和Docker容器的内存占用率，在这种情况下，通过Swarm节点的内存占用率判断所述节点运行负荷；通过Docker容器的内存占用率判断容器运行负荷。例如，当某一Swarm节点的内存占用率超过第一预设阈值(此时为对应内存占用率的阈值，例如80％)时，则符合迁移条件，将该内存占用率超过第一阈值的Swarm节点下的至少一个Docker容器迁移至内存占用率未超过第二预设阈值的另一Swarm节点中。
所述节点运行负荷和所述容器运行负荷可同时考虑Swarm节点和Docker容器的CPU占用率和内存占用率，在这种情况下，所述节点运行负荷信息还可包括节点的CPU使用率和内存占用率，“将节点运行负荷过载的Swarm节点中的至少一个Docker容器迁移至另一Swarm节点”具体包括：
当某一Swarm节点的CPU使用率超过Swarm节点的第一CPU使用率阈值时，将该Swarm节点下CPU使用率最小的Docker容器迁移至CPU使用率未超过第二CPU使用率阈值的另一Swarm节点中；
当某一Swarm节点的内存占用率超过Swarm节点的第一内存占用率阈值时，将该Swarm节点下内存占用率最小的Docker容器迁移至内存占用率未超过第二内存占用率阈值的另一Swarm节点中；
当某一Swarm节点的CPU使用率超过Swarm节点的CPU使用率阈值，且该Swarm节点的内存占用率超过Swarm节点的内存占用率阈值时，先将该Swarm节点下CPU使用率最小的Docker容器迁移至CPU使用率未超过第二CPU使用率阈值的另一Swarm节点中；若迁移后的该Swarm节点的内存占用率仍超过Swarm节点的内存占用率阈值，则将该Swarm节点下内存占用率最小的Docker容器迁移至内存占用率未超过第二内存占用率阈值的另一Swarm节点中。
可以理解，若迁移完成后，迁出Docker容器的Swarm节点的运行负荷仍超过第一预设阈值，和/或迁入Docker容器的Swarm节点的运行负荷超过了第一阈值，则仍采用上述方式，继续迁移运行负荷超过了第一阈值的Swarm节点下的Docker容器至其他未超过第二预设阈值的Swarm节点中。每次迁入的Swarm节点可相同，亦可不同。
进一步地，为了避免迁入Docker容器的Swarm节点的CPU使用率超过了第一预设阈值的情况。进一步地，“将节点运行负荷过载的Swarm节点中的至少一个Docker容器迁移至另一Swarm节点”具体包括：
接收每个Docker容器的容器运行负荷信息；
将节点运行负荷超过第一预设阈值的Swarm节点中容器运行负荷最小的Docker容器，迁移至节点运行负荷未超过第二预设阈值且完成迁移后节点负荷未超过第一预设阈值的Swarm节点中。
本方案考虑了Docker容器的容器运行负荷，并可在迁移前预先计算未超过第二预设阈值的Swarm节点在Docker容器迁入后的节点运行负荷，以完全避免Docker容器从一负荷过载的Swarm节点下迁出，又造成了另一Swarm节点的负荷过载。
其中，所述节点运行负荷和所述容器运行负荷可仅考虑Swarm节点和Docker容器的CPU使用率，在这种情况下，通过Swarm节点的CPU使用率判断所述节点运行负荷；通过Docker容器的CPU使用率判断容器运行负荷。例如，当某一Swarm节点的CPU使用率超过第一预设阈值(此时为对应CPU使用率的阈值，例如80％)时，则符合迁移条件，将该CPU使用率超过第一阈值的Swarm节点下的CPU使用率最小的Docker容器迁移至CPU使用率未超过第二预设阈值的另一Swarm节点中，并且，预先计算迁入Docker容器后的Swarm节点的CPU使用率是否超过第一预设阈值，如果仍未超过，则进行迁移。
所述节点运行负荷和所述容器运行负荷可仅考虑Swarm节点和Docker容器的内存占用率，在这种情况下，通过Swarm节点的内存占用率判断所述节点运行负荷；通过Docker容器的内存占用率判断容器运行负荷。例如，当某一Swarm节点的内存占用率超过第一预设阈值(此时为对应内存占用率的阈值，例如80％)时，则符合迁移条件，将该内存占用率超过第一阈值的Swarm节点下的内存占用率最小的Docker容器迁移至内存占用率未超过第二预设阈值的另一Swarm节点中，并且，预先计算迁入Docker容器后的Swarm节点的内存占用率是否超过第一预设阈值，如果仍未超过，则进行迁移。
所述节点运行负荷和所述容器运行负荷可同时考虑Swarm节点和Docker容器的CPU占用率和内存占用率，在这种情况下，所述节点运行负荷信息还包括节点的CPU使用率和内存占用率，“将节点运行负荷过载的Swarm节点中的至少一个Docker容器迁移至另一Swarm节点”具体包括：
接收每个Docker容器的CPU使用率和内存占用率；
当某一Swarm节点的CPU使用率超过Swarm节点的第一CPU使用率阈值时，将该Swarm节点下CPU使用率最小的Docker容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一Swarm节点中；
当某一Swarm节点的内存占用率超过Swarm节点的第一内存占用率阈值时，将该Swarm节点下内存占用率最小的Docker容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存率预设阈值的另一Swarm节点中；
当某一Swarm节点的CPU使用率超过Swarm节点的CPU使用率阈值，且该Swarm节点的内存占用率超过Swarm节点的内存占用率阈值时，先将该Swarm节点下CPU使用率最小的Docker容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一Swarm节点中；若迁移后的该Swarm节点的内存占用率仍超过Swarm节点的内存占用率阈值，则将该Swarm节点下内存占用率最小的Docker容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存占用率阈值的另一Swarm节点中。
可以理解，若迁移完成后，迁出Docker容器的Swarm节点的运行负荷仍超过第一预设阈值，则仍采用上述方式，继续迁移运行负荷超过了第一阈值的Swarm节点下的Docker容器至其他未超过第二预设阈值的Swarm节点中。每次迁入的Swarm节点可相同，亦可不同。
如图7所示，在本发明一实施方式中，所述基于应用容器集群工具的应用容器管控装置，该装置可是上述的资源管理装置20，所述装置包括：
通信模块201，用于接收来自用户端或应用容器集群工具(例如Docker Swarm)的输入信息；
控制模块203，用于根据输入信息的内容，调用匹配的预设规则控制应用容器(例如Docker容器)。
以下将分别从创建Docker容器、删除Docker容器、迁移Docker容器的管理方式进行详细说明。
以创建Docker容器为例：
在本实施方式中，所述控制模块203用于：
判断所述输入数据的内容，若接收到的输入信息为用户端发送的Docker容器创建请求和创建参数，则调用预设的Docker容器创建规则进行处理：
将所述创建参数套用至代码模板中，生成Dockerfile文档；
将所述Dockerfile文档作为参数调用Docker Swarm创建镜像文件；
根据所述镜像文件调用Docker Swarm创建在Swarm节点下的Docker容器。
在本实施方式中，通过预设的Docker容器创建规则，可自动识别所述创建参数，并将所述创建参数中的值代入代码模板中对应的位置，以自动生成所述Dockerfile文档。
在生成Dockerfile文档后，可将所述Dockerfile文档保存，例如保存至本地，以便后续在创建镜像文件时调取所述Dockerfile文档。所述Dockerfile文档的格式、通过Dockerfile创建镜像文件，以及将通过镜像文件创建Docker容器，是本领域技术人员可通过公知技术掌握的，在此不再赘述。
进一步地，在本实施方式中，在Docker容器创建完成后，根据所述预设的Docker容器创建规则，所述资源管理装置20还将通过Docker Swarm控制创建的Docker容器自动启动。
在本实施方式中，所述创建参数包括：待部署应用的运行环境、容器配置要求，以及待部署应用的网络地址。其中，所述容器配置要求包括待部署应用的所需内存大小、CPU配置等。
进一步地，所述控制模块203可用于：将所述创建参数存储，例如存储至数据库30，并与对应的Docker容器信息关联。在所述数据库30中，每条创建参数可如下表所示示例存储：
列名 数据类型 空/非空 Key
resourceId VarChar(64) 非空
userId VarChar(255) 非空
runtimeEnv VarChar(64) 非空
memorySize Int(10) 非空
cpuConfig Int(10) 非空
codeLocation VarChar(255) 非空
handler VarChar(1024) 非空
createTime Datetime 非空
modifyTime Datetime 非空
其中，ResourceId表示创建的Docker容器的Docker容器名；UserId表示创建者的用户ID；RuntimeEnv表示待部署应用的运行环境(操作系统环境)用来确定镜像；MemorySize表示待部署应用的所需内存大小；CpuConfig表示待部署应用的CPU配置；CodeLocation表示待部署应用的网络地址，创建的Docker容器运行时会自动从所述网络地址下载该应用；Handlar表示创建的Docker容器启动时运行的应用名称；CreateTime表示容器创建时间；ModifyTime表示容器修改时间。
可以理解，在本实施方式中，可通过Docker容器名与创建参数信息关联，如此，可通过Docker容器名查找到相应的创建参数，以便在后续迁移Docker容器时使用。
从上表中可以看出，在本实施方式中，所述创建参数还可包括：创建者的用户ID、Docker容器启动时运行的应用名称、容器创建时间、容器修改时间等。
进一步地，所述控制模块203用于：若所述创建参数包括容器创建时间，则在当前时间到达所述容器创建时间时，调用预设的Docker容器创建规则创建Docker容器。
具体地，在本实施方式中，资源管理装置内会运行一个定时器，并维护一个创建列表，当某个容器创建时间到达时，就会触发该Docker容器的创建流程。
进一步地，所述控制模块203用于：
判断Docker容器创建请求是否可执行，其中，判断是否可执行的维度至少包括创建Docker容器的Docker是否能提供达到所述容器配置要求的环境，例如容器配置要求中的CPU配置和/或所需内存大小Docker是否能提供；
若是，则调用预设的Docker容器创建规则创建Docker容器；若否，则反馈创建失败信息至用户端。
在本实施方式中，判断是否可执行的维度还可包括，创建者的用户ID、待部署应用的网络地址等。例如，当创建者的用户ID在资源管理装置20中没有注册或没有激活时，返回创建失败信息；当待部署应用的网络地址为无效URL时，返回创建失败信息。
进一步地，所述代码模板中包括资源监控配置，以在创建的Docker容器运行时获得Docker容器对应的Swarm节点的运行负荷信息。如此，在创建并启动Docker容器时，对应所述资源监控配置的后台程序可运行，以实现监控Swarm节点的运行负荷，从而及时地进行Docker容器的迁移。
在本实施方式中，所述资源管理装置20中管控的Docker容器的状态包括：创建中、启动中、运行中、更新中、停止中、已停止、删除中、已删除。其中已创建、运行中、已停止、已删除为稳定状态，其他则为临时状态，稳定状态下的Docker容器可接受管控，如删除、迁移等；而临时状态下的Docker容器则不能接受管控。
以删除Docker容器为例：
所述控制模块203用于：
若接收到的输入信息为用户端发送Docker容器删除请求和请求删除的Docker容器名，则调用预设的Docker容器删除规则进行处理，具体包括：
根据请求删除的Docker容器名查询对应的Docker容器是否存在；
若是，判断与请求删除的Docker容器名对应的Docker容器的运行状态是否为写状态(例如在临时状态下)；若否，则反馈删除失败信息至用户端；
若是，则不允许删除；若否，则调用Docker Swarm删除与请求删除的Docker容器名对应的Docker容器。
可以理解，请求删除的Docker容器可通过是通过上述方式创建的Docker容器，也可是通过其他方式创建的Docker容器，例如通过传统方式创建的Docker容器。若是通过上述方式创建的Docker容器，则可通过查询数据库30确定请求删除的Docker容器是否存在；若是通过其他方式创建的Docker容器，则可通过在Docker中直接查询Docker容器的容器名来确定请求删除的Docker容器是否存在。
进一步地，若待删除的Docker容器是通过上述方式创建的，则所述控制模块203用于将与请求删除的Docker容器名对应的创建参数删除或标注，例如，在数据库30中将对应的创建参数删除或标注为“已删除”。
以迁移Docker容器为例：
所述控制模块203用于：
若接收的输入信息为应用容器集群工具传输的Swarm节点中监控程序上报的节点运行负荷信息；
则调用预设的Docker容器迁移规则进行处理，将节点运行负荷过载的Swarm节点中的至少一个Docker容器迁移至另一Swarm节点。
其中，迁移Docker容器的过程可参照上述创建Docker容器和删除Docker容器的方式。因每个Docker容器在创建时都保存了对应的创建参数，故可根据Docker容器的Docker容器名查找到对应的创建参数，以在另外的Swarm节点中创建该Docker容器，在创建Docker容器并启动后，即可停止并删除原先Swarm节点下的Docker容器。
进一步地，为避免在两个运行负荷都过载的Swarm节点间迁移Docker容器，本实施方式中，所述控制模块203用于：
将节点运行负荷超过第一预设阈值(即表示过载)的Swarm节点中的至少一个Docker容器，迁移至节点运行负荷未超过第二预设阈值的Swarm节点中。
其中，所述第一预设阈值与所述第二预设阈值可相同，也可不同。在本实施方式中，所述第一预设阈值大于所述第二预设阈值，以尽可能避免完成迁移后，迁入Docker容器的Swarm节点的运行负荷超过了第一预设阈值的情况。
所述节点运行负荷和所述容器运行负荷可仅考虑Swarm节点和Docker容器的CPU使用率，在这种情况下，通过Swarm节点的CPU使用率判断所述节点运行负荷；通过Docker容器的CPU使用率判断容器运行负荷(所述Docker容器的容器运行负荷信息由所述资源管理装置20主动向所述Docker Swarm请求获得)。例如，当某一Swarm节点的CPU使用率超过第一预设阈值(此时为对应CPU使用率的阈值，例如80％)时，则符合迁移条件，将该CPU使用率超过第一阈值的Swarm节点下的至少一个Docker容器迁移至CPU使用率未超过第二预设阈值的另一Swarm节点中。
所述节点运行负荷和所述容器运行负荷可仅考虑Swarm节点和Docker容器的内存占用率，在这种情况下，通过Swarm节点的内存占用率判断所述节点运行负荷；通过Docker容器的内存占用率判断容器运行负荷。例如，当某一Swarm节点的内存占用率超过第一预设阈值(此时为对应内存占用率的阈值，例如80％)时，则符合迁移条件，将该内存占用率超过第一阈值的Swarm节点下的至少一个Docker容器迁移至内存占用率未超过第二预设阈值的另一Swarm节点中。
所述节点运行负荷和所述容器运行负荷可同时考虑Swarm节点和Docker容器的CPU占用率和内存占用率，在这种情况下，所述节点运行负荷信息还可包括节点的CPU使用率和内存占用率，所述通信模块201用于接收每个Docker容器的CPU使用率和内存占用率；所述控制模块203用于：
当某一Swarm节点的CPU使用率超过Swarm节点的第一CPU使用率阈值时，将该Swarm节点下CPU使用率最小的Docker容器迁移至CPU使用率未超过第二CPU使用率阈值的另一Swarm节点中；
当某一Swarm节点的内存占用率超过Swarm节点的第一内存占用率阈值时，将该Swarm节点下内存占用率最小的Docker容器迁移至内存占用率未超过第二内存占用率阈值的另一Swarm节点中；
当某一Swarm节点的CPU使用率超过Swarm节点的CPU使用率阈值，且该Swarm节点的内存占用率超过Swarm节点的内存占用率阈值时，先将该Swarm节点下CPU使用率最小的Docker容器迁移至CPU使用率未超过第二CPU使用率阈值的另一Swarm节点中；若迁移后的该Swarm节点的内存占用率仍超过Swarm节点的内存占用率阈值，则将该Swarm节点下内存占用率最小的Docker容器迁移至内存占用率未超过第二内存占用率阈值的另一Swarm节点中。
可以理解，若迁移完成后，迁出Docker容器的Swarm节点的运行负荷仍超过第一预设阈值，和/或迁入Docker容器的Swarm节点的运行负荷超过了第一阈值，则仍采用上述方式，继续迁移运行负荷超过了第一阈值的Swarm节点下的Docker容器至其他未超过第二预设阈值的Swarm节点中。每次迁入的Swarm节点可相同，亦可不同。
进一步地，为了避免迁入Docker容器的Swarm节点的CPU使用率超过了第一预设阈值的情况。进一步地，所述通信模块201用于接收每个Docker容器的容器运行负荷信息；所述控制模块203用于：
将节点运行负荷超过第一预设阈值的Swarm节点中容器运行负荷最小的Docker容器，迁移至节点运行负荷未超过第二预设阈值且完成迁移后节点负荷未超过第一预设阈值的Swarm节点中。
本方案考虑了Docker容器的容器运行负荷，并可在迁移前预先计算未超过第二预设阈值的Swarm节点在Docker容器迁入后的节点运行负荷，以完全避免Docker容器从一负荷过载的Swarm节点下迁出，又造成了另一Swarm节点的负荷过载。
其中，所述节点运行负荷和所述容器运行负荷可仅考虑Swarm节点和Docker容器的CPU使用率，在这种情况下，通过Swarm节点的CPU使用率判断所述节点运行负荷；通过Docker容器的CPU使用率判断容器运行负荷。例如，当某一Swarm节点的CPU使用率超过第一预设阈值(此时为对应CPU使用率的阈值，例如80％)时，则符合迁移条件，将该CPU使用率超过第一阈值的Swarm节点下的CPU使用率最小的Docker容器迁移至CPU使用率未超过第二预设阈值的另一Swarm节点中，并且，预先计算迁入Docker容器后的Swarm节点的CPU使用率是否超过第一预设阈值，如果仍未超过，则进行迁移。
所述节点运行负荷和所述容器运行负荷可仅考虑Swarm节点和Docker容器的内存占用率，在这种情况下，通过Swarm节点的内存占用率判断所述节点运行负荷；通过Docker容器的内存占用率判断容器运行负荷。例如，当某一Swarm节点的内存占用率超过第一预设阈值(此时为对应内存占用率的阈值，例如80％)时，则符合迁移条件，将该内存占用率超过第一阈值的Swarm节点下的内存占用率最小的Docker容器迁移至内存占用率未超过第二预设阈值的另一Swarm节点中，并且，预先计算迁入Docker容器后的Swarm节点的内存占用率是否超过第一预设阈值，如果仍未超过，则进行迁移。
所述节点运行负荷和所述容器运行负荷可同时考虑Swarm节点和Docker容器的CPU占用率和内存占用率，在这种情况下，所述节点运行负荷信息还包括节点的CPU使用率和内存占用率，所述通信模块201用于接收每个Docker容器的CPU使用率和内存占用率；所述控制模块203用于：
当某一Swarm节点的CPU使用率超过Swarm节点的第一CPU使用率阈值时，将该Swarm节点下CPU使用率最小的Docker容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一Swarm节点中；
当某一Swarm节点的内存占用率超过Swarm节点的第一内存占用率阈值时，将该Swarm节点下内存占用率最小的Docker容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存率预设阈值的另一Swarm节点中；
当某一Swarm节点的CPU使用率超过Swarm节点的CPU使用率阈值，且该Swarm节点的内存占用率超过Swarm节点的内存占用率阈值时，先将该Swarm节点下CPU使用率最小的Docker容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一Swarm节点中；若迁移后的该Swarm节点的内存占用率仍超过Swarm节点的内存占用率阈值，则将该Swarm节点下内存占用率最小的Docker容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存占用率阈值的另一Swarm节点中。
可以理解，若迁移完成后，迁出Docker容器的Swarm节点的运行负荷仍超过第一预设阈值，则仍采用上述方式，继续迁移运行负荷超过了第一阈值的Swarm节点下的Docker容器至其他未超过第二预设阈值的Swarm节点中。每次迁入的Swarm节点可相同，亦可不同。
综上所述，本发明的基于Docker Swarm的Docker容器管控方法及装置，实现了无需进行命令行操作即可对Docker容器进行管控，效率高，且有效地降低了出错的可能，可靠性高。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置，装置和模块的具体工作过程，可以参考前述方法实施方式中的对应过程，在此不再赘述。
在本发明所提供的几个实施方式中，应该理解到，所揭露的装置，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所展示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块展示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个通信模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施方式方案的目的。
另外，在本发明各个实施方式中的各功能模块可以集成在一个决策模块中，也可以是各个模块单独物理存在，也可以2个或2个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。
上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器(processor)执行本发明各个实施方式所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read‐Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上实施方式仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施方式对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施方式技术方案的精神和范围。

Claims (30)

1.一种基于应用容器集群工具的应用容器管控方法，其特征在于，所述方法包括：
接收来自用户端或应用容器集群工具的输入信息；
根据输入信息的内容，调用匹配的预设规则控制应用容器；
其中，“根据输入信息的内容，调用匹配的预设规则控制应用容器”步骤，包括：若接收的输入信息为应用容器集群工具传输的集群节点中监控程序上报的节点运行负荷信息；则调用预设的应用容器迁移规则进行处理，将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点；
所述节点运行负荷信息包括节点的CPU使用率，“将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点”具体包括：
接收每个应用容器的CPU使用率；
当某一集群节点的CPU使用率超过集群节点的第一CPU使用率阈值时，将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值的另一集群节点中。
2.根据权利要求1所述的基于应用容器集群工具的应用容器管控方法，其特征在于，所述“根据输入信息的内容，调用匹配的预设规则控制应用容器”步骤，包括：
若接收到的输入信息为应用容器创建请求和创建参数，则调用预设的应用容器创建规则进行处理：
将所述创建参数套用至代码模板中，生成应用文档；
将所述应用文档作为参数调用应用容器集群工具创建镜像文件；
根据所述镜像文件调用应用容器集群工具创建在集群节点下的应用容器。
3.根据权利要求2所述的基于应用容器集群工具的应用容器管控方法，其特征在于，所述创建参数包括：待部署应用的运行环境、容器配置要求，以及待部署应用的网络地址。
4.根据权利要求2所述的基于应用容器集群工具的应用容器管控方法，其特征在于，所述方法还包括：
将所述创建参数存储，并与对应的应用容器信息关联。
5.根据权利要求2所述的基于应用容器集群工具的应用容器管控方法，其特征在于，所述方法包括：
若所述创建参数包括容器创建时间，则在当前时间到达所述容器创建时间时，调用预设的应用容器创建规则创建应用容器。
6.根据权利要求3所述的基于应用容器集群工具的应用容器管控方法，其特征在于，所述方法还包括：
判断应用容器创建请求是否可执行，其中，判断是否可执行的维度至少包括创建应用容器的容器引擎是否能提供达到所述容器配置要求的环境；
若是，则调用预设的应用容器创建规则创建应用容器。
7.根据权利要求2所述的基于应用容器集群工具的应用容器管控方法，其特征在于，所述代码模板中包括资源监控配置，以在创建的应用容器运行时获得应用容器对应的集群节点的运行负荷信息。
8.根据权利要求1所述的基于应用容器集群工具的应用容器管控方法，其特征在于，“将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点”具体包括：
将节点运行负荷超过第一预设阈值的集群节点中的至少一个应用容器，迁移至节点运行负荷未超过第二预设阈值的集群节点中。
9.根据权利要求8所述的基于应用容器集群工具的应用容器管控方法，其特征在于，“将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点”具体包括：
接收每个应用容器的容器运行负荷信息；
将节点运行负荷超过第一预设阈值的集群节点中容器运行负荷最小的应用容器，迁移至节点运行负荷未超过第二预设阈值且完成迁移后节点负荷未超过第一预设阈值的集群节点中。
10.根据权利要求9所述的基于应用容器集群工具的应用容器管控方法，其特征在于，通过集群节点的CPU使用率判断所述节点运行负荷；通过应用容器的CPU使用率判断容器运行负荷。
11.根据权利要求9所述的基于应用容器集群工具的应用容器管控方法，其特征在于，通过集群节点的内存占用率判断所述节点运行负荷；通过应用容器的内存占用率判断容器运行负荷。
12.根据权利要求1所述的基于应用容器集群工具的应用容器管控方法，其特征在于，所述节点运行负荷信息还包括节点的内存占用率，“将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点”具体还包括：
接收每个应用容器的内存占用率；
当某一集群节点的内存占用率超过集群节点的第一内存占用率阈值时，将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值的另一集群节点中；
当某一集群节点的CPU使用率超过集群节点的CPU使用率阈值，且该集群节点的内存占用率超过集群节点的内存占用率阈值时，先将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值的另一集群节点中；若迁移后的该集群节点的内存占用率仍超过集群节点的内存占用率阈值，则将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值的另一集群节点中。
13.根据权利要求1所述的基于应用容器集群工具的应用容器管控方法，其特征在于，所述节点运行负荷信息还包括节点的内存占用率，“将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点”具体还包括：
接收每个应用容器的内存占用率；
当某一集群节点的CPU使用率超过集群节点的第一CPU使用率阈值时，将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一集群节点中；
当某一集群节点的内存占用率超过集群节点的第一内存占用率阈值时，将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存率预设阈值的另一集群节点中；
当某一集群节点的CPU使用率超过集群节点的CPU使用率阈值，且该集群节点的内存占用率超过集群节点的内存占用率阈值时，先将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一集群节点中；若迁移后的该集群节点的内存占用率仍超过集群节点的内存占用率阈值，则将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存占用率阈值的另一集群节点中。
14.根据权利要求1至7中任意一项所述的基于应用容器集群工具的应用容器管控方法，其特征在于，“根据输入信息的内容，调用匹配的预设规则控制应用容器”步骤，包括：
若接收到的输入信息为应用容器删除请求和请求删除的应用容器名，则调用预设的应用容器删除规则进行处理：
根据请求删除的应用容器名查询对应的应用容器是否存在；
若是，判断与请求删除的应用容器名对应的应用容器的运行状态是否为写状态；
若否，则调用应用容器集群工具删除与请求删除的应用容器名对应的应用容器。
15.根据权利要求4所述的基于应用容器集群工具的应用容器管控方法，其特征在于，“根据输入信息的内容，调用匹配的预设规则控制应用容器”步骤，包括：
根据请求删除的应用容器名查询对应的应用容器是否存在；
若是，判断与请求删除的应用容器名对应的应用容器的运行状态是否为写状态；
若否，则调用应用容器集群工具删除与请求删除的应用容器名对应的应用容器；
将与请求删除的应用容器名对应的创建参数删除或标注。
16.一种基于应用容器集群工具的应用容器管控装置，其特征在于，所述装置包括：
通信模块，用于接收来自用户端或应用容器集群工具的输入信息；
控制模块，用于根据输入信息的内容，调用匹配的预设规则控制应用容器；
其中，所述控制模块具体用于：若接收的输入信息为应用容器集群工具传输的集群节点中监控程序上报的节点运行负荷信息；则调用预设的应用容器迁移规则进行处理，将节点运行负荷过载的集群节点中的至少一个应用容器迁移至另一集群节点；
所述节点运行负荷信息包括节点的CPU使用率，所述通信模块用于接收每个应用容器的CPU使用率；
所述控制模块具体用于：当某一集群节点的CPU使用率超过集群节点的第一CPU使用率阈值时，将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值的另一集群节点中。
17.根据权利要求16所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述控制模块用于：
若接收到的输入信息为应用容器创建请求和创建参数，则调用预设的应用容器创建规则进行处理：
将所述创建参数套用至代码模板中，生成应用文档；
将所述应用文档作为参数调用应用容器集群工具创建镜像文件；
根据所述镜像文件调用应用容器集群工具创建在集群节点下的应用容器。
18.根据权利要求17所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述创建参数包括：待部署应用的运行环境、容器配置要求，以及待部署应用的网络地址。
19.根据权利要求17所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述控制模块还用于：
将所述创建参数存储，并与对应的应用容器信息关联。
20.根据权利要求17所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述控制模块用于：
若所述创建参数包括容器创建时间，则在当前时间到达所述容器创建时间时，调用预设的应用容器创建规则创建应用容器。
21.根据权利要求18所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述控制模块用于：
判断应用容器创建请求是否可执行，其中，判断是否可执行的维度至少包括创建应用容器的容器引擎是否能提供达到所述容器配置要求的环境；
若是，则调用预设的应用容器创建规则创建应用容器。
22.根据权利要求17所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述代码模板中包括资源监控配置，以在创建的应用容器运行时获得应用容器对应的集群节点的运行负荷信息。
23.根据权利要求16所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述控制模块用于：
将节点运行负荷超过第一预设阈值的集群节点中的至少一个应用容器，迁移至节点运行负荷未超过第二预设阈值的集群节点中。
24.根据权利要求23所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述通信模块用于接收每个应用容器的容器运行负荷信息；所述控制模块用于：
将节点运行负荷超过第一预设阈值的集群节点中容器运行负荷最小的应用容器，迁移至节点运行负荷未超过第二预设阈值且完成迁移后节点负荷未超过第一预设阈值的集群节点中。
25.根据权利要求24所述的基于应用容器集群工具的应用容器管控装置，其特征在于，通过集群节点的CPU使用率判断所述节点运行负荷；通过应用容器的CPU使用率判断容器运行负荷。
26.根据权利要求24所述的基于应用容器集群工具的应用容器管控装置，其特征在于，通过集群节点的内存占用率判断所述节点运行负荷；通过应用容器的内存占用率判断容器运行负荷。
27.根据权利要求16所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述节点运行负荷信息还包括节点的内存占用率，所述通信模块还用于接收每个应用容器的内存占用率；
所述控制模块具体还用于：
当某一集群节点的内存占用率超过集群节点的第一内存占用率阈值时，将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值的另一集群节点中；
当某一集群节点的CPU使用率超过集群节点的CPU使用率阈值，且该集群节点的内存占用率超过集群节点的内存占用率阈值时，先将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值的另一集群节点中；若迁移后的该集群节点的内存占用率仍超过集群节点的内存占用率阈值，则将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值的另一集群节点中。
28.根据权利要求16所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述节点运行负荷信息还包括节点的内存占用率，所述通信模块还用于接收每个应用容器的内存占用率；
所述控制模块具体还用于：
当某一集群节点的CPU使用率超过集群节点的第一CPU使用率阈值时，将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一集群节点中；
当某一集群节点的内存占用率超过集群节点的第一内存占用率阈值时，将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存率预设阈值的另一集群节点中；
当某一集群节点的CPU使用率超过集群节点的CPU使用率阈值，且该集群节点的内存占用率超过集群节点的内存占用率阈值时，先将该集群节点下CPU使用率最小的应用容器迁移至CPU使用率未超过第二CPU使用率阈值，且完成迁移后CPU使用率未超过第一CPU使用率阈值的另一集群节点中；若迁移后的该集群节点的内存占用率仍超过集群节点的内存占用率阈值，则将该集群节点下内存占用率最小的应用容器迁移至内存占用率未超过第二内存占用率阈值，且完成迁移后内存占用率未超过第一内存占用率阈值的另一集群节点中。
29.根据权利要求16至22中任意一项所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述控制模块用于：
若接收到的输入信息为应用容器删除请求和请求删除的应用容器名，则调用预设的应用容器删除规则进行处理，所述控制模块具体用于：
若接收到的输入信息为应用容器删除请求和请求删除的应用容器名，则调用预设的应用容器删除规则进行处理：
根据请求删除的应用容器名查询对应的应用容器是否存在；
若是，判断与请求删除的应用容器名对应的应用容器的运行状态是否为写状态；
若否，则调用应用容器集群工具删除与请求删除的应用容器名对应的应用容器。
30.根据权利要求19所述的基于应用容器集群工具的应用容器管控装置，其特征在于，所述控制模块用于：
根据请求删除的应用容器名查询对应的应用容器是否存在；
若是，判断与请求删除的应用容器名对应的应用容器的运行状态是否为写状态；
若否，则调用应用容器集群工具删除与请求删除的应用容器名对应的应用容器；
将与请求删除的应用容器名对应的创建参数删除或标注。
CN201610427672.XA 2016-06-16 2016-06-16 基于应用容器集群工具的应用容器管控方法及装置 Active CN107515783B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610427672.XA CN107515783B (zh) 2016-06-16 2016-06-16 基于应用容器集群工具的应用容器管控方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610427672.XA CN107515783B (zh) 2016-06-16 2016-06-16 基于应用容器集群工具的应用容器管控方法及装置

Publications (2)

Publication Number Publication Date
CN107515783A CN107515783A (zh) 2017-12-26
CN107515783B true CN107515783B (zh) 2021-01-22

Family

ID=60721198

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610427672.XA Active CN107515783B (zh) 2016-06-16 2016-06-16 基于应用容器集群工具的应用容器管控方法及装置

Country Status (1)

Country Link
CN (1) CN107515783B (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108196940B (zh) * 2017-12-29 2022-03-11 华为云计算技术有限公司 删除容器的方法和相关设备
CN108388469B (zh) * 2018-01-10 2021-06-18 北京思特奇信息技术股份有限公司 一种进程调度方法及系统
CN108664290B (zh) * 2018-05-17 2024-02-02 中国平安人寿保险股份有限公司 一种应用程序配置方法、装置、电子设备及存储介质
CN109324819A (zh) * 2018-09-28 2019-02-12 中国平安财产保险股份有限公司 服务器代码部署方法、装置、服务器设备及存储介质
CN112306843A (zh) * 2019-07-29 2021-02-02 北京中关村科金技术有限公司 一种测试方法、装置以及存储介质
CN110865840B (zh) * 2019-11-18 2023-11-03 义乌中国小商品城大数据有限公司 一种应用管理方法、装置、服务器及存储介质
CN110932935A (zh) * 2019-11-26 2020-03-27 深圳前海微众银行股份有限公司 资源控制方法、装置、设备及计算机存储介质
CN112015376A (zh) * 2020-08-21 2020-12-01 广州欢网科技有限责任公司 一种生成Dockerfile的方法和装置
CN112328379A (zh) * 2020-11-05 2021-02-05 浪潮电子信息产业股份有限公司 一种应用迁移方法、装置、设备及介质
CN113162954B (zh) * 2021-06-23 2021-09-03 西南石油大学 靶机的创建方法以及网络攻防训练系统
CN116340416A (zh) * 2021-12-22 2023-06-27 中兴通讯股份有限公司 数据库部署方法、数据库处理方法、相关设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1991753A (zh) * 2005-12-27 2007-07-04 国际商业机器公司 应用模板创建和管理的方法和系统
CN104950757A (zh) * 2015-06-12 2015-09-30 北京奇虎科技有限公司 监控容器的方法及系统
CN104991815A (zh) * 2015-06-19 2015-10-21 北京奇虎科技有限公司 Docker容器的管理方法和系统
CN105260233A (zh) * 2015-09-30 2016-01-20 北京奇虎科技有限公司 一种应用容器的创建方法和装置
CN105630488A (zh) * 2015-12-18 2016-06-01 上海爱数信息技术股份有限公司 一种基于docker容器技术的持续集成实现方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1991753A (zh) * 2005-12-27 2007-07-04 国际商业机器公司 应用模板创建和管理的方法和系统
CN104950757A (zh) * 2015-06-12 2015-09-30 北京奇虎科技有限公司 监控容器的方法及系统
CN104991815A (zh) * 2015-06-19 2015-10-21 北京奇虎科技有限公司 Docker容器的管理方法和系统
CN105260233A (zh) * 2015-09-30 2016-01-20 北京奇虎科技有限公司 一种应用容器的创建方法和装置
CN105630488A (zh) * 2015-12-18 2016-06-01 上海爱数信息技术股份有限公司 一种基于docker容器技术的持续集成实现方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Docker Dockerfile详解;某先生xxx;<http://blog.cnds.net/wsscy2004/article/details/25878223>;20140515;正文第1-3页 *

Also Published As

Publication number Publication date
CN107515783A (zh) 2017-12-26

Similar Documents

Publication Publication Date Title
CN107515783B (zh) 基于应用容器集群工具的应用容器管控方法及装置
CN109155782B (zh) 容器之间的进程间通信
JP5510556B2 (ja) 仮想マシンのストレージスペースおよび物理ホストを管理するための方法およびシステム
CN110383764B (zh) 无服务器系统中使用历史数据处理事件的系统和方法
WO2018059222A1 (zh) 一种文件切片上传方法、装置及云存储系统
US20110239216A1 (en) Service providing system, a virtual machine server, a service providing method, and a program thereof
CN108984266B (zh) 一种虚拟机的管理方法、装置及系统
US9904337B2 (en) Affinity-aware parallel zeroing of pages in non-uniform memory access (NUMA) servers
CN108028833A (zh) 一种nas数据访问的方法、系统及相关设备
US10884880B2 (en) Method for transmitting request message and apparatus
US20110173319A1 (en) Apparatus and method for operating server using virtualization technique
CN112395107A (zh) 税控设备控制的方法、装置、存储介质及电子设备
CN111881476A (zh) 对象存储控制方法、装置、计算机设备及存储介质
KR102168994B1 (ko) 클라우드 컴퓨팅 환경에서 클라우드 호스트를 삭제하는 방법, 장치, 서버 및 저장 매체
WO2020252724A1 (zh) 日志处理方法、设备及计算机可读存储介质
CN113821333A (zh) 安卓应用程序迁移的方法和装置
CN112241398A (zh) 一种数据迁移方法和系统
EP3346671B1 (en) Service processing method and equipment
CN115268909A (zh) 一种web前端创建并运行构建任务的方法、系统和终端
US20170168867A1 (en) Information processing system and control method
CN109582464B (zh) 一种云平台管理多种虚拟化平台的方法和装置
CN109634721B (zh) 一种虚拟机与主机的启动通信方法及相关装置
CN108614732B (zh) 龙芯平台动态前景下的操作系统硬件设备快速映射方法
EP3783484A1 (en) Data processing method and computer device
US11550753B2 (en) Data labeling awareness for backup systems

Legal Events

Date Code Title Description
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
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20230609

Address after: Room 1-2-A06, Yungu Park, No. 1008 Dengcai Street, Sandun Town, Xihu District, Hangzhou City, Zhejiang Province

Patentee after: Aliyun Computing Co.,Ltd.

Address before: Box 847, four, Grand Cayman capital, Cayman Islands, UK

Patentee before: ALIBABA GROUP HOLDING Ltd.