CN106528224A - 一种Docker容器的内容更新方法、服务器及系统 - Google Patents

Abstract

本申请提供了一种Docker容器的内容更新方法、服务器及系统，当需要发布网络产品新版本的Docker镜像时，开发人员可以在客户端进行相应触发操作，客户端向服务器发起相应的镜像版本更新请求，服务器将会据此确定Docker容器需要更新后的目标Docker镜像，并获取该目标Docker镜像与源Docker镜像的差异镜像层，并从镜像仓库调取差异镜像层对应的差异镜像层数据，之后，本申请将根据该差异镜像层数据，直接将Docker容器对应的源Dcoker镜像更新为目标Docker镜像，不需要重启Docker容器，也就不会使该Docker容器里的内存数据丢失，且不会影响业务正常对外服务，从而实现了Docker容器的在线更新。

Description

一种Docker容器的内容更新方法、服务器及系统

技术领域

本申请主要涉及通信领域，更具体地说是涉及一种Docker容器的内容更新方法、服务器及系统。

背景技术

Docker是一个开源的应用容器引擎，旨在提供一种应用的自动化部署解决方案，能够让开发者打包他们的应用及依赖包到一个可移植的容器中，容器即为轻量级虚拟机，然后发布到任何流行的Linux机器上，实现应用的自动化安装、部署和升级，非常方便。而且，Docker能够虚拟出多个容器，每个容器之间相互隔离没有接口，可以将彼此的生产环境和开发环境分开，互不影响。

目前云服务的基石是操作系统级别的隔离，在同一台宿主机上通过一个或多个虚拟机(VitualMachine，简称VM)运行业务，而Docker实现了一种应用级别的隔离，它改变了基本的开发、操作单元，由直接操作VM转换为操作应用运行的“容器”。

随着Docker容器技术的发展，容器镜像(Docker image)将取代原来的程序二进制成为一种新的软件交付介质，当一款网络产品的新版本上线时，现有技术通常是把原来的Docker容器全部停止\销毁，并基于构建的新的容器镜像，重新创建一个全新的Docker容器，从而利用新的Docker容器实现新版本网络产品的发布。

由此可见，现有的这种实现新版本网络产品发布的处理方案，需要停机一段时间；而且，由于重启Docker容器后，其内存数据会被清除，对于如MSN、网络游戏等这种采用状态化服务器的应用场景的网络产品版本更新，现有的这种处理方案将无法保留Docker容器原有内存状态数据，以及业务的正常对外服务，将会无法在这种应用场景中实现新版本网络产品的发布。

发明内容

有鉴于此，本发明提供了一种Docker容器的内容更新方法、服务器及系统，实现了Docker容器的在线更新，避免了重启Docker容器，导致其保留内存数据丢失以及业务的正常对外服务。

为了实现上述目的，本申请提供了以下技术方案：

本申请实施例还提供一种Docker容器的内容更新方法，包括：

接收客户端发起的镜像版本更新请求，所述镜像版本更新请求用于更新所述Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

确定所述Docker容器需要更新后的目标Docker镜像；

获取所述目标Docker镜像与所述源Docker镜像的差异镜像层；

调取所述差异镜像层对应差异镜像层数据；

根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像。

本申请实施例还提供了一种服务器，包括：第一数据传输模块、镜像仓库、Docker容器以及数据处理模块，其中：

第一所述数据传输模块，用于接收客户端发送的镜像版本更新请求，所述镜像版本更新请求是用于更新所述Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

所述镜像仓库，用于存储所述目标Docker镜像以及所述Docker容器当前对应的所述源Docker镜像的镜像层文件以及所述镜像层文件中各镜像层对应的镜像层数据；

所述数据处理模块，用于确定所述Docker容器需要更新后的目标Docker镜像，获取所述目标Docker镜像与所述源Docker镜像的差异镜像层，并从所述镜像仓库调取所述差异镜像层对应差异镜像层数据，根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像。

本申请实施例还提供一种Docker容器的内容更新系统，包括：客户端以及服务器，其中：

所述客户端，用于向服务器发起镜像版本更新请求，所述镜像版本更新请求用于更新所述Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

所述服务器，用于接收到所述镜像版本更新请求后，确定所述Docker容器需要更新后的目标Docker镜像，获取所述目标Docker镜像与所述源Docker镜像的差异镜像层，调取所述差异镜像层对应差异镜像层数据，并根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像。

由此可见，与现有技术相比，本申请提供了一种Docker容器的内容更新方法、服务器及系统，当需要发布网络产品新版本的Docker镜像时，开发人员可以在客户端进行相应触发操作，使客户端向服务器发起相应的镜像版本更新请求，用于更新正在运行的Docker容器对应的源Docker镜像，此时，服务器将会据此确定Docker容器需要更新后的目标Docker镜像，并获取该目标Docker镜像与源Docker镜像的差异镜像层，并从镜像仓库调取差异镜像层对应的差异镜像层数据，之后，本申请将根据该差异镜像层数据，直接将Docker容器对应的源Dcoker镜像更新为目标Docker镜像，不需要重启Docker容器，也就不会使该Docker容器里的内存数据丢失，且不会影响业务正常对外服务，从而实现了Docker容器的在线更新。

附图说明

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

图1为本申请实施例提供的一种Docker容器的内容更新系统的结构图；

图2为本申请实施例提供的一种Docker容器的内容更新方法方法的流程图；

图3为本申请实施例提供的另一种Docker容器的内容更新方法的流程图；

图4(a)为源Docker镜像的镜像层文件示意图；

图4(b)为目标Docker镜像的镜像层文件示意图；

图5为本申请实施例提供的另一种测试方法的部分流程图；

图6为本申请实施例提供的一种Docker容器的内容更新服务器的结构框图；

图7为本申请实施例提供的另一种Docker容器的内容更新服务器的部分结构框图；

图8为本申请实施例提供的又另一种Docker容器的内容更新服务器的部分结构框图；

图9为本申请实施例提供的一种Docker容器的内容更新服务器的结构示意图；

图10为本申请实施例提供的Docker容器的内容更新方法的时序图；

图11为本申请实施例提供的一种Docker容器的内容更新服务器的硬件结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。其中，为了方便理解本申请技术方案，将对下文实施例可能涉及到的技术术语进行解释说明，具体如下：

Docker容器，允许单个进程以比普通Unix进程更高水平的隔离性运行。例如提供游戏程序运行的虚拟OS，具有轻量级，性能损耗小，能更高效利用服务器资源等特点

Docker镜像(Docker image)：image是docker相关属性的一种，代表一个只读的layer集合，本质上是docker容器的一个快照。

Image Layer(镜像层)：Docker image(Docker镜像)的rootfs是容器只读的文件系统，而rootfs又是多个只读的image构成，而每一个只读的image 都可以成为一层layer。

Docker Registry(镜像仓库)：是一个无状态的、高度可扩展的，且用于存储\分发Docker image的服务端程序。

Docker Merge：(以下简称merge)把两个Docker image之间的差异内容更新到Docker容器里，即用于实现Docker image的热发布的接口实现。

Docker Config：提供Docker容器在线修改配置接口，用于修改Docker image发布后配置信息的修改，保证配置一致性。

图1为本申请实施例提供的Docker容器的内容更新系统的结构框图，该图所示的Docker容器的内容更新系统可以用于实现本申请实施例提供的Docker容器的内容更新方法。参照图1，该系统可以包括：服务器100以及多个客户端200；

其中，服务器为网络侧为用户提供服务的服务设备，其可能是多台服务器组成的服务器集群，也可能是单台服务器。

在本实施例中，上述服务器100可以是本地服务器也可以是云服务器，其实现Docker容器的内容更新方法的过程可以参见下文相应实施例的描述。

客户端是与服务器相对应的，为用户提供本地服务的程序，在实际应用中，客户端一般可以装载在手机、平板电脑、笔记本电脑等用户设备上。

基于图1所示的Docker容器的内容更新系统，下面从服务器的角度对本申请提供的Docker容器的内容更新方法进行介绍。如图2所示，为本申请实施例提供的一种Docker容器的内容更新方法的流程图，该方法可以包括以下步骤：

步骤S11，接收客户端发起的镜像版本更新请求；

其中，镜像版本更新请求可以用于更Docker容器对应的源Docker镜像，如客户端所在本地服务器正在运行的Docker容器对应的源Docker镜像，但并不局限于此。

在实际应用中，针对状态化的服务，如MSN、在线游戏等网络产品的新版本的在线发布场景，开发人员确定需要发布的Docker镜像(即为本文的目标Docker镜像)后，可以利用客户端直接下发相应的触发指令，用于在不影 响当前运行的Docker容器的正常使用的情况下，将该Docker容器对应的源Docker镜像更新为目标Docker镜像，即实现Docker容器在线更新。

可选的，当客户端输入针对当前运行的需要更新的Docker容器的触发指令，可以调用服务器的Docker的Docker API(Application Programming Interface,应用程序编程接口)，采用POST方式发起HTTP请求，即镜像版本更新请求。

在本实施例中，服务器接收到客户端发起的镜像版本更新请求后，可以创建相应的Docker jobs，即满足该镜像版本更新请求的具体任务逻辑实现模块，根据需要与镜像仓库和Docker容器进行交互，以实现Docker容器的在线更新，具体过程参见下文相应部分的描述。

基于上述分析，本申请上述镜像版本更新请求可以用来表明将当前运行的需要更新的Docker容器对应的源Docker镜像更新为目标Docker镜像。可选的，在实际应用中，根据需要该镜像版本更新请求可以携带需要在线更新的Docker容器(即上述当前运行的Docker容器)的容器标识(如容器ID等)，必要时，还可以包括该Docker容器对应的源Docker镜像的镜像标识(如源Docker镜像的镜像ID、名称、标签等)和/或目标Docker镜像的镜像标识(如目标Docker镜像的镜像ID、名称、标签等)等。

当然，上述源Docker镜像的镜像标识也可以通过Docker容器的容器标识确定，本申请对镜像版本更新请求携带的具体信息内容不作限定。

步骤S12，确定Docker容器需要更新后的目标Docker镜像；

在实际应用中，开发人员研究应用在虚拟机上的部署后，通常会依据Docker镜像要求，构建该应用对应的Docker镜像，在完成对构建的Docker镜像的部署和配置，并测试成功后，将该Docker镜像存储至Docker的镜像仓库(Docker Registry)，以便今后从中调取应用的Docker镜像并运行，从而实现应用的运行。

所以，本实施例可以采用这种方式构建目标Docker镜像，并将其相关信息存储至镜像仓库，以便在需要从该镜像仓库直接调取相应的镜像层文件或具体镜像层数据等，来满足实际需要。

由此可见，在本实施例中，当需要对某Docker容器对应的源Docker镜像更新时，通常会先构建更新所用的目标Docker镜像，并将其相关信息存储到 镜像仓库。当服务器接收到客户端发起的用于更新该Docker容器对应的源Docker镜像的镜像版本更新请求后，将据此确定用来更新该Dcoker容器的目标Dcoker镜像。

具体的，可以确定该目标Docker镜像的镜像标识，用来识别该目标Docker镜像的相关信息，如上文描述，该镜像标识可以包括目标Docker镜像的镜像ID、镜像名称、镜像标签等，本申请对确定的该目标Docker镜像的镜像标识指代的具体内容不作限定。

步骤S13，获取目标Docker镜像与源Docker镜像的差异镜像层；

Docker镜像是一种层叠结构关系，是一个只读的存储状态，包含有多层镜像层(Layer)，通常将第1层的镜像层称为基础镜像，其他层的镜像层称为父层镜像，每一个镜像层都是相对于其父镜像层的一个增量内容，如增加、删除、修改场景等内容，可见，这些镜像继承了他们的父层镜像的所有属性和设置，并在Dockerfile中添加自己的配置。在实际应用中，每一个镜像层都有对应的层ID，用来识别不同的镜像层。

其中，上述增量内容中的删除可以指记录被删除文件(或目录)的名称和地址；增加可以指记录被增加文件(或目录)的属性信息(如名称、格式、大小等)以及内容数据；修改可以指逻辑处理与增加数据一致。

可选的，上述增量内容可以以tar包形式存在，当需要在线热发布目标Docker镜像时，可以基于这些tar包的数据信息进行分析处理。具体的，对于删除场景，可以根据记录的文件(或目录)信息在需要更新的Docker容器上执行相应的删除操作；对于增加、修改场景，则可以分别在Docker容器里执行增加和覆盖操作，通过这些操作，可以保证Docker容器数据得到正确的更新。

另外，在所有镜像层之后有一个可写层，其包括运行在CPU上的进程，而且通常可以包括运行态和退出态这两种不同的状态，即为上述Docker容器。

基于此，当需要发布新版本的Docker镜像时，即将源Docker镜像更新为目标Docker镜像，可以对两者对应的镜像层文件进行差异化计算，从而确定两者差异镜像层及其对应的差异镜像层数据。

镜像层文件步骤S14，调取差异镜像层对应的差异镜像层数据；

如上述描述，在实际应用中，由于构建的Docker镜像的相关信息会存储到镜像仓库，所以，在确定目标Docker镜像与源Docker镜像的差异镜像层后，可以利用该差异镜像层的层ID等标识，从镜像仓库调取每一个差异镜像层对应的差异镜像层数据。

可选的，本实施例可以触发GetRemoteImageLayer函数读取镜像仓库中各差异镜像层对应的差异镜像层数据，但并不局限于此。

步骤S15，根据差异镜像层数据，将Docker容器对应的源Docker镜像更新为目标Docker镜像。

对于状态化服务，如在线游戏等在线服务，后端的功能模块基本都是有状态的，即后台都是有状态的服务，所以每次发布新版本的Docker镜像，更新正在运行的Docker容器是不能重启，即需要保留该Docker容器里的内存数据，以及业务的正常对外服务。可见，现有的销毁重建Docker容器的版本更新方案并不适用于上述状态化服务场景，无法实现该场景下的Docker镜像的在线热发布功能。

针对上述问题，本申请通过上述方式得到目标Docker镜像与源Docker镜像的差异镜像层数据后，可以直接将该差异镜像层数据合并当前运行的需要更新的Docker容器的源Docker镜像中，即前文描述的Docker Merge过程。

具体的，本申请可以调用底层ApplyLayer函数将获得的差异镜像层数据写入Docker容器，实现Docker容器中源Docker镜像的在线更新，不需要重启该Docker容器，也就不会使该Docker容器里的内存数据丢失，且由于本申请是对Docker容器中的镜像信息进行更新，不会影响业务正常对外服务，从而实现了Docker容器的在线更新。

需要说明的是，本实施例同样也适用于无状态的服务，在这种应用场景下，由于本方案不需要销毁并重建Docker容器，不存在重启该Docker容器的问题，解决了现有技术存在的停机时间长，维护成本太高的技术问题，

如图2所示，为本申请实施例提供的另一种Docker容器的内容更新方法的流程图，该方法可以包括以下步骤：

步骤S21，接收客户端发起的镜像版本更新请求；

在本实施例中，该镜像版本更新请求是可以用于更新所述Docker容器对应的源Docker镜像，其中，一个Docker镜像通常可以包括多个镜像层，且每一个镜像层对应一个镜像层数据，需要说明的是，该镜像层对应的镜像层数据都是只读文件。

可选的，在实际应用中，该镜像版本更新请求可以是POST请求，具体可以通过调用用于进行Docker Merge的Docker API发起POST请求，而且，根据需要，POST请求可以携带需要更新的Docker容器的容器标识，本申请对镜像版本更新请求携带的内容不作限定。

步骤S22，确定Docker容器需要更新后的目标Docker镜像；

可选的，本实施例可以基于接收到的镜像版本更新请求，确定需要更新的Docker容器更新后的目标Docker镜像的镜像名称，当然，也可以是目标Docker镜像的镜像ID等。

步骤S23，解析该镜像版本更新请求，确定需要更新源Docker镜像的Docker容器的容器标识；

可选的，该容器标识可以是容器ID，用来识别不同的Docker容器，但容器标识指代的内容并不局限于此。

步骤S24，通过该容器标识，获得需要更新的源Docker镜像的镜像标识；

在本实施例中，源Docker镜像是创建该Docker容器时利用的Docker镜像。且源Docker镜像的镜像标识可以是镜像ID、镜像名称或镜像标签等，可以根据实际需要确定该镜像标识指代的具体内容。

步骤S25，利用源Docker镜像的镜像标识，调取源Docker镜像的镜像层文件，并利用目标Docker镜像的镜像标识，调取目标Docker镜像的镜像层文件；

在实际应用中，由于构建Docker镜像后，通常会将其相应的配置信息以及部署文件等数据存储到镜像仓库，所以，本申请在确定源Docker镜像的镜像标识以及目标Docker镜像的镜像标识后，可以向该镜像仓库发送包含这些镜像标识的指令，以获取该镜像仓库中存储的与各镜像标识对应的镜像层文件。

其中，镜像层文件可以包括各镜像层的镜像ID、镜像名称、镜像标签、各镜像层的层ID等等，本申请对其包含的具体内容不作限定。

可选的，上述镜像层文件可以是Docker镜像对应的所有镜像层列表，其可以采用数组形式从镜像仓库获得，每个项可以是一个镜像层的层ID，则该镜像层文件可以如下，但并不局限于此。

[

“094fb0f442bf879dfc17f97159a924a103a2313c6437d4a3f916fde61160afac”,

“c84732e5d092317b177ec3cfcbfc49ea638edb0edb0ebc4840ec8b1d330ffb46”,

......

]

步骤S26，对源Docker镜像的镜像层文件和目标Docker镜像的镜像层文件进行递归计算，得到目标Docker镜像与源Docker镜像的差异镜像层；

由于Docker镜像通常包括多个镜像层，每一个镜像层都有对应的层ID，本申请可以利用递归算法将目标Docker镜像的镜像层文件的每一镜像层的层ID与源Docker镜像的镜像层文件的每一镜像层的层ID进行逐层对比，从而确定目标Docker镜像与源Docker镜像的差异层ID，即确定目标Docker镜像与源Docker镜像的差异镜像层。

举例说明，如图4(a)所示的源Docker镜像的镜像层文件以及图4(b)所示的目标Docker镜像的镜像层文件，通过两者各镜像层的层ID的对比可知，目标Docker镜像与源Docker镜像的差异镜像层是ID为6k3h40296821的第四层镜像层。

需要说明的是，本申请对获得目标Docker镜像与源Docker镜像的差异镜像层的方法并不局限于上文列举的方式。

继上述描述，当镜像层文件可以是Docker镜像对应的所有镜像层列表，具体为数组时，可以将目标Docker镜像对应的数组(记为目标数组)与源Docker镜像对应的数组(记为源数组)进行对比，从而确定目标数组中在源数组中不存在的层ID，即为目标Docker镜像与源Docker镜像的差异镜像层。

步骤S27，调取差异镜像层对应的差异镜像层数据；

如上述实施例对应部分的描述，Docker镜像的部署以及配置等数据都存存储在镜像仓库中，所以，本实施例在确定目标Docker镜像与源Docker镜像的差异镜像层，即差异层ID后，可以根据该差异层ID从镜像仓库调取相对应的层数据即为目标Docker镜像与源Docker镜像的差异镜像层数据。

可选的，本实施例可以利用GetRemoteImageLayer函数读取镜像仓库中与差异层ID对应的层数据，但并不局限于此。

步骤S28，根据差异镜像层数据，将Docker容器对应的源Docker镜像更新为目标Docker镜像。

其中，关于利用差异镜像层数据更新Docker容器内容的过程可以参照上述实施例对应部分的描述，本实施在此不再赘述。

可选的，在实际应用中，本申请可以将Docker容器的层数据更新结果反逐级反馈至客户端，具体可以是服务器内各程序模块每执行完一操作，都可以将执行该操作的结果反馈至上一级的程序模块，依次反馈，直至反馈至客户端，本申请对该具体实现过程不作限定。

综上所述，开发人员指定要发布的目标Docker镜像后，本实施例将计算目标Docker镜像与源Docker镜像的差异镜像层，并从镜像仓库直接调取对应的差异镜像层数据后，直接将差异镜像层数据合并到当前运行的Docker容器，来更新该Docker容器对应的源Docker镜像，不需要销毁当前运行的Docker容器后重现Docker容器，避免了重启Docker容器而导致Docker容器里的内存数据丢失，且不会影响业务正常对外服务，从而实现了Docker容器的在线更新。

如图5所示，为本申请实施例提供的另一种Docker容器的内容更新方法的流程图，本实施例仅对获取差异镜像层后续步骤进行详细说明，而对于获取差异镜像层的过程可以参照上述实施例相应部分的描述，本实施例对此不作详述，在本实施例可以包括：

步骤S41，按照预设规则从多个差异镜像层选定一个差异镜像层作为待处理差异镜像层；

在实际应用中，可以从镜像层文件的各镜像层的一侧依次选择一个差异镜像层作为待处理差异镜像层，也可以任意选择一个差异镜像层作为待处理差异镜像层，本申请对选择待处理差异镜像层的预设规则的具体内容不作限定。

步骤S42，调取该待处理差异镜像层对应的差异镜像层数据，并利用调取的差异镜像层数据更新Docker容器对应的源Docker镜像；

本实施例可以根据差异镜像层的层ID通过HTTP协议去镜像仓库请求相应的层数据，本申请对镜像仓库如何基于层ID获得对应层数据的处理过程不作限定。

结合上述描述，在本实施例中，对于确定的多个差异镜像层，将一个一个从镜像仓库调取相应的差异镜像层数据，且每调取一个差异镜像层对应的差异镜像层数据，可以将其合并到当前运行的Docker容器的源Docker镜像后，再调取下一个差异镜像层对应的差异镜像层数据，依次类推，从而完成获得的目标Docker镜像与源Docker镜像的所有差异镜像层对应的差异镜像层数据的调取。

可选的，本申请获得的多个差异镜像层可以是多个层ID组成的数组，当需要调取相应的差异镜像层数据时，可以采用上述方式遍历该数组，一个一个去调取每个层ID对应的镜像层数据。

步骤S43，判断是否存在未调取相应差异镜像层数据的差异镜像层，若存在，返回步骤S41；若不存在，进入步骤S44；

其中，若步骤S43的判断结果为存在未调取相应差异镜像层数据的差异镜像层，将从剩余的未调取相应差异镜像层数据的差异镜像层中，返回上述步骤S41重新选择新的待处理差异镜像层，直至调取完获得的所有差异镜像层对应的差异镜像层数据。

步骤S44，接收客户端发送的针对Docker容器的镜像描述更新请求；

由于Docker容器的镜像描述(配置)信息与该Docker容器的内容无关，主要用于管理端调度或者客户端的展示，以及配置一致性的保证，所以，在更新Docker容器的镜像层数据后，需要对镜像描述信息进行对应更新，从而保证在后续的操作(如重启、迁移等)中得到正确的调取，并能够准确表达Docker镜像更新后的版本信息。

由此可见，上述镜像描述更新请求可以用于表示在完成对当前运行的Docker容器对应的源Docker镜像的层数据更新后，对该Docker容器中的镜像描述信息进行更新，以便与更新后的镜像信息相匹配。可选的，在本实施例中，可以通过调取Docker的用于执行Docker Config的Docker API发起镜像描述更新请求，且该镜像描述更新请求也可以是POST请求，但并不局限于此。

步骤S45，确定Docker容器更新后的镜像信息；

结合上文描述，在本实施例实际应用中，可以通过创建的Docker jobs与镜像仓库和Docker容器进行交互，从而实现Docker容器的在线更新，所以，完成Docker容器中源Docker镜像的更新时，Docker jobs必然是得知更新后的镜像信息，即用于更新源Docker镜像的镜像信息，那么，当服务器接收到客户端发起的镜像描述更新请求后，Docker jobs可以直接确定Docker容器更新后的镜像信息，不需要与Docker容器和镜像仓库进行交互。

由此可见，上述步骤S44可以在完成Docker容器在线更新后执行，也可以在Dockerjobs得知用来更新Docker容器的镜像信息，即差异镜像层及其对应差异镜像层数据等信息后执行，本实施例仅以前一种方式为例进行说明，后一种方式实现过程类似，本申请不再详述。

步骤S46，根据更新后的镜像信息更新Docker容器的镜像描述信息。

可选的，需要更新Docker容器的镜像描述信息可以包括镜像名称、镜像层ID等用于识别更新的镜像信息的标识，当然，根据需要其还可以包括其他内容，本申请在此不再一一列举。

另外，在实际应用中，完成对Docker容器的镜像描述的更新后，可以将更新结果逐级反馈至客户端。客户端还可以显示该更新结果，以便开发人员能够直观得知是否完成本次对Docker容器的在线热发布。

可选的，对于本申请提出的Docker容器的内容更新方案可以在云服务器完成，也可以在本地服务器完成，其中，关于在云服务器完成该内容更新方案的实现过程可以参照上述各实施例的描述过程，在此仅对本地服务器完成该内容更新方案的实现过程进行描述，关于该实现过程与上述实施例类似步骤的实现过程，可以参照上述实施例相应部分的描述，本实施在此不再赘述。

具体的，作为本申请又一实施例，由于本地服务器上存在运行的Docker容器及其对应的源Docker镜像的相关信息，在开发人员确定目标Docker镜像后，客户端可以向本地服务器发起镜像版本更新请求，用来请求更新当前正在运行的Docker容器对应的源Docker镜像，从而使本地服务器确定该Docker容器需要更新后的目标Docker镜像，并利用该目标Docker镜像的镜像标识，调取该目标Docker镜像的镜像层文件，如由各镜像层的层ID构成的数组， 之后，由于本地服务器存储有源Docker镜像的相关信息，所以，本实施例可以依次验证目标Docker镜像的镜像层文件中的每一个镜像层在本地服务器是否存在，也就是说，源Docker镜像是否存在当前验证的目标Docker镜像的镜像层。

若当前验证的目标Docker镜像的镜像层在本地服务器不存在，从云服务器调取当前验证的目标Docker镜像的镜像层对应的镜像层数据，并利用调取的镜像层数据，更新Docker容器对应的源Docker镜像，直至验证完目标Docker镜像的镜像层文件中的所有镜像层。

由此可见，在对目标Docker镜像的镜像层文件验证过程中，可以选择一个镜像层的层ID，验证其在本地服务器是否存在，若存在，重新选择一个镜像层的层ID继续验证；若不存在，说明其为差异镜像层，可以从云服务器的镜像仓库调取相应的镜像层数据，并将调取的镜像层数据更新到当前运行的Docker容器后，继续选择一个新的镜像层的层ID验证，依次循环，直至验证完目标Docker镜像的镜像层文件。

基于上述分析可知，在本地服务器也能够实现Docker容器的在线热发布，从而解决现有技术中因在本地重建Docker容器，而导致源Docker容器里的内存数据丢失，影响业务正常对外服务的技术问题，如在线游戏的游戏镜像发布应用中，本申请采用的方案完全不需要停机，让在线游戏版本发布更加标准化和高效。

如图6所示，为本申请实施例提供的一种服务器的结构框图，该服务器可以包括：第一数据传输模块51、镜像仓库52、Docker容器53以及数据处理模块54，其中：

第一数据传输模块51，用于接收客户端发送的镜像版本更新请求，该镜像版本更新请求用于更新Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

在本实施例中，客户端可以通过调用Docker的Docker API发起镜像版本更新请求，可选的，该镜像版本更新请求可以是采用POST方式发起HTTP请求，也可以称为POST请求。

镜像仓库52，用于存储目标Docker镜像以及Docker容器当前对应的源Docker镜像的镜像层文件以及该镜像层文件中各镜像层对应的镜像层数据；

如上述方法实施例对应部分的描述，镜像层文件可以是Docker镜像对应的所有镜像层列表，具体可以是数组形式存在该镜像仓库中，且该数组中的每一个数据可以是一个镜像层的层ID，且在该镜像仓库中存储有对应每个层ID的层数据。

在实际应用中，镜像仓库中上述数据可以是创建Docker镜像时生成并存储的，本申请对创建Docker镜像的过程及其生成的数据内容不作限定，且对于镜像仓库存储的数据并不局限于本申请上述列举的几项。

数据处理模块54，用于确定Docker容器需要更新后的目标Docker镜像，获取目标Docker镜像与源Docker镜像的差异镜像层，并从镜像仓库调取差异镜像层对应差异镜像层数据，根据差异镜像层数据，将Docker容器对应的源Docker镜像更新为目标Docker镜像。

可选的，在实际应用中，服务器中的Docker接收到客户端发起的镜像版本更新请求后，可以创建相应的Docker jobs，即满足该镜像版本更新请求的具体任务逻辑实现模块，将其作为数据处理模块，来基于接收到的镜像版本更新请求，获得目标Docker镜像与源Docker镜像的差异镜像层数据，并将该差异镜像层数据更新到当前运行的Docker容器中。

在实际应用中，目标/源Docker镜像的镜像层文件是由多个层ID组成的数组，第一计算单元可以从镜像仓库52获取目标Docker镜像和源Docker镜像的镜像层文件，通过数组的对比，确定目标Docker镜像具有的在源Docker镜像的镜像层文件中不存在的层ID，即为目标Docker镜像与源Docker镜像的差异镜像层。

作为本申请另一实施例，如图7所示，数据处理模块54可以包括：

解析单元541，用于解析镜像版本更新请求，确定需要更新源Docker镜像的Docker容器的容器标识；

镜像标识确定单元542，用于通过所述容器标识，获得需要更新的源Docker镜像的镜像标识；

以容器标识为容器ID，镜像标识为镜像名称为例，在实际应用中，由于镜像版本更新请求能够表明将所述Docker容器对应的源Docker镜像更新为目标Docker镜像，所以，解析镜像版本更新请求能够得知需要更新的Docker容器的容器ID(用于识别该需要更新的Docker容器)。

由于Docker容器是利用Docker镜像创建的，所以，本申请通过需要更新的Docker容器的容器ID，能够得知该Docker容器的镜像名称，从而确定创建该Docker容器的源Docker镜像。

第一数据调取单元543，用于利用源Docker镜像的镜像标识，从所述镜像仓库调取源Docker镜像的镜像层文件，并利用目标Docker镜像的镜像标识，从镜像仓库调取目标Docker镜像的镜像层文件；

在实际应用中，镜像ID、镜像名称等镜像标识都能够用来识别对应的Docker镜像，而对于创建的每一个Docker镜像，镜像仓库中通常存储有相应的镜像层文件、层数据等相关信息，以便发布该Docker镜像时调取。所以，第二数据调取单元可以向镜像仓库发送包含有确定的目标/源Docker镜像的镜像标识的请求，以使镜像仓库利用各镜像标识获得相应的镜像层文件，并将该镜像层文件发送至第二数据调取单元，以完成后续操作。

第一计算单元544，对源Docker镜像的镜像层文件和目标Docker镜像的镜像层文件进行递归计算，得到目标Docker镜像与源Docker镜像的差异镜像层。

可选的，对于得到的目标Docker镜像与源Docker镜像的差异镜像层，可以通过存储模块进行记录保存。

在本实施例中，利用差异镜像层调取与各差异镜像层对应的差异镜像层数据时，尤其是在差异镜像层时多个镜像层时，可以完成一个差异镜像层对应的差异镜像层数据的调取后，再对下一个差异镜像层对应的差异镜像层数据进行调取。而且，每调取一个差异镜像层数据直接更新到当前处于运行状态的Docker容器。

基于此，如图6所示，数据处理模块54还可以包括：

选定单元545，用于按照预设规则从多个差异镜像层选定一个差异镜像层作为待处理差异镜像层；

第二数据调取单元546，用于调取待处理差异镜像层对应的差异镜像层数据，并利用调取的差异镜像层数据更新所述Docker容器对应的源Docker镜像；

判断单元547，用于判断是否存在未调取相应差异镜像层数据的差异镜像层，若存在，触发选定单元从未调取相应差异镜像层数据的差异镜像层中，重新选择一个差异化层数据作为新的待处理差异化数据，并由所述第二数据调取单元546继续调取新的待处理差异镜像层对应的差异镜像层数据，并利用新调取的差异镜像层数据更新当前运行的需要更新的Docker容器对应的源Docker镜像，直至将所有差异镜像层对应的差异镜像层数据都更新到该Docker容器中。

可选的，在实际应用中，Docker容器可以将是否完成差异镜像层数据更新的结果，即服务器针对镜像版本更新请求的响应结果反馈至客户端。具体的，Docker容器可以将其是否更新差异镜像层数据的结果反馈至数据处理模块，如创建的Docker jobs，再由该Docker jobs将其是否执行镜像版本更新请求的结果反馈至第一数据传输模块，具体可以是Docker API，之后，由该Docker API将其是否接收到镜像版本更新请求的结果反馈至客户端。

其中，需要说明的是，对于服务器各部分之间结果反馈，可以不按照上述顺序依次反馈，可以在本模块完成其发送端的模块发送的请求或信息直接反馈完成结果，以便在该结果为失败是，发送端的模块能够重新发送或调用或写入数据信息，以完成Docker镜像的版本更新任务。

作为本申请又一实施例，在上述各实施例的基础上，如图8所示，服务器还可以包括：

第二数据传输模块55，用于接收客户端发送的针对所述Docker容器的镜像描述更新请求；

数据处理模块54还可以用于确定所述Docker容器更新后的镜像信息，并根据更新后的镜像信息更新Docker容器的镜像描述信息。

由此可见，在更新Docker容器的镜像层数据后，需要对镜像描述信息进行对应更新，从而保证在后续的操作(如重启、迁移等)中得到正确的调取，并能够准确表达Docker镜像更新后的版本信息。需要说明是，该Docker容器 的镜像配置信息的更新过程与Docker容器的内容无关，不需要Docker容器参与。

可选的，当数据处理模块54可以基于接收到的镜像描述更新请求，重新创建配置任务，对镜像描述信息的对应更新，之后，可以将该配置任务的执行结果即对镜像描述信息的更新结果反馈至数据传输模块，进而反馈至客户端，从而使开发人员能够及时得知对Docker容器的在线更新的进展。

综上，开发人员指定要发布的目标Docker镜像后，本实施例将计算目标Docker镜像与源Docker镜像的差异镜像层，并从镜像仓库直接调取对应的差异镜像层数据后，将直接把该差异镜像层数据更新到当前运行的Docker容器中，不需要销毁当前运行的Docker容器后重现Docker容器，避免了重启Docker容器，而导致Docker容器里的内存数据丢失，且不会影响业务正常对外服务，从而实现了Docker容器的在线更新。

为了更清楚理解本申请提供的Docker容器的内容更新方案，本申请将基于上述描述的服务器的系统结构，采用如图10所示的时序图，来简单描述该方案的实现过程。需要说明的是图10所示的方案是本申请提供的Docker容器的内容更新方法的一种优选方案，但并不局限于此。

如图9所示，该方法可以包括：

步骤S91，客户端向Docker的Docker API发送POST更新请求，该POST更新请求用于更新Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

结合上述分析可知，该POST更新请求即为本申请上文描述的镜像版本更新请求。而Docker API可以是上述数据传输模块。

步骤S92，Docker创建相应的镜像更新任务，得到Docker jobs；

其中，Docker jobs可以是本申请上述数据处理模块。

步骤S93，Docker jobs向镜像仓库发送镜像层文件获取指令；

步骤S94，镜像仓库基于该镜像层文件获取指令，将源Docker镜像和目标Docker镜像的所有镜像层的层ID反馈至Docker jobs；

步骤S95，Docker jobs对源Docker镜像的所有层ID和目标Docker镜像的所有层ID进行差异化计算，得到差异层ID；

步骤S96，Docker jobs向镜像仓库发送层数据获取指令；

步骤S97，镜像仓库基于层数据获取指令，将各差异层ID对应的差异镜像层数据发送至Docker jobs；

步骤S98，Docker jobs利用差异镜像层数据更新Docker容器对应的源Docker镜像；

步骤S99，客户端向Docker的Docker API发送POST配置请求；

其中，该POST配置请求可以是上文镜像配置内容更新请求。

步骤S910，Docker创建相应的镜像配置任务，并将该镜像配置任务发送至Dockerjobs；

其中，所述镜像配置任务中可以包含源Dcoker镜像更新后的镜像信息。

步骤S911，Docker jobs根据更新后的镜像信息更新Docker容器的镜像描述信息。

可选的，对于服务器上述各模块完成相应工作后，可以向其发送端的模块反馈完成结果，对此，图9并没有一一示出，但这仍属于本申请保护范围。

上文描述的是服务器的软件功能模块构架，对于该服务器的硬件结构，可以参照图11所示：

图11为本申请实施例提供的一种服务器的硬件结构框图，如图11所示，该服务器可以包括：处理器101、存储器102、通信接口103以及通信总线104；

其中，处理器101、存储器102以及通信接口103通过通信总线104完成相互间的通信。

可选的，该通信接口103可以是USB接口或者其他串口等等。

处理器101，用于执行程序；

存储器102，用于存放程序以及获得的各种数据等；

在本实施例中，该处理器101可以是中央处理器CPU，或者是特定集成电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。

存储器102可以包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器等。

其中，上述程序可具体用于：

接收客户端发起的镜像版本更新请求，所述镜像版本更新请求用于更新所述Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

确定所述Docker容器需要更新后的目标Docker镜像；

获取所述目标Docker镜像与所述源Docker镜像的差异镜像层；

调取所述差异镜像层对应差异镜像层数据；

根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像。需要说明的是，Docker容器的内容更新方法的实现过程，即新版本的Docker镜像的在线热发布的实现过程可以参照方法实施例对应部分的描述，本实施例在此不再一一详述。

可选的，可以采用以下方式获得所述目标Docker镜像与所述源Docker镜像的差异镜像层数据，但并不局限于此，则该程序具体可以用于：

利用所述源Docker镜像的镜像标识，调取所述源Docker镜像的镜像层文件，并利用所述目标Docker镜像的镜像标识，调取所述目标Docker镜像的镜像层文件；

对所述源Docker镜像的镜像层文件和所述目标Docker镜像的镜像层文件进行递归计算，得到所述目标Docker镜像与所述源Docker镜像的差异镜像层；

利用所述差异镜像层，调取与各差异镜像层对应的差异镜像层数据。

可选的，当调取差异镜像层数据时，具体可以采用以下方式实现，则该程序具体可以用于：

按照预设规则从多个差异镜像层选定一个差异镜像层作为待处理差异镜像层；

调取所述待处理差异镜像层对应的差异镜像层数据，并利用调取的差异镜像层数据更新所述Docker容器对应的源Docker镜像；

判断是否存在未调取相应差异镜像层数据的差异镜像层；

若存在，从所述未调取相应差异镜像层数据的差异镜像层中，重新选择一个差异镜像层作为新的待处理差异镜像层，继续调取所述新的待处理差异镜像层对应的差异镜像层数据，并利用新调取的差异镜像层数据更新所述Docker容器对应的源Docker镜像，直至调取所有差异镜像层对应的差异镜像层数据。

综上，本申请实施例不需要重启Docker容器，使得Docker容器的内存数据得到了保存，从而实现了Docker镜像的热发布更新方案，之后，通过修改Docker容器对应的镜像描述信息，并将数据保存在磁盘，解决了Docker容器配置一致性问题。

本实施例还提供了一种Docker容器的内容更新系统，该系统结构框图如图1所示，包括服务器100和多个客户端200，其中：

所述客户端200，用于向服务器发起镜像版本更新请求，所述镜像版本更新请求用于更新所述Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

所述服务器100，用于接收到所述镜像版本更新请求后，确定所述Docker容器需要更新后的目标Docker镜像，获取所述目标Docker镜像与所述源Docker镜像的差异镜像层，调取所述差异镜像层对应差异镜像层数据，并根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像。

可选的，服务器100具体为云服务器或本地服务器。

当所述服务器为本地服务器时，所述服务器中的数据处理模块具体用于利用所述目标Docker镜像的镜像标识，调取所述目标Docker镜像的镜像层文件，并依次验证所述目标Docker镜像的镜像层文件中的每一个镜像层在本地服务器是否存在；若当前验证的所述目标Docker镜像的镜像层在所述本地服务器不存在，从云服务器调取当前验证的所述目标Docker镜像的镜像层对应的镜像层数据，并利用调取的镜像层数据，更新所述Docker容器对应的源Docker镜像，直至验证完所述目标Docker镜像的镜像层文件中的所有镜像层。

综上所述，本申请实施例能够实现Docker容器的在线更新，不需要重新构建Docker容器，也就不需要重启Docker容器，从而使该Docker容器里的内存数据丢失，且不会影响业务正常对外服务。

此外，需要说明的是，关于上述各实施例中，诸如第一、第二等之类的 关系术语仅仅用来将一个操作、单元或模块与另一个操作、单元或模块区分开来，而不一定要求或者暗示这些单元、操作或模块之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者系统中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的服务器而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (14)

1.一种Docker容器的内容更新方法，其特征在于，包括：

接收客户端发起的镜像版本更新请求，所述镜像版本更新请求用于更新所述Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

确定所述Docker容器需要更新后的目标Docker镜像；

获取所述目标Docker镜像与所述源Docker镜像的差异镜像层；

调取所述差异镜像层对应差异镜像层数据；

根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像。

2.根据权利要求1所述的方法，其特征在于，获取所述目标Docker镜像与所述源Docker镜像的差异镜像层，包括：

利用所述源Docker镜像的镜像标识，调取所述源Docker镜像的镜像层文件，并利用所述目标Docker镜像的镜像标识，调取所述目标Docker镜像的镜像层文件；

对所述源Docker镜像的镜像层文件和所述目标Docker镜像的镜像层文件进行递归计算，得到所述目标Docker镜像与所述源Docker镜像的差异镜像层。

3.根据权利要求1所述的方法，其特征在于，当所述差异镜像层数据包括多个，所述调取所述差异镜像层对应差异镜像层数据，根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像，包括：

按照预设规则从多个差异镜像层选定一个差异镜像层作为待处理差异镜像层；

调取所述待处理差异镜像层对应的差异镜像层数据，并利用调取的差异镜像层数据更新所述Docker容器对应的源Docker镜像；

判断是否存在未调取相应差异镜像层数据的差异镜像层；

若存在，从所述未调取相应差异镜像层数据的差异镜像层中，重新选择一个差异镜像层作为新的待处理差异镜像层，继续调取所述新的待处理差异镜像层对应的差异镜像层数据，并利用新调取的差异镜像层数据更新所述Docker容器对应的源Docker镜像，直至调取所有差异镜像层对应的差异镜像层数据。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

解析所述镜像版本更新请求，确定需要更新源Docker镜像的Docker容器的容器标识；

通过所述容器标识，获得需要更新的源Docker镜像的镜像标识。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收客户端发送的针对所述Docker容器的镜像描述更新请求；

确定所述Docker容器更新后的镜像信息；

根据更新后的镜像信息更新Docker容器的镜像描述信息。

6.根据权利要求4所述的方法，其特征在于，所述方法还包括：

向所述客户端反馈针对所述镜像版本更新请求和/或所述镜像描述更新请求的响应结果。

7.根据权利要求1所述的方法，其特征在于，所述获取所述目标Docker镜像与所述源Docker镜像的差异镜像层，调取所述差异镜像层对应差异镜像层数据，根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像，包括：

利用所述目标Docker镜像的镜像标识，调取所述目标Docker镜像的镜像层文件；

依次验证所述目标Docker镜像的镜像层文件中的每一个镜像层在本地服务器是否存在；

若当前验证的所述目标Docker镜像的镜像层在所述本地服务器不存在，从云服务器调取当前验证的所述目标Docker镜像的镜像层对应的镜像层数据，并利用调取的镜像层数据，更新所述Docker容器对应的源Docker镜像，直至验证完所述目标Docker镜像的镜像层文件中的所有镜像层。

8.一种服务器，其特征在于，包括：第一数据传输模块、镜像仓库、Docker容器以及数据处理模块，其中：

第一所述数据传输模块，用于接收客户端发送的镜像版本更新请求，所述镜像版本更新请求是用于更新所述Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

所述镜像仓库，用于存储所述目标Docker镜像以及所述Docker容器当前对应的所述源Docker镜像的镜像层文件以及所述镜像层文件中各镜像层对应的镜像层数据；

所述数据处理模块，用于确定所述Docker容器需要更新后的目标Docker镜像，获取所述目标Docker镜像与所述源Docker镜像的差异镜像层，并从所述镜像仓库调取所述差异镜像层对应差异镜像层数据，根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像。

9.根据权利要求8所述的服务器，其特征在于，所述数据处理模块包括：

第一数据调取单元，用于利用所述源Docker镜像的镜像标识，从所述镜像仓库调取所述源Docker镜像的镜像层文件，并利用所述目标Docker镜像的镜像标识，从所述镜像仓库调取所述目标Docker镜像的镜像层文件；

第一计算单元，对所述源Docker镜像的镜像层文件和所述目标Docker镜像的镜像层文件进行递归计算，得到所述目标Docker镜像与所述源Docker镜像的差异镜像层。

10.根据权利要求8所述的服务器，其特征在于，当所述差异镜像层数据包括多个，所述数据处理模块包括：

选定单元，用于按照预设规则从多个差异镜像层选定一个差异镜像层作为待处理差异镜像层；

第二数据调取单元，用于调取所述待处理差异镜像层对应的差异镜像层数据，并利用调取的差异镜像层数据更新所述Docker容器对应的源Docker镜像；

判断单元，用于判断是否存在未调取相应差异镜像层数据的差异镜像层，若存在，触发所述选定单元从所述未调取相应差异镜像层数据的差异镜像层中，重新选择一个差异化层数据作为新的待处理差异化数据，并由所述第三调取单元继续调取所述新的待处理差异镜像层对应的差异镜像层数据，并利用新调取的差异镜像层数据更新所述Docker容器对应的源Docker镜像，直至调取所有差异镜像层对应的差异镜像层数据。

11.根据权利要求9所述的服务器，其特征在于，所述数据处理模块还包括：

解析单元，用于解析所述镜像版本更新请求，确定需要更新源Docker镜像的Docker容器的容器标识；

镜像标识确定单元，用于通过所述容器标识，获得需要更新的源Docker镜像的镜像标识。

12.根据权利要求8所述的服务器，其特征在于，第二数据传输模块；

所述第二数据传输模块，用于接收客户端发送的针对所述Docker容器的镜像描述更新请求；

则所述数据处理模块还用于确定所述Docker容器更新后的镜像信息，并根据更新后的镜像信息更新Docker容器的镜像描述信息。

13.一种Docker容器的内容更新系统，其特征在于，包括：客户端以及服务器，其中：

所述客户端，用于向服务器发起镜像版本更新请求，所述镜像版本更新请求用于更新所述Docker容器对应的源Docker镜像，其中，一个Docker镜像包括多个镜像层，每一个镜像层对应一个镜像层数据；

所述服务器，用于接收到所述镜像版本更新请求后，确定所述Docker容器需要更新后的目标Docker镜像，获取所述目标Docker镜像与所述源Docker镜像的差异镜像层，调取所述差异镜像层对应差异镜像层数据，并根据所述差异镜像层数据，将所述Docker容器对应的源Docker镜像更新为所述目标Docker镜像。

14.根据权利要求13所述的系统，其特征在于，所述服务器具体为云服务器或本地服务器；

当所述服务器为本地服务器时，所述服务器中的数据处理模块具体用于利用所述目标Docker镜像的镜像标识，调取所述目标Docker镜像的镜像层文件，并依次验证所述目标Docker镜像的镜像层文件中的每一个镜像层在本地服务器是否存在；若当前验证的所述目标Docker镜像的镜像层在所述本地服务器不存在，从云服务器调取当前验证的所述目标Docker镜像的镜像层对应的镜像层数据，并利用调取的镜像层数据，更新所述Docker容器对应的源Docker镜像，直至验证完所述目标Docker镜像的镜像层文件中的所有镜像层。