CN117971782A - 一种镜像管理方法及服务器 - Google Patents

Abstract

本申请实施例提供一种镜像管理方法及服务器。应用于服务器技术领域。该方法中，获取至少一个应用的软件包；其中，每个应用的软件包中记录了应用的依赖关系信息，依赖关系信息用于表示应用的软件包与至少一个依赖包的依赖关系；根据依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息，镜像分层信息用于表示每个应用的软件包和至少一个依赖包按照依赖关系分层排列的信息；根据镜像分层信息，生成每个应用对应的镜像生成文件；根据每个应用对应的镜像生成文件，生成每个应用对应的容器镜像。本申请实施例能够优化至少一个应用的容器镜像的制作。

Description

一种镜像管理方法及服务器

技术领域

本申请涉及服务器技术领域，尤其涉及一种镜像管理方法及服务器。

背景技术

容器及容器化技术是一种轻量级的虚拟化技术。镜像是容器及容器化技术的核心之一，是一个特殊的文件系统。镜像包含操作系统完整的root文件系统，其体积往往是庞大的，在Docker设计时，可以充分利用联合文件系统的技术，将其设计为分层存储的架构，以实现镜像的分层共享。

相关技术中的镜像管理方法，在制作应用对应的容器镜像时，需要先基于软件包和多个其他软件包(包括软件包依赖的软件包，以及软件包不依赖的软件包)，生成容器镜像。在应用运行时，分析应用对应的软件包所依赖的软件包，将应用对应的软件包所不依赖的其他软件包，进行裁剪处理。

但是，相关技术中的镜像管理方法，可能存在裁剪的其他软件包，被其他应用的软件包依赖的情况，从而导致相关技术中的镜像管理方法，可能存在容器镜像无法正常使用的问题。因此，亟需要一种镜像管理方法，能够优化至少一个应用的容器镜像的制作。

发明内容

本申请实施例提供一种镜像管理方法及服务器，能够优化至少一个应用的容器镜像的制作。

第一方面，本申请实施例提供一种镜像管理方法，包括：

获取至少一个应用的软件包；其中，每个应用的软件包中记录了应用的依赖关系信息，依赖关系信息用于表示应用的软件包与至少一个依赖包的依赖关系；

根据依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息，镜像分层信息用于表示每个应用的软件包和至少一个依赖包按照依赖关系分层排列的信息；

根据镜像分层信息，生成每个应用对应的镜像生成文件；

根据每个应用对应的镜像生成文件，生成每个应用对应的容器镜像。

本实施例的有益效果：本申请实施例是基于软件包中记录的依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，确定镜像分层信息，进而生成用于制作容器镜像的镜像生成文件，通过该种方式，优化了应用的容器镜像的制作，使得生成的容器镜像可以正常使用。

在一种实现方式中，根据依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息，包括：

在获取多个应用的软件包的情况下，对多个应用的依赖关系信息进行合并处理，得到整体依赖关系信息；

根据整体依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息。

本实现方式的有益效果：本申请实施例在生成应用对应的容器镜像之前，先对多个应用的依赖关系信息进行合并处理，得到整体依赖关系信息，再根据整体依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息，以根据镜像分层信息，生成镜像生成文件，进而根据每个应用对应的镜像生成文件，生成每个应用对应的容器镜像。通过上述方式，实现了容器镜像的分层共享能力，实现了同时优化多个容器镜像的制作。

在一种实现方式中，镜像分层信息至少包括公共层信息、第一子层信息和第二子层信息，公共层信息包括至少一个公共依赖包，第一子层信息包括第一应用的专属依赖包和第一应用的软件包，第二子层信息包括第二应用的专属依赖包和第二应用的软件包，根据镜像分层信息，生成每个应用对应的镜像生成文件，包括：

根据公共依赖包、第一应用的专属依赖包以及第一应用的软件包，生成第一应用对应的镜像生成文件；

根据公共依赖包、第二应用的专属依赖包以及第二应用的软件包，生成第二应用对应的镜像生成文件。

本实现方式的有益效果：服务器可以根据公共依赖包、第一应用的专属依赖包以及第一应用的软件包，生成第一应用对应的镜像生成文件；服务器可以根据公共依赖包、第二应用的专属依赖包以及第二应用的软件包，生成第二应用对应的镜像生成文件。通过上述方式，在兼顾了容器镜像的分层共享能力的同时，实现了多镜像的共同优化。

在一种实现方式中，对多个应用的依赖关系信息进行合并处理，得到整体依赖关系信息，包括：

根据每个应用的依赖关系信息，生成每个应用的有向无环图；其中，在有向无环图中，源节点和依赖节点分别表示应用的软件包和依赖包，依赖节点与依赖节点的连接关系表示依赖包与依赖包的依赖关系，源节点与依赖节点的连接关系表示应用的软件包与依赖包的依赖关系；

对多个应用的有向无环图进行合并处理，得到多源有向无环图，并将多源有向无环图确定为整体依赖关系信息。

本实现方式的有益效果：本申请实施例利用了有向无环图有向无回路的特点，将每个应用的依赖关系信息，转换为有向无环图，进而合并出反映整体依赖关系信息的多源有向无环图。通过上述方式，实现了整体依赖关系的快速分析。

在一种实现方式中，根据整体依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息，包括：

根据每个有向无环图中各节点的连接关系，对多源有向无环图进行分层处理，生成层节点图，并将层节点图确定为镜像分层信息。

本实现方式的有益效果：根据多源有向无环图，确定能够用于进行镜像分层的层节点图。通过上述方式，实现了镜像分层信息的快速确定。

在一种实现方式中，根据每个有向无环图中各节点的连接关系，对多源有向无环图进行分层处理，生成层节点图，包括：

将连接相同的源节点的依赖节点，确定为同一连接层次的依赖节点；

针对每个源节点，将与源节点连接且未与其他源节点连接的依赖节点，所对应的连接层次，确定为源节点对应的连接层次；

根据每个源节点对应的连接层次，以及每个依赖节点对应的连接层次，对多源有向无环图进行分层处理，生成层节点图。

本实现方式的有益效果：本实施例中，将连接相同的源节点的依赖节点，确定为同一连接层次的依赖节点，针对每个源节点，将与源节点连接且未与其他源节点连接的依赖节点，所对应的连接层次，确定为源节点对应的连接层次；根据每个源节点对应的连接层次，以及每个依赖节点对应的连接层次，对多源有向无环图进行分层处理，生成层节点图。通过上述方式，可以实现对应用的软件包和依赖包的合理分层，从而实现多容器镜像整体占用的存储空间较小，单个容器镜像占用的存储空间较小，也就是说，兼顾单一容器镜像和总体容器镜像的优化。

在一种实现方式中，对多个应用的有向无环图进行合并处理，得到多源有向无环图，包括：

创建空白图；

针对每个应用的有向无环图，若空白图中不存在与有向无环图的源节点相同的源节点，则在空白图中创建对应的源节点，以对空白图进行更新处理；

若空白图中不存在与有向无环图的依赖节点相同的依赖节点，则在空白图中创建对应的依赖节点，以对空白图进行更新处理；

若空白图中不存在与有向无环图的连接关系相同的连接关系，则在空白图中创建对应的连接关系，以对空白图进行更新处理；

将更新后的空白图确定为多源有向无环图。

本实现方式的有益效果：在空白图中，创建多个有向无环图中的源节点、依赖节点或者连接关系所对应的源节点、依赖节点或者连接关系，以获取多源有向无环图。通过上述方式，可以实现对多个应用的有向无环图的快速合并。

在一种实现方式中，还包括：

获取升级后的应用的软件包；其中，升级后的应用的软件包中，记录了升级后的应用的依赖关系信息；

若确定升级后的应用的依赖关系信息，与升级前的应用的依赖关系信息相同，则获取应用对应的镜像生成文件；

根据升级后的应用的软件包，对应用对应的镜像生成文件进行变更处理，获取变更后的镜像生成文件；

根据变更后的镜像生成文件，生成升级后的应用对应的容器镜像。

本实现方式的有益效果：相较于相关技术中，在应用的软件包升级的情况下，服务器需要重新分析升级后的软件包在运行时所依赖的依赖包，并对镜像进行裁剪处理，导致镜像生成效率和镜像优化效率低下而言，本申请实施例中，在依赖关系信息未发生变更的情况下，应用对应的镜像生成文件可以复用，从而提高了容器镜像的生成效率和容器镜像优化效率。

在一种实现方式中，根据每个应用对应的镜像生成文件，生成每个应用对应的容器镜像，包括：

根据第一应用对应的镜像生成文件，生成第一应用对应的容器镜像；

根据第二应用对应的镜像生成文件，生成第二应用对应的容器镜像。

本实现方式的有益效果：在本实施例中，服务器可以根据第一应用对应的镜像生成文件，生成第一应用对应的容器镜像，并根据第二应用对应的镜像生成文件，生成第二应用对应的容器镜像。通过上述方式，实现了第一应用和第二应用对应的容器镜像的快速制作。

第二方面，本申请实施例提供一种镜像管理装置，包括：

依赖解析模块，用于获取至少一个应用的软件包；其中，每个应用的软件包中记录了应用的依赖关系信息，依赖关系信息用于表示应用的软件包与至少一个依赖包的依赖关系；

依赖分析模块，用于根据依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息，镜像分层信息用于表示每个应用的软件包和至少一个依赖包按照依赖关系分层排列的信息；

镜像生成文件生成模块，用于根据镜像分层信息，生成每个应用对应的镜像生成文件；

镜像制作模块，用于根据每个应用对应的镜像生成文件，生成每个应用对应的容器镜像。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块，具体用于：

在获取多个应用的软件包的情况下，对多个应用的依赖关系信息进行合并处理，得到整体依赖关系信息；

根据整体依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，镜像分层信息至少包括公共层信息、第一子层信息和第二子层信息，公共层信息包括至少一个公共依赖包，第一子层信息包括第一应用的专属依赖包和第一应用的软件包，第二子层信息包括第二应用的专属依赖包和第二应用的软件包，镜像生成文件生成模块，具体用于：

根据公共依赖包、第一应用的专属依赖包以及第一应用的软件包，生成第一应用对应的镜像生成文件；

根据公共依赖包、第二应用的专属依赖包以及第二应用的软件包，生成第二应用对应的镜像生成文件。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块，具体用于：

根据每个应用的依赖关系信息，生成每个应用的有向无环图；其中，在有向无环图中，源节点和依赖节点分别表示应用的软件包和依赖包，依赖节点与依赖节点的连接关系表示依赖包与依赖包的依赖关系，源节点与依赖节点的连接关系表示应用的软件包与依赖包的依赖关系；

对多个应用的有向无环图进行合并处理，得到多源有向无环图，并将多源有向无环图确定为整体依赖关系信息。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块，具体用于：

根据每个有向无环图中各节点的连接关系，对多源有向无环图进行分层处理，生成层节点图，并将层节点图确定为镜像分层信息。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块，具体用于：

将连接相同的源节点的依赖节点，确定为同一连接层次的依赖节点；

针对每个源节点，将与源节点连接且未与其他源节点连接的依赖节点，所对应的连接层次，确定为源节点对应的连接层次；

根据每个源节点对应的连接层次，以及每个依赖节点对应的连接层次，对多源有向无环图进行分层处理，生成层节点图。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块，具体用于：

创建空白图；

针对每个应用的有向无环图，若空白图中不存在与有向无环图的源节点相同的源节点，则在空白图中创建对应的源节点，以对空白图进行更新处理；

若空白图中不存在与有向无环图的依赖节点相同的依赖节点，则在空白图中创建对应的依赖节点，以对空白图进行更新处理；

若空白图中不存在与有向无环图的连接关系相同的连接关系，则在空白图中创建对应的连接关系，以对空白图进行更新处理；

将更新后的空白图确定为多源有向无环图。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，

依赖解析模块，还用于获取升级后的应用的软件包；其中，升级后的应用的软件包中，记录了升级后的应用的依赖关系信息；

依赖解析模块，还用于若确定升级后的应用的依赖关系信息，与升级前的应用的依赖关系信息相同，则获取应用对应的镜像生成文件；

镜像生成文件生成模块，还用于根据升级后的应用的软件包，对应用对应的镜像生成文件进行变更处理，获取变更后的镜像生成文件；

镜像制作模块，还用于根据变更后的镜像生成文件，生成升级后的应用对应的容器镜像。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，镜像制作模块，具体用于：

根据第一应用对应的镜像生成文件，生成第一应用对应的容器镜像；

根据第二应用对应的镜像生成文件，生成第二应用对应的容器镜像。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

第三方面，本申请实施例提供一种服务器，包括：

处理器，以及与处理器通信连接的存储器；

存储器用于存储计算机执行指令；

处理器用于执行存储器存储的计算机执行指令，以实现第一方面的镜像管理方法。

本申请实施例提供的服务器可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现第一方面的镜像管理方法。

本申请实施例提供的计算机可读存储介质可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时用于实现第一方面的镜像管理方法。

本申请实施例提供的计算机程序产品可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种分层存储架构的容器镜像的结构示意图；

图2为本申请实施例提供的一种镜像管理方法实施例一的流程示意图；

图3a为本申请实施例提供的一种镜像管理方法实施例二的流程示意图；

图3b为本申请实施例提供的一种应用的有向无环图的示意图；

图3c为本申请实施例提供的另一种应用的有向无环图的示意图；

图3d为本申请实施例提供的一种得到多源有向无环图的示意图；

图3e为本申请实施例提供的一种层节点图的示意图；

图3f为本申请实施例提供的一种分析依赖关系的示意图；

图3g为本申请实施例提供的另一种分层存储架构的容器镜像的结构示意图；

图4a为本申请实施例提供的一种镜像管理方法实施例三的流程示意图；

图4b为本申请实施例提供的另一种分析依赖关系的示意图；

图4c为本申请实施例提供的一种生成变更后的层节点图的示意图；

图4d为本申请实施例提供的又一种分层存储架构的容器镜像的结构示意图；

图5为本申请实施例提供的一种镜像管理装置的结构示意图；

图6为本申请实施例提供的一种服务器的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在根据本实施例的启示下作出的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

名词解释：

应用(application，APP)：是指针对用户的某种特殊应用目的所撰写的计算机程序。应用可以按照应用目的或功能划分为不同类型，例如应用可以包括电子商务应用、社交应用、办公应用、休闲娱乐应用等类型。

容器(container)：容器是一种操作系统虚拟化形式，通过Linux内核的命名空间隔离实现，实质上是一个被高度隔离的进程。容器是通过镜像创建的运行实例。该运行实例可以是包括至少一个只读层和一个读写层(read-write layer)的联合文件系统。容器运行应用所需的软件包，以实现操作系统级别的虚拟化，从而使得应用运行于相对独立和隔离的环境，简化了应用的部署流程，增强了应用的可移植性和安全性。

镜像(image)：是指包括多个只读层(read-only layer)的联合文件系统(unionfile system)。该联合文件系统能够将不同的只读层整合成一个文件系统，为这些只读层提供一个统一的视角，这样就隐藏了多层的存在，从用户的角度看来，镜像存在一个只读文件系统。镜像是容器的静态方式，与容器的关系就像是软件包和软件进程的关系一样。镜像除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数。因为镜像包含操作系统完整的root文件系统，其体积往往是庞大的，因此在Docker设计时，就充分利用联合文件系统(Union File System，简称UnionFS)的技术，将镜像设计为分层存储架构。镜像可以通过分层来进行继承，基于基础镜像，可以制作各种应用的容器镜像。图1为本申请实施例提供的一种分层存储架构的容器镜像的结构示意图。如图1所示，在分层存储架构下，容器镜像X、容器镜像Y以及容器镜像Z可以共享相同的镜像层A。容器镜像X和容器镜像Y可以共享相同的镜像层B。另外，容器镜像X还可以包括镜像层G和镜像层D；容器镜像Y还可以包括镜像层E；容器镜像Z还可以包括镜像层H、镜像层F以及镜像层C。

rpm(RedHat Package Managerment)：是由Red Hat公司提出，被众多Linux发行版本所采用，是一种数据库记录的方式来将所需要的软件安装到Linux系统的一套软件管理机制。

rpm包：是一种预编译的二进制软件包，包含了软件的源代码、二进制文件、库文件、配置文件等等。rpm包记录了依赖关系信息，包括软件包和依赖包的名称和版本号，以及软件包和依赖包之间的依赖关系(包括直接依赖关系和间接依赖关系)。例如，一个rpm包可能需要一个特定版本号的依赖包才能运行，而这个依赖包又需要该依赖包直接依赖的依赖包才能正常工作。rpm包管理器可以在安装rpm包时，确定该rpm包的依赖包是否存在，若不存在，则自动下载并安装依赖包，在对依赖包安装完毕后，再安装rpm包。在安装rpm包的过程中，会按照指定的顺序执行一组脚本，包括在rpm包中包含的预安装脚本、安装脚本、升级脚本和卸载脚本。这些脚本将确保rpm包被正确地安装到系统中，并且所有必要的配置文件被正确地设置。

依赖包：软件设计思想之一是模块化思想，即不同功能的代码分别存放到不同的文件、类中，每个文件、类都是一个单一功能的模块。软件包是模块化思想的一种体现，即将单一功能的代码划分为一个软件包，其他模块可以引用这个软件包，做到提高代码复用率，同时降低代码的维护成本。一个应用的软件包的生效需要其他的软件包作为基础，可以将被作为基础的软件包，称为依赖包。

rpmorphan：是一个命令行工具，可以分析rpm包，以确定依赖关系信息。

版本号：是版本的标识号，是分配给软件程序、文件、固件、设备驱动程序甚至硬件的特定版本的唯一编号或一组编号。随着新版本的发布，版本号将会增加，版本号能使用户了解所使用的应用是否为最新的版本以及它所提供的功能与设施。

有向无环图：在数学，特别是图论和计算机科学中，有向无环图指的是一个无回路的有向图。

DOT：DOT语言是一种文本图形描述语言。它提供了一种简单的描述图形的方法，并且可以为人类和计算机程序所理解。DOT语言文件通常是具有.gv或是.dot的文件扩展名。

镜像生成文件(dockerfile)：是一个用来构建镜像的文本文件，是构建容器过程中的指令，docker能够读取镜像生成文件的指令进行自动构建容器，基于镜像生成文件制作容器镜像，每一个指令都会创建一个镜像层，即容器镜像都是多层叠加而成。

docker：容器技术，用于支持创建和使用linux容器。

docker build：docker build命令用于使用镜像生成文件创建容器镜像。

相关技术中的镜像管理方法，在制作应用对应的容器镜像时，需要先基于软件包和多个其他软件包(包括软件包依赖的软件包，以及软件包不依赖的软件包)，生成容器镜像。在应用运行时，分析应用对应的软件包所依赖的软件包，将应用对应的软件包所不依赖的其他软件包，进行裁剪处理。但是，相关技术中的镜像管理方法，可能存在裁剪的其他软件包，被其他应用的软件包依赖的情况，从而导致相关技术中的镜像管理方法，可能存在容器镜像无法正常使用的问题。

基于上述技术问题，本申请实施例的技术构思过程如下：根据多个应用的依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息(可以表示每个应用的软件包和至少一个依赖包按照依赖关系分层排列的信息)，并根据镜像分层信息，生成每个应用对应的镜像生成文件，以制作每个应用对应的容器镜像。

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

图2为本申请实施例提供的一种镜像管理方法实施例一的流程示意图。参见图2，该方法具体包括以下步骤：

S201：获取至少一个应用的软件包。

在本实施例中，在服务器需要运行至少一个应用，以对外提供某种功能的情况下，需要在服务器上安装至少一个应用的软件包。服务器可以获取至少一个应用的软件包。其中，软件包中记录了应用的依赖关系信息。

需要说明的是，应用的依赖关系信息用于表示应用的软件包与至少一个依赖包的依赖关系。其中，该依赖关系可以包括直接依赖关系和间接依赖关系。另外，应用的依赖关系信息可以包括软件包的名称和版本号，至少一个依赖包的名称和版本号。

举例来说，第一应用的依赖关系信息包括：软件包A的名称和版本号，依赖包1的名称和版本号，依赖包2的名称和版本号，依赖包3的名称和版本号，依赖包4的名称和版本号，依赖包6的名称和版本号，软件包A和依赖包1之间的直接依赖关系，软件包A和依赖包2之间的直接依赖关系，软件包A和依赖包4之间的直接依赖关系，依赖包2和依赖包3之间的直接依赖关系，以及依赖包4和依赖包6之间的直接依赖关系。

还需要说明的是，软件包可以为rpm包，还可以为其他形式的软件包，本申请实施例对此不进行限制。

还需要说明的是，在一种实现方式中，服务器可以利用rpmorphan(软件)，对软件包进行分析，获取应用的依赖关系信息。

S202：根据依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息。

在本实施例中，服务器可以根据依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息。

在服务器获取一个应用的软件包的情况下：

服务器可以直接根据该应用的依赖关系信息，对该应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息。需要说明的是，镜像分层信息可以包括一个层信息。该层信息包括该应用的软件包和至少一个依赖包。

在服务器获取多个应用的软件包的情况下：

服务器可以对多个应用的依赖关系信息进行合并处理，得到整体依赖关系信息。服务器可以根据整体依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息。需要说明的是，镜像分层信息至少包括公共层信息、第一子层信息和第二子层信息。其中，公共层信息包括至少一个公共依赖包，第一子层信息包括第一应用的专属依赖包和第一应用的软件包，第二子层信息包括第二应用的专属依赖包和第二应用的软件包。另外，需要说明的是，第一子层信息和第二子层信息为并列关系，第一子层信息以公共层信息为基础，第二子层信息以公共层信息为基础。

S203：根据镜像分层信息，生成每个应用对应的镜像生成文件。

在本实施例中，服务器可以根据镜像分层信息，生成每个应用对应的镜像生成文件。

示例性地，在服务器获取第一应用的软件包和第二应用的软件包的情况下，镜像分层信息包括公共层信息、第一子层信息和第二子层信息。公共层信息包括至少一个公共依赖包，第一子层信息包括第一应用的专属依赖包和第一应用的软件包，第二子层信息包括第二应用的专属依赖包和第二应用的软件包。服务器可以根据公共依赖包、第一应用的专属依赖包以及第一应用的软件包，生成第一应用对应的镜像生成文件。服务器可以根据公共依赖包、第二应用的专属依赖包以及第二应用的软件包，生成第二应用对应的镜像生成文件。

具体地，服务器可以根据镜像分层信息，确定每个镜像层中的软件包(和/或依赖包)。服务器可以根据每个镜像层中的软件包(和/或依赖包)，自底而上(每层都以下一层作为基础镜像)逐层生成应用对应的镜像生成文件。需要说明的是，在生成每层镜像生成文件的过程中，服务器通过在每层镜像生成文件中加入该层的软件包(和/或依赖包)的安装脚本的方式，生成该层镜像生成文件(dockerfile)。

S204：根据每个应用对应的镜像生成文件，生成每个应用对应的容器镜像。

在本实施例中，服务器可以根据每个应用的镜像生成文件，生成每个应用对应的容器镜像。

示例性地，在服务器需要生成第一应用对应的容器镜像，和第二应用对应的容器镜像的情况下，服务器可以根据第一应用对应的镜像生成文件，生成第一应用对应的容器镜像；服务器可以根据第二应用对应的镜像生成文件，生成第二应用对应的容器镜像。

具体地，针对每个应用，服务器可以根据该应用对应的镜像生成文件，自底而上逐层生成该应用的容器镜像。示例性地，代码如下：

$docker build-t${IMAGE_NAME}:latest-f${DOCKER_FILE_PATH}

需要说明的是，上述代码表示：使用“docker build”命令，基于镜像生成文件，生成容器镜像。其中，PATH表示要生成的容器镜像的上下文路径，通常是包含镜像生成文件的目录。“IMAGE_NAME”表示容器镜像的名称。“latest”表示打标为latest。

本实施例的有益效果：本申请实施例是基于软件包中记录的依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，确定镜像分层信息，进而生成用于制作容器镜像的镜像生成文件，通过该种方式，优化了应用的容器镜像的制作，使得生成的容器镜像可以正常使用。

下面通过方法实施例二，对服务器获取多个应用的软件包的情况下，服务器生成每个应用对应的容器镜像的过程，进行说明。

图3a为本申请实施例提供的一种镜像管理方法实施例二的流程示意图。参见图3a，该方法具体包括以下步骤：

S301：获取多个应用的软件包。

在本实施例中，服务器可以获取多个应用的软件包。

其中，每个应用的软件包中记录了应用的依赖关系信息，依赖关系信息用于表示应用的软件包与至少一个依赖包的依赖关系。

S302：对多个应用的依赖关系信息进行合并处理，得到整体依赖关系信息。

在本实施例中，服务器可以对多个应用的依赖关系信息进行合并处理，得到整体依赖关系信息。

具体地，服务器可以根据每个应用的依赖关系信息，生成每个应用的有向无环图。其中，有向无环图的源节点表示应用的软件包；有向无环图的依赖节点表示依赖包；有向无环图中的源节点和依赖节点的连接关系，表示应用的软件包与依赖包之间的依赖关系(直接依赖关系)；有向无环图中的依赖节点和依赖节点的连接关系，表示依赖包与依赖包之间的依赖关系(直接依赖关系)。

示例性地，图3b为本申请实施例提供的一种应用的有向无环图的示意图。如图3b所示，在第一应用对应的有向无环图中，源节点表示第一应用的软件包A，依赖节点分别表示依赖包1、依赖包2、依赖包3、依赖包4以及依赖包6。在第一应用对应的有向无环图中，连接关系分别表示软件包A和依赖包1之间的直接依赖关系，软件包A和依赖包2之间的直接依赖关系，依赖包2和依赖包3之间的直接依赖关系，软件包A与依赖包4之间的直接依赖关系，依赖包4与依赖包6之间的直接依赖关系。

示例性地，图3c为本申请实施例提供的另一种应用的有向无环图的示意图。如图3c所示，在第二应用对应的有向无环图中，源节点表示第二应用的软件包B，依赖节点分别表示依赖包1、依赖包3、依赖包5以及依赖包6。在第二应用对应的有向无环图中，连接关系分别表示软件包B和依赖包1之间的直接依赖关系，软件包B和依赖包3之间的直接依赖关系，软件包B和依赖包5之间的直接依赖关系，依赖包5与依赖包6之间的直接依赖关系。

服务器可以在生成多个应用的有向无环图后，对多个应用的有向无环图进行合并处理，得到多源有向无环图。该多源有向无环图可以表示整体依赖关系信息。

下面对服务器对多个应用的有向无环图进行合并处理，得到多源有向无环图的过程进行说明。

具体地，服务器可以创建一个空白图。其中，该空白图可以为DOT格式的图。

针对每个应用的有向无环图，服务器可以在确定空白图中不存在与有向无环图的源节点相同的源节点时，在空白图中创建对应的源节点，以对空白图进行更新处理；服务器可以在确定空白图中不存在与有向无环图的依赖节点相同的依赖节点的情况下，在空白图中创建对应的依赖节点，以对空白图进行更新处理；服务器可以在确定空白图中不存在与有向无环图的连接关系相同的连接关系的情况下，在空白图中创建对应的连接关系，以对空白图进行更新处理。服务器可以将更新后的空白图确定为多源有向无环图。

图3d为本申请实施例提供的一种得到多源有向无环图的示意图。如图3d所示，服务器可以对第一应用对应的有向无环图和第二应用对应的有向无环图进行合并处理，得到多源有向无环图。

S303：根据整体依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息。

在本实施例中，服务器可以根据整体依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息。

具体地，服务器可以根据每个有向无环图中各节点的连接关系，对多源有向无环图进行分层处理，生成层节点图，并将层节点图确定为镜像分层信息。

下面对服务器根据每个有向无环图中各节点的连接关系，对多源有向无环图进行分层处理，生成层节点图的过程，进行详细说明。

具体地，服务器可以将连接相同的源节点的依赖节点，确定为同一连接层次的依赖节点。针对每个源节点，服务器可以将与源节点连接且未与其他源节点连接的依赖节点，所对应的连接层次，确定为源节点对应的连接层次。服务器根据每个源节点对应的连接层次，以及每个依赖节点对应的连接层次，对多源有向无环图进行分层处理，生成层节点图。示例性地，图3e为本申请实施例提供的一种层节点图的示意图。如图3e所示，一个层节点中包括表示软件包A的源节点、表示依赖包2的依赖节点以及表示依赖包4的依赖节点，一个层节点中包括表示软件包B的源节点、表示依赖包5的依赖节点，一个层节点中包括表示依赖包1的依赖节点、表示依赖包3的依赖节点以及表示依赖包6的依赖节点。

在一种实现方式中，服务器可以在生成层节点图后，根据层节点图中的每个源节点(或者依赖节点)所表示的软件包(或者依赖包)的大小，以及预设的分层大小，对层节点图进行调整处理。举例来说，层节点图中的一个层节点中包括一个源节点和两个依赖节点，服务器可以基于该源节点所表示的软件包的大小为200MB，两个依赖节点所表示的两个依赖包的大小皆为100MB，预设的分层大小为200MB，将该层节点拆分为两个层节点(一个层节点包括源节点，另一个层节点包括两个依赖节点)，以对层节点图进行调整处理。服务器可以将调整后的层节点图，确定为镜像分层信息。

下面结合具体示例，对服务器确定每个依赖节点连接的源节点的过程，进行详细说明。

首先，服务器可以对各个源节点和依赖节点的依赖关系进行分析。

图3f为本申请实施例提供的一种分析依赖关系的示意图。如图3f所示，服务器可以根据每个有向无环图中各节点的连接关系，对各个源节点和依赖节点的依赖关系进行分析，可知：

软件包A和软件包B皆直接依赖于依赖包1；软件包A间接依赖于依赖包3(软件包A直接依赖与依赖包2，依赖包2直接依赖于依赖包3)，软件包B直接依赖于依赖包3；软件包A间接依赖于依赖包6，(软件包A直接依赖与依赖包4，依赖包4直接依赖于依赖包6)；软件包B间接依赖于依赖包6(软件包B直接依赖于依赖包5，依赖包5直接依赖于依赖包6)。

基于上述内容可知：

依赖包1对应的依赖节点，连接的源节点为软件包A对应的源节点和软件包B对应的源节点；依赖包2对应的依赖节点，连接的源节点为软件包A对应的源节点；依赖包3对应的依赖节点，连接的源节点为软件包A对应的源节点和软件包B对应的源节点；依赖包4对应的依赖节点，连接的源节点为软件包A对应的源节点；依赖包5对应的依赖节点，连接的源节点为软件包B对应的源节点；依赖包6对应的依赖节点，连接的源节点为软件包A对应的源节点和软件包B对应的源节点。

S304：根据镜像分层信息，生成每个应用对应的镜像生成文件。

在本实施例中，服务器可以根据镜像分层信息，生成每个应用对应的镜像生成文件。

具体地，针对每个应用，服务器可以确定层节点图中，表示该应用的软件包的源节点所属的层节点，以及该层节点连接的其他层节点。服务器可以根据该应用的软件包的源节点所属的层节点，以及该层节点连接的其他层节点，生成该应用对应的镜像生成文件。

在服务器根据该应用的软件包的源节点所属的层节点，以及该层节点连接的其他层节点，生成该应用对应的镜像生成文件的过程中：

服务器可以将每个层节点中的源节点(和/或依赖节点)所表示的软件包(和/或依赖包)，确定为每个镜像层中的软件包(和/或依赖包)。服务器可以根据基础镜像，以及每个镜像层中的软件包(和/或依赖包)，自底而上(每层都以下一层作为基础镜像)逐层生成应用对应的镜像生成文件。需要说明的是，在生成每层镜像生成文件的过程中，服务器通过在每层镜像生成文件中加入该层的软件包(和/或依赖包)的安装脚本的方式，生成该层镜像生成文件。

示例性地，生成第一应用对应的镜像生成文件的过程的代码如下：

###common_layer_base_image

from baseimage

RUN rpm-ivh依赖包1依赖包3依赖包6

###app_a_image

from common_layer_base_image

RUN rpm-ivh依赖包2依赖包4软件包A

需要说明的是，上述代码表示：将baseimage作为基础镜像，在公共基础镜像层(common_layer_base_image)中加入依赖包1、依赖包3以及依赖包6，以生成公共基础镜像层(common_layer_base_image)。将公共基础镜像层(common_layer_base_image)作为基础镜像，在第一应用的镜像层中加入依赖包2、依赖包4以及软件包A，以生成第一应用的镜像层(app_a_image)。

示例性地，生成软件包B对应的Dockerfile的过程的代码如下：

###common_layer_base_image

from baseimage

RUN rpm-ivh依赖包1依赖包3依赖包6

###app_b_image

from common_layer_base_image

RUN rpm-ivh依赖包5软件包B

需要说明的是，上述代码表示：将baseimage作为基础镜像，在公共基础镜像层(common_layer_base_image)中加入依赖包1、依赖包3以及依赖包6，以生成公共基础镜像层(common_layer_base_image)。将公共基础镜像层(common_layer_base_image)作为基础镜像，在第二应用的镜像层(app_b_image)中加入依赖包5和软件包B，以生成第一应用的镜像层(app_b_image)。

另外，服务器在生成每个应用对应的镜像生成文件后，可以对每个应用对应的镜像生成文件进行存储处理。

S305：根据每个应用对应的镜像生成文件，生成每个应用对应的容器镜像。

在本实施例中，服务器可以根据每个应用的镜像生成文件，生成每个应用对应的容器镜像。

需要说明的是，在服务器需要同时发布多个应用的情况下，多个应用对应的容器镜像可以为分层存储架构。示例性地，图3g为本申请实施例提供的另一种分层存储架构的容器镜像的结构示意图。

另外，服务器可以根据对每个应用对应的容器镜像进行保存处理。

在一种实现方式中，服务器可以将每个应用对应的镜像保存为一个文件。示例性地，代码如下：

$docker save${IMAGE_NAME}:latest-o${IMAGE_PKG_NAME}#

需要说明的是，上述代码表示：使用“docker save”命令，保存容器镜像“IMAGE_NAME”为一个文件。

在一种实现方式中，在服务器生成多个应用对应的容器镜像的情况下，服务器可以将多个应用对应的容器镜像保存为一个文件。示例性地，代码如下：

$docker save${IMAGE_NAME_1}:latest${IMAGE_NAME_2}:latest…-o${PKG_NAME}#

需要说明的是，上述代码表示：使用“docker save”命令，保存容器镜像“IMAGE_NAME_1”、容器镜像“IMAGE_NAME_2”等等，为一个文件。

本实施例的有益效果：本申请实施例在生成应用对应的容器镜像之前，先对多个应用的依赖关系信息进行合并处理，得到整体依赖关系信息，再根据整体依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息，以根据镜像分层信息，生成镜像生成文件，进而根据每个应用对应的镜像生成文件，生成每个应用对应的容器镜像。通过上述方式，实现了容器镜像的分层共享能力，实现了同时优化多个容器镜像的制作。

图4a为本申请实施例提供的一种镜像管理方法实施例三的流程示意图。参见图4a，该方法具体包括以下步骤：

S401：获取升级后的应用的软件包。

在本实施例中，服务器可以获取升级后的应用的软件包，其中，升级后的应用的软件包中，记录了升级后的应用的依赖关系信息。

S402：若确定升级后的应用的依赖关系信息，与升级前的应用的依赖关系信息相同，则获取应用对应的镜像生成文件。

在本实施例中，服务器可以在获取升级后的应用的软件包后，比较升级后的应用的依赖关系信息和升级前的应用的依赖关系信息。

服务器可以在确定升级后的应用的依赖关系信息和升级前的应用的依赖关系信息相同的情况下，获取服务器存储的该应用对应的镜像生成文件。

另外，需要说明的是，服务器在确定升级后的应用的依赖关系信息和升级前的应用的依赖关系信息不同的情况下，可以对升级后的应用的依赖关系信息，以及与该应用相关的其他应用的依赖关系信息，进行合并处理，得到变更后的整体依赖关系信息。服务器可以根据变更后的整体依赖关系信息，对每个应用(升级后的应用，以及与该应用相关的其他应用)的软件包和至少一个依赖包进行分层处理，得到变更后的镜像分层信息。服务器可以根据变更后的镜像分层信息，生成升级后的应用对应的镜像生成文件，以及其他应用对应的镜像生成文件。服务器可以根据升级后的应用对应的镜像生成文件，生成升级后的应用对应的容器镜像。服务器可以根据其他应用对应的镜像生成文件，生成其他应用对应的容器镜像。

下面结合具体示例，对在升级后的应用的依赖关系信息，和升级前的应用的依赖关系信息不同的情况下，服务器生成升级后的应用对应的容器镜像，以及其他应用对应的容器镜像的过程，进行说明。

图4b为本申请实施例提供的另一种分析依赖关系的示意图。

如图4b所示，升级前，软件包A和软件包B皆直接依赖于依赖包1；软件包A间接依赖于依赖包3(软件包A直接依赖与依赖包2，依赖包2直接依赖于依赖包3)，软件包B直接依赖于依赖包3；软件包A间接依赖于依赖包6，(软件包A直接依赖与依赖包4，依赖包4直接依赖于依赖包6)；软件包B间接依赖于依赖包6(软件包B直接依赖于依赖包5，依赖包5直接依赖于依赖包6)。

升级后，软件包A和软件包B皆直接依赖于依赖包1；软件包A间接依赖于依赖包3(软件包A直接依赖与依赖包2，依赖包2直接依赖于依赖包3)，软件包B直接依赖于依赖包3；软件包A间接依赖于依赖包6，(软件包A直接依赖与依赖包5，依赖包5直接依赖于依赖包6)；软件包B间接依赖于依赖包6(软件包B直接依赖于依赖包5，依赖包5直接依赖于依赖包6)。

服务器可以确定升级后的第一应用的依赖关系信息和升级前的第一应用的依赖关系信息不同。

服务器可以对升级后的第一应用的依赖关系信息，以及第二应用的依赖关系信息，进行合并处理，得到变更后的整体依赖关系信息。服务器可以根据变更后的整体依赖关系信息，对每个应用(升级后的第一应用，以及与第二应用)的软件包和至少一个依赖包进行分层处理，得到变更后的镜像分层信息。图4c为本申请实施例提供的一种生成变更后的层节点图的示意图。其中，变更后的多源有向无环图，表示变更后的整体依赖关系信息；变更后的层节点图，表示变更后的镜像分层信息。

服务器可以根据变更后的镜像分层信息，生成升级后的应用对应的镜像生成文件，以及其他应用对应的镜像生成文件。服务器可以根据升级后的应用对应的镜像生成文件，生成升级后的应用对应的容器镜像。服务器可以根据其他应用对应的镜像生成文件，生成其他应用对应的容器镜像。需要说明的是，升级后的应用对应的容器镜像，和其他应用对应的容器镜像可以为分层存储架构。示例性地，图4d为本申请实施例提供的又一种分层存储架构的容器镜像的结构示意图。如图4d所示，在服务器确定升级后的第一应用的依赖关系信息和升级前的第一应用的依赖关系信息不同的情况下，服务器可以生成第一应用对应的容器镜像，并生成第二应用对应的容器镜像。

S403：根据升级后的应用的软件包，对应用对应的镜像生成文件进行变更处理，获取变更后的镜像生成文件。

在本实施例中，服务器可以在获取应用对应的镜像生成文件后，根据升级后的应用的软件包，对应用对应的镜像生成文件，进行变更处理，以获取变更后的镜像生成文件。

具体地，服务器可以将镜像生成文件中的顶层镜像生成文件的安装脚本中的软件包，变更为升级后的软件包，以获取变更后的镜像生成文件。

S404：根据变更后的镜像生成文件，生成升级后的应用对应的容器镜像。

在本实施例中，服务器可以根据变更后的镜像生成文件，生成升级后的应用对应的容器镜像。

本实施例中，服务器在获取升级后的应用的软件包后，若确定升级后的应用的依赖关系信息，与升级前的应用的依赖关系信息相同，则获取应用对应的镜像生成文件。服务器可以根据升级后的应用的软件包，对应用对应的镜像生成文件进行变更处理，获取变更后的镜像生成文件。服务器可以根据变更后的镜像生成文件，生成升级后的应用对应的容器镜像。相较于相关技术中，在应用升级的情况下，服务器需要生成该升级后的应用对应的容器镜像，并重新分析升级后的应用在运行时所依赖的依赖包，对容器镜像进行裁剪处理，导致容器镜像的生成效率和容器镜像的优化效率低下而言，本申请实施例中，在应用的依赖关系信息未发生变更的情况下，应用对应的镜像生成文件可以复用，从而提高了容器镜像的生成效率和容器镜像的优化效率。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图5为本申请实施例提供的一种镜像管理装置的结构示意图，如图5所示，镜像管理装置50，包括：依赖解析模块51、依赖分析模块52、镜像生成文件生成模块53以及镜像制作模块54。其中，

依赖解析模块51，用于获取至少一个应用的软件包；其中，每个应用的软件包中记录了应用的依赖关系信息，依赖关系信息用于表示应用的软件包与至少一个依赖包的依赖关系；

依赖分析模块52，用于根据依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息，镜像分层信息用于表示每个应用的软件包和至少一个依赖包按照依赖关系分层排列的信息；

镜像生成文件生成模块53，用于根据镜像分层信息，生成每个应用对应的镜像生成文件；

镜像制作模块54，用于根据每个应用对应的镜像生成文件，生成每个应用对应的容器镜像。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块52，具体用于：

在获取多个应用的软件包的情况下，对多个应用的依赖关系信息进行合并处理，得到整体依赖关系信息；

根据整体依赖关系信息，对每个应用的软件包和至少一个依赖包进行分层处理，得到镜像分层信息。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，镜像分层信息至少包括公共层信息、第一子层信息和第二子层信息，公共层信息包括至少一个公共依赖包，第一子层信息包括第一应用的专属依赖包和第一应用的软件包，第二子层信息包括第二应用的专属依赖包和第二应用的软件包，镜像生成文件生成模块53，具体用于：

根据公共依赖包、第一应用的专属依赖包以及第一应用的软件包，生成第一应用对应的镜像生成文件；

根据公共依赖包、第二应用的专属依赖包以及第二应用的软件包，生成第二应用对应的镜像生成文件。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块52，具体用于：

根据每个应用的依赖关系信息，生成每个应用的有向无环图；其中，在有向无环图中，源节点和依赖节点分别表示应用的软件包和依赖包，依赖节点与依赖节点的连接关系表示依赖包与依赖包的依赖关系，源节点与依赖节点的连接关系表示应用的软件包与依赖包的依赖关系；

对多个应用的有向无环图进行合并处理，得到多源有向无环图，并将多源有向无环图确定为整体依赖关系信息。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块52，具体用于：

根据每个有向无环图中各节点的连接关系，对多源有向无环图进行分层处理，生成层节点图，并将层节点图确定为镜像分层信息。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块52，具体用于：

将连接相同的源节点的依赖节点，确定为同一连接层次的依赖节点；

针对每个源节点，将与源节点连接且未与其他源节点连接的依赖节点，所对应的连接层次，确定为源节点对应的连接层次；

根据每个源节点对应的连接层次，以及每个依赖节点对应的连接层次，对多源有向无环图进行分层处理，生成层节点图。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，依赖分析模块52，具体用于：

创建空白图；

针对每个应用的有向无环图，若空白图中不存在与有向无环图的源节点相同的源节点，则在空白图中创建对应的源节点，以对空白图进行更新处理；

若空白图中不存在与有向无环图的依赖节点相同的依赖节点，则在空白图中创建对应的依赖节点，以对空白图进行更新处理；

若空白图中不存在与有向无环图的连接关系相同的连接关系，则在空白图中创建对应的连接关系，以对空白图进行更新处理；

将更新后的空白图确定为多源有向无环图。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，

依赖解析模块51，还用于获取升级后的应用的软件包；其中，升级后的应用的软件包中，记录了升级后的应用的依赖关系信息；

依赖解析模块51，还用于若确定升级后的应用的依赖关系信息，与升级前的应用的依赖关系信息相同，则获取应用对应的镜像生成文件；

镜像生成文件生成模块53，还用于根据升级后的应用的软件包，对应用对应的镜像生成文件进行变更处理，获取变更后的镜像生成文件；

镜像制作模块54，还用于根据变更后的镜像生成文件，生成升级后的应用对应的容器镜像。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种实现方式中，镜像制作模块54，具体用于：

根据第一应用对应的镜像生成文件，生成第一应用对应的容器镜像；

根据第二应用对应的镜像生成文件，生成第二应用对应的容器镜像。

本申请实施例提供的镜像管理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

图6为本申请实施例提供的一种服务器的结构示意图。如图6所示，该服务器60包括：处理器61和存储器62；其中，处理器61与存储器62通信连接，存储器62用于存储计算机执行指令；处理器81配置为经由执行存储器62存储的计算机执行指令来执行前述方法实施例中的技术方案。

可选的，存储器62既可以是独立的，也可以跟处理器61集成在一起。可选的，当存储器62是独立于处理器61之外的器件时，服务器60还可以包括：总线，用于将上述器件连接起来。

该处理器用于执行前述方法实施例中的技术方案，其实现原理和技术效果类似，在此不再赘述。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现前述方法实施例提供的技术方案。

本申请实施例还提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时用于实现前述方法实施例提供的技术方案。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或对其中部分或全部技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种镜像管理方法，其特征在于，包括：

获取至少一个应用的软件包；其中，每个所述应用的软件包中记录了所述应用的依赖关系信息，所述依赖关系信息用于表示所述应用的软件包与至少一个依赖包的依赖关系；

根据所述依赖关系信息，对每个所述应用的软件包和至少一个所述依赖包进行分层处理，得到镜像分层信息，所述镜像分层信息用于表示每个所述应用的软件包和至少一个所述依赖包按照所述依赖关系分层排列的信息；

根据所述镜像分层信息，生成每个所述应用对应的镜像生成文件；

根据每个所述应用对应的镜像生成文件，生成每个所述应用对应的容器镜像。

2.根据权利要求1所述的镜像管理方法，其特征在于，所述根据所述依赖关系信息，对每个所述应用的软件包和至少一个所述依赖包进行分层处理，得到镜像分层信息，包括：

在获取多个应用的软件包的情况下，对多个所述应用的依赖关系信息进行合并处理，得到整体依赖关系信息；

根据所述整体依赖关系信息，对每个所述应用的软件包和至少一个所述依赖包进行分层处理，得到所述镜像分层信息。

3.根据权利要求2所述的镜像管理方法，其特征在于，所述镜像分层信息至少包括公共层信息、第一子层信息和第二子层信息，所述公共层信息包括至少一个公共依赖包，所述第一子层信息包括所述第一应用的专属依赖包和所述第一应用的软件包，所述第二子层信息包括所述第二应用的专属依赖包和所述第二应用的软件包，所述根据所述镜像分层信息，生成每个所述应用对应的镜像生成文件，包括：

根据所述公共依赖包、所述第一应用的专属依赖包以及所述第一应用的软件包，生成所述第一应用对应的镜像生成文件；

根据所述公共依赖包、所述第二应用的专属依赖包以及所述第二应用的软件包，生成所述第二应用对应的镜像生成文件。

4.根据权利要求2所述的镜像管理方法，其特征在于，所述对多个所述应用的依赖关系信息进行合并处理，得到整体依赖关系信息，包括：

根据每个所述应用的依赖关系信息，生成每个所述应用的有向无环图；其中，在所述有向无环图中，源节点和依赖节点分别表示所述应用的软件包和依赖包，依赖节点与依赖节点的连接关系表示依赖包与依赖包的依赖关系，源节点与依赖节点的连接关系表示所述应用的软件包与依赖包的依赖关系；

对多个所述应用的有向无环图进行合并处理，得到多源有向无环图，并将所述多源有向无环图确定为所述整体依赖关系信息。

5.根据权利要求4所述的镜像管理方法，其特征在于，所述根据所述整体依赖关系信息，对每个所述应用的软件包和至少一个所述依赖包进行分层处理，得到所述镜像分层信息，包括：

根据每个所述有向无环图中各节点的连接关系，对所述多源有向无环图进行分层处理，生成层节点图，并将所述层节点图确定为所述镜像分层信息。

6.根据权利要求5所述的镜像管理方法，其特征在于，所述根据每个所述有向无环图中各节点的连接关系，对所述多源有向无环图进行分层处理，生成层节点图，包括：

将连接相同的源节点的依赖节点，确定为同一连接层次的依赖节点；

针对每个源节点，将与所述源节点连接且未与其他源节点连接的依赖节点，所对应的连接层次，确定为所述源节点对应的连接层次；

根据每个源节点对应的连接层次，以及每个依赖节点对应的连接层次，对所述多源有向无环图进行分层处理，生成所述层节点图。

7.根据权利要求4所述的镜像管理方法，其特征在于，所述对多个应用的有向无环图进行合并处理，得到多源有向无环图，包括：

创建空白图；

针对每个应用的有向无环图，若所述空白图中不存在与所述有向无环图的源节点相同的源节点，则在所述空白图中创建对应的源节点，以对所述空白图进行更新处理；

若所述空白图中不存在与所述有向无环图的依赖节点相同的依赖节点，则在所述空白图中创建对应的依赖节点，以对所述空白图进行更新处理；

若所述空白图中不存在与所述有向无环图的连接关系相同的连接关系，则在所述空白图中创建对应的连接关系，以对所述空白图进行更新处理；

将更新后的空白图确定为所述多源有向无环图。

8.根据权利要求1所述的镜像管理方法，其特征在于，还包括：

获取升级后的应用的软件包；其中，所述升级后的应用的软件包中，记录了所述升级后的应用的依赖关系信息；

若确定所述升级后的应用的依赖关系信息，与升级前的应用的依赖关系信息相同，则获取所述应用对应的镜像生成文件；

根据所述升级后的应用的软件包，对所述应用对应的镜像生成文件进行变更处理，获取变更后的镜像生成文件；

根据所述变更后的镜像生成文件，生成所述升级后的应用对应的容器镜像。

9.根据权利要求3所述的镜像管理方法，其特征在于，所述根据每个所述应用对应的镜像生成文件，生成每个所述应用对应的容器镜像，包括：

根据所述第一应用对应的镜像生成文件，生成所述第一应用对应的容器镜像；

根据所述第二应用对应的镜像生成文件，生成所述第二应用对应的容器镜像。

10.一种服务器，其特征在于，包括：

处理器，以及与所述处理器通信连接的存储器；

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

所述处理器用于执行所述存储器存储的计算机执行指令，以实现权利要求1-9所述的镜像管理方法。