CN111459530B - 打补丁方法、装置和存储介质 - Google Patents

Abstract

本申请实施例提供一种打补丁方法、装置和存储介质，该方法包括：获取至少一个补丁包集的元数据信息，所述补丁包集的元数据信息用于指示所述补丁包集的容器镜象范围，以及，所述补丁包集的版本；根据所述至少一个补丁包集的元数据信息，确定至少一个待打补丁对象，所述待打补丁对象为存储在容器镜象仓库中的容器镜象或在线运行的容器服务，所述待打补丁对象的当前补丁版本低于所述补丁包集的版本；根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁。本申请实施例采用补丁包集对待打补丁对象打补丁，避免了对新版本的整个容器镜象包的发送，减小了带宽的占用，提高了交付的效率。

Description

打补丁方法、装置和存储介质

技术领域

本申请实施例涉及互联网技术领域，尤其涉及一种打补丁方法、装置和存储介质。

背景技术

Docker是一个开源的应用容器引擎，能够提供一种应用程序的自动化部署解决方案，通过在操作系统上创建容器(容器即轻量级虚拟机)，并在容器中部署和运行应用程序的容器镜象，可以实现应用程序的自动化安装、部署和升级。应用程序的开发端，用于对应用程序的源码进行控制，如实现应用程序的各个版本的发布，以及应用程序对应的容器镜象的构建；应用程序的运营端，用于将应用程序对应的容器镜象存储在容器镜象仓库中，以及实现应用程序对应的容器镜象的运行。

在以互联网为代表的自建自营的场景中，应用程序的开发端和运营端对应用程序的自动化安装、部署和升级是连通的；当容器镜象在运行过程中出现缺陷时，可以将缺陷返回给开发端，开发端根据该缺陷进行新版本容器镜象的构建，将新版本的容器镜象包重新发送给运营端继续运行。

上述方式中对容器镜象进行缺陷修复的过程不适用于开发端和运营端割裂的场景，在这种情况下，对于开发端根据缺陷获取的新版本容器镜象发送给运营端需要占用较大带宽，尤其是当多个容器镜象在运行过程中出现缺陷时，需要修改的容器镜象较多，需要对多个新版本的容器镜象进行发送，体积一般会达到数G以上，不利于传输、限制了交付的效率。

发明内容

本申请实施例提供了一种打补丁方法、装置和存储介质，采用补丁包集对待打补丁对象打补丁，避免了对新版本的整个容器镜象包的发送，减小了带宽的占用，提高了交付的效率。

本申请实施例的第一方面提供一种打补丁方法，该打补丁方法可以应用于开发端和运营端割裂的场景，也可以适用于自建自营的场景等。其中打补丁方法的执行主体可以为运营端中的容器平台，该容器平台可以为服务器，下面以容器平台为例对该方法进行描述。

容器平台从开发端获取至少一个补丁包集的元数据信息，其中，所述补丁包集的元数据信息用于指示所述补丁包集的容器镜象范围，以及，所述补丁包集的版本；容器平台根据补丁包集指示的容器镜象范围和补丁包集的版本，可以获取容器平台中存储的每个容器镜象的补丁包集的版本，以及每个容器服务对应的容器实例的补丁包集的版本。

容器平台根据所述至少一个补丁包集的元数据信息，确定至少一个待打补丁对象，所述待打补丁对象为存储在容器镜象仓库中的容器镜象或在线运行的容器服务，所述待打补丁对象的当前补丁版本低于所述补丁包集的版本；其中，容器平台对补丁包集的版本和补丁包集指示的容器镜象范围对应的容器镜象或容器实例的补丁包集的版本进行对比，若容器镜象或容器实例的补丁包集的版本低于补丁包集的版本，则确定该容器镜象或容器实例为待打补丁对象。

容器平台在确定待打补丁的对象后，可以根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁。

容器镜象为层级结构，高层级的容器镜象依赖于低层级的容器镜象，容器镜象之间存在依赖关系；相应的，容器镜象对应的补丁包集之间也存在依赖关系。

在一种可能的设计中，补丁包集与其他补丁包集之间存在依赖关系，补丁包集的元数据信息还包括：所述补丁包集依赖的补丁包集的信息。容器平台根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁时，需要根据补丁包集之间的依赖关系确定执行补丁包集的顺序，对待打补丁对象打补丁。

在一种可能的设计中，补丁包集与其他补丁包集之间不存在依赖关系，补丁包集的元数据信息中不包括：所述补丁包集依赖的补丁包集的信息。相应的，容器平台根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁时，执行该补丁包集，对待打补丁对象打补丁。

上述方法中，容器平台运行的容器镜象出现缺陷时，容器平台根据该补丁包集对容器镜象的缺陷进行打补丁修复；该种方法无论是开发端和容器平台割裂的场景还是自建自营的场景，避免了修复缺陷的整个版本的容器镜象包的发送，减小了带宽的占用，提高了交付效率。

在一种可能的设计中，容器平台还可与用户交互，在容器平台确定至少一个待打补丁对象后，推送所述至少一个待打补丁对象的标识。容器平台根据用户输入的更新消息，确定更新消息对应的待打补丁对象清单，所述更新消息用于指示更新后的至少一个待打补丁对象，使得容器平台用户输入的待打补丁对象清单，对所述至少一个所述待打补丁对象进行更新。

这种容器平台与用户交互的方式，可以满足用户定制化的需求，对用户输入的更新消息中的至少一个待打补丁对象打补丁。

在一种可能的设计中，待打补丁的对象为容器镜象。容器镜象存储在容器平台的容器镜象仓库中，容器平台获取至少一个补丁包集的元数据信息后，可以从所述容器镜象仓库中获取每个容器镜象的元数据信息，其中，所述容器镜象的元数据信息用于指示所述容器镜象的标识和所述容器镜象的当前补丁版本。容器平台可以根据所述至少一个补丁包集的元数据信息，以及，每个所述容器镜象的元数据信息，确定所述至少一个待打补丁的容器镜象。

容器平台可以根据至少一个补丁包集的元数据信息中的容器镜象范围和每个容器镜象的元数据信息中的容器镜象的标识，初步确定待打补丁的容器镜象；再对补丁包集的版本和初步确定待打补丁的容器镜象的当前补丁版本，在初步确定待打补丁的容器镜象的当前补丁版本低于补丁包集的版本时，确定该初步确定待打补丁的容器镜象为待打补丁的容器镜象。

容器平台根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁；其中，容器平台根据每个所述待打补丁的容器镜象的元数据信息，以及，所述至少一个补丁包集的元数据信息，生成与每个所述待打补丁容器镜象对应的第一任务清单，所述第一任务清单用于指示根据每个所述待打补丁的容器镜象对应的补丁包集，对每个所述待打补丁的容器镜象打补丁，且容器平台执行所述第一任务清单。

所述第一任务清单包括：所述待打补丁的容器镜象的标识、所述待打补丁的容器镜象对应的补丁包集的标识，以及，所述待打补丁的容器镜象对应的补丁包集之间的依赖关系。容器平台并应执行所述第一任务清单的过程为：根据所述待打补丁的容器镜象的标识，从所述容器镜象仓库中提取所述待打补丁的容器镜象；根据所述待打补丁的容器镜象对应的补丁包集的标识，从补丁仓库中获取所述待打补丁的容器镜象对应的补丁包集；根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，对所述待打补丁的容器镜象打补丁。

容器平台在对待打补丁的容器镜象打补丁时，需要创建镜象补丁服务实例；由镜象补丁服务实例根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，通过所述镜象补丁服务实例对所述待打补丁的容器镜象打补丁。其中，无论是对容器镜象打补丁还是对容器服务打补丁，打补丁的顺序遵循的基本原则为：执行顺序都是从低层级镜象的补丁开始执行，在同一层级则根据依赖顺序关系执行，即被依赖的补丁包集先执行，没有依赖关系则可以并行执行。容器平台在对打补丁的容器镜象打完补丁后，将打完补丁后的容器镜象存储至所述容器镜象仓库。

上述方法中，在对容器镜象打补丁时，避免了修复缺陷的整个版本的容器镜象包的发送，采用修复容器镜象缺陷的补丁包集对容器镜象打补丁，减小了带宽的占用，提高了交付效率。

在一种可能的设计中，待打补丁的对象为容器镜象。容器平台获取所有在线运行的容器服务的元数据信息，其中，所述容器服务的元数据信息用于指示所述容器服务所包括的容器实例的标识和所述容器实例的当前补丁版本。容器平台根据所述至少一个补丁包集的元数据信息，以及，所有在线运行的容器服务的元数据信息，确定至少一个待打补丁的容器服务。其中，容器平台可以根据至少一个补丁包集的元数据信息中的容器镜象范围和每个容器实例的元数据信息中的容器实例的标识，初步确定待打补丁的容器实例对应的容器服务；再对补丁包集的版本和初步确定待打补丁的容器实例对应的当前补丁版本，在初步确定待打补丁的容器实例的当前补丁版本低于补丁包集的版本时，确定该初步确定待打补丁的容器实例对应的容器服务为待打补丁的容器服务。

容器平台根据所述待打补丁的容器服务，确定待打补丁的容器服务所包括的容器实例；根据所述待打补丁的容器服务所包括的容器实例，以及，所述至少一个补丁包集的元数据信息，生成第二任务清单；所述第二任务清单用于指示根据每个所述待打补丁的容器服务对应的补丁包集，对每个所述待打补丁的容器服务打补丁，且执行所述第二任务清单。

所述第二任务清单包括：所述待打补丁的容器服务所包括的每个容器实例的标识、每个所述容器实例对应的补丁包集的标识，以及，所述容器实例对应的补丁包集之间的依赖关系。容器平台执行所述第二任务清单的过程为：容器平台根据所述容器实例对应的补丁包集的标识，从所述补丁仓库中提取所述容器实例对应的补丁包集；根据所述容器实例对应的补丁包集之间的依赖关系，以及，所述容器实例对应的补丁包集，在所述容器实例所在的节点上对所述容器实例在线打补丁。该在线打补丁可以为对每个容器实例并行打补丁，或者，灰度打补丁。

其中，容器平台在对容器实例打补丁需要在所述容器实例所在的节点上，根据所述容器实例对应的补丁包集之间的依赖关系，从所述容器实例的上下文中回调安装钩子函数和激活钩子函数，以根据所述容器实例对应的补丁包集，对所述容器实例在线打补丁。

上述方法中，在对容器服务打补丁时，一方面采用修复容器镜象缺陷的补丁包集对容器镜象打补丁，减小了带宽的占用，提高了交付效率；且另一方面，实现了对容器服务在线打补丁，降低在线业务影响，在线业务可以连续不间断。

在一种可能的设计中，在对容器服务打补丁的过程中，本申请实施例提供的打补丁方法还可以实现对容器服务进行补丁状态查询处理、补丁去激活处理、补丁删除处理等。在用户需要对特定的容器服务的待处理补丁进行处理时，向容器平台发送第一请求；容器平台接收该第一请求，所述第一请求包括待处理的容器服务的标识和待处理补丁的标识。容器平台根据所述待处理的容器服务的标识，查询所述待处理的容器服务中包括所述待处理补丁的容器实例；根据所述待处理的容器服务中包括所述待处理补丁的容器实例，生成第三任务清单。

所述第三任务清单包括：所述待处理的容器服务中包括所述待处理补丁的容器实例的标识和所述待处理补丁的标识；容器平台根据第三任务清单，对所述包括所述待处理补丁的容器实例中的待处理补丁进行处理。

在一种可能的设计中，在第一请求中还可以包括对待处理的容器服务的待处理补丁的处理标识，对待处理的容器服务的待处理补丁的查询标识、去激活处理标识、补丁删除标识。容器平台根据第一请求中处理标识，对待处理的容器服务的待处理补丁进行对应的处理。

在上述方法中，本申请实施例中容器平台在实现对容器服务打补丁的过程，还可以实现对容器服务的其他处理过程，提高了容器平台对待处理补丁处理业务的灵活性。

本申请实施例的第二方面提供一种打补丁装置，该打补丁装置可以为容器平台。该打补丁装置包括：

获取模块，用于获取至少一个补丁包集的元数据信息，所述补丁包集的元数据信息用于指示所述补丁包集的容器镜象范围，以及，所述补丁包集的版本；

确定模块，用于根据所述至少一个补丁包集的元数据信息，确定至少一个待打补丁对象，所述待打补丁对象为存储在容器镜象仓库中的容器镜象或在线运行的容器服务，所述待打补丁对象的当前补丁版本低于所述补丁包集的版本；

打补丁模块，用于根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁。

在一种可能的设计中，所述补丁包集与其他补丁包集存在依赖关系，则所述补丁包集的元数据信息还包括：所述补丁包集依赖的补丁包集的信息。

该种方法无论是开发端和运营端割裂的场景还是自建自营的场景，避免了修复缺陷的整个版本的容器镜象包的发送，减小了带宽的占用，提高了交付效率。

在一种可能的设计中，所述装置还包括：推送模块和更新模块；

所述推送模块，用于推送所述至少一个待打补丁对象的标识；

所述更新模块，用于接收用户输入的更新消息，所述更新消息用于指示更新后的至少一个待打补丁对象；根据用户输入的待打补丁对象清单，对所述至少一个所述待打补丁对象进行更新。

这种容器平台与用户交互的方式，可以满足用户定制化的需求，对用户输入的更新消息中的至少一个待打补丁对象打补丁。

在一种可能的设计中，所述待打补丁对象为存储在容器镜象仓库中的容器镜象；

所述确定模块，具体用于从所述容器镜象仓库中获取每个容器镜象的元数据信息，所述容器镜象的元数据信息用于指示所述容器镜象的标识和所述容器镜象的当前补丁版本；根据所述至少一个补丁包集的元数据信息，以及，每个所述容器镜象的元数据信息，确定所述至少一个待打补丁的容器镜象。

所述打补丁模块，具体用于根据每个所述待打补丁的容器镜象的元数据信息，以及，所述至少一个补丁包集的元数据信息，生成与每个所述待打补丁容器镜象对应的第一任务清单，所述第一任务清单用于指示根据每个所述待打补丁的容器镜象对应的补丁包集，对每个所述待打补丁的容器镜象打补丁；并行执行所述第一任务清单。

其中，所述第一任务清单包括：所述待打补丁的容器镜象的标识、所述待打补丁的容器镜象对应的补丁包集的标识，以及，所述待打补丁的容器镜象对应的补丁包集之间的依赖关系；

所述打补丁模块包括：拉取单元、获取单元、打补丁单元和存储单元；

所述拉取单元，用于根据所述待打补丁的容器镜象的标识，从所述容器镜象仓库中提取所述待打补丁的容器镜象；

所述获取单元，用于根据所述待打补丁的容器镜象对应的补丁包集的标识，从补丁仓库中获取所述待打补丁的容器镜象对应的补丁包集；

所述打补丁单元，用于根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，对所述待打补丁的容器镜象打补丁；

所述存储单元，用于将打完补丁后的容器镜象存储至所述容器镜象仓库。

具体的，所述打补丁单元，具体用于创建镜象补丁服务实例；根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，通过所述镜象补丁服务实例对所述待打补丁的容器镜象打补丁。

在对容器镜象打补丁时，避免了修复缺陷的整个版本的容器镜象包的发送，采用修复容器镜象缺陷的补丁包集对容器镜象打补丁，减小了带宽的占用，提高了交付效率。

在一种可能的设计中，所述待打补丁对象为在线运行的容器服务；

所述确定模块，还用于获取所有在线运行的容器服务的元数据信息，所述容器服务的元数据信息用于指示所述容器服务所包括的容器实例的标识和所述容器实例的当前补丁版本；根据所述至少一个补丁包集的元数据信息，以及，所有在线运行的容器服务的元数据信息，确定至少一个待打补丁的容器服务。

所述打补丁模块，还用于根据所述待打补丁的容器服务，确定待打补丁的容器服务所包括的容器实例；根据所述待打补丁的容器服务所包括的容器实例，以及，所述至少一个补丁包集的元数据信息，生成第二任务清单；所述第二任务清单用于指示根据每个所述待打补丁的容器服务对应的补丁包集，对每个所述待打补丁的容器服务打补丁；执行所述第二任务清单。

所述第二任务清单包括：所述待打补丁的容器服务所包括的每个容器实例的标识、每个所述容器实例对应的补丁包集的标识，以及，所述容器实例对应的补丁包集之间的依赖关系。

所述拉取单元，还用于根据所述容器实例对应的补丁包集的标识，从所述补丁仓库中提取所述容器实例对应的补丁包集；

所述打补丁单元，还用于根据所述容器实例对应的补丁包集之间的依赖关系，以及，所述容器实例对应的补丁包集，在所述容器实例所在的节点上对所述容器实例在线打补丁。

具体的，所述打补丁单元，具体用于在所述容器实例所在的节点上，根据所述容器实例对应的补丁包集之间的依赖关系，从所述容器实例的上下文中回调安装钩子函数和激活钩子函数，以根据所述容器实例对应的补丁包集，对所述容器实例在线打补丁。

所述打补丁模块，具体用于根据所述第二任务清单，对所述待打补丁的容器服务所包括的每个容器实例并行打补丁，或者，灰度打补丁。

在对容器服务打补丁时，一方面采用修复容器镜象缺陷的补丁包集对容器镜象打补丁，减小了带宽的占用，提高了交付效率；且另一方面，实现了对容器服务在线打补丁，降低在线业务影响，在线业务可以连续不间断。

在一种可能的设计中，所述装置还包括：接收模块、查询模块和处理模块；

所述接收模块，用于接收第一请求，所述第一请求包括待处理的容器服务的标识和待处理补丁的标识；

所述查询模块，用于根据所述待处理的容器服务的标识，查询所述待处理的容器服务中包括所述待处理补丁的容器实例；

所述处理模块，用于根据所述待处理的容器服务中包括所述待处理补丁的容器实例，生成第三任务清单，所述第三任务清单包括：所述待处理的容器服务中包括所述待处理补丁的容器实例的标识和所述待处理补丁的标识；根据第三任务清单，对所述包括所述待处理补丁的容器实例中的待处理补丁进行处理。

其中，所述处理包括下述任一项：补丁状态查询处理、补丁去激活处理、补丁删除处理。

本申请实施例的第三方面提供一种打补丁装置，所述打补丁装置包括：处理器、存储器。

其中，存储器用于存储计算机可执行程序代码，程序代码包括指令；当处理器执行指令时，指令使所述打补丁装置执行如第一方面或第一方面的各可能的设计所提供的打补丁方法。

本申请实施例的第四方面提供一种打补丁装置，包括用于执行以上第一方面或第一方面各可能的设计所提供的方法的单元、模块或电路。该打补丁装置可以为服务器，也可以为应用于服务器的一个模块，例如，可以为应用于服务器的芯片。

本申请实施例的第五方面提供一种打补丁装置(例如芯片)，所述打补丁装置上存储有计算机程序，在所述计算机程序被所述打补丁装置执行时，实现如第一方面或第一方面的各可能的设计所提供的方法。

本申请实施例的第六方面提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面的各种可能的设计中的方法。

本申请实施例的第七方面提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面的各种可能的设计中的方法。

本申请实施例的第八方面提供一种打补丁系统，包括开发端和运营端，运营端可以为容器平台，即如上述第二方面或第二方面的各种可能的设计中的打补丁装置。其中，开发端可以用于向运营端中的容器平台发送补丁包集。

本申请实施例提供一种打补丁方法、装置和存储介质，该方法采用补丁包集对待打补丁对象打补丁，其中，开发端和运营端传输的是用于修复出现缺陷的容器镜象或者容器服务的补丁包集，而非整个新版本的容器镜象或者容器服务，减小了带宽的占用，提高了交付的效率。

附图说明

图1为操作系统中应用Docker的结构示意图；

图2为本申请实施例提供的容器镜象依赖关系示意图；

图3为现有技术中的容器镜象缺陷修复的结构示意图；

图4为现有技术中开发端和运营端割裂的场景示意图；

图5为本申请实施例提供的容器镜象缺陷修复的结构示意图；

图6为本申请实施例提供的打补丁方法的流程示意图一；

图7为本申请实施例提供的补丁包的格式示意图；

图8为本申请实施例提供的打补丁方法的流程示意图二；

图9为本申请实施例提供的容器平台的结构示意图；

图10为本申请实施例提供的打补丁方法的流程示意图三；

图11为本申请实施例提供的打补丁方法的流程示意图四；

图12为本申请实施例提供的打补丁方法的流程示意图五；

图13为本申请实施例提供的对容器服务处理的流程示意图；

图14为本申请实施例提供的对容器服务状态查询的流程示意图；

图15为本申请实施例提供的对容器服务去激活的流程示意图；

图16为本申请实施例提供的对容器服务删除的流程示意图；

图17为本申请实施例提供的打补丁装置的结构示意图一；

图18为本申请实施例提供的打补丁装置的结构示意图二；

图19为本申请实施例提供的打补丁装置的结构示意图三。

具体实施方式

Docker通过在操作系统上创建一个容器(容器即轻量级虚拟机)，并在容器中部署和运行应用程序的容器镜象，可以实现应用程序的自动化安装、部署。Docker可虚拟出至少两个容器，由于每个容器之间彼此独立、没有任何接口，因而可将彼此的开发环境和运行环境分开。容器技术的出现，实现了对传统应用程序，特别是基于网络的浏览器/服务器的应用程序的灵活部署和管理，同时也实现了资源的隔离和限制，满足了应用程序的快速部署及多样化的需求。随着容器技术的兴起，容器应用的使用越来越普遍，容器最大优点就是开发运行一体化，通过容器镜象打包应用，使得开发、测试和发布都具有相同的运行环境，带来极大的便利。越来越多的软件系统开始采用以容器的形式分发和部署。

图1为操作系统中应用Docker的结构示意图，图1所示的为在支持Docker运行环境的主机系统Host OS机器上创建容器，在容器中部署应用程序的结构示意图。如图1所示，一服务器中部署有主机系统，在主机系统上包括有基础镜象，如图1中的基础镜象1和基础镜象2，多个应用程序对应的容器镜象可以包括同一基础镜象，如应用程序A和应用程序A'均包括基础镜象1，应用程序B和应用程序B'均包括基础镜象2；具体的，每个应用程序中还包括自身独有的容器镜象，图1中未示出；其中，在服务器中还部署容器引擎，该容器引擎可以在主机系统中构建容器，控制容器的运行；图1中在主机系统中部署多个容器，每个容器中部署有应用程序对应的容器镜象，其中，包括应用程序A、应用程序B、应用程序A'、应用程序B'。

其中，以Docker为代表的容器镜象本身是分层的，容器镜象之间存在依赖关系；一个容器镜象对应至少一个容器实例，一个容器服务对应至少一个容器实例。示例性的，如APP对应的容器镜象包括容器镜象1、容器镜象2，容器镜象1运行后对应容器实例1，容器镜象2运行后对应容器实例2和容器实例3；容器实例1和容器实例2对应一个容器服务1。本示例仅是对容器镜象、容器实例和容器服务的对应关系进行说明。

下面结合图2对容器镜象存在依赖关系的容器镜象结构进行说明，图2为本申请实施例提供的容器镜象依赖关系示意图，如图2所示，其中包括第1层级容器镜象、第2层级容器镜象和第3层级容器镜象，图2中的每个层级中的方框为一个容器镜象，如第1层级容器镜象包括1个容器镜象，第2层级容器镜象包括3个容器镜象，第3层级容器镜象包括2个容器镜象；其中，第2层级中包括容器服务3对应的容器镜象和容器服务4对应的容器镜象，第3层级中包括容器服务1对应的容器镜象和容器服务2对应的容器镜象；图2中阴影部分的方框为容器镜象中的补丁包集，具体的，包括补丁包集P1.1、P1.2、P1.3、P2.1、P2.2、P3.1、P5.1和P5.2。

容器镜象之间存在依赖关系，容器镜象运行后对应的容器服务可以共享最低层的基础容器镜象，即第1层级容器镜象；如容器服务1对应的容器镜象、容器服务2对应的容器镜象、容器服务3对应的容器镜象和容器服务4对应的容器镜象均共享第1层级容器镜象，即基础容器镜象；高层级镜象依赖低层级镜象，如第3层级容器镜象依赖第2层级容器镜象。对应的，由于容器镜象之间存在依赖关系，每个容器镜象对应的补丁包集之间也存在依赖关系。

其中，容器服务1对应的容器镜象、容器服务2对应的容器镜象、容器服务3对应的容器镜象和容器服务4对应的容器镜象，都依赖最低层级的基础容器镜象；容器服务1对应的容器镜象和容器服务2对应的容器镜象均依赖第2层级的开发包镜象，如开发包镜象可以为java开发包(java development kit)镜象，开发包镜象又依赖第一层级的基础容器镜象。图中具有阴影的小方框代表某层级容器镜象的一个补丁包集，比如容器服务2对应的容器镜象和容器服务4对应的容器镜象没有补丁包集，但其依赖的容器镜象有补丁包集，容器服务1对应的容器镜象和容器服务3对应的容器镜象都有各自的补丁包集。

容器镜象是对应用程序的代码及其运行环境进行标准化封装，得到的一种特殊的文件系统，可直接运行在任何安装有容器的操作系统中，容器镜象提供了容器运行时所需的各种程序文件、库文件和配置文件，是容器得以运行的基础。

容器镜象是静态资源，其不包含任何动态数据，且其内容在构建之后就不会被改变，容器镜象可以存储在磁盘或者镜象服务器中；容器镜象在容器中进行运行后对应为容器实例，同一个容器镜象可以运行多次，生成多个容器实例，容器服务是指基于容器镜象机制部署的微服务，一个容器服务可以有多个服务实例，每个服务实例对应一个容器实例。

图3为现有技术中的容器镜象缺陷修复的结构示意图，现有技术中的容器镜象缺陷修复的场景中包括应用程序的开发端和运营端。其中，开发端可以包括源码控制系统和容器镜象构建系统，运营端可以包括容器平台、至少一个节点和容器镜象仓库。

源码控制系统，用于对应用程序对应的代码及其运行环境进行发布，其中发布的可以是该应用程序的初始代码及其初始运行环境，即首次发布；也可以是对该应用程序的新版本对应的代码及其运行环境进行发布。

容器镜象构建系统，用于根据应用程序发布的代码及其运行环境，进行应用程序对应的容器镜象的构建，获取应用程序对应的容器镜象包。

容器平台，用于在至少一个节点上部署容器(图3中未示出)。

容器镜象仓库，用于对应用程序对应的容器镜象包进行存储。

至少一个节点，用于运行使用容器镜象创建的容器实例，为用户提供该容器实例对应的容器服务。

若在自建自营的场景中，即应用程序的开发端和运营端可以位于同一局域网内，示例性的，如图3所示，其中的开发端和运营端分别可以为容器镜象包的生产商和运营商，生产商和运营商为一家商家，均处于同一局域网。在生产商将容器镜象包开发好后，直接存储在运营商的容器镜象仓库，或者，采用内网将容器镜象包发送给运营商。

其中对于应用程序的容器镜象包的发送可以依靠内网或者自身独有的传输机制；在运营端对容器镜象的运行出现缺陷时，运营端可以将缺陷返回给开发端，开发端中的源码控制系统根据该缺陷对上一版本的应用程序的代码或者应用环境进行升级，发布新版本的应用程序，进而使得容器镜象构建系统重新对该应用程序的新版本的代码或者应用环境进行容器镜象的构建，获取新版本的容器镜象包，将该新版本的容器镜象包发送给运营端。运营端采用新版本的容器镜象包实现对容器镜象的运行。

而这种修复方式对于开发端和运营端割裂的场景，图4为现有技术中开发端和运营端割裂的场景示意图；开发端和运营端割裂的场景如当前通讯技术产业(communicationtechnology)为代表的产品化交付场景，示例性的，如容器镜象包的生产商和运营商属于不同的厂商，二者处于不同的局域网中，需要通过外网进行容器镜象包的传输。其中，运营端和开发端可与上述中的运营端和开发端的作用相同。

若运营端实现对容器镜象的运行出现缺陷时，开发端需要将解决该缺陷的新版本的容器镜象包发送给运营端，由于开发端和运营端割裂，因此可能采用外网进行新版本的容器镜象包的传输，需要占用较大带宽；若多个容器镜象在运行时均出现缺陷，需要外用外网进行多个新版本容器镜象包的传输，占用的带宽更大，传输速度慢，交付效率低。

进一步的，每个容器镜象包中包括基础镜象和每个容器镜象包对应的独有镜象，该独有镜象用于实现不同的镜象服务。当一个容器镜象包中的基础镜象有缺陷时，则引用此基础镜象的所有容器服务都需要重新构建容器镜象包，由于容器镜象包大，不利于存放和传输，限制了交付的效率。

为了解决上述问题，本申请实施例中提供了一种打补丁方法，图5为本申请实施例提供的容器镜象缺陷修复的结构示意图，如图5所示，在开发端增加补丁构建系统，在运营端构建补丁仓库；其中，补丁构建系统，用于针对运营端反馈的缺陷进行补丁包的开发，补丁仓库用于存储补丁包集。在开发端进行初始发布时，可以对应用程序的容器镜象包发送给运营端中的容器平台，容器平台将对应的容器镜象包存储在容器镜象仓库中，且实现对容器镜象的运行；在运营端中的容器镜象产生缺陷时，可以将缺陷反馈至开发端，开发端中的补丁构建系统针对该缺陷构建补丁包，其将补丁包发送给运营端中的容器平台，容器平台将补丁包存储在补丁仓库中，且使用补丁包对容器镜象的缺陷进行修复，即打补丁。本实施例中的打补丁方法可以实现对容器镜象打补丁，也可实现对在线运行的容器服务打补丁。下述实施例中对容器平台根据补丁包对容器镜象或容器服务打补丁的过程进行具体说明。

本申请实施例中提供的打补丁方法，采用补丁包集对待打补丁对象打补丁，避免了整个新版本的容器镜象或者容器服务的传输，减小了带宽的占用，提高了交付的效率。本申请实施例的方法可以适用于开发端和运营端割裂的场景，也可以适用于自建自营的场景等。

下面结合具体地实施例对本申请实施例的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图6为本申请实施例提供的打补丁方法的流程示意图一。本申请实施例中的打补丁的方法的执行主体为运营端中的容器平台，该容器平台可以服务器；该服务器可以用于进行本申请实施例中的打补丁方法，也可以实现容器部署，容器镜象运行等过程；下述实施例中以容器平台为执行主体对打补丁方法进行说明；如图6所示，本实施例所述的打补丁方法包括如下步骤：

步骤S601、获取至少一个补丁包集的元数据信息，补丁包集的元数据信息用于指示补丁包集的容器镜象范围，以及，补丁包集的版本。

本实施例中，容器平台运行容器镜象，为用户提供容器服务；在容器镜象运行过程中产生缺陷时，可以将该缺陷发送给开发端，开发端根据该缺陷生成修复该缺陷的补丁包集，即补丁包集为产生缺陷的容器镜象或容器服务打补丁，下述均以为容器镜象打补丁作为对容器镜象的修复；其中，修复一个容器镜象的缺陷的补丁包可以为至少一个，本实施例中将修复一个容器镜象的缺陷的补丁包作为一个补丁包集。在容器平台中，可以有多个应用程序的容器镜象同时运行；当多个容器镜象先生缺陷时，开发端可以根据多个缺陷生成多个补丁包集。

其中，在开发端生成至少一个补丁包集后，可以将该至少一个补丁包集发送给容器平台；具体的，在每个补丁包集携带有补丁包集的元数据信息，容器平台可以根据至少一个补丁包集携带的元数据信息，获取至少一个补丁包集的元数据信息。或者，本实施例中，开发端也可以将生成的至少一个补丁包集携带的元数据信息发送给容器平台，使得容器平台获取至少一个补丁包集的元数据信息。

本实施例中的补丁包集的元数据信息用于指示补丁包集的容器镜象范围，以及，补丁包集的版本。其中，补丁包集的容器镜象范围为该补丁包集用于打补丁的容器镜象的范围；补丁包集中携带有对应修复的镜象的标识，补丁包集的容器镜象范围可以为包含有该标识的镜象的所有的容器镜象，也可以是依赖该标识的镜象的所有的容器镜象；如补丁包集为容器镜象中的基础镜象的补丁包集，则该补丁包集指示的容器镜象范围为包含有该基础镜象的多个容器镜象。

其中，补丁包集的版本高于其打补丁容器镜象的版本；示例性的，若待打补丁的容器镜象的版本为1.0，则为其打补丁的补丁包集的版本为高于待打补丁的容器镜象的版本，如2.0。具体的，补丁包集的版本可以根据带打补丁容器镜象的版本生成。

步骤S602、根据至少一个补丁包集的元数据信息，确定至少一个待打补丁对象，待打补丁对象为存储在容器镜象仓库中的容器镜象或在线运行的容器服务，待打补丁对象的当前补丁版本低于补丁包集的版本。

本实施例中，容器镜象仓库中存储有容器镜象，以及容器镜象的元数据信息，如容器镜象的标识和容器镜象的当前补丁版本，容器镜象对应的在线运行的容器服务也具有当前补丁版本标识；容器平台在获取至少一个补丁包集的元数据信息后，根据至少一个补丁包集容器镜象范围，以及，补丁包集的版本，确定至少一个待打补丁对象；具体的，待打补丁对象为存储在容器镜象仓库中的容器镜象或在线运行的容器服务，其中，确定的至少一个待打补丁对象的当前补丁版本低于补丁包集的版本。

其中，确定至少一个待打补丁对象的过程可以为：根据至少一个补丁包集容器镜象范围，在容器镜象仓库中确定待打补丁的容器镜象，再通过比较补丁包集的版本和待打补丁的容器镜象的当前补丁版本，确定待打补丁的容器镜象或在线运行的容器服务；若根据补丁包集容器镜象范围确定的待打补丁的容器镜象的版本与补丁包集的当前补丁版本相同时，确定该待打补丁的容器镜象未产生缺陷，再比较该容器镜象对应的在线运行的容器服务的当前补丁版本与补丁包集的版本，若在线运行的容器服务的当前补丁版本小于该补丁包集的版本，则确定该容器镜象对应的在线运行的容器服务为待打补丁的对象；若根据补丁包集容器镜象范围确定的待打补丁的容器镜象的当前补丁版本小于补丁包集的版本，则确定该待打补丁的容器镜象产生确缺陷，即该容器镜象为待打补丁的对象。或者，

也可根据至少一个补丁包集容器镜象范围，在容器镜象仓库中确定待打补丁的容器镜象，同时比较待打补丁的容器镜象的当前补丁版本、该待打补丁的容器镜象对应的在线运行的容器服务的当前补丁版本与补丁包集的版本；若待打补丁的容器镜象的当前补丁版本或该待打补丁的容器镜象对应的在线运行的容器服务的当前补丁版本，低于补丁包集的版本，则确定待打补丁的容器镜象或该待打补丁的容器镜象对应的在线运行的容器服务为待打补丁的对象。本实施例中对根据至少一个补丁包集的元数据信息，确定至少一个待打补丁对象的方式进行示例说明，值得注意的是，本领域的技术人员也可采用其他方式根据至少一个补丁包集的元数据信息，确定至少一个待打补丁对象。

步骤S603、根据每个待打补丁对象对应的补丁包集，对每个待打补丁对象打补丁。

本实施例中，在根据至少一个补丁包集的元数据信息确定待打补丁对象后，可以获取每个待打补丁对象对应的补丁包集；其中，若开发端在向容器平台发送补丁包集时已将对应的至少一个补丁包集发送给容器平台，则容器平台直接根据接收到的至少一个补丁包集中的每个待打补丁对象对应的补丁包集，对每个待打补丁对象打补丁。

其中，本实施例对待打补丁对象打补丁过程可以为：当待打补丁对象为容器镜象时，回调容器镜象对应的安装钩子函数，对容器镜象对应的补丁包集进行安装；当待打补丁对象为容器服务时，确定容器服务对应的容器实例，回调容器实例对应的安装钩子函数，对容器服务对应的补丁包集进行安装，在对补丁包集进行安装后，由于容器服务是在线运行的，还需要回调容器实例对应的激活钩子函数，对安装后的补丁包集进行激活，以实现容器服务的在线打补丁，且不影响在线容器服务。

可选的，本实施例中，容器平台还可与用户交互，在容器平台确定至少一个待打补丁对象后，由用户选择最终进行打补丁的目标对象。具体的，示例性的，如在容器平台的显示界面上显示至少一个待打补丁对象的标识和选择控件；用户可以对需要更新的待打补丁对象进行更新选择，在用户对待打补丁对象选择后，触发容器平台接收用户输入的更新消息，其中，该更新消息用于指示更新后的至少一个待打补丁对象，即目标对象。

容器平台根据更新消息，确定更新消息对应的待打补丁对象清单，该清单中可以包括目标对象的标识，使得容器平台采用上述打补丁的方式对至少一个待打补丁对象进行更新。其中，当待打补丁对象为容器镜象时，可以通过容器平台现有的灰度打补丁的方式对打过补丁的容器镜象进行更新。当待打补丁对象为容器服务时，由于容器服务为在线运行的，可以通过热更新的方式对打过补丁的容器服务进行更新。

本申请实施例提供的打补丁方法，根据开发端发送的补丁包集，补丁包集用于对容器镜象或者容器服务的缺陷进行修复；一方面，打补丁的方法支持在线对容器镜象和容器服务打补丁，而不需要通过发布新版本容器镜象包后在线升级的方式实现缺陷修正，补丁包集相对于整个版本的容器镜象包具有更小的体积，减小了开发端和运营端之间的带宽的占用，且在线对运行中的容器服务打补丁，可以降低在线业务影响；另一方面，当容器镜象包中的基础镜象发生缺陷时，开发端针对该发生缺陷的基础镜象生成补丁包，避免了对每个容器镜象均生成新版本的容器镜象包造成占用带宽大的问题，提高了交付效率。

容器平台在根据补丁包集对待打补丁的对象进行打补丁时，该补丁包集可能与其他补丁包集存在依赖关系，该依赖关系用于表示在其他依赖包的共同作用下，能够实现对待打补丁对象打补丁，即实现对待打补丁对象的完整升级。

图7为本申请实施例提供的补丁包的格式示意图，如图7所示，每个补丁包中包括补丁包的标识、补丁包的版本、容器镜象范围、补丁类型和在打补丁过程中所用的钩子函数外，还包括该补丁包存在依赖关系的补丁包信息；其中，存在依赖关系的补丁包信息包括该补丁包依赖的补丁包的名称和容器镜象范围。具体的，其中补丁类型可以为冷补丁或者热补丁，热补丁为在线实现打补丁，对应的容器镜象可以采用冷补丁或者热补丁，容器服务采用热补丁实现在线打补丁，其中采用在线打补丁的方式对运行中的容器服务打补丁，可以不间断的提供容器服务，降低对在线业务影响；打补丁过程中所用的钩子函数可以包括安装钩子函数、激活钩子函数、去激活钩子函数、状态钩子函数和卸载钩子函数等。值得注意的是，补丁包中还包括补丁程序文件和补丁包的签名数据。

在补丁包集与其他补丁包集存在依赖关系时，补丁包集的元数据信息还包括：补丁包集依赖的补丁包集的信息。对应的，容器平台根据该依赖关系和补丁包集对待打补丁的对象进行打补丁时，由于补丁包集存在依赖关系，则对于打补丁过程中执行补丁的先后顺序有所不同。

由于对容器镜象和容器实例打补丁的过程不同，下述实施例分别对容器镜象和容器实例打补丁进行说明。下面结合图8为对容器镜象打补丁的过程进行说明，图8为本申请实施例提供的打补丁方法的流程示意图二，如图8所示，本实施例提供的打补丁方法包括：

步骤S801、获取至少一个补丁包集的元数据信息。

本实施例中的步骤S801中的实施方式可以参照上述实施例步骤S601中的相关描述，在此不做赘述。

步骤S802、从容器镜象仓库中获取每个容器镜象的元数据信息，容器镜象的元数据信息用于指示容器镜象的标识和容器镜象的当前补丁版本。

本实施例中，容器镜象仓库中存储有多个容器镜象，以及每个容器镜象的元数据信息，其中，容器镜象的元数据信息用于指示容器镜象的标识和容器镜象的当前补丁版本；具体的，在容器平台获取至少一个补丁包集的元数据信息后，为了确定待打补丁的对象，从容器镜象仓库中获取每个容器镜象的元数据信息。

容器平台可以根据至少一个补丁包集的元数据信息中的补丁包集的容器镜象范围、补丁包集的版本，以及每个容器镜象的标识和每个容器镜象的当前补丁版本，确定容器镜象仓库中是否有待打补丁的容器镜象。

步骤S803、根据至少一个补丁包集的元数据信息，以及，每个容器镜象的元数据信息，确定至少一个待打补丁的容器镜象。

本实施例中的待打补丁对象为存储在容器镜象仓库中的容器镜象；容器平台根据至少一个补丁包集的元数据信息，以及，每个容器镜象的元数据信息，确定至少一个待打补丁的容器镜象。

具体的，根据至少一个补丁包集的元数据信息中的补丁包集的容器镜象范围和每个容器镜象的标识，确定每个补丁包集对应的待打补丁的容器镜象；根据补丁包集的版本，以及每个容器镜象的当前补丁版本确定待打补丁的容器镜象，若根据补丁包集的容器镜象范围确定的容器镜象的当前补丁版本低于补丁包集的版本时，该容器镜象为待打补丁的容器镜象。

步骤S804、根据每个待打补丁的容器镜象的元数据信息，以及，至少一个补丁包集的元数据信息，生成与每个待打补丁容器镜象对应的第一任务清单，第一任务清单用于指示根据每个待打补丁的容器镜象对应的补丁包集，对每个待打补丁的容器镜象打补丁。

本实施例中，根据每个待打补丁的容器镜象的元数据信息和至少一个补丁包集的元数据信息，可以确定容器镜象仓库中的待打补丁的容器镜象对应的补丁包集，具体生成与每个待打补丁容器镜象对应的第一任务清单，其中，该第一任务清单用于指示根据每个待打补丁的容器镜象对应的补丁包集，对每个待打补丁的容器镜象打补丁。

具体的，若待打补丁的容器镜象与其他容器镜象之间不存在依赖关系时，容器镜象对应的补丁包集与其他其他补丁包集也不存在依赖关系，则第一任务清单中可以包括待打补丁的容器镜象的标识、待打补丁的容器镜象对应的补丁包集的标识，使得容器平台根据该第一任务清单中的标识，获取待打补丁的容器镜象对应的补丁包集，对该待打补丁的容器镜象打补丁。

若补丁包集与其他其他补丁包集存在依赖关系，则第一任务清单中可以包括待打补丁的容器镜象的标识、待打补丁的容器镜象对应的补丁包集的标识，以及待打补丁的容器镜象对应的补丁包集之间的依赖关系；使得容器平台根据该第一任务清单中的标识，获取待打补丁的容器镜象对应的补丁包集和与该补丁包集具有依赖关系的其他补丁包集，对该待打补丁的容器镜象打补丁。

步骤S805、执行第一任务清单。

下面从两种情况对执行第一任务清单的过程进行说明，可以为并行执行第一任务清单。一种情况为待打补丁的容器镜象对应的补丁包集与其他补丁包集之间存在依赖关系；另一种情况为待打补丁的容器镜象对应的补丁包集与其他补丁包集之间不存在依赖关系。

一种情况为：当待打补丁的容器镜象对应的补丁包集与其他补丁包集之间存在依赖关系时，第一任务清单包括：待打补丁的容器镜象的标识、待打补丁的容器镜象对应的补丁包集的标识，以及，待打补丁的容器镜象对应的补丁包集之间的依赖关系。

其中，执行第一任务清单的过程可以为：容器平台根据待打补丁的容器镜象的标识，从容器镜象仓库中提取待打补丁的容器镜象；根据待打补丁的容器镜象对应的补丁包集的标识，从补丁仓库中获取待打补丁的容器镜象对应的补丁包集；根据待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，待打补丁的容器镜象对应的补丁包集，对待打补丁的容器镜象打补丁。

具体的，由于待打补丁的容器镜象为静态资源，因此在对容器镜象打补丁之前，为待打补丁的容器镜象创建镜象补丁服务实例，再根据待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，待打补丁的容器镜象对应的补丁包集，通过镜象补丁服务实例对待打补丁的容器镜象打补丁。其中，对容器镜象打补丁的顺序和方式可如下所述：

图2中的高层级镜象依赖低层级镜象，对应的补丁包集之间也存在依赖关系。下面以对图2中的容器服务1对应的静态容器镜象打补丁的过程进行说明，打补丁的顺序遵循的基本原则为：无论是给镜象打补丁，还是给容器打补丁，执行顺序都是从低层级镜象的补丁开始执行，在同一层级则根据依赖顺序关系执行，即被依赖的补丁包集先执行，没有依赖关系则可以并行执行。

对容器服务1对应的容器镜象打补丁：由于容器镜象为静态资源，可采用热升级或者线下升级的方式进行。其中，对容器服务1对应的容器镜象打补丁的过程为：步骤a)回调补丁包集P1.1和补丁包集P1.3中的安装函数钩子，对补丁包集P1.1和补丁包集P1.3进行安装；步骤b)补丁包集P1.1安装完成后，回调补丁包集P1.2中的安装函数钩子，对补丁包集P1.2进行安装；步骤c)补丁包集P1.2安装完成后，回调补丁包集P2.1中的安装函数钩子，对补丁包集P2.1进行安装，接着回调补丁包集P2.2中的安装函数钩子，对补丁包集P2.2进行安装；步骤d)补丁包集P2.2安装完成后，回调补丁包集P3.1中的安装函数钩子，对补丁包集P3.1进行安装；在执行完步骤d)执行完成后，将打补丁的容器镜象存储至容器镜象仓库中。

另一种情况为：当待打补丁的容器镜象对应的补丁包集与其他补丁包集之间不存在依赖关系时，第一任务清单包括：待打补丁的容器镜象的标识、待打补丁的容器镜象对应的补丁包集的标识。

其中，执行第一任务清单的过程可以为：容器平台根据待打补丁的容器镜象的标识，从容器镜象仓库中提取待打补丁的容器镜象；根据待打补丁的容器镜象对应的补丁包集的标识，从补丁仓库中获取待打补丁的容器镜象对应的补丁包集；根据待打补丁的容器镜象对应的补丁包集，对待打补丁的容器镜象打补丁。

具体的，在对容器镜象打补丁之前，为待打补丁的容器镜象创建镜象补丁服务实例，再根据待打补丁的容器镜象对应的补丁包集，通过镜象补丁服务实例对待打补丁的容器镜象打补丁。

本实施例中在对待打补丁的容器镜象打完补丁后，获取无缺陷的容器镜象，再将打完补丁后的容器镜象存储至容器镜象仓库，使得容器平台可以运行打完补丁后的容器镜象。

具体的，在实际应用过程中，图9为本申请实施例提供的容器平台的结构示意图，如图9所示，在容器平台中包括主节点和工作节点，主节点和工作节点连接；值得注意的是，图9中具有阴影的模块为本申请实施例中的新增模块。

本实施例中在主节点中设置有仓库，其中包括容器镜象仓库，本实施例中在该仓库中增加补丁仓库(patch repository)，用于存储开发端发送的补丁包集；在主节点中设置有控制器，其中控制器包括容器生命周期控制器(container lifecycle controller)，本实施例中在主节点中还增加镜象补丁控制器(image patch controller)和容器补丁控制器(container patch controller)；此外，主节点中还设置有容器调度器(containerscheduler)。

工作节点中可设置多个应用服务容器实例，图中将多个应用服务容器实例叠加示出；工作节点中还设置有代理装置，该代理装置中包括容器生命周期执行器(containerlifecycle executor)，本实施例中还增加了容器补丁执行器(container patchexecutor)。且进一步的，本实施例中的工作节点中增加了多个镜象补丁服务实例(Imagepatch service instance)，用于创建临时容器，在打补丁的过程中，实现对补丁包集中的钩子函数的调用，图中将多个镜象补丁服务实例叠加示出。其中，临时容器和代理装置分别与主节点连接，代理装置分别与临时容器、应用服务容器实例连接。

图10为本申请实施例提供的打补丁方法的流程示意图三，如图10所示，在实际打补丁的过程中，用户可以一次性提交多个补丁包集到补丁仓库，在用户确定对容器镜象进行打补丁后，包括：

步骤S1001、镜象补丁控制器，从补丁仓库中获取至少一个补丁集的元数据信息。

步骤S1002、镜象补丁控制器从容器镜象仓库中获取所有容器镜象的标识和当前补丁版本。

步骤S1003、镜象补丁控制器根据至少一个补丁集的元数据信息、所有容器镜象的标识和当前补丁版本，确定待打补丁的对象，并生成候选任务清单。

步骤S1004、镜象补丁控制器将候选任务清单返回给用户。其中，镜象补丁控制器可以根据至少一个补丁集的元数据信息、所有容器镜象的标识和当前补丁版本，将已经打过补丁的容器镜象进行排除。

步骤S1005、镜象补丁控制器根据用户的操作信息，生成对应的第一任务清单。其中，用户可以在候选任务清单中选择待打补丁的目标对象，或者将候选任务清单中所有待打补丁的对象作为待打补丁的目标对象，并提交给镜象补丁控制器。

步骤S1006、镜象补丁控制器把生成的第一任务清单发送给容器生命周期控制器。

步骤S1007、容器生命周期控制器将第一任务清单发送给容器调度器。

步骤S1008、容器调度器根据第一任务清单在空闲节点创建临时容器。

步骤S1009、容器生命周期执行器对该临时容器进行运行。

步骤S10010、容器生命周期执行器对该临时容器进行运行时，由镜象补丁服务实例根据容器镜象对应的补丁包集，从补丁仓库中获取容器镜象对应的补丁包集。

步骤S10011、镜象补丁服务实例从容器镜象仓库中获取待打补丁的容器镜象。

步骤S10012、镜象补丁服务实例采用补丁包集对待打补丁的容器镜象打补丁，进而生成打过补丁后的新的容器镜象。

步骤S10013、镜象补丁服务实例将打过补丁后的新的容器镜象存储至容器镜象仓库。

步骤S10014、当第一任务清单中的待打补丁的容器镜象的打补丁任务执行完后，镜象补丁服务实例向容器生命周期执行器发送任务完成消息。

步骤S10015、容器生命周期执行器向容器生命周期控制器发送该任务完成消息。

步骤S10016、容器生命周期控制器将任务完成消息返回给镜象补丁控制器。再由镜象补丁控制器将任务完成消息返回给用户。

本实施例中，对于冷补丁，可通过容器平台提供的线下升级流程实现打过补丁的容器镜象的更新。对于已有容器实例如果发生故障需要重建实例，或者扩容新建容器实例，可以使用新的容器镜象创建。

本实施例中，一方面，打补丁的方法不需要通过发布新版本容器镜象包后在线升级的方式实现缺陷修正，补丁包集相对于整个版本的容器镜象包具有更小的体积，减小了开发端和运营端之间的带宽的占用，提高了交付效率；另一方面，当容器镜象包中的基础镜象发生缺陷时，开发端针对该发生缺陷的基础镜象生成补丁包，避免了对每个容器镜象均生成新版本的容器镜象包造成占用带宽大的问题。

下面结合图11为对容器服务打补丁的过程进行说明，图11为本申请实施例提供的打补丁方法的流程示意图四，如图11所示，本实施例提供的打补丁方法包括：

步骤S1101、获取至少一个补丁包集的元数据信息。

本实施例中的步骤S1101中的实施方式可以参照上述实施例步骤S601中的相关描述，在此不做赘述。

步骤S1102、获取所有在线运行的容器服务的元数据信息，容器服务的元数据信息用于指示容器服务所包括的容器实例的标识和容器实例的当前补丁版本。

一个在线运行的容器服务包括至少一个容器实例，本实施例中的待打补丁对象为在线运行的容器服务。为了确定待打补丁的容器服务，容器平台获取所有在线运行的容器服务的元数据信息，其中，容器服务的元数据信息用于指示容器服务所包括的容器实例的标识和容器实例的当前补丁版本，而容器实例与容器镜象具有对应关系，因此根据容器服务的元数据信息和至少一个补丁包集的元数据信息，可以获取确定待打补丁的容器服务。

步骤S1103、根据至少一个补丁包集的元数据信息，以及，所有在线运行的容器服务的元数据信息，确定至少一个待打补丁的容器服务。

本实施例中，容器平台根据至少一个补丁包集的元数据信息中的补丁包集的容器镜象范围和每个容器实例的标识，确定每个补丁包集对应的待打补丁的容器实例，由于容器镜象和容器实例具有对应关系，因此可以根据补丁包集的容器镜象范围确定对应的待打补丁的容器实例，根据待打补丁的容器实例可以确定待打补丁的容器服务。根据补丁包集的版本，以及每个容器实例的当前补丁版本确定待打补丁的容器实例，若根据补丁包集的容器镜象范围确定的容器实例的当前补丁版本低于补丁包集的版本时，该容器实例为待打补丁的容器实例，该待打补丁的容器实例对应的容器服务为待打补丁的容器服务。

步骤S1104、根据待打补丁的容器服务，确定待打补丁的容器服务所包括的容器实例。

如上步骤S1104，容器服务和容器实例具体对应关系，在获取待打补丁的容器服务后，相应的可以获取待打补丁的容器服务所包括的容器实例。

步骤S1105、根据待打补丁的容器服务所包括的容器实例，以及，至少一个补丁包集的元数据信息，生成第二任务清单；第二任务清单用于指示根据每个待打补丁的容器服务对应的补丁包集，对每个待打补丁的容器服务打补丁。

其中，根据待打补丁的容器服务所包括的容器实例，以及，至少一个补丁包集的元数据信息，生成第二任务清单的具体方式可以与上述实施例中生成第一任务清单的方式相同。但第二任务清单与第一任务清单用于指示打补丁的方式和对象不同。

本实施例中的第二任务清单具体用于指示容器平台根据每个待打补丁的容器服务对应的补丁包集，对每个待打补丁的容器服务打补丁。

步骤S1106、执行第二任务清单。

本实施例中执行第二任务清单的过程也可以分为两种情况。一种情况为待打补丁的容器镜象对应的补丁包集与其他补丁包集之间存在依赖关系；另一种情况为待打补丁的容器镜象对应的补丁包集与其他补丁包集之间不存在依赖关系。

下面对这两种情况进行说明，一种情况：待打补丁的容器镜象对应的补丁包集与其他补丁包集之间存在依赖关系时，第二任务清单包括：待打补丁的容器服务所包括的每个容器实例的标识、每个容器实例对应的补丁包集的标识，以及，容器实例对应的补丁包集之间的依赖关系。

具体的，容器平台执行第二任务清单的具体过程为：根据容器实例对应的补丁包集的标识，从补丁仓库中提取容器实例对应的补丁包集；根据容器实例对应的补丁包集之间的依赖关系，以及，容器实例对应的补丁包集，在容器实例所在的节点上对容器实例在线打补丁。

其中，对容器实例在线打补丁可以在容器服务对应的容器实例所在的节点上，根据容器实例对应的补丁包集之间的依赖关系，从容器实例的上下文中回调安装钩子函数和激活钩子函数，以根据容器实例对应的补丁包集，对容器实例在线打补丁。具体的，本实施例中对容器服务打补丁的方式为根据第二任务清单，对待打补丁的容器服务所包括的每个容器实例并行打补丁，或者，灰度打补丁，其中灰度打补丁为串行打补丁的方式，即一个一个对每个容器实例的补丁包集进行安装。本实施例中对存在依赖关系的补丁包集的打补丁方式如下所述：

以图2中的补丁包集的依赖关系，对容器服务1打补丁的过程进行说明，打补丁的顺序遵循的基本原则为：无论是给镜象打补丁，还是给容器服务打补丁，执行顺序都是从低层级容器镜象的补丁开始执行，在同一层级则根据依赖顺序关系执行，即被依赖的补丁包集先执行，没有依赖关系则可以并行执行。

对容器服务1打补丁：由于容器服务1是动态资源，容器镜象运行后为容器实例，为用户提供容器服务，容器服务采用热升级的方式打补丁，即在线打补丁。由于容器服务1为在线运行的，则对容器服务1打补丁时，步骤a)回调补丁包集P1.1和补丁包集P1.3中的安装函数钩子，对补丁包集P1.1和补丁包集P1.3进行安装；步骤b)补丁包集P1.1安装完成后，回调补丁包集P1.2中的安装函数钩子，对补丁包集P1.2进行安装；步骤c)补丁包集P1.2安装完成后，回调补丁包集P2.1中的安装函数钩子，对补丁包集P2.1进行安装，接着回调补丁包集P2.2中的安装函数钩子，对补丁包集P2.2进行安装；步骤d)补丁包集P2.2安装完成后，回调补丁包集P3.1中的安装函数钩子，对补丁包集P3.1进行安装；步骤e)回调所有补丁包集的激活函数钩子激活所有的补丁，实现对容器服务1打补丁。

另一种情况：待打补丁的容器镜象对应的补丁包集与其他补丁包集之间存在依赖关系时，第二任务清单包括：待打补丁的容器服务所包括的每个容器实例的标识、每个容器实例对应的补丁包集的标识。

具体的，容器平台执行第二任务清单的具体过程为：根据容器实例对应的补丁包集的标识，从补丁仓库中提取容器实例对应的补丁包集；容器实例对应的补丁包集，在容器实例所在的节点上对容器实例在线打补丁。

其中，对容器实例在线打补丁可以在容器服务对应的容器实例所在的节点上，根据容器实例对应的补丁包集之间的依赖关系，从容器实例的上下文中回调安装钩子函数和激活钩子函数，以根据容器实例对应的补丁包集，对容器实例在线打补丁。其中，对待打补丁的容器服务所包括的每个容器实例并行打补丁，或者，灰度打补丁。

图12为本申请实施例提供的打补丁方法的流程示意图五，如图12所示，具体的，在实际应用过程中，用户可以一次性提交多个补丁包集到补丁仓库，在用户确定对容器服务进行打补丁后，包括

步骤S1201、容器补丁控制器获取补丁仓库中至少一个补丁包集的元数据信息。

步骤S1202、容器补丁控制器获取所有在线运行的容器服务所包括的容器实例的标识和容器实例的当前补丁版本。

步骤S1203、容器补丁控制器根据至少一个补丁包集的元数据信息、所有容器实例的标识和当前补丁版本，确定待打补丁的对象，并生成候选任务清单。

步骤S1204、容器补丁控制器将候选任务清单返回给用户。其中，容器补丁控制器可以根据至少一个补丁集的元数据信息、所有容器实例的标识和当前补丁版本，将已经打过补丁的容器服务进行排除。

步骤S1205、容器补丁控制器根据用户的操作信息，在容器服务中查询待打补丁的容器服务对应的容器实例，生成第二任务清单。用户可以在候选任务清单中选择待打补丁的目标对象，或者将候选任务清单中所有待打补丁的对象作为待打补丁的目标对象。

步骤S1206、将第二任务清单发送给容器补丁执行器。

步骤S1207、容器补丁执行器可以根据待打补丁的容器服务对应的补丁包集，从补丁仓库中获取容器服务对应的补丁包集。

步骤S1208、容器补丁执行器根据预设打补丁策略，并行或串行执行不同容器服务的补丁，直至完成。其中，容器补丁执行器根据补丁包集中补丁包的依赖关系在容器实例上下文回调安装函数钩子和激活函数钩子，实现对补丁包集中的补丁的安装和激活。

步骤S1209、在容器补丁执行器打完补丁后，向容器补丁控制器发送任务完成消息，进而由容器补丁控制器将该消息返回给用户。

本实施例中，打补丁的方法仅对补丁包集进行传输，补丁包集相对于整个版本的容器镜象包具有更小的体积，减小了开发端和运营端之间的带宽的占用，且在线对运行中的容器服务打补丁，可以降低在线业务影响。

在上述实施例的基础上，本申请实施例提供的容器平台在实现对容器服务打补丁的过程，还可以实现对容器服务的其他处理过程，本实施例中的对容器服务的其他处理过程可以与上述实施例中的打补丁方式并行执行，也可在上述实施例中的打补丁方式之前或之后执行。

图13为本申请实施例提供的对容器服务处理的流程示意图，如图13所示，本实施例提供的对容器服务处理过程包括：

步骤S1301、接收第一请求，第一请求包括待处理的容器服务的标识和待处理补丁的标识。

本实施例中，用户确定需要对容器服务打补丁或者其他处理后，可以在容器平台进行相关处理方式的选择，具体的，该处理包括下述任一项：打补丁处理、补丁状态查询处理、补丁去激活处理、补丁删除处理。示例性的，在容器平台的显示界面上显示有对容器服务的多种处理选择控件，每种处理选择控件对应一种处理过程，用户对处理选择控件的选择触发容器平台接收第一请求。

其中，该第一请求包括待处理的容器服务的标识和待处理补丁的标识。相应的，可以实现对待处理的容器服务的待处理补丁进行打补丁、补丁状态查询处理、补丁去激活处理、补丁删除处理等过程。具体的，对待处理的容器服务的待处理补丁进行打补丁方法具体可参照上述实施例中打补丁方法。

步骤S1302、根据待处理的容器服务的标识，查询待处理的容器服务中包括待处理补丁的容器实例。

本实施例中，容器平台根据第一请求中的待处理的容器服务的标识，查询待处理的容器服务中包括待处理补丁的容器实例。具体的，在实际应用过程中，由容器平台的补丁控制器查找待处理的容器服务的所有容器实例。

步骤S1303、根据待处理的容器服务中包括待处理补丁的容器实例，生成第三任务清单，第三任务清单包括：待处理的容器服务中包括待处理补丁的容器实例的标识和待处理补丁的标识。

步骤S1304、根据第三任务清单，对包括待处理补丁的容器实例中的待处理补丁进行处理。

而上述用户对不同处理选择控件的选择，触发容器平台对待处理补丁的容器服务中的待处理补丁进行处理。

可选的，本实施例中的处理包括补丁状态查询处理、补丁去激活处理、补丁删除处理。任一项；上述对补丁状态查询处理过程进行了说明，下面对补丁去激活处理、补丁删除处理进行处理。

本实施例中，以对待处理的补丁进行补丁状态查询处理进行示例说明，图14为本申请实施例提供的对容器服务状态查询的流程示意图，如图14所示，若用户对容器服务进行处理为对容器服务的查询，则用户触发对待处理的容器服务的查询，即触发容器补丁控制器对容器服务进行查询；具体包括：

步骤S1401、容器补丁控制器根据待处理的容器服务中包括待处理补丁的容器实例，生成补丁查询的任务清单，即第三任务清单；该第三任务清单包括：待处理的容器服务中包括待处理补丁的容器实例的标识和待处理补丁的标识。

步骤S1402、容器补丁控制器将查询的任务清单发送给容器补丁执行器。

步骤S1403、然后容器补丁执行器根据待处理补丁的容器实例的标识，回调容器实例中的状态函数钩子，以及待处理补丁的标识，来获得待处理补丁的当前状态。

步骤S1404、容器补丁执行器将待处理补丁的当前状态返回给容器补丁控制器，补丁控制器将待处理补丁的当前状态返回给用户。

以对待处理的补丁进行补丁去激活处理进行示例说明，图15为本申请实施例提供的对容器服务去激活的流程示意图，如图15所示，用户触发对待处理的容器服务的去激活任务，即触发容器补丁控制器对容器服务进行去激活；补丁去激活的处理过程为：

步骤S1501、容器补丁控制器查找待处理的容器服务的所有容器实例，且根据待处理的容器服务中包括待处理补丁的容器实例，生成补丁去激活的任务清单，即第三任务清单。

该第三任务清单包括：待处理的容器服务中包括待处理补丁的容器实例的标识和待处理补丁的标识。

步骤S1502、容器补丁控制器将去激活的任务清单发送给容器补丁执行器。

步骤S1503、容器补丁执行器根据待处理补丁的容器实例的标识，回调容器实例中的去激活函数钩子，以及待处理补丁的标识，按照预设去激活策略，对待处理补丁去激活。

步骤S1504、去激活任务完成后，容器补丁执行器返回给容器补丁控制器任务完成消息，容器补丁控制器将任务完成消息返回给用户。

以对待处理的补丁进行补丁删除处理进行示例说明，图16为本申请实施例提供的对容器服务删除的流程示意图，如图16所示，用户触发对待处理的容器服务的删除任务，即触发容器补丁控制器对容器服务进行删除；补丁删除处理过程包括：

步骤S1601、容器补丁控制器查找待处理的容器服务的所有容器实例，且根据待处理的容器服务中包括待处理补丁的容器实例，生成补丁删除的任务清单，即第三任务清单；该第三任务清单包括：待处理的容器服务中包括待处理补丁的容器实例的标识和待处理补丁的标识。

步骤S1602、容器补丁控制器将补丁删除的任务清单发送给容器补丁执行器。

步骤S1603、容器补丁执行器根据待处理补丁的容器实例的标识，回调容器实例中的删除函数钩子，以及待处理补丁的标识，删除待处理补丁。

步骤S1604、容器补丁执行器返回给容器补丁控制器任务完成消息，以使容器补丁控制器将任务完成消息返回给用户。

本实施例中的提供的容器平台在实现对容器服务打补丁的过程，还可以实现对容器服务的其他处理过程，提高了容器平台的灵活性。

图17为本申请实施例提供的打补丁装置的结构示意图一。本实施例所涉及的打补丁装置可以为前述所说的容器平台，或者为容器平台对应的服务器，也可以为应用于服务器的芯片。该打补丁装置可以用于执行上述方法实施例中容器平台的动作。如图17所示，该打补丁装置可以包括：获取模块11、确定模块12和打补丁模块13。其中，

获取模块11，用于获取至少一个补丁包集的元数据信息，所述补丁包集的元数据信息用于指示所述补丁包集的容器镜象范围，以及，所述补丁包集的版本。

确定模块12，用于根据所述至少一个补丁包集的元数据信息，确定至少一个待打补丁对象，所述待打补丁对象为存储在容器镜象仓库中的容器镜象或在线运行的容器服务，所述待打补丁对象的当前补丁版本低于所述补丁包集的版本。

打补丁模块13，用于根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁。

可选的，若所述补丁包集与其他补丁包集存在依赖关系，则所述补丁包集的元数据信息还包括：所述补丁包集依赖的补丁包集的信息。

可选的，所述待打补丁对象为存储在容器镜象仓库中的容器镜象；

所述确定模块12，具体用于从所述容器镜象仓库中获取每个容器镜象的元数据信息，所述容器镜象的元数据信息用于指示所述容器镜象的标识和所述容器镜象的当前补丁版本；根据所述至少一个补丁包集的元数据信息，以及，每个所述容器镜象的元数据信息，确定所述至少一个待打补丁的容器镜象。

可选的，所述打补丁模块13，具体用于根据每个所述待打补丁的容器镜象的元数据信息，以及，所述至少一个补丁包集的元数据信息，生成与每个所述待打补丁容器镜象对应的第一任务清单，所述第一任务清单用于指示根据每个所述待打补丁的容器镜象对应的补丁包集，对每个所述待打补丁的容器镜象打补丁；并行执行所述第一任务清单。

其中，所述第一任务清单包括：所述待打补丁的容器镜象的标识、所述待打补丁的容器镜象对应的补丁包集的标识，以及，所述待打补丁的容器镜象对应的补丁包集之间的依赖关系。

可选的，所述打补丁模块13包括：拉取单元131、获取单元132、打补丁单元133和存储单元134。

其中，所述拉取单元131，用于根据所述待打补丁的容器镜象的标识，从所述容器镜象仓库中提取所述待打补丁的容器镜象。

所述获取单元132，用于根据所述待打补丁的容器镜象对应的补丁包集的标识，从补丁仓库中获取所述待打补丁的容器镜象对应的补丁包集。

所述打补丁单元133，用于根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，对所述待打补丁的容器镜象打补丁。

所述存储单元134，用于将打完补丁后的容器镜象存储至所述容器镜象仓库。

可选的，所述打补丁单元133，具体用于创建镜象补丁服务实例；根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，通过所述镜象补丁服务实例对所述待打补丁的容器镜象打补丁。

可选的，所述待打补丁对象为在线运行的容器服务；所述确定模块12，还用于获取所有在线运行的容器服务的元数据信息，所述容器服务的元数据信息用于指示所述容器服务所包括的容器实例的标识和所述容器实例的当前补丁版本；根据所述至少一个补丁包集的元数据信息，以及，所有在线运行的容器服务的元数据信息，确定至少一个待打补丁的容器服务。

可选的，所述打补丁模块13，还用于根据所述待打补丁的容器服务，确定待打补丁的容器服务所包括的容器实例；根据所述待打补丁的容器服务所包括的容器实例，以及，所述至少一个补丁包集的元数据信息，生成第二任务清单；所述第二任务清单用于指示根据每个所述待打补丁的容器服务对应的补丁包集，对每个所述待打补丁的容器服务打补丁；执行所述第二任务清单。

可选的，所述第二任务清单包括：所述待打补丁的容器服务所包括的每个容器实例的标识、每个所述容器实例对应的补丁包集的标识，以及，所述容器实例对应的补丁包集之间的依赖关系。

可选的，所述拉取单元131，还用于根据所述容器实例对应的补丁包集的标识，从所述补丁仓库中提取所述容器实例对应的补丁包集。

可选的，所述打补丁单元133，还用于根据所述容器实例对应的补丁包集之间的依赖关系，以及，所述容器实例对应的补丁包集，在所述容器实例所在的节点上对所述容器实例在线打补丁。

可选的，所述打补丁单元133，具体用于在所述容器实例所在的节点上，根据所述容器实例对应的补丁包集之间的依赖关系，从所述容器实例的上下文中回调安装钩子函数和激活钩子函数，以根据所述容器实例对应的补丁包集，对所述容器实例在线打补丁。

可选的，所述打补丁模块13，具体用于根据所述第二任务清单，对所述待打补丁的容器服务所包括的每个容器实例并行打补丁，或者，灰度打补丁。

本申请实施例提供的打补丁装置，可以执行上述方法实施例中容器平台的动作，其实现原理和技术效果类似，在此不再赘述。

图18为本申请实施例提供的打补丁装置的结构示意图二，如图18所示，该打补丁装置可以包括：接收模块14、查询模块15、处理模块16、推送模块17和更新模块18；

所述接收模块14，用于接收第一请求，所述第一请求包括待处理的容器服务的标识和待处理补丁的标识。

所述查询模块15，用于根据所述待处理的容器服务的标识，查询所述待处理的容器服务中包括所述待处理补丁的容器实例。

所述处理模块16，用于根据所述待处理的容器服务中包括所述待处理补丁的容器实例，生成第三任务清单，所述第三任务清单包括：所述待处理的容器服务中包括所述待处理补丁的容器实例的标识和所述待处理补丁的标识；根据第三任务清单，对所述包括所述待处理补丁的容器实例中的待处理补丁进行处理。

可选的，所述处理包括下述任一项：补丁状态查询处理、补丁去激活处理、补丁删除处理。

所述推送模块17，用于推送所述至少一个待打补丁对象的标识；

所述更新模块18，用于接收用户输入的更新消息，所述更新消息用于指示更新后的至少一个待打补丁对象；根据用户输入的待打补丁对象清单，对所述至少一个所述待打补丁对象进行更新。

需要说明的是，应理解以上模块可以以软件通过处理元件调用的形式实现；也可以以硬件的形式实现。例如，处理模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块的功能。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个专用集成电路(application specific integrated circuit，ASIC)，或，一个或多个微处理器(digital signal processor，DSP)，或，一个或者多个现场可编程门阵列(field programmable gate array，FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessing unit，CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。

图19为本申请实施例提供的打补丁装置的结构示意图三。如图19所示，该打补丁装置可以包括：处理器21(例如CPU)、存储器22；存储器22可能包含高速随机存取存储器(random-access memory，RAM)，也可能还包括非易失性存储器(non-volatile memory，NVM)，例如至少一个磁盘存储器，存储器22中可以存储各种指令，以用于完成各种处理功能以及实现本申请实施例的方法步骤。可选的，本申请实施例涉及的打补丁装置还可以包括：电源23、通信总线24以及通信端口25。通信总线24用于实现元件之间的通信连接。上述通信端口25用于实现打补丁装置与其他外设之间进行连接通信。

在本申请实施例中，上述存储器22用于存储计算机可执行程序代码，程序代码包括指令；当处理器21执行指令时，指令使打补丁装置的处理器21执行上述方法实施例中容器平台的处理动作，其实现原理和技术效果类似，在此不再赘述。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

本文中的术语“多个”是指两个或两个以上。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。

可以理解的是，在本申请实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请实施例的范围。

可以理解的是，在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

Claims (28)

1.一种打补丁方法，其特征在于，包括：

获取至少一个补丁包集的元数据信息，所述补丁包集的元数据信息用于指示所述补丁包集的容器镜象范围，以及，所述补丁包集的版本；

根据所述至少一个补丁包集的元数据信息，确定至少一个待打补丁对象，所述待打补丁对象为存储在容器镜象仓库中的容器镜象或在线运行的容器服务，所述待打补丁对象的当前补丁版本低于所述补丁包集的版本；

根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁；

所述根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁，包括：

根据每个所述待打补丁的容器镜象的元数据信息，以及，所述至少一个补丁包集的元数据信息，生成与每个所述待打补丁容器镜象对应的第一任务清单，所述第一任务清单用于指示根据每个所述待打补丁的容器镜象对应的补丁包集，对每个所述待打补丁的容器镜象打补丁；

执行所述第一任务清单。

2.根据权利要求1所述的方法，其特征在于，若所述补丁包集与其他补丁包集存在依赖关系，则所述补丁包集的元数据信息还包括：所述补丁包集依赖的补丁包集的信息。

3.根据权利要求2所述的方法，其特征在于，所述待打补丁对象为存储在容器镜象仓库中的容器镜象；

所述根据所述至少一个补丁包集的元数据信息，确定至少一个待打补丁对象，包括：

从所述容器镜象仓库中获取每个容器镜象的元数据信息，所述容器镜象的元数据信息用于指示所述容器镜象的标识和所述容器镜象的当前补丁版本；

根据所述至少一个补丁包集的元数据信息，以及，每个所述容器镜象的元数据信息，确定所述至少一个待打补丁的容器镜象。

4.根据权利要求1所述的方法，其特征在于，所述第一任务清单包括：所述待打补丁的容器镜象的标识、所述待打补丁的容器镜象对应的补丁包集的标识，以及，所述待打补丁的容器镜象对应的补丁包集之间的依赖关系；

所述执行所述第一任务清单，包括：

根据所述待打补丁的容器镜象的标识，从所述容器镜象仓库中提取所述待打补丁的容器镜象；

根据所述待打补丁的容器镜象对应的补丁包集的标识，从补丁仓库中获取所述待打补丁的容器镜象对应的补丁包集；

根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，对所述待打补丁的容器镜象打补丁；

将打完补丁后的容器镜象存储至所述容器镜象仓库。

5.根据权利要求4所述的方法，其特征在于，所述根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，对所述待打补丁的容器镜象打补丁，包括：

创建镜象补丁服务实例；

根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，通过所述镜象补丁服务实例对所述待打补丁的容器镜象打补丁。

6.根据权利要求2所述的方法，其特征在于，所述待打补丁对象为在线运行的容器服务；

所述根据所述至少一个补丁包集的元数据信息，确定至少一个待打补丁对象，包括：

获取所有在线运行的容器服务的元数据信息，所述容器服务的元数据信息用于指示所述容器服务所包括的容器实例的标识和所述容器实例的当前补丁版本；

根据所述至少一个补丁包集的元数据信息，以及，所有在线运行的容器服务的元数据信息，确定至少一个待打补丁的容器服务。

7.根据权利要求6所述的方法，其特征在于，所述根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁，包括：

根据所述待打补丁的容器服务，确定待打补丁的容器服务所包括的容器实例；

根据所述待打补丁的容器服务所包括的容器实例，以及，所述至少一个补丁包集的元数据信息，生成第二任务清单；所述第二任务清单用于指示根据每个所述待打补丁的容器服务对应的补丁包集，对每个所述待打补丁的容器服务打补丁；

执行所述第二任务清单。

8.根据权利要求7所述的方法，其特征在于，所述第二任务清单包括：所述待打补丁的容器服务所包括的每个容器实例的标识、每个所述容器实例对应的补丁包集的标识，以及，所述容器实例对应的补丁包集之间的依赖关系；

所述执行所述第二任务清单，包括：

根据所述容器实例对应的补丁包集的标识，从所述补丁仓库中提取所述容器实例对应的补丁包集；

根据所述容器实例对应的补丁包集之间的依赖关系，以及，所述容器实例对应的补丁包集，在所述容器实例所在的节点上对所述容器实例在线打补丁。

9.根据权利要求8所述的方法，其特征在于，所述根据所述容器实例对应的补丁包集之间的依赖关系，以及，所述容器实例对应的补丁包集，在所述容器实例所在的节点上对所述容器实例在线打补丁，包括：

在所述容器实例所在的节点上，根据所述容器实例对应的补丁包集之间的依赖关系，从所述容器实例的上下文中回调安装钩子函数和激活钩子函数，以根据所述容器实例对应的补丁包集，对所述容器实例在线打补丁。

10.根据权利要求7-9任一项所述的方法，其特征在于，所述执行所述第二任务清单，包括：

根据所述第二任务清单，对所述待打补丁的容器服务所包括的每个容器实例并行打补丁，或者，灰度打补丁。

11.根据权利要求6-9任一项所述的方法，其特征在于，所述方法还包括：

接收第一请求，所述第一请求包括待处理的容器服务的标识和待处理补丁的标识；

根据所述待处理的容器服务的标识，查询所述待处理的容器服务中包括所述待处理补丁的容器实例；

根据所述待处理的容器服务中包括所述待处理补丁的容器实例，生成第三任务清单，所述第三任务清单包括：所述待处理的容器服务中包括所述待处理补丁的容器实例的标识和所述待处理补丁的标识；

根据第三任务清单，对所述包括所述待处理补丁的容器实例中的待处理补丁进行处理。

12.根据权利要求11所述的方法，其特征在于，所述处理包括下述任一项：

补丁状态查询处理、补丁去激活处理、补丁删除处理。

13.根据权利要求1-9、12任一项所述的方法，其特征在于，所述根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁之前，还包括：

推送所述至少一个待打补丁对象的标识；

接收用户输入的更新消息，所述更新消息用于指示更新后的至少一个待打补丁对象；

根据用户输入的待打补丁对象清单，对所述至少一个所述待打补丁对象进行更新。

14.一种打补丁装置，其特征在于，包括：

获取模块，用于获取至少一个补丁包集的元数据信息，所述补丁包集的元数据信息用于指示所述补丁包集的容器镜象范围，以及，所述补丁包集的版本；

确定模块，用于根据所述至少一个补丁包集的元数据信息，确定至少一个待打补丁对象，所述待打补丁对象为存储在容器镜象仓库中的容器镜象或在线运行的容器服务，所述待打补丁对象的当前补丁版本低于所述补丁包集的版本；

打补丁模块，用于根据每个所述待打补丁对象对应的补丁包集，对每个所述待打补丁对象打补丁；

所述打补丁模块，具体用于根据每个所述待打补丁的容器镜象的元数据信息，以及，所述至少一个补丁包集的元数据信息，生成与每个所述待打补丁容器镜象对应的第一任务清单，所述第一任务清单用于指示根据每个所述待打补丁的容器镜象对应的补丁包集，对每个所述待打补丁的容器镜象打补丁；执行所述第一任务清单。

15.根据权利要求14所述的装置，其特征在于，若所述补丁包集与其他补丁包集存在依赖关系，则所述补丁包集的元数据信息还包括：所述补丁包集依赖的补丁包集的信息。

16.根据权利要求15所述的装置，其特征在于，所述待打补丁对象为存储在容器镜象仓库中的容器镜象；

所述确定模块，具体用于从所述容器镜象仓库中获取每个容器镜象的元数据信息，所述容器镜象的元数据信息用于指示所述容器镜象的标识和所述容器镜象的当前补丁版本；根据所述至少一个补丁包集的元数据信息，以及，每个所述容器镜象的元数据信息，确定所述至少一个待打补丁的容器镜象。

17.根据权利要求14所述的装置，其特征在于，所述第一任务清单包括：所述待打补丁的容器镜象的标识、所述待打补丁的容器镜象对应的补丁包集的标识，以及，所述待打补丁的容器镜象对应的补丁包集之间的依赖关系；

所述打补丁模块包括：拉取单元、获取单元、打补丁单元和存储单元；

所述拉取单元，用于根据所述待打补丁的容器镜象的标识，从所述容器镜象仓库中提取所述待打补丁的容器镜象；

所述获取单元，用于根据所述待打补丁的容器镜象对应的补丁包集的标识，从补丁仓库中获取所述待打补丁的容器镜象对应的补丁包集；

所述打补丁单元，用于根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，对所述待打补丁的容器镜象打补丁；

所述存储单元，用于将打完补丁后的容器镜象存储至所述容器镜象仓库。

18.根据权利要求17所述的装置，其特征在于，所述打补丁单元，具体用于创建镜象补丁服务实例；根据所述待打补丁的容器镜象对应的补丁包集之间的依赖关系，以及，所述待打补丁的容器镜象对应的补丁包集，通过所述镜象补丁服务实例对所述待打补丁的容器镜象打补丁。

19.根据权利要求15所述的装置，其特征在于，所述待打补丁对象为在线运行的容器服务；

所述确定模块，还用于获取所有在线运行的容器服务的元数据信息，所述容器服务的元数据信息用于指示所述容器服务所包括的容器实例的标识和所述容器实例的当前补丁版本；根据所述至少一个补丁包集的元数据信息，以及，所有在线运行的容器服务的元数据信息，确定至少一个待打补丁的容器服务。

20.根据权利要求19所述的装置，其特征在于，所述打补丁模块，还用于根据所述待打补丁的容器服务，确定待打补丁的容器服务所包括的容器实例；根据所述待打补丁的容器服务所包括的容器实例，以及，所述至少一个补丁包集的元数据信息，生成第二任务清单；所述第二任务清单用于指示根据每个所述待打补丁的容器服务对应的补丁包集，对每个所述待打补丁的容器服务打补丁；执行所述第二任务清单。

21.根据权利要求20所述的装置，其特征在于，所述第二任务清单包括：所述待打补丁的容器服务所包括的每个容器实例的标识、每个所述容器实例对应的补丁包集的标识，以及，所述容器实例对应的补丁包集之间的依赖关系；

拉取单元，还用于根据所述容器实例对应的补丁包集的标识，从所述补丁仓库中提取所述容器实例对应的补丁包集；

打补丁单元，还用于根据所述容器实例对应的补丁包集之间的依赖关系，以及，所述容器实例对应的补丁包集，在所述容器实例所在的节点上对所述容器实例在线打补丁。

22.根据权利要求21所述的装置，其特征在于，所述打补丁单元，具体用于在所述容器实例所在的节点上，根据所述容器实例对应的补丁包集之间的依赖关系，从所述容器实例的上下文中回调安装钩子函数和激活钩子函数，以根据所述容器实例对应的补丁包集，对所述容器实例在线打补丁。

23.根据权利要求20-22任一项所述的装置，其特征在于，所述打补丁模块，具体用于根据所述第二任务清单，对所述待打补丁的容器服务所包括的每个容器实例并行打补丁，或者，灰度打补丁。

24.根据权利要求19-22任一项所述的装置，其特征在于，所述装置还包括：接收模块、查询模块和处理模块；

所述接收模块，用于接收第一请求，所述第一请求包括待处理的容器服务的标识和待处理补丁的标识；

所述查询模块，用于根据所述待处理的容器服务的标识，查询所述待处理的容器服务中包括所述待处理补丁的容器实例；

所述处理模块，用于根据所述待处理的容器服务中包括所述待处理补丁的容器实例，生成第三任务清单，所述第三任务清单包括：所述待处理的容器服务中包括所述待处理补丁的容器实例的标识和所述待处理补丁的标识；根据第三任务清单，对所述包括所述待处理补丁的容器实例中的待处理补丁进行处理。

25.根据权利要求24所述的装置，其特征在于，所述处理包括下述任一项：

补丁状态查询处理、补丁去激活处理、补丁删除处理。

26.根据权利要求14-22、25任一项所述的装置，其特征在于，所述装置还包括：推送模块和更新模块；

所述推送模块，用于推送所述至少一个待打补丁对象的标识；

所述更新模块，用于接收用户输入的更新消息，所述更新消息用于指示更新后的至少一个待打补丁对象；根据用户输入的待打补丁对象清单，对所述至少一个所述待打补丁对象进行更新。

27.一种打补丁装置，其特征在于，至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述打补丁装置执行权利要求1至13任一项所述的方法。

28.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序或指令，当所述计算机程序或指令被运行时，实现如权利要求1至13任一项所述的方法。

Images