基于容器Docker的应用部署方法、装置及电子设备

技术领域

本发明涉及容器集群技术领域，尤其涉及一种基于容器Docker的应用部署方法、装置及电子设备。

背景技术

容器(Docker)作为新一代应用的标准交付件，是一个开源的应用容器引擎，开发者可以打包应用以及依赖包到可移植的镜像中，然后进行部署。

在创建Docker容器并部署应用时，需要开发者人工编排配置文件，再手动发布及部署。也就是说，Docker容器的资源配置和部署都需要人工编排，应用部署效率较低。

发明内容

本申请实施例的目的是提供一种基于容器Docker的应用部署方法及装置，以解决应用部署的效率过低的问题。

为了解决上述技术问题，本申请实施例是这样实现的：

第一方面，本申请实施例提供了一种基于容器Docker的应用部署方法，所述方法包括：

接收用于指示进行应用部署交付指令；响应所述交付指令，调用第一目标对象构建待部署的应用的Docker镜像；调用第二目标对象，利用构建的Docker镜像进行应用部署。

第二方面，本申请实施例提供了一种基于容器Docker的应用部署装置，所述装置包括：

接收模块，用于接收用于指示进行应用部署交付指令；第一调用模块，用于响应所述交付指令，调用第一目标对象构建待部署的应用的Docker镜像；第二调用模块，用于调用第二目标对象，利用构建的Docker镜像进行应用部署。

第三方面，本申请实施例提供了一种电子设备，包括处理器、通信接口、存储器和通信总线；其中，所述处理器、所述通信接口以及所述存储器通过总线完成相互间的通信；所述存储器，用于存放计算机程序；所述处理器，用于执行所述存储器上所存放的程序，实现如第一方面所述的基于容器Docker的应用部署方法步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，实现如第一方面所述的基于容器Docker的应用部署方法步骤。

第五方面，本申请实施例提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的基于容器Docker的应用部署方法。

由以上本申请实施例提供的技术方案可见，通过接收用于指示进行应用部署交付指令，响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像，调用第二目标对象，利用构建的Docker镜像进行应用部署。因此，通过本申请实施例提供的技术方案，在接收到交付指令之后，能调用第一目标对象构建应用的Docker镜像并由第二目标对象部署，提高应用部署效率。

附图说明

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

图1为本申请实施例提供一种基于容器Docker的应用部署方法的第一种流程示意图；

图2为本申请实施例提供一种基于容器Docker的应用部署方法的第二种流程示意图；

图3为本申请实施例提供一种基于容器Docker的应用部署方法的第三种流程示意图；

图4为本申请实施例提供一种基于容器Docker的应用部署方法的第四种流程示意图；

图5为本申请实施例提供一种基于Docker的应用部署的功能模块示意图；

图6为本申请实施例提供的电子设备的结构示意图。

具体实施方式

本申请实施例提供了一种基于容器Docker的应用部署方法及装置，提高了应用部署的效率。

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

一些场景下，在互联网时代，企业需要找寻新的软件交付流程和互联网技术(internet Technology，IT)框架，从而实现架构平台化，交付持续化和业务服务化。容器将成为新一代应用的标准交付件，容器云将对接各类代码托管库，实现自动化持续集成和Docker镜像构建，为新一代应用交付和开发运维一体化奠定基础。

一些场景下，Kubernetes是自动化容器操作的开源平台，提供了应用部署，规划，更新，调度以及维护的一种机制，通过Docker容器技术部署容器，每个容器有自己的文件系统，每个容器之间互相隔离，因此，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。

Kubernetes下的容器即服务(Containers as a Service，CaaS)是一种云服务模型，允许用户通过基于容器的虚拟化来管理和部署容器、应用程序和集群。CaaS可以部署在任何物理机或虚拟机之上，对于构建安全且可扩展的容器化应用非常有用。

代码托管平台(Gitlab)提供分布式代码管理服务。通过Web页面，输入用户名和密码进入管理界面，管理界面主要包含项目管理、用户管理、群组管理和Gitlab配置四大部分，通过Gitlab对用户提交的代码进行管理。

本申请实施例中，在构建Docker容器前，需要对Gitlab进行项目配置，首先创建一个群专门负责基础组件添加和维护，接着增加新的用户并且添加到基础组件群组中，最后添加一个基础组件项目并且指定由群组中某些成员负责维护。群组主要的目的是聚合一群用户和它们维护的项目，只要在Web界面中添加群组相关信息最后点击创建就可以了。

然后就是创建项目(如创建构建Docker容器)，项目的创建可以在之前创建的群组里添加项目，这样整个项目就归所在群组维护，可以为项目增加各种维护人员，需要注意的是，只有项目里的管理员(master)分支的用户才有权限更新项目。

最后是Gitlab配置，Gitlab配置包括但不限于访问地址的配置、访问此GitLab的服务器上的公钥的配置、Gitlab的网络之间互连的协议(Internet Protocol，IP)显示配置及端口配置(如超文本传输协议(HyperTextTransferProtocol，Http)端口配置、安全壳协议(Secure Shell，SSH)端口配置)、中央处理器(Central Processing Unit，CPU)配置、分支名配置、默认公存地址配置等。进一步，Gitlab的各项配置可以转换为变量，由此可以通过已有的项目复制出新的项目。

Jenkins是一个开源的、可扩展的持续集成、交付、部署(代码的编译、打包、部署)的基于web界面的平台。允许持续集成和持续交付项目，无论用的是什么平台，可以处理任何类型的构建或持续集成。为了Jenkins和Gitlab协同工作，Jenkins中需要安装Gitlab的插件，从而保证Jenkins能根据Gitlab文件构建Docker镜像。

下面结合附图对本申请实施例提供的一种基于容器Docker的应用部署方法、装置及电子设备进行详细说明。

如图1所示，本申请实施例提供一种基于容器Docker的应用部署方法，该方法的执行主体可以为服务器，其中，该服务器可以是独立的服务器，也可以是由多个服务器组成的服务器集群。该服务器上部署有Gitlab、Jenkins、kubernetes和docker，该基于容器Docker的应用部署方法具体可以包括以下步骤S101-S104：

在S101中，接收用于指示进行应用部署的交付指令。

具体来讲，交付指令是用户提交一段代码后产生的指令，该一段代码用来指示进行应用部署，也就是首先构建Docker镜像，然后利用Docker镜像进行应用部署。

在一种实施例中，用户提交该段代码后，需要用户手动进行代码编译，然后构建Docker镜像，在Docker镜像构建完成后，再由用户手动上传至服务器。如此，最终Docker的应用部署效率较低。

为了解决以上技术问题，在一种可能的实现方式中，S101包括：

利用Gitlab接收交付指令，也就是说用于指示进行应用部署的交付指令通过Gitlab接收。其中，在完成Gitlab配置后，Gitlab能自动获取交付指令，该交付指令是用户通过Web页面提交一段用来构建Docker镜像的代码后产生的。

在S102中，响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像。

具体来讲，第一目标对象可以为Jenkins，在Gitlab获取交付指令之后，触发Jenkins自动构建Docker容器。

在一种可能的实现方式中，S102包括：

触发Gitlab web hook，从Gitlab web hook获取Jenkins的回调地址，基于获取到的回调地址调用Jenkins，构建待部署的应用的Docker镜像。

具体来讲，Gitlab接收到交付指令后，会向Jenkins推送交付指令，让Jenkins可以触发相应的操作。

向Jenkins推送交付指令之前，需要配置Gitlab web hook(Web钩子)和Jenkins。配置Gitlab web hook(Web钩子)具体是，配置Gitlab web hook(Web钩子)的请求地址(Jenkins的回调地址)，用户可以从Web页面填写“链接(URL)”，该“链接(URL)”从Jenkins中获取，然后配置触发器，并在Web页面选择推送事件(如推送Docker镜像)。

配置Jenkins具体是：用户可以通过Web页面配置端口、访问地址、插件安装、权限配置等。为了Jenkins与Gitlab建立连接，需要在Jenkins中添加Gitlab插件(如GitHubplugin，GIT plugin，GIT client plugin等)，从而在Jenkins与Gitlab之间建立连接。

通过Jenkins构建应用的Docker镜像具体是：首先用户通过Web页面创建项目，如nginx，然后配置源码地址，即Gitlab提供的与交付指令对应的代码的Git地址。在完成项目创建和配置好源码地址之后，构建shell脚本文件。完成如上配置之后，Jenkins从Gitlab上下载配置文件放在workspace目录中。因此，Jenkins触发脚本后，Jenkins中的build根据workspace目录中的配置文件直接开始构建nginx镜像(Dcoker镜像)。

Dcoker镜像构建完成后，可以去Jenkins主机查看Dcoker镜像是否完成构建，在构建完成后，直接启动该镜像。或者直接推送到远程仓库(如harbor镜像仓库)中。

在S104中，调用第二目标对象，利用构建的Docker镜像进行应用部署。

具体来讲，第二目标对象可以为kubernetes的应用程序接口，通过kubernetes可以自动部署Docker镜像从而完成应用部署，提高部署效率。

在一种可能的实现方式中，S104包括：

调用kubernetes的应用程序接口，基于kubernetes利用打包后的Docker镜像进行应用部署。

具体来讲，可以采用Jenkins调用kubernetes的应用程序接口，然后通过该应用程序接口，基于kubernetes利用打包后的Docker镜像进行应用部署。Kubernetes利用构建的Docker镜像进行应用部署时，确定部署该Docker镜像的所需资源，并选择命名空间，按照所需资源确定满足要求的服务器，kubernetes按所需资源调度服务器内存、CPU等在选择的命名空间将打包后的Dokcer镜像进行部署，完成应用的部署，实现了资源的高效利用。

对于kubernetes而言，其还可以定期清理过期的部署环境，避免过期的部署环境占用资源，造成资源浪费的问题，实现了资源的高效利用。

由以上本申请实施例提供的技术方案可见，通过接收用于指示进行应用部署的交付指令，响应交付指令，调用第一目标对象构建待部署应用的Docker镜像，调用第二目标对象，利用构建的Docker镜像进行应用部署。因此，通过本申请实施例提供的技术方案，在接收到交付指令之后，能调用第一目标对象自动构建应用的Docker镜像并由第二目标对象部署，提高应用部署效率。

此外，通过Gitlab和Jenkins自动获取代码以及构建镜像，避免了开发者手动编译代码，提高了部署效率。此外，基于kubernetes进行容器部署，实现了资源的高效利用。

如图2所示，本申请实施例提供一种基于容器Docker的应用部署方法，该方法的执行主体可以为服务器，其中，该服务器可以是独立的服务器，也可以是由多个服务器组成的服务器集群。该基于容器Docker的应用部署方法具体可以包括以下步骤S201-S205：

在S201中，接收用于指示进行应用部署的交付指令。

在S202中，响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像。

在S204中，调用第二目标对象，利用构建的Docker镜像进行应用部署。

值得注意的是，S201至S204具有与S101至S104相同或类似的实现方式，其可以互相参照，本申请实施例在此不再赘述。

在S205中，调用kubernetes的应用程序接口，获取利用构建的Docker镜像进行应用部署的日志记录；显示日志记录。

具体来讲，可以通过Jenkins调用kubernetes的应用程序接口，获取利用构建的Docker镜像进行应用部署的日志记录，并在Web网页上显示日志记录，便于用户查看。

由以上本申请实施例提供的技术方案可见，通过接收用于指示进行应用部署交付指令，响应交付指令，调用第一目标对象构建待部署应用的Docker镜像，调用第二目标对象，利用构建的Docker镜像进行应用部署。因此，通过本申请实施例提供的技术方案，在接收到交付指令之后，能调用第一目标对象自动构建应用的Docker镜像并由第二目标对象部署，提高应用部署效率。

此外，通过调用kubernetes的应用程序接口，获取部署Docker镜像的日志记录，显示日志记录，便于用户查看，掌握Docker镜像的部署情况，在Docker镜像部署异常时，便于用户及时解决，提升用户体验感。

如图3所示，本申请实施例提供一种基于容器Docker的应用部署方法，该方法的执行主体可以为服务器，其中，该服务器可以是独立的服务器，也可以是由多个服务器组成的服务器集群。该基于容器Docker的应用部署方法具体可以包括以下步骤S301-S304：

在S301中，接收用于指示进行应用部署的交付指令。

在S302中，响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像。

在S303中，打包Docker镜像；推送打包后的Docker镜像至harbor镜像仓库。

具体来讲，在推送Docker镜像至harbor镜像仓库前，需要构建Docker镜像推送至harbor镜像仓库的配置。具体是需要指定推送Docker镜像至harbor镜像仓库的路径、配置Docker镜像的名称、指定Dockerfile的文件路径以及harbor镜像仓库的账户密码等。在做好以上配置后，Jenkins中的build打包Docker镜像，通过“推送Docker镜像至harbor镜像仓库的路径”将Docker镜像推送至harbor镜像仓库。

在S304中，调用第二目标对象，利用构建的Docker镜像进行应用部署。

在一种可能的实现方式中，S304包括：

从harbor镜像仓库获取打包后的Docker镜像；利用Jenkins调用kubernetes的应用程序接口；通过应用程序接口，基于kubernetes利用打包后的Docker镜像进行应用部署。

值得注意的是，S301至S304具有与S101至S104相同或类似的实现方式，其可以互相参照，本申请实施例在此不再赘述。

值得注意的是，在S304之后还可以执行调用kubernetes的应用程序接口，获取部署Docker镜像的日志记录；显示日志记录的步骤。该“调用kubernetes的应用程序接口，获取部署Docker镜像的日志记录；显示日志记录”具有与上述S205相同或类似的实现方式，其可以互相参照，本申请实施例在此不再赘述。

通过本申请实施例公开的技术方案，通过接收用于指示进行应用部署交付指令，响应交付指令，调用第一目标对象构建待部署应用的Docker镜像，调用第二目标对象，利用构建的Docker镜像进行应用部署。因此，通过本申请实施例提供的技术方案，在接收到交付指令之后，能调用第一目标对象自动构建应用的Docker镜像并由第二目标对象部署，提高应用部署效率。

下面结合图4对本申请实施例提供的基于容器Docker的应用部署方法进行进一步的说明。

如图4所示的，gitlab接收到交付指令(表示有一段新的代码)，触发Gitlab webhook，Gitlab web hook中配置了Jenkins的回调地址，Gitlab web hook触发后，基于获取到的Jenkins的回调地址调用Jenkins，Jenkins从Gitlab上下载配置文件，并开始构建Docker镜像。在Docker镜像构建完成后，Jenkins推送Docker镜像至harbor镜像仓库。然后Jenkins调用kubernetes的应用程序接口启动部署；通过应用程序接口，利用kubernetes部署利用构建的Docker镜像进行应用部署。

此外，还可以由Jenkins调用kubernetes的应用程序接口，获取利用构建的Docker镜像进行应用部署的日志记录；并在Web页面显示日志记录。

通过本申请实施例公开的技术方案，通过Gitlab和Jenkins自动获取代码以及构建镜像，避免了开发者手动编译代码，提高了部署效率。此外，基于kubernetes进行容器部署，实现了资源的高效利用。

此外，通过调用kubernetes的应用程序接口，获取利用构建的Docker镜像进行应用部署的日志记录，显示日志记录，便于用户查看，掌握Docker镜像的部署情况，在Docker镜像部署异常时，便于用户及时解决，提升用户体验感。

对应上述实施例提供的基于容器Docker的应用部署方法，基于相同的技术构思，本申请实施例还提供了基于容器Docker的应用部署装置，图5为本申请实施例提供的基于容器Docker的应用部署装置的模块组成示意图，该基于容器Docker的应用部署装置用于执行图1和图3描述的基于容器Docker的应用部署方法，如图5所示，该基于容器Docker的应用部署装置5包括：接收模块501，第一调用模块502和第二调用模块503。

接收模块501，用于接收用于指示进行应用部署交付指令；第一调用模块502，用于响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像；第二调用模块503，用于调用第二目标对象，利用构建的Docker镜像进行应用部署。

通过本申请实施例公开的一种技术方案，通过接收用于指示进行应用部署交付指令，响应交付指令，调用第一目标对象构建待部署应用的Docker镜像，调用第二目标对象，利用构建的Docker镜像进行应用部署。因此，通过本申请实施例提供的技术方案，在接收到交付指令之后，能调用第一目标对象自动构建应用的Docker镜像并由第二目标对象部署，提高应用部署效率。

在一种可能的实现方式中，第一目标对象包括Jenkins，第一调用模块502，还用于触发Gitlab web hook，从Gitlab web hook获取Jenkins的回调地址；基于获取到的回调地址调用Jenkins，构建待部署的应用的Docker镜像。

在一种可能的实现方式中，还包括：打包模块(图中未示出)，用于打包第一目标对象构建的Docker镜像；推送模块(图中未示出)，用于推送打包后的Docker镜像至harbor镜像仓库；第二目标对象包括kubernetes的应用程序接口，第二调用模块503，还用于从所述harbor镜像仓库获取打包后的所述Docker镜像；调用kubernetes的应用程序接口，基于所述kubernetes，利用所述打包后的Docker镜像进行应用部署。

在一种可能的实现方式中，第二调用模块503，还用于利用Jenkins调用kubernetes的应用程序接口；通过所述应用程序接口，基于所述kubernetes利用所述打包后的Docker镜像进行应用部署。

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

第三调用模块(图中未示出)，用于调用kubernetes的应用程序接口，获取利用构建的Docker镜像进行应用部署的日志记录；显示模块(图中未示出)，用于显示日志记录。

本申请实施例提供的基于容器Docker的应用部署装置能够实现上述基于容器Docker的应用部署方法对应的实施例中的各个过程，为避免重复，这里不再赘述。

需要说明的是，本申请实施例提供的基于容器Docker的应用部署装置与本申请实施例提供的基于容器Docker的应用部署方法基于同一发明构思，因此该实施例的具体实施可以参见前述基于容器Docker的应用部署方法的实施，重复之处不再赘述。

对应上述实施例提供的基于容器Docker的应用部署方法，基于相同的技术构思，本申请实施例还提供了一种电子设备，该电子设备用于执行上述的基于容器Docker的应用部署方法，图6为实现本发明各个实施例的一种电子设备的结构示意图，如图6所示。电子设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器601和存储器602，存储器602中可以存储有一个或一个以上存储应用程序或数据。其中，存储器602可以是短暂存储或持久存储。存储在存储器602的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对电子设备中的一系列计算机可执行指令。更进一步地，处理器601可以设置为与存储器602通信，在电子设备上执行存储器602中的一系列计算机可执行指令。电子设备还可以包括一个或一个以上电源603，一个或一个以上有线或无线网络接口604，一个或一个以上输入输出接口605，一个或一个以上键盘606。

在本实施例中，电子设备包括有处理器、通信接口、存储器和通信总线；其中，处理器、通信接口以及存储器通过总线完成相互间的通信；存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序，实现以下方法步骤：

接收用于指示进行应用部署交付指令；响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像；调用第二目标对象，利用构建的Docker镜像进行应用部署。

通过本申请提供的一种技术方案，通过接收用于指示进行应用部署交付指令，响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像，调用第二目标对象，利用构建的Docker镜像进行应用部署。因此，通过本申请实施例提供的技术方案，在接收到交付指令之后，能调用第一目标对象自动构建应用的Docker镜像并由第二目标对象部署，提高应用部署效率。

具体实施例中，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时，实现如以下步骤：

接收用于指示进行应用部署交付指令；响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像；调用第二目标对象，利用构建的Docker镜像进行应用部署。

通过本申请提供的一种技术方案，通过接收用于指示进行应用部署交付指令，响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像，调用第二目标对象，利用构建的Docker镜像进行应用部署。因此，通过本申请实施例提供的技术方案，在接收到交付指令之后，能调用第一目标对象自动构建应用的Docker镜像并由第二目标对象部署，提高应用部署效率。

具体实施例中，本申请实施例提供了一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现如以下步骤：

接收用于指示进行应用部署交付指令；响应交付指令，调用第一目标对象构建待部署的应用的Docker镜像；调用第二目标对象，利用构建的Docker镜像进行应用部署。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，电子设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、装置或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。