一种应用部署方法、计算设备及可读存储介质

摘要

本发明公开了一种应用部署方法、计算设备及可读存储介质。本发明的应用部署方法在计算设备中执行，计算设备与服务部署服务器通信连接，该方法包括：当监听到第一事件时，获取应用当前所有服务的第一部署信息。接着，获取应用前一次有效部署时所有服务的第二部署信息，并将第一部署信息与第二部署信息的差异信息，在第一部署信息或第二部署信息中进行标注。然后，将标注后的第三部署信息发送至审核端。最后，当接收到审核端发送的审核成功消息后，将第三部署信息发送至服务部署服务器，以便服务部署服务器依据第三部署信息对应用中所修改的服务进行重新部署。本发明的应用部署方法支持按照服务更新，实现了小粒度的更新，方便快捷。

权利要求

1.一种应用部署方法，适于在计算设备中执行，所述计算设备与服务部署服务器通信连接，所述应用包括多个服务，所述方法包括：当监听到第二事件时，显示服务部署信息界面，所述服务部署信息界面中包括服务名称、镜像地址、启动命令、服务端口、配置映射、环境变量、密钥名称和部署控件，以便用户通过所述服务部署信息界面创建或修改所述应用的服务的部署信息，并触发所述部署控件；

当监听到所述部署控件的触发事件时，获取所述应用当前所有服务的第一部署信息；

获取所述应用前一次有效部署时所有服务的第二部署信息，并将所述第一部署信息与所述第二部署信息的差异信息，在所述第一部署信息或第二部署信息中进行标注；

将标注后的第三部署信息发送至审核端，以便所述审核端依据所述第三部署信息对所修改的服务的部署信息进行审核；

当接收到所述审核端发送的审核成功消息后，将所述第三部署信息发送至所述服务部署服务器，以便所述服务部署服务器依据所述第三部署信息对所述应用中所修改的服务进行重新部署。

2.如权利要求1所述的方法，其中，将所述第一部署信息与所述第二部署信息的差异信息，在所述第一部署信息或第二部署信息中进行标注的步骤，包括：在所述第一部署信息或第二部署信息中，将第一部署信息相比于第二部署信息所新增的部分通过第一标识标注，并将第一部署信息相比于第二部署信息所删除的部分通过第二标识标注。

3.如权利要求1或2所述的方法，其中，所述服务部署服务器依据所述第三部署信息对所述应用中所修改的服务进行重新部署的方法，包括：当接收到所述计算设备发送的第三部署信息后，获取所述应用中所修改的各个服务的标注后的部署信息；

根据所修改的各个服务的标注后的部署信息，对所修改的各个服务进行重新部署。

4.如权利要求3所述的方法，其中，对所修改的各个服务进行重新部署的步骤，包括：针对所修改的每个服务，基于其标注后的部署信息，获取该服务中所修改的各个资源的标注后的部署信息；

根据所修改的各个资源的标注后的部署信息，对所修改的各个资源进行重新部署。

5.如权利要求4所述的方法，其中，所述服务部署服务器中搭建有容器集群，以及对所修改的各个资源进行重新部署的步骤，包括：针对所修改的每个资源，利用其标注后的部署信息，对基于所述容器集群的接口参数所生成的描述文件模板进行渲染，生成所述容器集群可识别的描述文件；

基于所述描述文件，对所述资源进行创建、更新或删除。

6.如权利要求5所述方法，其中，在对所述资源进行创建、更新或删除的步骤之后，还包括：检测所述资源所属的服务的状态；

若该服务状态正常，则继续对该服务中所修改的下个资源进行重新部署；

若该服务状态不正常，则对已重新部署的目标服务执行回滚。

7.如权利要求6所述的方法，其中，对已重新部署的目标服务执行回滚的步骤，包括：将对所述目标服务执行回滚的消息发送至所述计算设备，以便所述计算设备将所述目标服务的当前部署信息与其前一次有效部署的部署信息的差异信息，在所述目标服务的当前部署信息或其前一次有效部署的部署信息中进行标注；

接收所述计算设备发送的标注后的第四部署信息，并基于所述第四部署信息 ，对所述目标服务执行回滚。

8.如权利要求1或2所述的方法，其中，在获取所述应用当前所有服务的第一部署信息的步骤之后，还包括：将所获取到的第一部署信息进行存储。

9.一种计算设备，包括：

至少一个处理器；以及

存储器，存储有程序指令，其中，所述程序指令被配置为适于由所述至少一个处理器执行，所述程序指令包括用于执行如权利要求1‑8中任一项所述的方法的指令。

10.一种存储有程序指令的可读存储介质，当所述程序指令被计算设备读取并执行时，使得所述计算设备执行如权利要求1‑8中任一项所述方法。

说明书

一种应用部署方法、计算设备及可读存储介质

技术领域

[0001] 本发明涉及计算机领域，尤其涉及一种应用部署方法、计算设备及可读存储介质。

背景技术

[0002] 目前，应用部署主要是基于Helm来实现。具体地，首先，上传需要部署的应用包，一般为jar和war格式。然后，调用Java Api按照Velocity语法渲染生成Dockerfile文件，并根据Docker API生成可被Kubernetes使用的Docker镜像。接着，将Docker镜像以及生成好的Helm chart部署文件通过Java API上传至服务器。最后，通过helm install命令创建Pod和Deployment等Kubernetes组件。

[0003] 显然，上述应用部署方法的实现依赖于部署人员编写Dockerfile和Helm chart文件，对部署人员要求过高，并且其不支持按照服务更新，效率低下。

[0004] 为此，亟需一种新的应用部署方法来解决上述问题。

发明内容

[0005] 为此，本发明提供了一种应用部署方法、计算设备及可读存储介质，以力图解决或者至少缓解上面存在的问题。

[0006] 根据本发明的一个方面，提供一种应用部署方法，在计算设备中执行，计算设备与服务部署服务器通信连接，该方法包括：当监听到第一事件时，获取应用当前所有服务的第一部署信息；获取应用前一次有效部署时所有服务的第二部署信息，并将第一部署信息与第二部署信息的差异信息，在第一部署信息或第二部署信息中进行标注；将标注后的第三部署信息发送至审核端，以便审核端依据第三部署信息对所修改的服务的部署信息进行审核；当接收到审核端发送的审核成功消息后，将第三部署信息发送至服务部署服务器，以便服务部署服务器依据第三部署信息对应用中所修改的服务进行重新部署。

[0007] 可选地，在根据本发明的应用部署方法中，在当监听到第一事件时，获取应用当前所有服务的第一部署信息的步骤之前，还包括：当监听到第二事件时，显示服务部署信息界面，以便用户通过服务部署信息界面创建或修改应用的服务的部署信息，并触发第一事件。

[0008] 可选地，在根据本发明的应用部署方法中，将第一部署信息与第二部署信息的差异信息，在第一部署信息或第二部署信息中进行标注的步骤，包括：在第一部署信息或第二部署信息中，将第一部署信息相比于第二部署信息所新增的部分通过第一标识标注，并将第一部署信息相比于第二部署信息所删除的部分通过第二标识标注。

[0009] 可选地，在根据本发明的应用部署方法中，服务部署服务器依据第三部署信息对应用中所修改的服务进行重新部署的方法，包括：当接收到计算设备发送的第三部署信息后，获取应用中所修改的各个服务的标注后的部署信息；根据所修改的各个服务的标注后的部署信息，对所修改的各个服务进行重新部署。

[0010] 可选地，在根据本发明的应用部署方法中，对所修改的各个服务进行重新部署的步骤，包括：针对所修改的每个服务，基于其标注后的部署信息，获取该服务中所修改的各个资源的标注后的部署信息；根据所修改的各个资源的标注后的部署信息，对所修改的各个资源进行重新部署。

[0011] 可选地，在根据本发明的应用部署方法中，服务部署服务器中搭建有容器集群，以及对所修改的各个资源进行重新部署的步骤，包括：针对所修改的每个资源，利用其标注后的部署信息，对基于容器集群的接口参数所生成的描述文件模板进行渲染，生成容器集群可识别的描述文件；基于描述文件，对资源进行创建、更新或删除。

[0012] 可选地，在根据本发明的应用部署方法中，在对资源进行创建、更新或删除的步骤之后，还包括：检测资源所属的服务的状态；若该服务状态正常，则继续对该服务中所修改的下个资源进行重新部署；若该服务状态不正常，则对已重新部署的目标服务执行回滚。

[0013] 可选地，在根据本发明的应用部署方法中，对已重新部署的目标服务执行回滚的步骤，包括：将对目标服务执行回滚的消息发送至计算设备，以便计算设备将目标服务的当前部署信息与其前一次有效部署的部署信息的差异信息，在目标服务的当前部署信息或其前一次有效部署的部署信息中进行标注；接收计算设备发送的标注后的第四部署信息，并基于第四部署消息，对目标服务执行回滚。

[0014] 可选地，在根据本发明的应用部署方法中，计算设备将目标服务的当前部署信息与其前一次有效部署的部署信息的差异信息，在目标服务的当前部署信息或其前一次有效部署的部署信息中进行标注的步骤，包括：在目标服务的当前部署信息或其前一次有效部署的部署信息中，将目标服务的前一次有效部署的部署信息相比于其当前部署信息所新增的部分通过第一标识标注，并将目标服务的前一次有效部署的部署信息相比于其当前部署信息所删除的部分通过第二标识标注。

[0015] 可选地，在根据本发明的应用部署方法中，在获取应用当前所有服务的第一部署信息的步骤之后，还包括：将所获取到的第一部署信息进行存储。

[0016] 根据本发明的又一个方面，提供一种计算设备，包括：至少一个处理器；以及存储器，存储有程序指令，其中，程序指令被配置为适于由至少一个处理器执行，程序指令包括用于执行根据本发明的应用部署方法的指令。

[0017] 根据本发明的又一个方面，提供一种存储有程序指令的可读存储介质，当程序指令被计算设备读取并执行时，使得计算设备执行根据本发明的应用部署方法。

[0018] 根据本发明的应用部署方法，在对应用进行部署时，首先获取应用当前的部署信息和其前一次有效部署的部署信息的差异信息。然后，基于该差异信息，对所修改的服务进行重新部署。可见，本发明只需对所修改的服务进行重新部署，便能实现对应用的重新部署。因此，本发明支持按照服务更新，实现了小粒度的更新，方便快捷。

[0019] 进一步地，本发明在获取到应用当前的部署信息和其前一次有效部署的部署信息的差异信息后，会将其发送至审核端进行审核，只有审核通过后，才会基于该差异信息对应用进行重新部署。因此，本发明能够保证应用部署信息的准确性，从而可以降低应用发布的出错率。

附图说明

[0020] 为了实现上述以及相关目的，本文结合下面的描述和附图来描述某些说明性方面，这些方面指示了可以实践本文所公开的原理的各种方式，并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述，本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开，相同的附图标记通常指代相同的部件或元素。

[0021] 图1示出了根据本发明一个实施例的计算设备100的结构框图；

[0022] 图2示出了根据本发明一个实施例的应用部署方法200的流程图；

[0023] 图3示出了根据本发明一个实施例的服务部署信息界面的示意图；

[0024] 图4示出了根据本发明一个实施例的应用的某一服务下的某一资源的两次部署信息的对比图；

[0025] 图5示出了根据本发明另一个实施例的应用部署方法的示意图；

[0026] 图6示出了根据本发明又一个实施例的应用部署方法的示意图。

具体实施方式

[0027] 下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

[0028] 图1示出了根据本发明一个实施例的计算设备100的结构框图。需要说明的是，图1所示的计算设备100仅为一个示例，在实践中，用于实施本发明的应用部署方法的计算设备可以是任意型号的设备，其硬件配置情况可以与图1所示的计算设备100相同，也可以与图1所示的计算设备100不同。实践中用于实施本发明的应用部署方法的计算设备可以对图1所示的计算设备100的硬件组件进行增加或删减，本发明对计算设备的具体硬件配置情况不做限制。

[0029] 如图1所示，在基本配置102中，计算设备100典型地包括系统存储器106和一个或者多个处理器104。存储器总线108可以用于在处理器104和系统存储器106之间的通信。

[0030] 取决于期望的配置，处理器104可以是任何类型的处理，包括但不限于：微处理器（µP）、微控制器（µC）、数字信息处理器（DSP）或者它们的任何组合。处理器104可以包括诸如一级高速缓存110和二级高速缓存112之类的一个或者多个级别的高速缓存、处理器核心114和寄存器116。示例的处理器核心114可以包括运算逻辑单元（ALU）、浮点数单元（FPU）、数字信号处理核心（DSP核心）或者它们的任何组合。示例的存储器控制器118可以与处理器
104一起使用，或者在一些实现中，存储器控制器118可以是处理器104的一个内部部分。

[0031] 取决于期望的配置，系统存储器106可以是任意类型的存储器，包括但不限于：易失性存储器（诸如RAM）、非易失性存储器（诸如ROM、闪存等）或者它们的任何组合。计算设备中的物理内存通常指的是易失性存储器RAM，磁盘中的数据需要加载至物理内存中才能够被处理器104读取。系统存储器106可以包括操作系统120、一个或者多个应用122以及程序数据124。在一些实施方式中，应用122可以布置为在操作系统上由一个或多个处理器104利用程序数据124执行指令。操作系统120例如可以是Linux、Windows等，其包括用于处理基本系统服务以及执行依赖于硬件的任务的程序指令。应用122包括用于实现各种用户期望的功能的程序指令，应用122例如可以是浏览器、即时通讯软件、软件开发工具（例如集成开发环境IDE、编译器等）等，但不限于此。当应用122被安装到计算设备100中时，可以向操作系统120添加驱动模块。

[0032] 在计算设备100启动运行时，处理器104会从系统存储器106中读取操作系统120的程序指令并执行。应用122运行在操作系统120之上，利用操作系统120以及底层硬件提供的接口来实现各种用户期望的功能。当用户启动应用122时，应用122会加载至系统存储器106中，处理器104从系统存储器106中读取并执行应用122的程序指令。

[0033] 计算设备100还包括储存设备132，储存设备132包括可移除储存器136和不可移除储存器138，可移除储存器136和不可移除储存器138均与储存接口总线134连接。

[0034] 计算设备100还可以包括有助于从各种接口设备（例如，输出设备142、外设接口144和通信设备146）到基本配置102经由总线/接口控制器130的通信的接口总线140。示例的输出设备142包括图形处理单元148和音频处理单元150。它们可以被配置为有助于经由一个或者多个A/V端口152与诸如显示器或者扬声器之类的各种外部设备进行通信。示例外设接口144可以包括串行接口控制器154和并行接口控制器156，它们可以被配置为有助于经由一个或者多个I/O端口158和诸如输入设备（例如，键盘、鼠标、笔、语音输入设备、触摸输入设备）或者其他外设（例如打印机、扫描仪等）之类的外部设备进行通信。示例的通信设备146可以包括网络控制器160，其可以被布置为便于经由一个或者多个通信端口164与一个或者多个其他计算设备162通过网络通信链路的通信。

[0035] 网络通信链路可以是通信介质的一个示例。通信介质通常可以体现为在诸如载波或者其他传输机制之类的调制数据信号中的计算机可读指令、数据结构、程序模块，并且可以包括任何信息递送介质。“调制数据信号”可以这样的信号，它的数据集中的一个或者多个或者它的改变可以在信号中编码信息的方式进行。作为非限制性的示例，通信介质可以包括诸如有线网络或者专线网络之类的有线介质，以及诸如声音、射频（RF）、微波、红外（IR）或者其它无线介质在内的各种无线介质。这里使用的术语计算机可读介质可以包括存储介质和通信介质二者。

[0036] 在根据本发明的计算设备100中，应用122包括用于执行本发明的应用部署方法200的指令，该指令可以指示处理器104执行本发明的应用部署方法。本领域技术人员可以理解，除了用于执行应用部署方法200的指令之外，应用122还可以包括用于实现其他功能的其他应用126。

[0037] 图2示出了根据本发明一个实施例的应用部署方法200的流程图，方法200适于在计算设备（例如图1所示的计算设备100）中执行。该计算设备与服务部署服务器通信连接。

[0038] 为了提高部署的效率，可以基于微服务的模式来对应用进行部署。微服务是一种体系结构样式，其将单个应用程序划分为多个较小的服务单元。因此，采用微服务模式对应用进行部署时，会将一个应用划分为多个服务。即，本发明中的应用由若干个服务组成。

[0039] 如图2所示，本发明的应用部署方法200始于步骤S210。其中，在步骤S210之前，还包括当监听到第二事件时，显示服务部署信息界面，以便用户通过该服务部署信息界面创建或修改应用的服务的部署信息，并触发第一事件。

[0040] 具体地，第二事件可以为预定按键的按下事件。这样，当用户按下该预定按键后，则会在当前桌面显示服务部署信息界面。服务部署信息界面中可以包括服务名称、镜像地址、启动命令、服务端口、配置映射、环境变量和密钥名称等。这样，用户通过该界面则可以对应用中的服务镜像地址、配置文件等部署信息进行修改。进一步地，服务部署信息界面可以采用表单的形式，如图3。当然，服务部署信息界面还可以采用其他形式，对此本发明不作限定。在具体的实施例中，本领域的技术人员可以根据实际需要进行设定。

[0041] 另外，第一事件可以为部署控件的点击事件。基于此，服务部署信息界面中还可以包括一个部署控件，这样当用户对应用中的服务镜像地址、配置文件等部署信息修改后，则可以通过点击该部署控件来触发第一事件（即部署事件）。当然，关于第一事件和第二事件的设定，上述仅是一个示例，在具体的实施例中，本领域的技术人员可以根据实际需要进行设定，对此本发明不作限定。

[0042] 随后，当监听到第一事件，则进入步骤S210，获取应用当前所有服务的第一部署信息。其中，在获取到应用当前所有服务的第一部署信息后，可以将其进行存储。具体地，可以将应用当前所有服务的第一部署信息进行快照，然后将生成的第一部署信息的快照存储在本地或与计算设备通信连接的存储装置中。其中，存储装置可以是数据库，例如MySQL、MariaDB、Oracle数据库等，对此本发明不作限定。

[0043] 在获取到应用当前所有服务的第一部署信息后，进入步骤S220，获取应用前一次有效部署时所有服务的第二部署信息，并将第一部署信息与第二部署信息的差异信息，在第一部署信息或第二部署信息中进行标注。

[0044] 基于上述描述可知，对于每一个应用，本发明会将其每一次发布的各个服务的部署信息存储在本地或与计算设备通信连接的存储装置中，因此可从本地或与计算设备通信连接的存储装置中，来获取应用前一次有效部署时所有服务的第二部署信息。其中，这里的有效是指发布成功，即获取应用上一次发布成功的所有服务的第二部署信息。

[0045] 接着，通过将应用当前所有服务的第一部署信息和应用上一次发布成功的所有服务的第二部署信息进行比对，则可获得第一部署信息与第二部署信息的差异信息（即修改差异），如图4，其左侧示出的是应用上一次发布成功时一个服务下的一个资源的部署信息，右侧示出的是应用当前版本下的该资源的部署信息。显然，图4中所标记的两行便为该资源的两次部署信息的差异信息，也可以将这相互对应的两行称之为该资源的两次部署信息的变更集。

[0046] 在得到第一部署信息和第二部署信息的差异信息后，则以应用当前所有服务的第一部署信息作为目标、应用上一次发布成功的所有服务的第二部署信息作为源，来将差异信息在第一部署信息或第二部署信息中进行标注。具体地，当将差异信息在第二部署信息中进行标注时，将第一部署信息相比于第二部署信息所新增的部分通过第一标识标注，将第一部署信息相比于第二部署信息所删除的部分通过第二标识标注。进一步讲，利用第一标识，将第一部署信息相比于第二部署信息中所新增的部分，在第二部署信息的对应位置处进行标注，利用第二标识将第一部署信息相比于第二部署信息所删除的部分，在第二部署信息的原有位置处进行标注。其中，可以设定第一标识为下划线，第二标识为中划线。当然，也可以设定第一标识为红色，第二标识为蓝色，对此本发明不作限定，在具体的实施例中，本领域的技术人员可以根据实际需要进行设定。

[0047] 另外，以第一部署信息为目标、第二部署信息为源，将差异信息在第一部署信息中进行标注的方法与上述示出的以第一部署信息为目标、第二部署信息为源，将差异信息在第二部署信息中进行标注的方法类似，相关之处，可参考在第二部署信息中进行标注的描述，这里不再赘述。

[0048] 为了对该步骤进行更好的说明，下面以某一应用的一服务下的AppConfig资源为例给出一个具体的示例。该应用上次发布成功时AppConfig资源的第一部署信息为“Host：0.0.0.0 Port：18822”，用户将AppConfig资源的第一部署信息修改为了“Host：127.0.0.1 Port：18822”，则以修改后的AppConfig资源的第二部署信息“Host：127.0.0.1 Port：
18822”为目标，应用上次发布成功时AppConfig资源的第一部署信息“Host：0.0.0.0 Port：
18822”为源，在第一部署信息中进行标注后则为“Host：127.0.0.1  Port：
18822”。

[0049] 至此便将第一部署信息与第二部署信息的差异信息，在第一部署信息或第二部署信息中进行了标注，得到了标注后的第三部署信息，随后进入步骤S230，将标注后的第三部署信息发送至审核端，以便审核端依据该第三部署信息对所修改的服务（即部署信息发生变化的服务）的部署信息进行审核。具体地，在审核端，可以由审核人员来基于标注后的第三部署信息，对所修改的服务的部署信息进行审核，并在审核通过后发送审核成功的消息至计算设备。

[0050] 对于计算设备而言，当接收到审核端发送的审核成功消息后，则进入步骤S240，将第三部署信息发送至服务部署服务器，以便服务部署服务器依据第三部署信息对应用中所修改的服务进行重新部署。可见，本发明只有审核成功后，才会将部署信息发送至服务部署服务器，因此能够保证应用部署信息的准确性，进而可以降低应用发布的出错率。

[0051] 具体地，对于服务部署服务器而言，当其接收到计算设备发送的第三部署信息后，首先获取应用中所修改的各个服务的标注后的部署信息。然后，根据所修改的各个服务的标注后的部署信息，对所修改的各个服务进行重新部署。

[0052] 其中，针对任一所修改的服务，可通过如下步骤来对其进行重新部署。首先，基于该服务标注后的部署信息，获取该服务中所修改的各个资源的标注后的部署信息。然后，根据所修改的各个资源的标注后的部署信息，对所修改的各个资源进行重新部署，从而便完成了对该服务的重新部署。

[0053] 根据本发明的一个实施例，在对任一所修改的资源进行部署时，可以通过容器集群来对其进行部署。因此，可以首先在服务部署服务器中搭建容器集群环境。具体地，容器集群环境可以为Kubernetes（开源容器集群管理系统，用于部署、扩展和管理容器化应用程序）、Docker‑Compose定义和运行多容器 Docker 应用程序的工具）或Docker‑SWARM（Docker 官方指定的集群管理工具）等环境，对此本发明不作限定，在具体的实施例中，本领域的技术人员可以根据实际需要进行选择。

[0054] 在服务部署服务器中搭建好容器集群环境后，则可利用容器集群来对任一所修改的资源进行部署。具体地：

[0055] 首先，利用该资源标注后的部署信息，对基于容器集群的接口参数所生成的描述文件模板进行渲染，生成容器集群可识别的描述文件。其中，在基于容器集群环境的接口参数生成描述文件模板时，可以基于模板引擎来生成。模板引擎可以采用Pongo2、Mustache、Hero、GO‑Template等，对此本发明不作限定。另外，在此作一示例，在Kubernetes容器集群环境中，生成的描述文件为YAML文件。YAML文件用于声明Kubernetes Objects，Kubernetes Objects是持久化的条目，Kubernetes使用这些条目去表示整个集群的状态，如Pod、ConfigMap、Service。关于其他容器集群的描述文件，在此不再一一说明。

[0056] 然后，基于所生成的描述文件，对该资源进行创建、更新或删除。具体地，可以通过容器集群的API（Application Programming Interface，应用程序接口）执行所生成的描述文件，来实现对该资源的创建、更新或删除，从而完成对该资源的部署。

[0057] 另外，根据本发明的一个实施例，在对任一资源进行创建、更新或删除之后，还包括检测该资源所属的服务的状态。其中，可以通过WebSocket检测该资源所属的服务的状态。进一步地，可以基于WebSocket，通过调用容器集群的检测接口来对该资源所属的服务的状态进行检测。

[0058] 若该资源所属的服务状态正常，则继续对该服务中所修改的下个资源进行重新部署。当对该服务中所修改的每个资源都部署完毕后，则继续对下个修改的服务进行部署，直至将所修改的各个服务部署完毕。此时，则完成了对该应用的部署，即发布完成。

[0059] 若该资源所属的服务状态不正常，则对已重新部署的目标服务执行回滚。具体地，首先，将对已重新部署的目标服务执行回滚的消息发送至计算设备。

[0060] 对于计算设备而言，当其接收到对目标服务执行回滚的消息后，则会将基于第一部署信息获得的目标服务的当前部署信息和基于第二部署信息获得的目标服务前一次有效部署的部署信息进行比对，来获取目标服务的当前部署信息与其前一次有效部署的部署信息的差异信息，并将所获得的差异信息，在目标服务的当前部署信息或其前一次有效部署的部署信息中进行标注。

[0061] 其中，在将所获得的差异信息，在目标服务的当前部署信息或其前一次有效部署的部署信息中进行标注时，应以目标服务的前一次有效部署的部署信息作为目标、目标服务的当前部署信息作为源，来将所获得的差异信息在目标服务的当前部署信息或其前一次有效部署的部署信息中进行标注。

[0062] 具体地，当将所获得的差异信息，在目标服务的当前部署信息中进行标注时，将目标服务的前一次有效部署的部署信息相比于其当前部署信息所新增的部分通过第一标识标注，将目标服务的前一次有效部署的部署信息相比于其当前部署信息所删除的部分通过第二标识标注。另外，将所获得的差异信息在目标服务的前一次有效部署的部署信息中进行标注的方法与在目标服务的当前部署信息中进行标注的方法类似，在此不再赘述。

[0063] 下面仍以某一应用的一服务下的AppConfig资源为例给出一个具体的示例。应用上次发布成功时AppConfig资源的部署信息为“Host：0.0.0.0 Port：18822”，用户将AppConfig资源的部署信息修改为了“Host：127.0.0.1 Port：18822”。当计算设备接收到回滚消息后，则以AppConfig资源的上次有效部署的部署信息“Host：0.0.0.0 Port：18822”为目标，以AppConfig资源的当前部署信息“Host：127.0.0.1 Port：18822”为源，在当前部署信息中进行标注后则为“Host：0.0.0.0  Port：18822”。

[0064] 在将所获得的差异信息在目标服务的当前部署信息或其前一次有效部署的部署信息中进行标注后，则得到了标注后的第四部署信息，随之计算设备则会将标注后的第四部署信息发送至服务部署服务器。

[0065] 当服务部署服务器接收到计算设备发送的标注后的第四部署信息后，则基于接收到的第四部署消息，对目标服务执行回滚。其中，在对目标服务执行回滚时，不再需要审核端进行审查。具体地：

[0066] 针对任一目标服务，基于该目标服务标注后的部署信息，获取该目标服务中所修改的各个资源的标注后的部署信息。然后，根据所修改的各个资源的标注后的部署信息，对所修改的各个资源执行回滚，从而便完成了对该目标服务的回滚。

[0067] 其中，在对任一所修改的资源执行回滚时，首先，利用该资源标注后的部署信息，对基于容器集群的接口参数所生成的描述文件模板进行渲染，生成容器集群可识别的描述文件。然后，基于所生成的描述文件，对该资源进行创建、更新或删除，从而完成对该资源的回滚。

[0068] 需要说明的是，对目标服务执行回滚的方法与对服务进行部署的方法类似，具体地可参见上述对应用中所修改的服务进行重新部署的方法，在此不再赘述。

[0069] 至此可见，本发明是基于正向获取的两次部署的差异信息（以应用当前的部署信息为目标、上次有效部署的部署信息为源），来对所修改的资源进行重新部署，从而实现对应的重新部署。其中，若部署时中途检测出异常，则基于反向获取的已重新部署的服务的两次部署的差异信息（以已重新部署的服务的当前部署信息为源、上次有效部署的部署信息为目标），来对已重新部署的资源执行回滚，从而实现对应用的回滚。显然，本发明基于相邻两次部署的差异信息，仅需通过小量更新便能实现应用的重新部署和回滚，方便快捷。

[0070] 为了更好的说明本发明的完整实现过程，下面将结合图5通过一个具体示例来对本发明的应用部署方法的整个过程进行说明。其中，在该示例中用户通过服务部署信息表单对应用的服务A、服务B和服务C的部署信息进行了修改。具体地，对于应用服务A，用户是修改了其ConfigMap Objects和 Pod Objects两个资源。另外，在本示例中，服务部署服务器中搭建的容器集群为Kubernetes，其是一个开源的用于管理云平台中多个主机上的容器化的应用。基于Kubernetes的接口参数生成的描述文件模板为Kubernetes Objects，其是持久化的条目，Kubernetes使用这些条目表示整个集群的状态，如Pod、ConfigMap和Service。接下来，对应用的部署方法进行说明。

[0071] 第一步：当监听到部署事件时，获取应用当前所有服务的部署信息，并生成其快照。

[0072] 第二步：获取应用上次有效部署时的所有服务的部署信息的快照，并将应用当前所有服务的部署信息的快照作为目标、应用上次有效部署时的所有服务的部署信息的快照作为源，正向获取这两次部署信息的修改差异。

[0073] 第三步：将获取到的修改差异在应用上次有效部署时的部署信息的快照中进行标注，并将标注后的部署信息发送给审核端进行审核。

[0074] 第四步：如果审核不通过，则通知用户通过表单重新修改服务的部署信息。如果审查通过，则进入Kubernetes Objects阶段，首先使用服务A中的ConfigMap Objects资源的标注后的部署信息渲染Kubernetes Objects模板，生成YAML文件。其中，在Kubernetes 8中YAML文件用来声明Kubernetes Objects。

[0075] 第五步：通过Kubernetes API Server执行YAML文件，实现对ConfigMap Objects资源的更新。

[0076] 第六步：通过WebSocket检查服务A的状态。如果不正常，则执行回滚，并记录回滚消息。如果正常，则继续对服务A中的下个Pod Objects资源进行更新（与对ConfigMap Objects资源的更新方法类似）。

[0077] 第七步：继续通过WebSocket检查服务A的状态。如果不正常，则执行回滚，并记录回滚消息。如果正常则继续对服务B和服务C进行部署（与部署服务A的方法类似），当服务B和服务C都部署完后，则发布完成，并记录发布信息。

[0078] 其中，关于本实施例的应用部署方法的具体细节可以参考上述基于图1至图4的描述，在此不再赘述。

[0079] 为了更好的理解本发明的应用部署方法，本发明结合图6又给出了四个实施例。其中，需说明的是，该四个示例都是以一个资源为例进行的说明。

[0080] （一）首次发布时创建配置

[0081] 第一步：用户通过服务部署信息表单创建配置（如下），并申请部署。

[0082]

[0083] 第二步：当监听到部署事件时，创建新的部署快照new，并缓存上次有效部署时的部署快照old，如下：

[0084]

[0085] 第三步：将上次有效部署时的部署快照作为源，本次部署快照作为目标，获取两次部署的差异信息（即计算变更集），并将差异信息进行标注，其中下划线代表新增，中划线代表删除，如下。另外，将标注后的部署信息发送至审核人员。

[0086]

[0087] 第四步：当接收到审核人员发送的审查通过消息后进入Kubernetes Objects模板阶段，使用标注后的部署信息渲染Kubernetes Objects模板，生成YAML文件，如下：

[0088]

[0089] 第五步：通过Kubernetes API Server执行YAML文件，进行Kubernetes Objects的创建。

[0090] 第六步：通过WebSocket检查服务状态，状态是Running（即正常），则完成了对配置的创建，即完成了发布。

[0091] 第七步：记录发布状态。

[0092] （二）修改配置

[0093] 第一步：用户通过服务部署信息表单修改配置（如下），并申请部署。

[0094]

[0095] 第二步：当监听到部署事件时，创建新的部署快照new，并缓存上次有效部署时的部署快照old，如下：

[0096]

[0097] 第三步：将上次有效部署时的部署快照作为源，本次部署快照作为目标，获取两次部署的差异信息（即计算变更集），并将差异信息进行标注，其中下划线代表新增，中划线代表删除，如下。另外，将标注后的部署信息发送至审核人员。

[0098]

[0099] 第四步：当接收到审核人员发送的审查通过消息后进入Kubernetes Objects模板阶段，使用标注后的部署信息渲染Kubernetes Objects模板，生成YAML文件，如下：

[0100]

[0101] 第五步：通过Kubernetes API Server执行YAML文件，进行Kubernetes Objects的更新。

[0102] 第六步：通过WebSocket检查服务状态，状态是Running（即正常），则完成了对配置的更新，即完成了发布。

[0103] 第七步：记录发布状态。

[0104] （三）删除配置

[0105] 第一步：用户通过部署信息表单修改配置（如下），并申请部署。

[0106]

[0107] 第二步：当监听到部署事件时，创建新的部署快照new，并缓存上次有效部署时的部署快照old，如下：

[0108]

[0109] 第三步：将上次有效部署时的部署快照作为源，本次部署快照作为目标，获取两次部署的差异信息（即计算变更集），并将差异信息进行标注，其中下划线代表新增，中划线代表删除，如下。另外，将标注后的部署信息发送至审核人员。

[0110]

[0111] 第四步：当接收到审核人员发送的审查通过消息后进入Kubernetes Objects模板阶段，使用标注后的部署信息渲染Kubernetes Objects模板，生成YAML文件，如下：

[0112]

[0113] 第五步：通过Kubernetes API Server执行YAML文件，进行Kubernetes Objects的删除。

[0114] 第六步：通过WebSocket检查服务状态，状态是Running（即正常），则完成了对配置的删除，即完成了发布。

[0115] 第七步：记录发布状态。

[0116] （四）修改配置失败，回滚

[0117] 第一步：用户通过部署信息表单修改配置（如下），并申请部署。

[0118]

[0119] 第二步：当监听到部署事件时，创建新的部署快照new，并缓存上次有效部署时的部署快照old，如下：

[0120]

[0121] 第三步：将上次有效部署时的部署快照作为源，本次部署快照作为目标，获取两次部署的差异信息（即计算变更集），并将差异信息进行标注，其中下划线代表新增，中划线代表删除，如下。另外，将标注后的部署信息发送至审核人员。

[0122]

[0123] 第四步：当接收到审核人员发送的审查通过消息后进入Kubernetes Objects模板阶段，使用标注后的部署信息渲染Kubernetes Objects模板，生成YAML文件，如下：

[0124]

[0125] 第五步：通过Kubernetes API Server执行YAML文件，进行Kubernetes Objects的更新。

[0126] 第六步：通过WebSocket检查服务状态，状态是Fail（即不正常），则执行回滚操作。

[0127] 第七步：将部署过程中获取两次部署的差异信息的源和目标进行调换，即将本次部署快照中已执行部分的部署快照作为源、上次有效部署时该部分的部署快照作为目标，获取两次部署的差异信息，并将该差异信息进行标注，其中下划线代表新增，中划线代表删除，如下。需要说明的是，执行回滚时，不需要将标注后的部署信息发送至审核人员进行审查。

[0128]

[0129] 第八步：进入Kubernetes Objects模板阶段，使用标注后的部署信息渲染Kubernetes Objects模板，生成YAML文件，如下：

[0130]

[0131] 第九步：通过Kubernetes API Server执行YAML文件，进行Kubernetes Objects的更新，则完成了回滚。

[0132] 第十步：记录回滚状态。

[0133] 根据本发明的应用部署方法，在对应用进行部署时，首先获取应用当前的部署信息和其前一次有效部署的部署信息的差异信息。然后，基于该差异信息，对修改的服务下的所修改的资源进行重新部署。即，本发明只需对所修改的资源进行重新部署，便能实现对应用的重新部署。并且，当对应用进行部署时，如果中途出现异常，本发明可以基于应用当前的部署信息和其前一次有效部署的部署信息，来获取已重新部署的服务的当前部署信息与其前一次有效部署的部署信息的差异信息，基于该差异信息，本发明则只需通过对已重新部署的资源执行回滚，便能实现对应用的回滚。可见，本发明在对应用进行部署和回滚时，实现了最小粒度的更新，方便快捷。

[0134] 进一步地，本发明在获取到应用当前的部署信息和其前一次有效部署的部署信息的差异信息后，会将其发送至审核端进行审核，只有审核通过后，才会基于该差异信息对应用进行重新部署。因此，本发明能够保证应用部署信息的准确性，从而可以降低应用发布的出错率。

[0135] 另外，本发明提供了一个可视化的服务部署信息界面，用户只需在该界面上填写少量的部署资料如应用名称等便可实现对应用的部署，降低了对部署人员的要求。

[0136] 这里描述的各种技术可结合硬件或软件，或者它们的组合一起实现。从而，本发明的方法和设备，或者本发明的方法和设备的某些方面或部分可采取嵌入有形媒介，例如可移动硬盘、U盘、软盘、CD‑ROM或者其它任意机器可读的存储介质中的程序代码(即指令)的形式，其中当程序被载入诸如计算机之类的机器，并被所述机器执行时，所述机器变成实践本发明的设备。

[0137] 在程序代码在可编程计算机上执行的情况下，计算设备一般包括处理器、处理器可读的存储介质(包括易失性和非易失性存储器和/或存储元件)，至少一个输入装置，和至少一个输出装置。其中，存储器被配置用于存储程序代码；处理器被配置用于根据该存储器中存储的所述程序代码中的指令，执行本发明的应用部署方法。

[0138] 以示例而非限制的方式，可读介质包括可读存储介质和通信介质。可读存储介质存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息。通信介质一般以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传递介质。以上的任一种的组合也包括在可读介质的范围之内。

[0139] 在此处所提供的说明书中，算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与本发明的示例一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

[0140] 在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

[0141] 应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。

[0142] 本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。

[0143] 本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

[0144] 此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。

[0145] 此外，所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此，具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外，装置实施例的在此所述的元素是如下装置的例子：该装置用于实施由为了实施该发明的目的的元素所执行的功能。

[0146] 如在此所使用的那样，除非另行规定，使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例，并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。

[0147] 尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。