一种镜像构建和更新方法及装置与流程

1.本技术实施例涉及计算机技术领域，尤其涉及一种镜像构建和更新方法及装置。


背景技术：

2.docker基于go语言实现的云开源项目，docker的主要目标是对应用的封装、分发、部署、运行等生命周期管理，达到“一次封装，到处运行”的效果。
3.一个完整的应用(application，app)镜像实际上是多个镜像层的组合，每个镜像层都有唯一的数值作为镜像的标识。为了便于理解，通常按照镜像层的作用和其所处于的层级，将完整的app镜像分为三部分，底层镜像层、至少一个中间层镜像层和上层镜像层，如图1所示。其中，上层镜像层依赖中间层镜像层，中间层镜像层依赖底层镜像层，因此可能出现多个完整的app镜像包含重复的中间层镜像层或底层镜像层，造成存储资源的浪费。
4.当前通用的做法是采用镜像分层瘦身去重方法，删除重复的中间层镜像层或底层镜像层。通过采用镜像分层瘦身去重技术，可以大幅度降低app镜像的体积，从而对构建、发布效率产生有益效果。但是，在app镜像依赖的镜像发生更新时，可能导致该app镜像不可用，需要基于更新后的镜像重新制作app镜像，进而带来了开发、维护效率的大幅降低的问题。


技术实现要素：

5.本技术实施例提供一种镜像构建和更新方法及装置，用以解决由于app镜像依赖的镜像更新导致该app镜像不可用的问题。
6.第一方面，本技术提供一种镜像构建方法，该方法包括：第一设备构建第一镜像，并向第二设备发送所述第一镜像；所述第一设备构建第二镜像，所述第二镜像包括所述第二镜像的元数据文件，所述第二镜像的元数据文件指示所述第二镜像依赖于所述第一镜像，所述第二镜像的元数据文件包括所述第一镜像的镜像名称、所述第一镜像的版本号和所述第一镜像的标识；所述第一设备向所述第二设备发送所述第二镜像。
7.采用上述方法，通过在第二镜像的元数据文件增加第一镜像的镜像名称和第一镜像的版本号，从而完善了指示第二镜像依赖于第一镜像的具体内容，且能够为后续在镜像更新时确定依赖更新后的镜像的镜像提供保障，即可以通过第一镜像的镜像名称和第一镜像的版本号确定第二镜像依赖第一镜像，进而能够实现更新第二镜像的元数据文件，避免重建第二镜像。
8.在一种可能的设计中，在所述第一设备构建第二镜像时，所述第一设备根据镜像构建模板构建所述第二镜像，所述镜像构建模板包括第一标签，所述第一标签用于定义镜像之间的依赖关系。
9.采用上述设计，镜像构建模板新增第一标签，以实现通过填充第一标签记录镜像之间的依赖关系。
10.在一种可能的设计中，所述第一设备根据所述第一标签获取所述第一镜像的镜像
名称和所述第一镜像的版本号；所述第一设备将所述第一镜像的镜像名称和所述第一镜像的版本号写入所述第二镜像的元数据文件。
11.采用上述设计，第一设备可以通过填充后的第一标签读取第一镜像的镜像名称和第一镜像的版本号，并写入第二镜像的元数据文件。
12.在一种可能的设计中，所述第一镜像为base镜像，所述第二镜像为lib镜像；或者，所述第一镜像为base镜像，所述第二镜像为app镜像。
13.在一种可能的设计中，所述第一镜像为lib镜像，所述第二镜像为app镜像；所述第一镜像包括所述第一镜像的元数据文件，所述第一镜像的元数据文件包括第三镜像的镜像名称、所述第三镜像的版本号和所述第三镜像的标识；所述第一镜像依赖于所述第三镜像；在向第二设备发送所述第一镜像之前，所述第一设备构建所述第三镜像，并向所述第二设备发送所述第三镜像。
14.采用上述设计，当第二镜像为app镜像时，app镜像的元数据文件用于记录app镜像依赖的lib镜像，不需要记录app镜像依赖的lib镜像依赖的base镜像，进而可以实现控制元数据文件的大小。
15.在一种可能的设计中，所述第一设备构建第四镜像，并向所述第二设备发送所述第四镜像；其中，所述第四镜像为所述第一镜像的更新镜像，所述第四镜像包括所述第一镜像的名称和所述第一镜像的版本号，所述第四镜像的标识与所述第一镜像的标识不同。
16.在一种可能的设计中，所述第一设备为镜像构建设备，所述第二设备为镜像仓库。
17.第二方面，本技术提供一种镜像更新方法，该方法包括：
18.第二设备接收第一镜像，所述第二设备接收第二镜像，所述第二镜像依赖于所述第一镜像，所述第二镜像包括所述第二镜像的元数据文件，所述第二镜像的元数据文件包括所述第一镜像的镜像名称、所述第一镜像的版本号和所述第一镜像的标识。所述第二设备接收第四镜像，所述第四镜像包括所述第一镜像的名称和所述第一镜像的版本号，所述第四镜像为所述第一镜像的更新镜像，所述第四镜像的标识与所述第一镜像的标识不同。所述第二设备根据所述第二镜像的元数据文件和所述第四镜像确定更新所述第二镜像的元数据文件，更新后的所述第二镜像的元数据文件包括所述第一镜像的镜像名称、所述第一镜像的版本号和所述第四镜像的标识。
19.采用上述方法，通过在第二镜像的元数据文件增加第一镜像的镜像名称和第一镜像的版本号，从而完善了指示第二镜像依赖于第一镜像的具体内容，且能够为后续在镜像更新时确定依赖更新后的镜像的镜像提供保障，即可以通过第一镜像的镜像名称和第一镜像的版本号确定第二镜像依赖第一镜像，进而确定需要更新的元数据文件，即能够实现将第二镜像的元数据文件中的第一镜像的标识更新为第四镜像的标识，因此能够实现避免重建第二镜像。
20.在一种可能的设计中，所述第二设备根据所述第二镜像的元数据文件确定所述第二镜像的镜像数据，所述第二镜像的镜像数据指示所述第二镜像依赖于所述第一镜像，所述第二镜像的镜像数据包括所述第一镜像的镜像名称和所述第一镜像的版本号；在接收到所述第四镜像之后，所述第二设备根据所述第一镜像的名称和所述第一镜像的版本号检索所述第二设备保存的镜像数据；所述第二设备确定依赖于所述第一镜像的镜像的镜像数据，所述依赖于所述第一镜像的镜像的镜像数据包括所述第二镜像的镜像数据；所述第二
设备根据所述第二镜像的镜像数据确定所述第二镜像的元数据文件。
21.采用上述方法，在接收到镜像时，生成相应的镜像数据，并在发生镜像更新时，通过更新后的镜像携带的镜像名称和版本号检索保存的镜像数据，实现确定依赖更新后的镜像的镜像数据，并进一步确定相应的元数据文件。
22.在一种可能的设计中，所述第一镜像为base镜像，所述第二镜像为lib镜像；或者，所述第一镜像为base镜像，所述第二镜像为应用app镜像。
23.在一种可能的设计中，所述第一镜像为lib镜像，所述第二镜像为应用app镜像；所述第一镜像包括第一镜像的元数据文件，所述第一镜像的元数据文件用于指示所述第一镜像依赖于第三镜像，所述第三镜像为base镜像，所述第一镜像的元数据文件包括第三镜像的镜像名称、所述第三镜像的版本号和所述第三镜像的标识；所述第二设备接收所述第三镜像。所述第二设备根据第一镜像的元数据文件确定所述第一镜像的镜像数据，所述第一镜像的镜像数据指示所述第一镜像依赖于所述第三镜像，所述第二镜像的镜像数据包括所述第三镜像的镜像名称和所述第三镜像的版本号。
24.在一种可能的设计中，所述第一设备为镜像构建设备，所述第二设备为镜像仓库。
25.第三方面，本技术提供一种镜像构建装置，所述装置为第一设备或具有第一设备的功能的装置，所述装置包括处理单元和收发单元；所述处理单元，用于构建第一镜像，所述收发单元，用于向第二设备发送所述第一镜像；所述处理单元用于构建第二镜像，所述第二镜像包括所述第二镜像的元数据文件，所述第二镜像的元数据文件指示所述第二镜像依赖于所述第一镜像，所述第二镜像的元数据文件包括所述第一镜像的镜像名称、所述第一镜像的版本号和所述第一镜像的标识；所述收发单元，用于向所述第二设备发送所述第二镜像。
26.在一种可能的设计中，所述处理单元，用于在构建第二镜像时，根据镜像构建模板构建所述第二镜像，所述镜像构建模板包括第一标签，所述第一标签用于定义镜像之间的依赖关系。
27.在一种可能的设计中，所述处理单元，还用于根据所述第一标签获取所述第一镜像的镜像名称和所述第一镜像的版本号；将所述第一镜像的镜像名称和所述第一镜像的版本号写入所述第二镜像的元数据文件。
28.在一种可能的设计中，所述第一镜像为基础base镜像，所述第二镜像为资源lib镜像；或者，所述第一镜像为base镜像，所述第二镜像为应用app镜像。
29.在一种可能的设计中，所述第一镜像为lib镜像，所述第二镜像为app镜像；所述第一镜像包括所述第一镜像的元数据文件，所述第一镜像的元数据文件包括第三镜像的镜像名称、所述第三镜像的版本号和所述第三镜像的标识；所述第一镜像依赖于所述第三镜像；所述处理单元，用于在向第二设备发送所述第一镜像之前，构建所述第三镜像；所述收发单元，用于向所述第二设备发送所述第三镜像。
30.在一种可能的设计中，还包括：所述处理单元，用于构建第四镜像；所述收发单元，用于向所述第二设备发送所述第四镜像；其中，所述第四镜像为所述第一镜像的更新镜像，所述第四镜像包括所述第一镜像的名称和所述第一镜像的版本号，所述第四镜像的标识与所述第一镜像的标识不同。
31.在一种可能的设计中，所述第一设备为镜像构建设备，所述第二设备为镜像仓库。
32.第四方面，本技术提供一种镜像更新装置，所述装置为第一设备或具有第一设备的功能的装置，所述装置包括处理单元和收发单元；所述收发单元，用于接收第一镜像；接收第二镜像，所述第二镜像依赖于所述第一镜像，所述第二镜像包括所述第二镜像的元数据文件，所述第二镜像的元数据文件包括所述第一镜像的镜像名称、所述第一镜像的版本号和所述第一镜像的标识；接收第四镜像，所述第四镜像包括所述第一镜像的名称和所述第一镜像的版本号，所述第四镜像为所述第一镜像的更新镜像，所述第四镜像的标识与所述第一镜像的标识不同；所述处理单元，用于根据所述第二镜像的元数据文件和所述第四镜像确定更新所述第二镜像的元数据文件，更新后的所述第二镜像的元数据文件包括所述第一镜像的镜像名称、所述第一镜像的版本号和所述第四镜像的标识。
33.在一种可能的设计中，所述处理单元，用于根据所述第二镜像的元数据文件确定所述第二镜像的镜像数据，所述第二镜像的镜像数据指示所述第二镜像依赖于所述第一镜像，所述第二镜像的镜像数据包括所述第一镜像的镜像名称和所述第一镜像的版本号；在接收到所述第四镜像之后，根据所述第一镜像的名称和所述第一镜像的版本号检索所述第二设备保存的镜像数据；确定依赖于所述第一镜像的镜像的镜像数据，所述依赖于所述第一镜像的镜像的镜像数据包括所述第二镜像的镜像数据；根据所述第二镜像的镜像数据确定所述第二镜像的元数据文件。
34.在一种可能的设计中，所述第一镜像为base镜像，所述第二镜像为lib镜像；或者，所述第一镜像为base镜像，所述第二镜像为应用app镜像。
35.在一种可能的设计中，所述第一镜像为lib镜像，所述第二镜像为应用app镜像；所述第一镜像包括第一镜像的元数据文件，所述第一镜像的元数据文件用于指示所述第一镜像依赖于第三镜像，所述第三镜像为base镜像，所述第一镜像的元数据文件包括第三镜像的镜像名称、所述第三镜像的版本号和所述第三镜像的标识；所述收发单元，用于接收所述第三镜像。所述处理单元，用于根据第一镜像的元数据文件确定所述第一镜像的镜像数据，所述第一镜像的镜像数据指示所述第一镜像依赖于所述第三镜像，所述第二镜像的镜像数据包括所述第三镜像的镜像名称和所述第三镜像的版本号。
36.在一种可能的设计中，所述第一设备为镜像构建设备，所述第二设备为镜像仓库。
37.第五方面，本技术还提供一种装置。该装置可以执行上述方法设计。该装置可以是能够执行上述方法对应的功能的芯片或电路，或者是包括该芯片或电路的设备。
38.在一种可能的实现方式中，该装置包括：存储器，用于存储计算机可执行程序代码；以及处理器，处理器与存储器耦合。其中存储器所存储的程序代码包括指令，当处理器执行所述指令时，使该装置或者安装有该装置的设备执行上述任意一种可能的设计中的方法。
39.其中，该装置还可以包括通信接口，该通信接口可以是收发器，或者，如果该装置为芯片或电路，则通信接口可以是该芯片的输入/输出接口，例如输入/输出管脚等。
40.在一种可能的设计中，该装置包括相应的功能单元，分别用于实现以上方法中的步骤。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的单元。
41.第六方面，本技术提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在装置上运行时，执行上述任意一种可能的设计中的方
法。
42.第七方面，本技术提供一种计算机程序产品，所述计算机程序产品包括计算机程序，当所述计算机程序在装置上运行时，执行上述任意一种可能的设计中的方法。
43.第八方面，本技术提供一种通信系统，所述系统包括第一设备和第二设备，其中，所述第一设备用于执行上述第一方面中的任意一种可能的设计中的方法，所述第二设备用于执行上述第二方面中的任意一种可能的设计中的方法。
附图说明
44.图1为本技术中各个镜像层的依赖关系示意图之一；
45.图2为本技术应用的docker系统框架的示意图；
46.图3为本技术中各个镜像层的依赖关系示意图之二；
47.图4为本技术中镜像分层瘦身去重方法的示意图；
48.图5为本技术中一种镜像构建和更新方法的概述流程图；
49.图6为本技术中元数据文件的更新示意图之二；
50.图7为本技术中一种装置的结构示意图之一；
51.图8为本技术中一种装置的结构示意图之二。
具体实施方式
52.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。本技术的说明书和权利要求书及上述附图中的术语“第一”、第二”以及相应术语标号等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本技术的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。
53.在本技术的描述中，除非另有说明，“/”表示或的意思，例如，a/b可以表示a或b；本技术中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，在本技术的描述中，“至少一项”是指一项或者多项，“多项”是指两项或两项以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。
54.以下对本技术涉及的一些技术概念进行说明：
55.1.镜像(又称docker镜像)
56.镜像是容器运行时的只读模板，每一个镜像由一系列的层(layers)组成。镜像是一个特殊的文件系统，可以提供容器运行时所需的程序、库、资源、配置等文件。
57.2.容器(docker containers)
58.容器是镜像的运行的一个实例，容器类似于一个轻量级的沙盒，可以实现对容器
外部的软件以及硬件进行屏蔽。容器从镜像启动时，在镜像的最上层创建一个可写层，镜像本身保持不变。
59.3.元数据(meta data又称data about data)
60.元数据用于描述数据的数据，从信息资源中抽取出来的用于说明其特征、内容的结构化的数据。元数据文件为用于存储元数据的文件。
61.4.构建模板(dockerfile)(又称为镜像构建模板)
62.构建模板是一个用来构建镜像的文本文件，该文本文件包含了多条构建镜像所需的指令和说明。
63.本技术应用于docker系统，如图2所示为一种docker系统框架的示意图。该系统至少可以包括镜像构建设备、镜像仓库和运行节点。
64.其中，镜像构建设备用于根据开发人员提交的源码和定义的构建模板生成镜像，并将生成的镜像上传至镜像仓库。
65.镜像仓库用于存储大量镜像，负责镜像的存储、管理和分发。
66.运行节点为应用实际运行所在的业务节点，用于从镜像仓库拉取镜像，根据镜像创建容器，并且启动应用。
67.在采用镜像分层瘦身去重方法之前，一个完整的应用镜像实际上是多个镜像层的组合。以下结合图3对各个镜像层的功能进行简要说明。
68.底层镜像层，又可称为基础(base)镜像层：仅包含基础的操作系统功能。
69.中间层镜像层，又可称为资源(library，lib)镜像层：在基础的操作系统之上，集成提供增强的通用基础能力，例如python、jre等。
70.上层镜像层，又可称为app镜像层：在中间镜像层的基础上，提供多种不同的服务能力，例如常用的redis，zookeeper等。
71.可以理解的是，在采用镜像分层瘦身去重技术之后，上述各个镜像层各自作为独立的镜像，其功能保持不变。
72.如图4所示，在采用镜像分层瘦身去重方法之前，完整的app1镜像和完整的app2镜像包括相同的base镜像层和部分相同的lib镜像层。其中，完整的app1镜像包括app1镜像层，lib1镜像层，base1镜像层，完整的app2镜像包括app2镜像层，lib1镜像层，lib2镜像层，base1镜像层。因此，镜像仓库需要存储上述7个镜像层，而base1镜像层和lib1镜像层为完整的app1镜像和完整的app2镜像均包括的镜像层，各存储了两份，造成存储资源的浪费。
73.在采用镜像分层瘦身去重方法之后，镜像仓库仅需存储app1镜像(对应上述app1镜像层)、app2镜像(对应上述app2镜像层)、lib1镜像(对应上述lib1镜像层)、lib2镜像(对应上述lib2镜像层)、base1镜像(对应上述base1镜像层)，即去除重复的镜像层，去重后的镜像层各自作为独立的镜像。因此，从效果上来看，分层瘦身去重之后，app镜像是将本身与lib镜像层和base镜像层从完整包含的集成关系转变为间接依赖的配套关系。
74.为了实现app镜像正常工作，镜像构建系统将会在app镜像的元数据文件中增加描述本app镜像与其他base镜像和lib镜像的依赖关系。同理，lib镜像的元数据文件中增加描述本lib镜像与其他base镜像的依赖关系。示例性地，上述元数据文件可以是manifest.json文件。元数据文件可以记录一个镜像依赖的各个镜像的元数据，例如，可以记录每个镜像的标识，例如，每个镜像的标识可以是sha256值。
75.示例性地，在app1镜像的元数据文件中，详细定义了app1镜像依赖的各个镜像的标识，以及各个镜像之间的依赖关系。例如，如图4右侧所示为app1镜像的元数据文件的部分内容。由上述内容可知，app1镜像依赖lib1镜像、lib1镜像依赖base1镜像。app1镜像的元数据文件包括app1镜像的标识，lib1镜像的标识和base1镜像的标识。具体的，在图4中，按照从下往上的顺序，第一行的镜像标识为base1镜像的标识，表示app1镜像依赖的base镜像，第二行的镜像标识为lib1镜像的标识，表示app镜像依赖的lib镜像，第三行的镜像标识为app1镜像的标识。同理，app2镜像的元数据文件包括app2镜像的标识，lib1镜像的标识、lib2镜像的标识和base1镜像的标识。
76.但是，在app镜像依赖的镜像发生更新时，可能导致该app镜像不可用。以下以base1镜像更新导致app1镜像不可用为例进行说明。当base1镜像更新时，这里假设更新后的base1镜像记为base1*镜像，base1*镜像的标识与base1镜像的标识不同，即base1*镜像的标识与app1镜像的元数据文件中的从下往上的第一行的镜像标识不一致。由于在base1*镜像上传到镜像仓库后，base1镜像可能不可用。因此，运行节点此时根据app1镜像的元数据文件下载的app1镜像、lib1镜像和base1镜像创建的容器也将会不可用。由于app1镜像的元数据文件不可以独立生成，且镜像仓库也无法根据base1*镜像的标识识别出base1*镜像为base1镜像的更新，因此，无法对app1镜像的元数据文件进行更新。此时，镜像构建设备需要重新生成新的app1镜像，记为app1*镜像。app1*镜像的元数据文件包括app1*镜像的标识、lib1镜像的标识和base1*镜像的标识。因此，每次出现app1镜像依赖的镜像(例如lib1镜像或base1镜像)更新，镜像构建设备均需要根据更新的镜像重新构建app1镜像，从进而带来了开发、维护效率的大幅降低。
77.基于此，本技术实施例提供一种镜像构建和镜像文件的更新方法，用以解决由于app镜像依赖的镜像更新导致该app镜像不可用的问题。采用本技术实施例提供的方法可以实现app镜像依赖的镜像更新后无需重新构建app镜像，进而提升开发和维护效率。
78.如图5所示，该方法涉及第一设备和第二设备。其中，第一设备用于构建镜像，例如，如图2中的镜像构建设备，第二设备用于存储第一设备构建的镜像，例如镜像仓库。
79.步骤500：第一设备构建第一镜像。
80.步骤510：第一设备向第二设备发送第一镜像。
81.相应的，第二设备接收并存储第一镜像。
82.步骤520：第一设备构建第二镜像，第二镜像包括第二镜像的元数据文件，第二镜像的元数据文件用于指示第二镜像依赖于第一镜像，第二镜像的元数据文件包括第一镜像的镜像名称、第一镜像的版本号和第一镜像的标识。
83.相较于现有技术中，第二镜像的元数据文件仅记录第一镜像的标识，本技术中第二镜像的元数据文件增加记录了第一镜像的镜像名称和第一镜像的版本号，从而完善了指示第二镜像依赖于第一镜像的具体内容，且能够为后续在镜像更新时确定依赖更新后的镜像的镜像提供保障，即可以通过第一镜像的镜像名称和第一镜像的版本号确定第二镜像依赖第一镜像，进而能够实现同步更新第二镜像的元数据文件中第一镜像的标识，避免重建第二镜像。
84.可以理解的是，除了元数据文件，记录镜像之间的依赖关系的文件还可以替换为其他文件，或者新定义的文件，本技术对此不作限定。下文仅以记录镜像之间的依赖关系的
文件为元数据文件为例进行说明。
85.在一种可能的设计中，第一设备根据镜像构建模板构建第二镜像，镜像构建模板包括第一标签，第一标签用于定义镜像之间的依赖关系。由于第二镜像依赖于第一镜像，则第一设备根据第一标签获取第一镜像的镜像名称和第一镜像的版本号，并将第一镜像的镜像名称和第一镜像的版本号写入第二镜像的元数据文件。
86.需要说明的是，这里的镜像构建模板为lib镜像的镜像构建模板或app镜像的镜像构建模板。由于base镜像不依赖其他镜像，因此，base镜像的镜像构建模板可以不需要增加第一标签，或者base镜像的镜像构建模板中的第一标签置为0或空。
87.示例性地，lib镜像的镜像构建模板或app镜像的镜像中新增第一标签，例如，第一标签可以为label标签，或者其他名称的标签，本技术对此不作限定。
88.以下label标签的格式进行举例说明第一标签的具体结构，可以理解的是，label标签还可以采用其他格式，本技术对此不作限定。
89.lbael from＝[“xxx:xxx”]。
[0090]
xxx:xxx的定义方法为冒号左边为镜像名称，冒号右边为版本号。
[0091]
如果一个镜像依赖多个镜像，中间以逗号分隔，可以限定不允许有空格等任意其他字符。
[0092]
lbael from＝[“xxx:xxx”,“xxx:xxx”]。
[0093]
示例性地，第一设备根据上述label标签的格式填充第一镜像的镜像名称和第一镜像的版本号之后，第一设备根据填充后label标签将第一镜像的镜像名称和第一镜像的版本号写入第二镜像的元数据文件。
[0094]
以下结合具体场景1和场景2进行说明第一镜像和第二镜像。需要说明的是，在本技术中，第一设备优先上传base镜像，再上传lib镜像、最后上传app镜像。因此，通过上传的顺序保证在上传app镜像时，即便该app镜像自身并未包含base镜像层和lib镜像层，该app镜像也是可用的。
[0095]
场景1：第一镜像为base镜像，第二镜像为lib镜像。或者第一镜像为base镜像，第二镜像为app镜像。以下以第一镜像为base镜像，第二镜像为lib镜像为例进行说明。
[0096]
第一设备根据base镜像的镜像构建模板构建第一镜像，向第二设备发送第一镜像。
[0097]
第一设备根据lib镜像的镜像构建模板构建第二镜像，由于第二镜像依赖于第一镜像，则第一设备根据lib镜像的镜像构建模板中的第一标签获取第一镜像的镜像名称和第一镜像的版本号。第一设备将第一镜像的镜像名称和第一镜像的版本号写入第二镜像的元数据文件。
[0098]
例如，第一镜像的镜像名称为eulerx86，第一镜像版本号为1.5.3，则第一设备根据lib镜像的镜像构建模板确定填充后的label标签具体为：
[0099]
label from＝["eulerx86:1.5.3"]。
[0100]
进一步地，第一设备根据填充后的label标签，将第一镜像的镜像名称为eulerx86，第一镜像版本号为1.5.3，写入第二镜像的元数据文件。
[0101]
需要说明的是，一般地，在第一设备构建完成第一镜像之后，第一设备继续构建其他base镜像，而不是构建第二镜像。当所有base镜像均构建完成并发送至第二设备之后，第
二设备开始构建lib镜像，例如包括第二镜像。或者又可以描述为，在完成上传与第一镜像类型相同的镜像后，第二设备构建第二镜像。
[0102]
此外，当第一镜像为base镜像，第二镜像为app镜像时，可以直接将上述内容中的lib镜像替换为app镜像，此处不再赘述。
[0103]
场景2：第一镜像为lib镜像，第二镜像为app镜像，第三镜像为base镜像。
[0104]
第一设备根据base镜像的镜像构建模板构建第三镜像，向第二设备发送第三镜像。
[0105]
第一设备根据lib镜像的镜像构建模板构建第一镜像，向第二设备发送第一镜像。由于第一镜像依赖于第三镜像，则第一设备根据lib镜像的镜像构建模板中的第一标签获取第三镜像的镜像名称和第三镜像的版本号。第一设备将第三镜像的镜像名称和第三镜像的版本号写入第一镜像的元数据文件。第一镜像的元数据文件用于指示第一镜像依赖于第三镜像，第一镜像的元数据文件包括第三镜像的镜像名称、第三镜像的版本号和第三镜像的标识。第一镜像包括第一镜像的元数据文件。
[0106]
例如，第三镜像的镜像名称为eulerx86，第三镜像版本号为1.5.3，则第一设备根据lib镜像的镜像构建模板确定填充后的label标签具体为：
[0107]
label from＝["eulerx86:1.5.3"]。
[0108]
进一步地，第一设备根据填充后的label标签，将第三镜像的镜像名称为eulerx86，第三镜像版本号为1.5.3，写入第一镜像的元数据文件。
[0109]
第一设备根据app镜像的镜像构建模板构建第二镜像，由于第二镜像依赖于第一镜像，则第一设备根据app镜像的镜像构建模板中的第一标签获取第一镜像的镜像名称和第一镜像的版本号。第一设备将第一镜像的镜像名称和第一镜像的版本号写入第二镜像的元数据文件。第二镜像包括第二镜像的元数据文件。
[0110]
例如，第一镜像的镜像名称为eulerx86lib，第一镜像版本号为1.5.3，则app镜像的镜像构建模板中填充后的label标签具体为：
[0111]
label from＝["eulerx86lib:1.5.3"]。
[0112]
进一步地，第一镜像根据填充后的label标签，将第一镜像的镜像名称为eulerx86lib，第一镜像版本号为1.5.3，写入第二镜像的元数据文件。
[0113]
需要说明的是，一般地，在第一设备构建完成第三镜像之后，第一设备继续构建其他base镜像，而不是构建第二镜像和第三镜像。当所有base镜像均构建完成并发送至第二设备之后，第二设备开始构建lib镜像，例如包括第一镜像。当所有lib镜像均构建完成并发送至第二设备之后，第二设备开始构建app镜像，例如包括第二镜像。
[0114]
步骤530：第一设备向第二设备发送第二镜像。
[0115]
相应的，第二设备接收并存储第二镜像。
[0116]
第二设备可以采用但不限于以下两种实现方式对接收到的镜像进行处理：
[0117]
第一种可能的实现方式：第二设备可以针对每个接收到的镜像的元数据文件生成一个镜像数据存入数据库，进而实现保存各个镜像之间的依赖关系。
[0118]
示例性地，第二设备可以针对每个镜像的元数据文件提取如下参数作为该镜像的镜像数据写入数据库，具体提取的参数可以包括但不限于以下几项：
[0119]
imagename(镜像名称)；
[0120]
imageversion(版本号)；
[0121]
labelfrom(依赖镜像的镜像名称和版本号)。
[0122]
可以理解的是，上述字段的名称仅为举例，还可以替换为其他名称，此外，镜像数据还可以扩充其他字段，本技术对此不作限定。其中，镜像的元数据文件包括镜像的镜像名称和版本号，此外，由上述内容可知，在本技术中，镜像的元数据文件还增加记录了镜像依赖的镜像的镜像名称和版本号。因此，通过镜像的元数据文件可以填充上述三个参数，获得该镜像的镜像数据。
[0123]
此外，当某个镜像为base镜像时，由于base镜像不依赖于其他镜像，因此，labelfrom可以为空或置为0。
[0124]
以下结合上述场景1和场景2对第二设备生成每个镜像的镜像数据的具体过程进行说明：
[0125]
对应于上述场景1，在第二设备接收并存储第一镜像之后，第二设备可以读取第一镜像的元数据文件，确定第一镜像的镜像数据。
[0126]
示例性地，第二设备根据第一镜像的元数据文件填充上述参数，获得的第一镜像的镜像数据，包括：
[0127]
imagename：第一镜像的镜像名称；
[0128]
imageversion：第一镜像的版本号；
[0129]
labelfrom：0。
[0130]
在第二设备接收并存储第二镜像之后，第二设备可以读取第二镜像的元数据文件，确定第二镜像的镜像数据。
[0131]
示例性地，第二设备根据第二镜像的元数据文件填充上述参数，获得的第二镜像的镜像数据，包括：
[0132]
imagename：第二镜像的镜像名称；
[0133]
imageversion：第二镜像的版本号；
[0134]
labelfrom：第一镜像的镜像名称，第一镜像的版本号。
[0135]
其中，第二设备从第二镜像的元数据文件获取第一镜像的镜像名称和第一镜像的版本号写入labelfrom字段，可以实现存储第一镜像与第二镜像的依赖关系。
[0136]
对应于上述场景2，第一镜像为lib镜像，第二镜像为app镜像，第三镜像为base镜像，在第二设备接收并存储第三镜像之后，第二设备可以读取第三镜像的元数据文件，确定第三镜像的镜像数据。示例性地，第二设备根据第三镜像的元数据文件填充上述参数，获得的第三镜像的镜像数据，包括：
[0137]
imagename：第三镜像的镜像名称；
[0138]
imageversion：第三镜像的版本号；
[0139]
labelfrom：0。
[0140]
在第二设备接收并存储第一镜像之后，第二设备可以读取第一镜像的元数据文件，确定第一镜像的镜像数据。
[0141]
示例性地，第二设备根据第一镜像的元数据文件填充上述参数，获得的第一镜像的镜像数据，包括：
[0142]
imagename：第一镜像的镜像名称；
[0143]
imageversion：第一镜像的版本号；
[0144]
labelfrom：第三镜像的镜像名称，第三镜像的版本号。
[0145]
其中，第二设备从第一镜像的元数据文件获取第三镜像的镜像名称和第三镜像的版本号，写入labelfrom字段，可以实现存储第一镜像与第三镜像的依赖关系。
[0146]
在第二设备接收并存储第二镜像之后，第二设备可以读取第二镜像的元数据文件，确定第二镜像的镜像数据。
[0147]
示例性地，第二设备根据第二镜像的元数据文件填充上述参数，获得的第二镜像的镜像数据，包括：
[0148]
imagename：第二镜像的镜像名称；
[0149]
imageversion：第二镜像的版本号；
[0150]
labelfrom：第一镜像的镜像名称，第一镜像的版本号。
[0151]
其中，第二设备从第二镜像的元数据文件获取第一镜像的镜像名称和第一镜像的版本号，写入labelfrom字段，可以实现存储第一镜像与第二镜像的依赖关系。
[0152]
通过上述过程，第二设备将各个镜像之间的依赖关系存入数据库，进而可以为后续在镜像更新时确定依赖更新后的镜像的镜像提供支持。
[0153]
第二种可能的实现方式：第二设备还可以仅生成lib镜像的镜像数据和app镜像的镜像数据，不生成base镜像的镜像数据。这里生成lib镜像的镜像数据和app镜像的镜像数据可以参考上述第一种可能的实现方式，重复之处不在赘述。
[0154]
此外，还需要说明的是，上述生成每个镜像的镜像数据的过程不是必选过程，当后续镜像更新需要确定依赖更新后的镜像的镜像时，也可以选择直接检索各个镜像的元数据文件。但是，直接检索各个镜像的元数据文件，相较于检索数据库中的镜像数据，速度较慢，效率较低。
[0155]
步骤540：第一设备构建第四镜像，其中，第四镜像为第一镜像的更新镜像，第四镜像包括第一镜像的镜像名称和第一镜像的版本号。第四镜像的标识与第一镜像的标识不同。其中，第一镜像的镜像名称和第一镜像的版本号，以及第四镜像的标识可以存储于第四镜像的元数据文件中。
[0156]
示例性地，第一设备接收到第一镜像的更新指令，第一设备根据第一镜像的更新指令生成第四镜像。
[0157]
可以理解的是，对应于上述场景1，第四镜像为base镜像，第一设备根据base镜像的镜像构建模板构建第四镜像。
[0158]
对应于上述场景2，第四镜像为lib镜像，第一设备根据lib镜像的镜像构建模板构建第四镜像。由于第一镜像依赖于第三镜像，则第四镜像也依赖于第三镜像，第一设备根据lib镜像的镜像构建模板中的第一标签获取第三镜像的镜像名称和第三镜像的版本号。第一设备将第三镜像的镜像名称和第三镜像的版本号写入第三文件。第四镜像包括第三文件，第三文件用于指示第四镜像依赖于第三镜像，第三文件包括第三镜像的镜像名称、第三镜像的版本号和第三镜像的标识。
[0159]
步骤550：第一设备向第二设备发送第四镜像。
[0160]
相应的，第二设备接收并存储第四镜像。其中，第二设备可以根据第四镜像包括的第一镜像的镜像名称和第一镜像的版本号确定第四镜像为第一镜像的更新镜像。
[0161]
此时，第二设备可以不需要生成第四镜像的镜像数据。原因在于，由于第四镜像为第一镜像的更新镜像，且由上述三个参数可知，若生成第四镜像的镜像数据，则第四镜像的镜像数据与第一镜像的镜像数据相同，因此，不需要两份完全相同的镜像数据。另外，第四镜像上传至第二设备后，第一镜像将不可用，则之前生成的第一镜像的镜像数据直接作为第四镜像的镜像数据即可。
[0162]
示例性地，第二设备根据第四镜像的元数据文件填充上述参数，获得的第四镜像的镜像数据，包括：
[0163]
imagename：第一镜像的镜像名称；
[0164]
imageversion：第一镜像的版本号；
[0165]
labelfrom：0。
[0166]
对应于上述场景2，在第二设备接收并存储第四镜像之后，第二设备可以读取第四镜像的元数据文件，确定第四镜像的镜像数据。
[0167]
示例性地，第二设备根据第四镜像的元数据文件填充上述参数，获得的第四镜像的镜像数据，包括：
[0168]
imagename：第一镜像的镜像名称；
[0169]
imageversion：第一镜像的版本号；
[0170]
labelfrom：第三镜像的镜像名称，第三镜像的版本号。
[0171]
此外，第二设备还可以不生成更新后的镜像的镜像数据。
[0172]
步骤560：第二设备根据第二镜像的元数据文件和第四镜像更新第二镜像的元数据文件，更新后的第二镜像的元数据文件包括第一镜像的镜像名称、第一镜像的版本号和第四镜像的标识。
[0173]
示例性地，在接收到第四镜像之后，第二设备可以根据第一镜像的名称和第一镜像的版本号检索第二设备保存的镜像数据，确定依赖于第一镜像的镜像的镜像数据，依赖于第一镜像的镜像的镜像数据包括第二镜像的镜像数据，即由于第二镜像的镜像数据中的labelfrom字段填充第一镜像的名称和第一镜像的版本号，进而确定第二镜像依赖于第一镜像，第二镜像的镜像数据为依赖于第一镜像的镜像的镜像数据。进一步地，第二设备根据第二镜像的镜像数据确定第二镜像的元数据文件。在确定第二镜像的元数据文件之后，第二设备根据第四镜像的镜像标识更新第二镜像的元数据文件，即将第二镜像的元数据文件中第一镜像的标识替换为第四镜像的标识。
[0174]
在一种实现方式中，第二设备可以在接收到第四镜像之后，不立即检索保存的镜像数据，而是定时开启检索保存的镜像数据，或者，第二设备可以在接收到第四镜像之后，立即检索保存的镜像数据进行扫描。
[0175]
示例性地，第二设备可以按照保存的镜像数据的标识从小到大的顺序，或者按照保存的镜像数据的保存时间先后顺序，这里还可以采用其他顺序检索保存的镜像数据。
[0176]
其中，第二设备可以根据第一镜像的镜像名称和第一镜像的版本号检索保存的镜像数据，具体可以采用下述规则确定依赖于第一镜像的镜像，或者依赖于第一镜像的镜像的镜像数据。
[0177]
规则1：
[0178]
对于任意一个镜像数据，若该镜像数据中的labelfrom字段为空或0，则表示该镜
像数据对应的镜像是base镜像，则跳过该镜像数据，继续处理下一个镜像数据；
[0179]
规则2：
[0180]
对于任意一个镜像数据，若该镜像数据labelfrom字段不为空，则表示该镜像是非base镜像，则进一步判断labelfrom字段是否包括第一镜像的镜像名称和第一镜像的版本号，若不包括，则继续处理下一个镜像数据；
[0181]
规则3：
[0182]
若该镜像数据labelfrom字段包括第一镜像的镜像名称和第一镜像的版本号，即该镜像数据对应的镜像依赖于第一镜像，此时，更新该镜像数据对应的镜像的元数据文件，即将其中第一镜像的标识替换为第四镜像的标识。
[0183]
规则4：
[0184]
在根据规则3确定依赖于第一镜像的镜像数据后，根据该镜像数据中的imagename字段和imageversion字段填充的内容(记为imagename
*
和imageversion
*
)，采用上述规则1至规则3，确定labelfrom字段包括imagename
*
和imageversion
*
的镜像数据，此时，更新该镜像数据对应的镜像的元数据文件，即将其中第一镜像的标识替换为第四镜像的标识。
[0185]
重复上述过程直至完成全部镜像数据的检索。
[0186]
例如，app1镜像依赖lib1镜像、lib1镜像依赖base1镜像。base 1镜像的元数据文件包括base 1镜像的镜像名称，base 1镜像的版本号和base 1镜像的标识。lib1镜像的元数据文件包括base 1镜像的镜像名称、base 1镜像的版本号，base 1镜像的标识，以及lib1镜像的镜像名称和lib1镜像的版本号和lib1镜像的标识。其中，lib1镜像的镜像名称和lib1镜像的版本号未在图6中画出。app1镜像的元数据文件包括lib1镜像的镜像名称、lib1镜像的版本号，lib1镜像的标识，以及base1镜像的标识，此外，还包括app1镜像的镜像名称、app 1镜像的版本号，app1镜像的标识。其中，app1镜像的镜像名称和app 1镜像的版本号未在图6中画出。可以理解的是，如图4所示，相较于原来的app1镜像的元数据文件，app1镜像的元数据文件增加了lib1镜像的镜像名称、lib1镜像的版本号。其中，app1镜像的镜像名称、app 1镜像的版本号在原来的app1镜像的元数据文件中也包括，图4未画出。
[0187]
同理，相较于原来的lib1镜像的元数据文件，lib1镜像的元数据文件增加了base 1镜像的镜像名称、base 1镜像的版本号。其中，lib1镜像的镜像名称、lib 1镜像的版本号在原来的app1镜像的元数据文件中也包括。
[0188]
第二设备根据base1镜像、lib1镜像和app1镜像，确定base1镜像的镜像数据，lib1镜像的镜像数据和app1镜像的镜像数据存入数据库。
[0189]
其中，base 1镜像的镜像数据包括：
[0190]
imagename：base 1镜像的镜像名称；
[0191]
imageversion：base 1镜像的版本号；
[0192]
labelfrom：0。
[0193]
lib1镜像的镜像数据包括：
[0194]
imagename：lib1镜像的镜像名称；
[0195]
imageversion：lib1镜像的版本号；
[0196]
labelfrom：base 1镜像的镜像名称，base 1镜像的版本号。
[0197]
app1镜像的镜像数据包括：
[0198]
imagename：app1镜像的镜像名称；
[0199]
imageversion：app 1镜像的版本号；
[0200]
labelfrom：lib1镜像的镜像名称，lib1镜像的版本号。
[0201]
当base1镜像更新时，这里假设更新后的base1镜像记为base1*镜像，base1*镜像的标识与base1镜像的标识不同。base1*镜像包括base1镜像的镜像名称和base1镜像的版本号。
[0202]
第二设备根据base1镜像的镜像名称和base1镜像的版本号检索保存的镜像数据：
[0203]
例如，当第二设备检索到base 1镜像的镜像数据时，根据规则1确定该镜像数据中的labelfrom字段为空，则表示该镜像数据对应的镜像是base镜像，则跳过该镜像数据，继续处理下一个镜像数据。
[0204]
可以理解的是，上述处理方式适用于第二设备保存的所有base镜像的镜像数据。
[0205]
例如，当第二设备检索到app1镜像的镜像数据时，根据规则2确定该镜像数据的labelfrom字段不为空，则表示该镜像是非base镜像，且该labelfrom字段不包括base1镜像的镜像名称和base1镜像的版本号，则继续处理下一个镜像数据。
[0206]
可以理解的是，上述处理方式适用于所有不依赖于base1镜像的镜像数据。
[0207]
例如，当第二设备检索到lib1镜像的镜像数据时，根据规则3确定该镜像数据labelfrom字段不为空，则表示该镜像是非base镜像，且该labelfrom字段包括base1镜像的镜像名称和base1镜像的版本号，则第二设备更新该镜像数据对应的镜像的元数据文件，即更新lib1镜像的元数据文件，在更新后的lib1镜像的元数据文件中，base1镜像的标识更新为base1*镜像的标识。可以理解的是，上述处理方式适用于所有依赖于base1镜像的lib镜像的元数据文件，或者仅依赖于base1镜像的app镜像的元数据文件。例如，当lib2镜像的镜像数据中的labelfrom字段包括base1镜像的镜像名称和base1镜像的版本号时，则第二设备需要更新lib2镜像的元数据文件，即将lib2镜像的元数据文件中base1镜像的标识更新为base1*镜像的标识。又例如，当app2镜像的镜像数据中的labelfrom字段包括base1镜像的镜像名称和base1镜像的版本号时，则第二设备还需要更新app2镜像的元数据文件，即将app2镜像的元数据文件中base1镜像的标识更新为base1*镜像的标识。
[0208]
进一步地，在更新lib1镜像的元数据文件之后，根据规则4，第二设备根据lib1镜像的镜像名称和lib1镜像的版本号检索保存的镜像数据：
[0209]
例如，当第二设备检索到app1镜像的镜像数据时，确定该镜像数据labelfrom字段不为空，则表示该镜像是非base镜像，且该labelfrom字段包括lib1镜像的镜像名称和lib1镜像的版本号，则第二设备更新该镜像数据对应的镜像的元数据文件，即更新app1镜像的元数据文件，在更新后的app 1镜像的元数据文件中，base1镜像的标识更新为base1*镜像的标识。可以理解的是，上述处理方式适用于所有依赖于lib1镜像的app镜像的元数据文件。例如，当app3镜像的镜像数据中的labelfrom字段包括lib1镜像的镜像名称和lib1镜像的版本号时，则第二设备需要更新app3镜像的元数据文件，即将app3镜像的元数据文件中base1镜像的标识更新为base1*镜像的标识。
[0210]
此外，由于没有依赖app1镜像的镜像，因此，根据app1镜像的镜像名称和版本号，无法找到匹配的镜像数据。
[0211]
通过上述过程，在base镜像更新后，第二设备可以实现对app 1镜像的元数据文件
和lib1镜像的元数据文件的更新，以使运行节点根据app1镜像的元数据文件下载的app1镜像、lib1镜像和base1*镜像创建的容器，且不需要重新构建app1镜像和lib1镜像，保证了app1镜像的可用性，且能够提升系统的开发、维护效率。
[0212]
图7示出了本技术实施例中所涉及的一种装置的可能的示例性框图，该装置700包括：收发模块710和处理模块720，收发模块710可以包括接收单元和发送单元。处理模块720用于对装置700的动作进行控制管理。收发模块710用于支持装置700与其他网络实体的通信。可选地，装置700还可以包括存储单元，所述存储单元用于存储装置700的程序代码和数据。
[0213]
可选地，所述装置700中各个模块可以是通过软件来实现。
[0214]
可选地，处理模块720可以是处理器或控制器，例如可以是通用中央处理器(central processing unit，cpu)，通用处理器，数字信号处理(digital signal processing，dsp)，专用集成电路(application specific integrated circuits，asic)，现场可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本技术实施例公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等等。收发模块710可以是通信接口、收发器或收发电路等，其中，该通信接口是统称，在具体实现中，该通信接口可以包括多个接口，存储单元可以是存储器。
[0215]
当装置700为第一设备或第一设备中的芯片时，装置700中的处理模块720可以支持装置700执行上文中各方法示例中第一设备的动作，例如，处理模块720可以支持装置700执行图5中的步骤500，步骤520，步骤540。
[0216]
收发模块710可以支持装置700与第二设备之间的通信，例如，收发模块710可以支持装置700执行图5中的步骤510，步骤530，步骤550。
[0217]
在一种实现方式中，处理模块720用于构建第一镜像；收发模块710用于向第二设备发送所述第一镜像；处理模块720用于构建第二镜像，所述第二镜像包括所述第二镜像的元数据文件，所述第二镜像的元数据文件指示所述第二镜像依赖于所述第一镜像，所述第二镜像的元数据文件包括所述第一镜像的镜像名称、所述第一镜像的版本号和所述第一镜像的标识；收发模块710用于向所述第二设备发送所述第二镜像。
[0218]
在一种可能的设计中，处理模块720用于在构建第二镜像时，根据镜像构建模板构建所述第二镜像，所述镜像构建模板包括第一标签，所述第一标签用于定义镜像之间的依赖关系。
[0219]
在一种可能的设计中，处理模块720用于根据所述第一标签获取所述第一镜像的镜像名称和所述第一镜像的版本号；将所述第一镜像的镜像名称和所述第一镜像的版本号写入所述第二镜像的元数据文件。
[0220]
在一种可能的设计中，所述第一镜像为基础base镜像，所述第二镜像为资源lib镜像；或者，所述第一镜像为lib镜像，所述第二镜像为应用app镜像。
[0221]
在一种可能的设计中，所述第一镜像为base镜像，所述第二镜像为app镜像；所述第一镜像包括所述第一镜像的元数据文件，所述第一镜像的元数据文件包括第三镜像的镜像名称、所述第三镜像的版本号和所述第三镜像的标识；所述第一镜像依赖于所述第三镜
像；处理模块720用于在向第二设备发送所述第一镜像之前，构建所述第三镜像；收发模块710用于向所述第二设备发送所述第三镜像。
[0222]
在一种可能的设计中，处理模块720用于构建第四镜像；收发模块710用于向所述第二设备发送所述第四镜像；其中，所述第四镜像为所述第一镜像的更新镜像，所述第四镜像包括所述第一镜像的名称和所述第一镜像的版本号，所述第四镜像的标识与所述第一镜像的标识不同。
[0223]
应理解，根据本技术实施例的装置700可对应于前述方法实施例中第一设备，并且装置700中的各个模块的操作和/或功能分别为了实现前述方法实施例中第一设备的方法的相应步骤，因此也可以实现前述方法实施例中的有益效果，为了简洁，这里不作赘述。
[0224]
当装置700为第二设备或第二设备中的芯片时，装置700中的处理模块720可以支持装置700执行上文中各方法示例中第二设备的动作。例如，处理模块720可以支持装置700执行图5中的步骤560。
[0225]
收发模块710可以支持装置700与第一设备之间的通信，例如，收发模块710可以支持装置700执行图5中的步骤510，步骤530，步骤550。
[0226]
在一种实现方式中，收发模块710用于接收第一镜像；接收第二镜像，所述第二镜像依赖于所述第一镜像，所述第二镜像包括所述第二镜像的元数据文件，所述第二镜像的元数据文件包括所述第一镜像的镜像名称、所述第一镜像的版本号和所述第一镜像的标识；接收第四镜像，所述第四镜像包括所述第一镜像的名称和所述第一镜像的版本号，所述第四镜像为所述第一镜像的更新镜像，所述第四镜像的标识与所述第一镜像的标识不同；处理模块720用于根据所述第二镜像的元数据文件和所述第四镜像确定更新所述第二镜像的元数据文件，更新后的所述第二镜像的元数据文件包括所述第一镜像的镜像名称、所述第一镜像的版本号和所述第四镜像的标识。
[0227]
在一种可能的设计中，处理模块720用于根据所述第二镜像的元数据文件确定所述第二镜像的镜像数据，所述第二镜像的镜像数据指示所述第二镜像依赖于所述第一镜像，所述第二镜像的镜像数据包括所述第一镜像的镜像名称和所述第一镜像的版本号；在接收到所述第四镜像之后，根据所述第一镜像的名称和所述第一镜像的版本号检索所述第二设备保存的镜像数据；确定依赖于所述第一镜像的镜像的镜像数据，所述依赖于所述第一镜像的镜像的镜像数据包括所述第二镜像的镜像数据；根据所述第二镜像的镜像数据确定所述第二镜像的元数据文件。
[0228]
在一种可能的设计中，所述第一镜像为base镜像，所述第二镜像为lib镜像；或者，所述第一镜像为base镜像，所述第二镜像为应用app镜像。
[0229]
在一种可能的设计中，所述第一镜像为lib镜像，所述第二镜像为应用app镜像；所述第一镜像包括第一镜像的元数据文件，所述第一镜像的元数据文件用于指示所述第一镜像依赖于第三镜像，所述第三镜像为base镜像，所述第一镜像的元数据文件包括第三镜像的镜像名称、所述第三镜像的版本号和所述第三镜像的标识；收发模块710用于接收所述第三镜像；处理模块720用于根据第一镜像的元数据文件确定所述第一镜像的镜像数据，所述第一镜像的镜像数据指示所述第一镜像依赖于所述第三镜像，所述第二镜像的镜像数据包括所述第三镜像的镜像名称和所述第三镜像的版本号。
[0230]
应理解，根据本技术实施例的装置700可对应于前述方法实施例中第二设备，并且
programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，还可以是系统芯片(system on chip，soc)，还可以是中央处理器(central processor unit，cpu)，还可以是网络处理器(network processor，np)，还可以是数字信号处理电路(digital signal processor，dsp)，还可以是微控制器(micro controller unit，mcu)，还可以是可编程控制器(programmable logic device，pld)或其他集成芯片。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
[0242]
可以理解，本技术实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，rom)、可编程只读存储器(programmable rom，prom)、可擦除可编程只读存储器(erasable prom，eprom)、电可擦除可编程只读存储器(electrically eprom，eeprom)或闪存。易失性存储器可以是随机存取存储器(random access memory，ram)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的ram可用，例如静态随机存取存储器(static ram，sram)、动态随机存取存储器(dynamic ram，dram)、同步动态随机存取存储器(synchronous dram，sdram)、双倍数据速率同步动态随机存取存储器(double data rate sdram，ddr sdram)、增强型同步动态随机存取存储器(enhanced sdram，esdram)、同步连接动态随机存取存储器(synchlink dram，sldram)和直接内存总线随机存取存储器(direct rambus ram，dr ram)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
[0243]
应理解，在本技术实施例中，编号“第一”、“第二
”…
仅仅为了区分不同的对象，比如为了区分不同的参数信息或者消息，并不对本技术实施例的范围构成限制，本技术实施例并不限于此。
[0244]
还应理解，在本技术的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定。上述各个过程涉及的各种数字编号或序号仅为描述方便进行的区分，而不应对本技术实施例的实施过程构成任何限定。
[0245]
还应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
[0246]
本技术中出现的类似于“项目包括如下中的一项或多项：a，b，以及c”表述的含义，如无特别说明，通常是指该项目可以为如下中任一个：a；b；c；a和b；a和c；b和c；a，b和c；a和a；a，a和a；a，a和b；a，a和c，a，b和b；a，c和c；b和b，b，b和b，b，b和c，c和c；c，c和c，以及其他a，b和c的组合。以上是以a，b和c共3个元素进行举例来说明该项目的可选用条目，当表达为“项目包括如下中至少一种：a，b，
……
，以及x”时，即表达中具有更多元素时，那么该项目可以适用的条目也可以按照前述规则获得。
[0247]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0248]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0249]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0250]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0251]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0252]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器rom、随机存取存储器ram、磁碟或者光盘等各种可以存储程序代码的介质。