镜像构建、镜像存储、镜像分发方法及装置与流程

本申请涉及计算机技术领域，特别涉及一种镜像构建、镜像存储、镜像分发方法及装置。

背景技术：

docker镜像是一种对应用程序及其运行环境的标准化封装，docker是一种实现docker镜像的构建、分发以及运行的引擎。通过docker，节点设备可以构建docker镜像，上传至docker镜像库中，docker镜像库可以向各个节点设备分发docker镜像，以便在各个节点设备上部署docker镜像。

以构建docker镜像的节点设备称为节点a，要部署docker镜像的节点设备称为节点b，docker镜像的构建和分发的流程为：节点a会预先存储docker镜像的镜像构建文件(例如可以是dockerfile文件)，当接收到镜像构建指令(例如可以是dockerbuild指令)时，会运行dockerfile文件，生成一个docker镜像，当节点a接收镜像发送指令(例如可以是dockerpush)指令后，会向docker镜像库发送该docker镜像，docker镜像库接收到该docker镜像后，会对应存储该docker镜像以及该docker镜像的镜像标识。当节点b想要下载该docker镜像时，会向docker镜像库发送镜像下载指令(例如可以是dockerpull指令)，dockerpull指令携带镜像标识，docker镜像库接收到dockerpull指令，会根据镜像标识，在镜像库中查询到该docker镜像，将该docker镜像发送给节点b。

基于上述方案，节点a每次构建镜像时，都需要构建包含父镜像和应用镜像的完整镜像，导致每次父镜像更新时，不仅需要更新父镜像，还需要重新构建依赖于父镜像的应用镜像，并重新将父镜像和应用镜像打包成完整镜像，并存储完整的镜像，严重影响了父镜像的更新效率。

技术实现要素：

本申请实施例提供了一种镜像构建、镜像存储、镜像分发方法及装置，能够解决相关技术中父镜像的更新效率较低的技术问题，所述技术方案如下：

第一方面，提供了一种镜像构建方法，所述方法包括：

通过目标镜像的镜像构建文件，分别生成第一镜像以及第二镜像，所述目标镜像包括所述第一镜像以及所述第二镜像，所述第二镜像为所述第一镜像的父镜像；

基于所述第一镜像与所述第二镜像之间的依赖关系，获取所述第一镜像的镜像依赖信息，所述镜像依赖信息用于指示所述第一镜像的父镜像为所述第二镜像；

分别存储所述第一镜像、所述镜像依赖信息以及所述第二镜像。

本申请提供的方法，通过在构建镜像时，将镜像拆分为父镜像和应用镜像，分别生成和存储父镜像和应用镜像，并存储应用镜像的镜像依赖信息，后续需要更新父镜像时，只需重新构建父镜像即可，而无需重新构建依赖于父镜像的应用镜像，也无需将父镜像和应用镜像打包成完整镜像，提高了父镜像的更新效率，节约了镜像占用的存储空间。

在一种可能的实现中，所述分别存储所述第一镜像、所述镜像依赖信息，包括：

向所述第一镜像中写入所述镜像依赖信息，存储写入了所述镜像依赖信息的第一镜像。

在一种可能的实现中，所述向所述第一镜像中写入所述镜像依赖信息，包括：

向所述第一镜像的目标文件中写入所述镜像依赖信息，所述目标文件包括所述第一镜像的元数据文件、所述第一镜像的配置文件中的至少一项。

在一种可能的实现中，所述基于所述第一镜像与所述第二镜像之间的依赖关系，获取所述第一镜像的镜像依赖信息，包括：

根据所述镜像构建文件中的父镜像定义指令，获取所述第一镜像的镜像依赖信息。

在一种可能的实现中，所述镜像依赖信息包括所述第二镜像的标识。

在一种可能的实现中，所述方法还包括下述至少一个步骤：

当接收到所述第一镜像的更新指令时，生成更新后的第一镜像；

当接收到所述第二镜像的更新指令时，生成更新后的第二镜像。

上述实现中，通过将父镜像的更新过程以及应用镜像的更新过程解耦开，当父镜像更新时，无需生成和发送应用镜像，也无需将应用镜像与父镜像重新编译打包，可以令父镜像的更新更加轻量化、更加高效，提升了更新父镜像的效率，并且减少了节点设备与镜像库节点之间的网络带宽，节约了节点设备上传父镜像的带宽成本。同理地，当应用镜像更新时，无需生成和发送父镜像，也无需将应用镜像与父镜像重新编译打包，提升了更新应用镜像的效率，可以令应用镜像的更新更加轻量化、更加高效，并且减少了节点设备与镜像库节点之间的网络带宽，节约了节点设备上传应用镜像的带宽成本。

第二方面，提供了一种镜像存储方法，所述方法包括：

接收对目标镜像的发送指令，所述目标镜像包括所述第一镜像以及第二镜像，所述第二镜像为所述第一镜像的父镜像；

获取所述第一镜像、所述第一镜像的镜像依赖信息以及第二镜像，所述镜像依赖信息用于指示所述第一镜像的父镜像为所述第二镜像；

向镜像库节点分别发送所述第一镜像、所述镜像依赖信息以及所述第二镜像。

本申请提供的方法，通过向镜像库节点分别上传父镜像、应用镜像以及镜像依赖信息，镜像库节点可以支持单独上传应用镜像的功能、单独上传父镜像的功能，使得镜像库节点中可以分别存储父镜像、应用镜像以及镜像依赖信息，令镜像的存储更加灵活、更加高效，使得后续需要更新父镜像时，只需重新上传更新后的父镜像即可，而无需上传包含父镜像和应用镜像的完整镜像，提高了父镜像的更新效率，节约了镜像库节点中镜像占用的存储空间。同理地，后续需要更新应用镜像时，只需重新上传更新后的应用镜像即可，而无需上传包含父镜像和应用镜像的完整镜像，提高了应用镜像的更新效率，节约了镜像库节点中镜像占用的存储空间。同理地

在一种可能的实现中，所述向镜像库节点分别发送所述第一镜像、所述第二镜像以及所述镜像依赖信息，包括下述至少一个步骤：

当历史运行中已发送过所述第一镜像时，向所述镜像库节点发送所述第二镜像；

当历史运行中已发送过所述第二镜像时，向所述镜像库节点发送所述第一镜像以及所述镜像依赖信息；

当所述镜像库节点已存储所述第一镜像时，向所述镜像库节点发送所述第二镜像；

当所述镜像库节点已存储所述第二镜像时，向所述镜像库节点发送所述第一镜像以及所述镜像依赖信息；

当所述第一镜像更新后，向所述镜像库节点发送更新后的第一镜像以及所述镜像依赖信息；

当所述第二镜像更新后，向所述镜像库节点发送更新后的第二镜像。

基于上述实现，可以在历史运行中未发送过父镜像、镜像库节点未存储父镜像、父镜像发生更新、接收到对父镜像的发送指令等场景下，发送父镜像，从而提高生成父镜像以及发送父镜像的灵活性。

在一种可能的实现中，所述向镜像库节点分别发送所述第一镜像、所述镜像依赖信息，包括：

将携带了镜像依赖信息的第一镜像发送给所述镜像库节点。

在一种可能的实现中，所述将携带有镜像依赖信息的第一镜像发送给所述镜像库节点，包括：

将目标文件中携带了镜像依赖信息的第一镜像发送给所述镜像库节点，所述目标文件包括所述第一镜像的元数据文件、所述第一镜像的配置文件中的至少一项。

第三方面，提供了一种镜像分发方法，所述方法包括：

当接收到节点设备对目标镜像的获取指令时，获取第一镜像的镜像依赖信息，所述目标镜像包括所述第一镜像以及第二镜像，所述第二镜像为所述第一镜像的父镜像，所述镜像依赖信息用于指示所述第一镜像的父镜像为第二镜像；

对所述第一镜像以及所述第二镜像进行组装，得到所述目标镜像；

向所述节点设备发送所述目标镜像。

本实施例提供的方法，镜像站节点可以分别存储应用镜像和父镜像，当需要分发镜像时，通过镜像依赖信息，确定应用镜像依赖的父镜像，对应用镜像和父镜像组装后，即可向节点设备发送完整的镜像，可以极大地提高部署镜像的灵活性，使得上传镜像的节点设备可以分别构建父镜像和应用镜像，分别发送父镜像和应用镜像，如果后续要更新父镜像，则无需重新构建和发送应用镜像，如果后续要更新应用镜像，则无需重新构建和发送父镜像，如果多个应用镜像依赖于同一父镜像，则只需为一个应用镜像生成和发送父镜像即可，极大地提升了镜像的构建效率。

在一种可能的实现中，所述获取所述第一镜像的镜像依赖信息，包括：

对所述第一镜像进行解析，得到所述第一镜像的镜像依赖信息。

在一种可能的实现中，所述对所述第一镜像进行解析，得到所述第一镜像的镜像依赖信息，包括：

对所述第一镜像的目标文件进行解析，得到所述目标文件携带的镜像依赖信息，所述目标文件包括所述第一镜像的元数据文件、所述第一镜像的配置文件中的至少一项。

在一种可能的实现中，所述对所述第一镜像以及所述第二镜像进行组装，得到所述目标镜像之前，所述方法还包括：

根据所述镜像依赖信息，在镜像库中进行查询，得到所述第二镜像。

在一种可能的实现中，所述对所述第一镜像以及所述第二镜像进行组装，得到所述目标镜像，包括：

解析所述第二镜像的目标文件，得到所述第二镜像的镜像依赖信息，所述第二镜像的镜像依赖信息用于指示所述第二镜像的父镜像为第三镜像；对所述第一镜像、所述第二镜像以及所述第三镜像进行组装，得到所述目标镜像。

在一种可能的实现中，所述获取所述第一镜像的镜像依赖信息之后，所述方法还包括：

对所述第一镜像的元数据文件以及所述第二镜像的元数据文件进行合并，得到所述目标镜像的元数据文件，元数据文件用于指示对应镜像中的每个镜像层；

向所述节点设备发送所述目标镜像的元数据文件。

在一种可能的实现中，所述向所述节点设备发送所述目标镜像之后，所述方法还包括下述至少一个步骤：

获取更新后的第一镜像；当接收到所述节点设备对所述目标镜像的获取指令时，向所述节点设备发送所述更新后的第一镜像；

获取更新后的第二镜像；当接收到所述节点设备对所述目标镜像的获取指令时，向所述节点设备发送所述更新后的第二镜像。

第四方面，提供了一种镜像构建装置，用于执行第一方面或第一方面的任一种可能实现方式中的方法。具体地，该镜像构建装置包括用于执行上述第一方面或第一方面的任一种可能实现方式中的方法的功能模块。

第五方面，提供了一种镜像存储装置，用于执行第二方面或第二方面的任一种可能实现方式中的方法。具体地，该镜像存储装置包括用于执行上述第二方面或第二方面的任一种可能实现方式中的方法的功能模块。

第六方面，提供了一种镜像分发装置，用于执行第三方面或第三方面的任一种可能实现方式中的方法。具体地，该镜像分发装置包括用于执行上述第三方面或第三方面的任一种可能实现方式中的方法的功能模块。

第七方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如用于执行第一方面或第一方面的任一种可能实现方式中的方法中的镜像构建方法所执行的操作。

第八方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如用于执行第二方面或第二方面的任一种可能实现方式中的方法中的镜像存储方法所执行的操作。

第九方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如用于执行第三方面或第三方面的任一种可能实现方式中的方法中的镜像分发方法所执行的操作。

第十方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如第一方面或第一方面的任一种可能实现方式中的方法中的镜像构建方法所执行的操作。

第十一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述指令由所述处理器加载并执行以实现第二方面或第二方面的任一种可能实现方式中的方法中的镜像存储方法所执行的操作。

第十二方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述指令由所述处理器加载并执行以实现第三方面或第三方面的任一种可能实现方式中的方法中的镜像分发方法所执行的操作。

第十三方面，提供了一种芯片，所述芯片包括处理器和/或程序指令，当所述芯片运行时，实现上述任一方面或任一方面中任一种可能实现方式所提供的方法。

附图说明

图1是本申请实施例提供的一种docker镜像的内容示意图；

图2是本申请实施例提供的一种上传docker镜像的流程图；

图3是本申请实施例提供的一种下载docker镜像的流程图；

图4是本申请实施例提供的一种镜像构建，镜像存储，镜像分发，通过镜像创建容器的全流程图；

图5是本申请实施例提供的一种计算机设备的结构示意图；

图6是本申请实施例提供的一种镜像构建方法的流程图；

图7是本申请实施例提供的一种镜像构建文件的内容示意图；

图8是本申请实施例提供的一种镜像存储方法的流程图；

图9是本申请实施例提供的一种镜像分发方法的流程图；

图10是本申请实施例提供的一种存储镜像的示意图；

图11是本申请实施例提供的一种分发镜像的流程图；

图12是本申请实施例提供的一种镜像构建，镜像存储，镜像分发的全流程图；

图13是本申请实施例提供的一种镜像构建装置的结构示意图；

图14是本申请实施例提供的一种镜像存储装置的结构示意图；

图15是本申请实施例提供的一种镜像分发装置的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

以下对本申请涉及的一些概念进行解释：

docker：是一种实现docker镜像构建、分发以及运行的引擎，开发人员和管理员基于docker，可以使用容器来开发、部署并运行应用程序。docker一般包含docker客户端(例如可以是dockerclient)以及docker守护进程(例如可以是dockerdaemon)。dockerdaemon也称docker引擎(dockerengine)，是主机上运行的管理镜像以及容器的守护进程。

docker镜像(也称dockerimage)是一个可执行程序包，包含运行应用程序所需的所有内容，例如可以包含应用程序的代码、库、环境变量和配置文件。docker镜像可以在任何装有dockerengine的环境中运行，当docker镜像运行后，会被创建为docker容器，docker容器可以实现对容器外部的软件以及硬件进行屏蔽。docker镜像的内容可以如图1所示，docker镜像包括元数据文件、配置文件以及至少一个镜像层文件，元数据文件可以是manifest.json文件，元数据文件记录了所有镜像层文件的元数据，例如可以记录每个镜像层文件的sha256值。配置文件可以记录镜像占用的内存大小、镜像包含的指令类型等。镜像层文件可以是layer文件。

docker容器(也称dockercontainer)是docker镜像的运行态的实例，可以根据查看指令(例如可以是dockerps指令)，显示docker容器的列表。

镜像构建文件：是一个包含多条指令的文本文件，例如可以是dockerfile文件。运行docker的节点设备通过解析镜像构建文件，可以得到镜像构建文件中的指令，根据镜像构建文件中的指令，可以自动构建docker镜像。

父镜像(也称parentimage)用于提供运行环境的镜像，可以是一个镜像层或多个镜像层的组合。父镜像可以是操作系统(operatingsystem，简称os)、中间件或者编译环境。父镜像可以是docker镜像的基础镜像，可以是docker镜像中底层镜像，例如是倒数第1层的镜像层至倒数第7层的镜像层。镜像构建文件中的from指令通常会指定docker镜像中的父镜像。

docker镜像库(也称dockerregistry)：提供docker镜像的上传功能、下载功能及管理功能的仓库。docker镜像库存储了大量的docker镜像，docker镜像仓库可以基于dockerregistry协议实现。

docker镜像的上传流程：对于待上传的docker镜像中的每个镜像层，节点设备可以查询docker镜像库中是否已经存储该镜像层，如果docker镜像库中未存储该镜像层，则向docker镜像库发送该镜像层，如果docker镜像库中已经存储该镜像层，则继续查询docker镜像库中是否已经存储该镜像层的下一个镜像层，通过循环执行查询以及上传镜像层的步骤，当确认docker镜像中所有镜像层都上传完成后，节点设备上传镜像的元数据文件，元数据文件上传后，结束上传流程。请参见图2，图2为本申请实施例提供的一种上传docker镜像的方法流程图。

docker镜像的部署流程：对于待下载的docker镜像，节点设备可以首先下载docker镜像的元数据文件，解析元数据文件，得到docker镜像中所有镜像层的标识，对于docker镜像中的每个镜像层，节点设备可以根据镜像层的标识，查询本机是否已经存储该镜像层，如果本机尚未存储该镜像层，则向docker镜像库发送该镜像层的获取指令(例如可以是dockerpull指令)，docker镜像库接收到镜像层的获取指令后，会向节点设备发送该镜像层，如果本机已经存储该镜像层，则继续查询本机是否已经存储下一个镜像层，通过循环执行查询以及下载镜像层的步骤，当确认docker镜像中所有镜像层都下载完成后，结束下载流程，完成在节点设备上部署docker镜像。请参见图3和图4，图3为本申请实施例提供的一种部署docker镜像的流程图，图4是本申请实施例提供的一种镜像构建，镜像存储，镜像分发，通过镜像创建容器的全流程图。

图5是本申请实施例提供的一种计算机设备的结构示意图，该计算机设备500可以提供为下述实施例中的节点设备或镜像库节点，该计算机设备500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，以下简称：cpu)501和一个或一个以上的存储器502，其中，存储器502中存储有至少一条指令，至少一条指令由处理器501加载并执行以实现下述各个方法实施例中镜像构建方法、镜像存储方法中的至少一项，或者镜像分发方法。当然，该计算机设备还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该计算机设备500还可以包括其他用于实现设备功能的部件，在此不做赘述。

下述实施例中，以权利要求书中的第一镜像为应用镜像进行示例性描述，需要说明的是，应用镜像仅是第一镜像的一种示例，下述实施例中的应用镜像可以替换为其他类型的镜像，例如可以是服务镜像或者微服务镜像，又如可以是任一个指定的镜像层或多个指定的镜像层的组合。另外，下述实施例中以权利要求书中的第二镜像称为父镜像进行示例性描述，当然第二镜像也可以具有其它名称，例如可以称为基础镜像或parent镜像，另外，下述实施例中以权利要求书中的第三镜像称为祖父镜像进行示例性描述，当然第三镜像也可以具有其它名称，例如可以称为父镜像的父镜像。

图6是本申请实施例提供的一种镜像构建方法的流程图，该方法的执行主体为节点设备，包括以下步骤：

601、节点设备通过目标镜像的镜像构建文件，分别生成应用镜像以及父镜像。

节点设备可以是服务器、个人电脑、笔记本电脑等，本申请实施例提供的方法，可以由独立的一台节点设备执行，也可以由多台节点设备组成的集群执行，也可以由一台节点设备上的一个或多个程序模块执行，例如可以由节点设备上运行的虚拟机或容器执行，另外也可以由分布在多台节点设备上的多个程序模块执行。

目标镜像是指需要构建的完整镜像，可以是docker镜像，当然也可以是docker以外的其他容器引擎下运行的镜像。目标镜像可以包括应用镜像以及父镜像，应用镜像可以为应用程序的镜像，父镜像可以为运行环境的镜像，应用镜像与父镜像之间存在依赖关系，应用镜像依赖于父镜像，应用镜像需要在父镜像提供的运行环境中运行。

关于生成应用镜像以及父镜像的具体过程，当节点设备接收到镜像构建指令(例如可以是dockerbuild指令)时，节点设备可以解析镜像构建指令，得到镜像构建指令携带的镜像构建文件的标识，确定镜像构建文件的标识对应的镜像构建文件，解析该镜像构建文件，得到镜像构建文件中的至少一条指令，可以根据镜像构建文件中的父镜像定义指令，生成父镜像，可以根据镜像构建文件中父镜像定义指令以外的至少一条指令，生成应用镜像。

镜像构建文件可以是dockerfile文件，镜像构建文件包括用于构建父镜像的父镜像定义指令以及用于构建应用镜像的其他指令，镜像构建文件中的每条指令可以用于构建目标镜像中的一个镜像层。镜像构建文件可以预先存储在节点设备中，也可以由其他设备发送给节点设备。举例来说，镜像构建文件的内容可以如图7所示，该镜像构建文件中包含三条指令。

父镜像定义指令用于指示目标镜像中的父镜像，父镜像定义指令可以是from指令，可以是镜像构建指令中的第一行指令。父镜像定义指令可以携带父镜像的标识，例如，父镜像定义指令中“from”字段后的内容可以是父镜像的标识。其中，该父镜像的标识可以包括父镜像的名称和父镜像的版本号(tag)中的至少一项。举例来说，请参见图7，父镜像定义指令可以是fromubuntu16.04，这条父镜像定义指令中父镜像的名称为ubuntu，父镜像的版本号为16.04。

父镜像定义指令以外的至少一条指令用于指示目标镜像中的应用镜像，可以携带应用镜像的标识。父镜像定义指令以外的至少一条指令可以是父镜像定义指令之后的所有指令，例如可以是第二行指令至倒数最后一行指令。举例来说，请参见图7，镜像构建文件中除了from指令以外，还包括两条指令，分别是复制(copy)指令以及运行(entrypoint)指令，可以根据这两条指令，生成应用镜像。

需要说明的是，docker原生的镜像构建逻辑为，通过dockerfile文件，对父镜像和应用镜像进行编译，生成一个包含父镜像和应用镜像的完整镜像，从完整镜像中，无法区分哪些镜像层是父镜像，哪些镜像层是应用镜像。而本实施例中，可以修改docker原生的镜像构建逻辑，例如修改docker的build代码，从而修改docker运行dockerfile文件的方式，可以通过一个dockerfile文件，分别生成父镜像和应用镜像这两个镜像，从而将目标镜像拆分为父镜像和应用镜像，实现父镜像和应用镜像的解耦，则如果后续父镜像要进行更新，只需构建和发送更新后的父镜像，如果后续应用镜像要进行更新，只需构建和发送更新后的应用镜像。

在一个示例性场景中，假设镜像构建文件如图7所示，根据from字段后的ubuntu16.04，可以生成一个名称为ubuntu，版本号为16.04的父镜像，将父镜像保存到本地，根据copy指令以及entrypoint指令，可以生成一个名称为app，版本号为latest的应用镜像，从而分别生成应用镜像和父镜像这两个镜像。

602、节点设备基于应用镜像与父镜像之间的依赖关系，获取应用镜像的镜像依赖信息。

镜像依赖信息用于标识应用镜像的父镜像，能够指示应用镜像的父镜像是哪个镜像，也即是应用镜像依赖于哪个镜像。镜像依赖信息可以包括父镜像的名称和版本号中的至少一项，例如应用镜像app:latest的镜像依赖信息可以是ubuntu16.04。

关于获取镜像依赖信息的方式，在一种可能的实现中，可以根据镜像构建文件中的父镜像定义指令，获取应用镜像的镜像依赖信息。具体来说，可以解析父镜像定义指令，得到父镜像定义指令携带的父镜像的名称和版本号中的至少一项，将父镜像的名称和版本号中的至少一项作为镜像依赖信息。

需要说明的是，根据父镜像定义指令来获取镜像依赖信息，仅是获取镜像依赖信息的一种可选方式，而非必选方式，可选地，可以通过其他方式获取镜像依赖信息，例如可以预先建立应用镜像和镜像依赖信息之间的映射关系，根据应用镜像，查询应用镜像和镜像依赖信息之间的映射关系，得到应用镜像对应的镜像依赖信息，又如可以接收输入的镜像依赖信息，本实施例对如何获取镜像依赖信息不做限定。

603、节点设备分别存储应用镜像、父镜像以及镜像依赖信息。

可选地，节点设备可以向应用镜像中写入镜像依赖信息，存储写入了镜像依赖信息的应用镜像。则由于应用镜像本身携带镜像依赖信息，通过存储应用镜像，即可实现分别存储应用镜像以及镜像依赖信息的功能，而无需额外地单独存储镜像依赖信息，因此提高了存储镜像依赖信息的效率。

其中，应用镜像中可以包括多个文件，例如可以包括至少一个镜像层文件、元数据文件以及配置文件，节点设备可以向应用镜像的任一文件中写入镜像依赖信息，本实施例对向哪个文件中写入镜像依赖信息不做限定。

可选地，节点设备可以向应用镜像的目标文件中写入镜像依赖信息，目标文件包括应用镜像的元数据文件、应用镜像的配置文件中的至少一项。举例来说，请参见图1，可以向图1中的manifest.json文件(元数据文件)中写入镜像依赖信息，也可以向图1中的c1473……bf.json文件(配置文件)中写入镜像依赖信息。

需要说明的是，向应用镜像中写入镜像依赖信息，仅是存储应用镜像以及镜像依赖信息的一种可选方式，而非必选方式，可选地，也可以通过其他方式来存储应用镜像以及镜像依赖信息。例如，可以建立镜像依赖信息库，在镜像依赖信息库中专门存储每个应用镜像的镜像依赖信息，又如，可以每当接收到镜像依赖信息时，记录应用镜像与镜像依赖信息之间的映射关系，从而将应用镜像以及镜像依赖信息对应存储。

本实施例提供的方法，通过在构建镜像时，将镜像拆分为父镜像和应用镜像，分别存储父镜像和应用镜像，如果后续要更新父镜像，则无需重新构建应用镜像，如果后续要更新应用镜像，则无需重新构建父镜像，如果多个应用镜像依赖于同一父镜像，则只需为一个应用镜像生成父镜像即可，从而极大地提高了构建镜像的灵活性，并极大地提升了镜像的构建效率。

图8是本申请实施例提供的一种镜像存储方法的流程图，该方法的执行主体为节点设备，包括以下步骤：

801、节点设备接收对目标镜像的发送指令。

对目标镜像的发送指令可以是dockerpush指令。

802、节点设备获取应用镜像、应用镜像的镜像依赖信息以及父镜像。

节点设备可以生成应用镜像、镜像依赖信息以及父镜像，也可以读取预先存储的应用镜像、镜像依赖信息以及父镜像，也可以接收输入的应用镜像、镜像依赖信息以及父镜像，本实施例对如何获取应用镜像、镜像依赖信息以及父镜像不做限定。其中，生成应用镜像、镜像依赖信息以及父镜像的方式详见上述图6实施例，在此不做赘述。

其中，获取应用镜像以及镜像依赖信息可以指获取携带了镜像依赖信息的应用镜像，例如获取目标文件中写入了镜像依赖信息的应用镜像。

803、节点设备向镜像库节点分别发送应用镜像、镜像依赖信息以及该父镜像。

通过向镜像库节点发送应用镜像、镜像依赖信息以及父镜像，镜像库节点可以接收应用镜像、镜像依赖信息以及父镜像，存储应用镜像、镜像依赖信息以及父镜像，从而将目标镜像存储在镜像库节点中，实现存储镜像的功能。

可选地，分别发送应用镜像、镜像依赖信息以及父镜像的方式可以包括以下(1)至(6)中的一项或多项。

(1)当历史运行中已发送过该应用镜像时，节点设备向该镜像库节点发送该父镜像；

可选地，可以单独生成父镜像，而无需生成应用镜像，例如可以修改docker的build代码，令节点设备运行镜像构建文件时，只是根据镜像构建文件中的父镜像定义指令，构建父镜像，当父镜像构建完成时，即结束镜像的构建流程，从而实现单独生成父镜像的功能。

可选地，节点设备可以判断历史运行中是否发送过该父镜像，如果历史运行中未发送过该父镜像，则向镜像库节点发送父镜像，如果历史运行中已经发送过父镜像，则可以无需向镜像库节点发送父镜像。在一种可能的实现中，节点设备可以维护镜像发送记录，当生成父镜像后，可以查询镜像发送记录，如果镜像发送记录不包括生成的父镜像的标识，表明历史运行中未发送过父镜像，则发送父镜像，并将父镜像的标识添加至镜像发送记录中，如果镜像发送记录包含生成的父镜像的标识，表明历史运行中已经发送过父镜像，则无需向镜像库节点发送父镜像。

在一个示例性场景中，如果节点设备首次构建包含该父镜像的目标镜像，则节点设备会生成父镜像并发送父镜像，如果节点设备后续构建目标镜像以外的其他包含该父镜像的镜像，则节点设备可以无需生成父镜像并发送父镜像。举例来说，比如某产品具有80个微服务，这80个微服务的镜像的父镜像可以都是ubuntu，节点设备可以在构建第1个微服务的镜像的过程中，构建父镜像和发送父镜像，而在构建第2个微服务至第80个微服务的镜像的过程中，可以无需构建父镜像和发送父镜像，只需构建和发送这79个微服务本身的镜像即可。假设每个ubuntu的大小为300mb，则可以减少生成79份ubuntu的副本，则减少79*300mb＝23.1gb的空间。

(2)当历史运行中已发送过该父镜像时，节点设备向该镜像库节点发送该应用镜像以及该镜像依赖信息。

可选地，可以单独生成应用镜像，而无需生成父镜像，例如可以修改docker的build代码，令节点设备运行镜像构建文件时，取消执行镜像构建文件中的父镜像定义指令，只根据父镜像定义指令以外的至少一条指令，构建应用镜像，当应用镜像构建完成后，即停止镜像的构建流程，从而实现单独生成应用镜像的功能。

在一个示例性场景中，某产品具有90个微服务，这90个微服务的镜像的父镜像可以都是ubuntu，则对于第2个微服务至第90个微服务中的每个微服务来说，节点设备在构建该微服务的镜像的过程中，可以只需单独生成微服务本身的镜像，并发送微服务本身的镜像以及镜像依赖信息，而无需构建ubuntu和发送ubuntu，假设每个ubuntu的大小为300mb，则可以减少生成89份ubuntu的副本，则减少89*300＝26.1gb的空间。

(3)当该镜像库节点已存储应用镜像时，节点设备向该镜像库节点发该父镜像。

具体来说，节点设备可以查询镜像库节点是否已经存储应用镜像，如果镜像库节点未存储应用镜像，则向镜像库节点发送应用镜像，如果镜像库节点已经存储应用镜像，则可以无需向镜像库节点发送应用镜像。在一种可能的实现中，节点设备可以向镜像库节点发送查询请求，查询请求携带应用镜像的标识，镜像库节点可以根据应用镜像的标识，在镜像库中进行查询，如果未查询到应用镜像的标识对应的镜像，表明镜像库节点尚未存储应用镜像，则镜像库节点向节点设备返回尚未存储应用镜像的通知消息，以使节点设备发送应用镜像，如果镜像库节点查询到应用镜像的标识对应的镜像，表明镜像库节点已经存储应用镜像，则镜像库节点向节点设备返回已存储应用镜像的通知消息，以避免节点设备发送应用镜像。

(4)当镜像库节点已存储父镜像时，节点设备向该镜像库节点发送应用镜像以及镜像依赖信息。

具体来说，节点设备可以查询镜像库节点是否已经存储父镜像，如果镜像库节点未存储父镜像，则向镜像库节点发送父镜像，如果镜像库节点已经存储父镜像，则可以无需向镜像库节点发送父镜像。在一种可能的实现中，节点设备可以向镜像库节点发送查询请求，查询请求携带父镜像的标识，镜像库节点可以根据父镜像的标识，在镜像库中进行查询，如果未查询到父镜像的标识对应的镜像，表明镜像库节点尚未存储父镜像，则镜像库节点向节点设备返回尚未存储父镜像的通知消息，以使节点设备发送父镜像，如果镜像库节点查询到父镜像的标识对应的镜像，表明镜像库节点已经存储父镜像，则镜像库节点向节点设备返回已存储父镜像的通知消息，以避免节点设备发送父镜像。

(5)当应用镜像更新后，节点设备向该镜像库节点发送更新后的应用镜像以及该镜像依赖信息。

方式(5)可以包括以下步骤一至步骤三：

步骤一、节点设备接收应用镜像的更新指令。

步骤二、节点设备生成更新后的应用镜像。

节点设备可以通过应用镜像的构建文件(例如可以是dockerfile文件)，生成更新后的应用镜像。具体来说，节点设备可以对应用镜像进行打补丁处理，得到打补丁后的应用镜像，从而对应用镜像进行更新。当然，更新应用镜像不限于打补丁场景，节点设备也可以在其他场景下更新应用镜像，例如可以在应用镜像中安装监控程序，从而对应用镜像进行更新，又如可以对应用镜像进行版本升级，从而对应用镜像进行更新，本实施例对更新应用镜像的场景不做限定。

步骤三、节点设备向镜像库节点发送更新后的应用镜像。

节点设备可以当接收到镜像发送指令时，向镜像库节点发送更新后的应用镜像，该镜像发送指令可以是dockerpush指令。

相关技术中，通过dockerfile文件构建出的镜像，是一个包含父镜像和应用镜像的完整镜像，镜像中无法区分哪些镜像层是父镜像，哪些镜像层是应用镜像，一旦任一应用镜像需打补丁时，需要重新构建父镜像，在父镜像的基础上继续构建该应用镜像，对父镜像和应用镜像编译打包，从而得到包含应用镜像和父镜像的完整镜像，将完整镜像更新到docker镜像库，以便docker镜像库重新分发完整镜像，来部署更新后的应用镜像。

通过将父镜像和应用镜像拆分开，当应用镜像要进行更新时，节点设备可以只需单独生成更新后的应用镜像，而无需构建应用镜像的父镜像，也无需将应用镜像与父镜像重新编译打包，提高了对应用镜像进行更新的效率，加快了更新应用镜像的速度，可以快速更新应用镜像。并且，可以单独发送更新后的应用镜像，而无需发送包含父镜像以及更新后的应用镜像的完整镜像，节约了更新后的应用镜像在节点设备与镜像库节点之间占用的网络带宽，提高了传输更新后的应用镜像的效率，可以令应用镜像的更新更加轻量化、更加高效。

(6)当该父镜像更新后，节点设备向该镜像库节点发送更新后的父镜像。

方式(6)可以包括以下步骤一至步骤三：

步骤一、节点设备接收父镜像的更新指令。

该对父镜像的更新指令用于指示对父镜像进行更新，可以由用户的输入操作触发。

步骤二、节点设备生成更新后的父镜像。

节点设备可以通过父镜像的构建文件(例如可以是dockerfile文件)，生成更新后的父镜像。具体来说，节点设备可以对父镜像进行打补丁处理，得到打补丁后的父镜像，从而对父镜像进行更新。当然，更新父镜像不限于打补丁场景，节点设备也可以在其他场景下更新父镜像，例如可以在父镜像中安装监控程序，从而对父镜像进行更新，又如可以对父镜像进行版本升级，从而对父镜像进行更新，本实施例对更新父镜像的场景不做限定。

步骤三、节点设备向镜像库节点发送更新后的父镜像。

节点设备可以接收镜像发送指令，根据该镜像发送指令，向镜像库节点发送更新后的父镜像，该镜像发送指令可以是dockerpush指令，该镜像发送指令可以携带父镜像的标识。

相关技术中，通过dockerfile文件构建出的镜像，是一个包含父镜像和应用镜像的完整镜像，镜像中无法区分哪些镜像层是父镜像，哪些镜像层是应用镜像，一旦任一父镜像需打补丁，需要重新构建依赖于该父镜像的所有应用镜像，并将重新构建的所有应用镜像更新到docker镜像库，由docker镜像库重新分发所有应用镜像。而一般一个产品存在几十甚至上百个应用，这些应用一般会使用同一种操作系统作为父镜像，一旦操作系统出现漏洞，需要打补丁，则需要重新构建并部署所有应用镜像，严重影响维护应用镜像的效率。

可选地，节点设备可以检测生成的父镜像是否发生了更新，如果父镜像发生更新，则节点设备向镜像库节点发送父镜像，如果父镜像尚未发生更新，则节点设备无需向镜像库节点发送父镜像，在一种可能的实现中，节点设备可以检测生成的父镜像的安全散列算法(securehashalgorithm，以下简称：sha)256值，并确定镜像库节点当前存储的父镜像的sha256值，如果父镜像的sha256值发生了变化，则确认父镜像发生了更新，则节点设备向镜像库节点发送父镜像。

通过将父镜像和应用镜像拆分开，当父镜像要进行更新时，节点设备可以单独生成更新后的父镜像，而无需构建依赖于父镜像的应用镜像，也无需将父镜像和应用镜像编译打包，提高了对父镜像进行更新的效率，加快了更新父镜像的速度，可以快速更新父镜像。并且，可以向镜像库节点单独发送更新后的父镜像，而无需发送包含更新后的父镜像以及应用镜像的完整镜像，节约了传输更新后的父镜像时，需要在节点设备与镜像库节点之间占用的网络带宽，提高了传输更新后的父镜像的效率，可以令父镜像的更新更加轻量化、更加高效。

本实施例提供的方法，通过向镜像库节点分别发送应用镜像、镜像依赖信息以及父镜像，可以将目标镜像中的应用镜像和父镜像分别存储在镜像库节点中，则当父镜像更新时，可以只需向镜像库节点发送更新后的父镜像，而无需重新构建依赖于父镜像的应用镜像，也无需将包含父镜像和应用镜像的完整镜像上传至镜像库节点，提高了对父镜像进行更新的效率，加快了更新父镜像的速度，可以快速更新父镜像，节约了更新后的父镜像在节点设备与镜像库节点之间占用的网络带宽，提高了传输更新后的父镜像的效率，可以令父镜像的更新更加轻量化、更加高效。

图9是本申请实施例提供的一种镜像分发方法的流程图，该方法的交互主体包括镜像库节点以及节点设备，包括以下步骤：

901、镜像库节点存储应用镜像、应用镜像的镜像依赖信息以及父镜像。

关于镜像库节点分别存储应用镜像、应用镜像的镜像依赖信息以及父镜像的方式，在一种可能的实现中，可以由节点设备向镜像库节点分别发送应用镜像、应用镜像的镜像依赖信息以及父镜像。其中，可以向应用镜像写入镜像依赖信息，将携带镜像依赖信息发送给镜像库节点，则由于应用镜像本身携带镜像依赖信息，通过发送应用镜像，即可实现向镜像库节点发送应用镜像以及镜像依赖信息的功能，而无需额外地单独传输镜像依赖信息，因此简化了传输镜像依赖信息的流程，提高了传输镜像依赖信息的效率。

其中，应用镜像中可以包括多个文件，例如可以包括至少一个镜像层文件、元数据文件以及配置文件，节点设备可以向应用镜像的任一文件中写入镜像依赖信息，本实施例对向哪个文件中写入镜像依赖信息不做限定。

可选地，节点设备可以向应用镜像的目标文件中写入镜像依赖信息，目标文件包括应用镜像的元数据文件、应用镜像的配置文件中的至少一项。举例来说，请参见图1，可以向图1中的manifest.json文件(元数据文件)中写入镜像依赖信息，也可以向图1中的c1473……bf.json文件(配置文件)中写入镜像依赖信息。

需要说明的第一点是，向应用镜像中写入镜像依赖信息，仅是发送应用镜像以及镜像依赖信息的一种可选方式，而非必选方式，可选地，也可以通过其他方式来发送应用镜像以及镜像依赖信息，例如，可以对应用镜像以及镜像依赖信息进行封装，得到数据包，向镜像库节点发送数据包，从而实现发送应用镜像以及镜像依赖信息的功能，又如，可以在发送应用镜像后，专门发送携带应用镜像的镜像依赖信息的通知消息，从而实现发送应用镜像以及镜像依赖信息的功能，本实施例对如何发送应用镜像以及镜像依赖信息不做限定。

需要说明的第二点是，节点设备可以接收镜像发送指令(例如可以是dockerpush指令)，根据接收到的镜像发送指令，分别发送应用镜像、父镜像以及镜像依赖信息。例如，可以当接收到应用镜像对应的镜像发送指令时，将写入了镜像依赖信息的应用镜像发送给镜像库节点，当接收到父镜像对应的镜像发送指令时，将父镜像发送给镜像库节点。

镜像库节点可以接收父镜像、应用镜像以及应用镜像的镜像依赖信息，可以将应用镜像以及应用镜像的镜像依赖信息对应存储。其中，接收父镜像、应用镜像以及应用镜像的镜像依赖信息的过程详见上述图6实施例，在此不做赘述。其中，应用镜像可以携带镜像依赖信息，则镜像库节点通过存储应用镜像，即可实现将应用镜像以及镜像依赖信息对应存储的功能，而无需额外维护应用镜像与镜像依赖信息的映射关系，提高了存储镜像依赖信息的效率，节约了存储空间。

示例性地，请参见图10，图10为本申请实施例提供的一种存储镜像的示意图，不同租户之间的镜像可以相互隔离，镜像的元数据文件可以在数据库中存储，镜像层文件可以在文件系统中存储或在对象中存储。其中，镜像1的manifest文件中携带镜像2的标识，从而指示镜像1依赖于镜像2，镜像2的manifest文件中携带镜像n的标识，从而指示镜像2依赖于镜像n。另外，同一租户的不同镜像层文件可以复用，即相同的镜像层文件只存储一份，从而减少镜像站节点的存储空间。

需要说明的是，在应用镜像中携带镜像依赖信息，仅是将应用镜像以及镜像依赖信息对应存储的一种示例，而非将应用镜像以及镜像依赖信息对应存储的必选方式，可选地，也可以通过其他方式，将应用镜像以及镜像依赖信息对应存储，例如，可以建立镜像依赖信息库，在镜像依赖信息库中专门存储每个应用镜像的镜像依赖信息，又如，可以每当接收到镜像依赖信息时，记录应用镜像与镜像依赖信息之间的映射关系，从而将应用镜像以及镜像依赖信息对应存储。

902、节点设备向镜像库节点发送对目标镜像的获取指令。

对目标镜像的获取指令可以携带应用镜像的标识，该应用镜像的标识可以包括应用镜像的名称以及应用镜像的版本号中的至少一项。对目标镜像的获取指令可以是dockerpull指令，可以通过用户的输入操作触发。

903、当接收到对目标镜像的获取指令时，镜像库节点获取应用镜像的镜像依赖信息。

在一种可能的实现中，镜像库节点可以解析对目标镜像的获取指令，得到应用镜像的标识，根据应用镜像的标识，查询到应用镜像，对应用镜像进行解析，得到应用镜像的镜像依赖信息，根据应用镜像的镜像依赖信息，可以确定应用镜像的父镜像，也即是，可以确定应用镜像依赖于哪个镜像。

可选地，镜像库节点可以确定应用镜像的目标文件，对应用镜像的目标文件进行解析，得到目标文件携带的镜像依赖信息，该目标文件包括应用镜像的元数据文件、应用镜像的配置文件中的至少一项。举例来说，假设接收到的目标镜像的获取指令携带“app7.0”,可以根据“app7.0”，查询镜像名称为“app”，且版本号为“7.0”的应用镜像，对该应用镜像的manifest文件进行解析，得到manifest文件中携带的“ubuntu16.04”，从而确定“app7.0”的父镜像是“ubuntu16.04”。

需要说明的是，对应用镜像解析仅是获取镜像依赖信息的一种可选方式，而非必选方式，可选地，镜像库节点也可以通过其他方式获取镜像依赖信息，例如可以预先存储应用镜像的标识与镜像依赖信息之间的映射关系，可以根据应用镜像的标识，查询应用镜像的标识与镜像依赖信息之间的映射关系，从而确定应用镜像的镜像依赖信息。

904、镜像库节点根据镜像依赖信息，在镜像库中进行查询，得到父镜像。

镜像库节点可以将镜像依赖信息作为索引，在镜像库中存储的大量镜像中查询，得到镜像依赖信息对应的镜像，作为应用镜像的父镜像。举例来说，可以根据“ubuntu16.04”，在镜像库进行查询，得到镜像名称为“ubuntu”，版本号为“16.04”的镜像，将该镜像作为父镜像。

905、镜像库节点对应用镜像以及父镜像进行组装，得到目标镜像。

在一种可能的实现中，镜像库节点可以对应用镜像的元数据文件以及父镜像的元数据文件进行合并，得到目标镜像的元数据文件，向节点设备发送目标镜像的元数据文件，其中，元数据文件用于指示对应镜像中的每个镜像层，可以包括对应镜像中每个镜像层的标识。具体来说，应用镜像的元数据文件可以包括应用镜像中每个镜像层的标识，父镜像的元数据文件包含应用镜像中每个镜像层的标识，该目标镜像的元数据文件包含应用镜像的元数据文件以及父镜像的元数据文件，由于因此目标镜像的元数据文件会包含应用镜像和父镜像中每个镜像层的标识，也即是，目标镜像的元数据文件会包含完整的目标镜像中每个镜像层的标识。

节点设备接收到对目标镜像的元数据文件后，可以解析对目标镜像的元数据文件，得到目标镜像中每个镜像层的标识，对于目标镜像中的每个镜像层，节点设备可以根据镜像层的标识，查询本机是否已经存储该镜像层，如果本机尚未存储该镜像层，则向镜像库节点发送对该镜像层的获取指令，镜像库节点接收到镜像层的获取指令后，会向节点设备发送该镜像层，节点设备会接收该镜像层，存储该镜像层。相应地，如果本机已经存储该镜像层，则节点设备可以继续查询本机是否已经存储下一个镜像层，通过循环执行查询以及下载镜像层的步骤，当确目标镜像中所有镜像层都下载完成后，结束下载流程。

可选地，对于父镜像再依赖其父镜像这种递归依赖场景，可以支持下载应用镜像时，将应用镜像连同其父镜像以及祖父镜像一起下载的功能。具体来说，可以解析父镜像的目标文件，得到父镜像的镜像依赖信息，父镜像的镜像依赖信息用于指示祖父镜像，例如可以包括祖父镜像的名称、祖父镜像的版本号中的至少一项。可以根据父镜像的镜像依赖信息，在镜像库中进行查询，得到祖父镜像，可以对应用镜像、父镜像以及祖父镜像进行组装，得到目标镜像。例如，可以对应用镜像的元数据文件、父镜像的元数据文件以及祖父镜像的元数据文件进行合并，得到目标镜像的元数据文件，向节点设备发送目标镜像的元数据文件。

示例性地，请参见图11，图11是本申请实施例提供的一种分发镜像的流程图，对于待下载的docker镜像，节点设备可以发送下载应用镜像的manifest文件的请求，该请求中携带应用镜像的名称和tag，镜像库节点可以根据应用镜像的名称和tag，查找应用镜像的manifest文件，解析应用镜像的manifest文件，得到父镜像的标识，根据父镜像的标识，查找到父镜像的manifest文件，并将应用镜像的manifest文件和父镜像的manifest文件合并，若父镜像的manifest文件指示父镜像又依赖于祖父镜像，则继续查找祖父镜像的manifest文件，则继续合并祖父镜像的manifest文件，最终将合并后的manifest文件发送给节点设备，节点设备解析manifest文件，得到docker镜像中所有镜像层的标识，对于docker镜像中的每个镜像层，节点设备可以根据镜像层的标识，查询本机是否已经存储该镜像层，如果本机尚未存储该镜像层，则向docker镜像库发送该镜像层的获取指令，docker镜像库接收到镜像层的获取指令后，会向节点设备发送该镜像层，如果本机已经存储该镜像层，则继续查询本机是否已经存储下一个镜像层，通过循环执行下载一个镜像层的步骤，当确认manifest文件中所有镜像层都下载完成后，结束下载流程。

906、镜像库节点向节点设备发送目标镜像。

907、节点设备接收目标镜像。

可选的，节点设备可以运行目标镜像，创建容器并部署应用。

综上所述，结合本实施例以及图6实施例，可以实现将应用镜像和父镜像彻底解耦开，在上传镜像的节点一侧，可以在构建镜像时，将一个完整的镜像拆分为应用镜像和父镜像，生成单独的应用镜像以及单独的父镜像，并分别发送应用镜像以及父镜像，在镜像站节点一侧，可以对应用镜像和父镜像重新组装起来，发送一个完整的镜像。请参见图12，图12中左侧的node节点在构建镜像时，通过dockerfile文件生成了两个镜像，即父镜像和应用镜像，通过dockerpush指令，可以将两个镜像分别上传至docker镜像仓库，docker镜像仓库可以分别存储父镜像以及应用镜像，docker镜像仓库可以将父镜像以及应用镜像组装，得到一个完整的目标镜像，向node1、node2以及node3分发目标镜像。

可选地，镜像库节点分发更新后的父镜像的过程可以包括以下步骤一至步骤五：

步骤一、镜像库节点存储更新后的父镜像。

镜像库节点可以接收更新后的应用镜像，存储该更新后的应用镜像，接收更新后的应用镜像的方式详见上述图6实施例，在此不做赘述。

步骤二、节点设备向镜像库节点发送对目标镜像的获取指令。

步骤三、当接收到对目标镜像的获取指令时，镜像库节点获取应用镜像的镜像依赖信息。

步骤四、镜像库节点根据镜像依赖信息，在镜像库中进行查询，得到更新后的父镜像。

步骤五、镜像库节点向节点设备发送更新后的父镜像。

综上所述，结合本实施例以及图6实施例，可以实现将父镜像的更新过程与应用镜像彻底解耦开，在上传镜像的节点一侧，在更新父镜像时，只需生成单独的更新后的父镜像，并发送更新后的父镜像即可，而无需重新构建依赖于父镜像的完整镜像，在镜像站节点一侧，可以单独存储更新后的父镜像，分发更新后的父镜像。

示例性地，当node节点生成了一个更新后的父镜像时，可以通过dockerpush指令，单独将这个更新后的父镜像传输至docker镜像仓库，docker镜像仓库可以向node1、node2以及node3分发更新后的父镜像，以使node1、node2以及node3更新已经部署的父镜像。

通过将父镜像和应用镜像拆分开，镜像库节点可以支持单独上传更新后的父镜像的功能，当父镜像更新后，可以只需向镜像库节点发送更新后的父镜像，镜像库节点即可分发更新后的父镜像，而无需重新构建依赖于父镜像的应用镜像，也无需将包含父镜像和应用镜像的完整镜像上传至镜像库节点，提高了对父镜像进行更新的效率，加快了更新父镜像的速度，可以快速更新父镜像，节约了更新后的父镜像在节点设备与镜像库节点之间占用的网络带宽，提高了传输更新后的父镜像的效率，可以令父镜像的更新更加轻量化、更加高效。

可选地，镜像库节点分发更新后的应用镜像的过程可以包括以下步骤一至步骤五：

步骤一、镜像库节点存储更新后的应用镜像。

镜像库节点可以接收更新后的应用镜像，存储该更新后的应用镜像，接收更新后的应用镜像的方式详见上述图6实施例，在此不做赘述。

步骤二、节点设备向镜像库节点发送对目标镜像的获取指令。

步骤三、当接收到对目标镜像的获取指令时，镜像库节点确定更新后的应用镜像。

步骤四、镜像库节点向节点设备发送更新后的应用镜像。

步骤五、节点设备接收更新后的应用镜像。

综上所述，结合本实施例以及图6实施例，可以实现将应用镜像的更新过程与父镜像彻底解耦开，在上传镜像的节点一侧，在更新应用镜像时，只需生成单独的更新后的应用镜像，并发送更新后的应用镜像即可，而无需重新构建父镜像，在镜像站节点一侧，可以单独存储更新后的应用镜像，分发更新后的应用镜像。

示例性地，当node节点生成了一个更新后的应用镜像，可以通过dockerpush指令，将这一个更新后的应用镜像单独传输至docker镜像仓库，docker镜像仓库可以向node1、node2以及node3分发更新后的应用镜像，以使node1、node2以及node3更新已经部署的应用镜像。

通过将父镜像和应用镜像拆分开，镜像库节点可以支持单独上传更新后的应用镜像的功能，当应用镜像更新后，可以只需向镜像库节点发送更新后的应用镜像，镜像库节点即可分发更新后的应用镜像，而无需重新构建父镜像，也无需将包含父镜像和应用镜像的完整镜像上传至镜像库节点，提高了对应用镜像进行更新的效率，加快了更新应用镜像的速度，可以快速更新应用镜像，节约了更新后的应用镜像在节点设备与镜像库节点之间占用的网络带宽，提高了传输更新后的应用镜像的效率，可以令应用镜像的更新更加轻量化、更加高效。

本实施例提供的方法，镜像站节点可以支持应用镜像和父镜像分别上传，当镜像站节点需要分发完整的镜像时，通过镜像依赖信息，确定应用镜像依赖的父镜像，对应用镜像和父镜像组装后进行发送即可，可以极大地提高部署镜像的灵活性，使得上传镜像的节点设备可以分别构建父镜像和应用镜像，分别发送父镜像和应用镜像，如果后续要更新父镜像，则无需重新构建和发送应用镜像，如果后续要更新应用镜像，则无需重新构建和发送父镜像，如果多个应用镜像依赖于同一父镜像，则只需为一个应用镜像生成和发送父镜像即可，极大地提升了镜像的构建效率。

图13是本申请实施例提供的一种镜像构建装置的结构示意图，如图13所示，该装置包括：生成模块1301、获取模块1302和存储模块1303。

生成模块1301，用于执行上述步骤601；

获取模块1302，用于执行上述步骤602；

存储模块1303，用于执行上述步骤603。

在一种可能的实现中，该存储模块1303，用于向该第一镜像中写入该镜像依赖信息，存储写入了该镜像依赖信息的第一镜像。

在一种可能的实现中，该存储模块1303，用于：向该第一镜像的目标文件中写入该镜像依赖信息。

在一种可能的实现中，该获取模块1302，用于：根据该镜像构建文件中的父镜像定义指令，获取该第一镜像的镜像依赖信息。

在一种可能的实现中，该生成模块1301，还用于执行方式(5)和方式(6)中的至少一项。

需要说明的是：上述实施例提供的镜像构建装置在构建镜像时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将计算机设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的镜像构建装置与镜像构建方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图14是本申请实施例提供的一种镜像存储装置的结构示意图，如图14所示，该装置包括：接收模块1401、获取模块1402和发送模块1403。

接收模块1401，用于执行上述步骤801；

获取模块1402，用于执行上述步骤802；

发送模块1403，用于执行上述步骤803。

在一种可能的实现中，该发送模块1403，用于执行上述步骤803中的(1)至(6)中的任意一项或多项的组合。

在一种可能的实现中，该发送模块1403，用于将携带了镜像依赖信息的第一镜像发送给该镜像库节点。

在一种可能的实现中，该发送模块1403，用于将目标文件中携带了镜像依赖信息的第一镜像发送给该镜像库节点。

需要说明的是：上述实施例提供的镜像存储装置在存储镜像时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将计算机设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的镜像存储装置与镜像存储方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图15是本申请实施例提供的一种镜像分发装置的结构示意图，如图15所示，该装置包括：获取模块1501、组装模块1502和发送模块1503。

获取模块1501，用于执行上述步骤903；

组装模块1502，用于执行上述步骤905；

发送模块15031，用于执行上述步骤906。

在一种可能的实现中，该获取模块1501，用于对该第一镜像进行解析，得到该第一镜像的镜像依赖信息。

在一种可能的实现中，该获取模块1501，用于对该第一镜像的目标文件进行解析，得到该目标文件携带的镜像依赖信息。

在一种可能的实现中，该装置还包括：

查询模块，用于执行上述步骤904。

在一种可能的实现中，该组装模块1502，用于对应用镜像、父镜像以及祖父镜像进行组装，得到目标镜像。

在一种可能的实现中，该装置还包括：

合并模块，用于对该第一镜像的元数据文件以及该第二镜像的元数据文件进行合并，得到该目标镜像的元数据文件。

发送模块1503，还用于向该节点设备发送该目标镜像的元数据文件。

在一种可能的实现中，该发送模块1503，还用于执行上述图9实施例中分发更新后的父镜像的过程、分发更新后的应用镜像的过程中的至少一项。

需要说明的是：上述实施例提供的镜像分发装置在分发镜像时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将计算机设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的镜像分发装置与镜像分发方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

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

本申请中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本申请中的字符“/”，一般表示前后关联对象是一种“或”的关系。

本申请中术语“多个”的含义是指两个或两个以上，例如，多个数据包是指两个或两个以上的数据包。

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，本领域技术人员可以理解，“第一”“第二”等字样不对数量和执行顺序进行限定。

以上所述仅为本申请的可选实施例，并不用以限制本申请，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。