CN113064600A - 部署应用的方法和装置 - Google Patents

Abstract

本公开披露了一种部署应用的方法和装置。所述方法应用于用户节点，所述方法包括：接收所述应用的管理节点为所述用户节点分配的部署令牌；响应于所述部署令牌，向所述管理节点发送第一请求，所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包括所述部署令牌；响应于所述部署令牌验证通过，从所述管理节点接收所述用户节点的应用部署文件；根据所述用户节点的应用部署文件，在所述用户节点处自动部署所述应用。

Description

部署应用的方法和装置

技术领域

本公开涉及应用部署领域，具体涉及一种部署应用的方法和装置。

背景技术

现有技术在用户的机器上部署应用时，需要运维人员通过访问用户的机器对该应用进行手动部署。不同用户的机器以及该机器所处的网络环境不同，由运维人员进行手动部署效率低下，且极易出错。

发明内容

有鉴于此，本公开提供一种部署应用的方法和装置，以提高应用部署效率和成功率。

第一方面，提供一种部署应用的方法，所述方法应用于用户节点，所述方法包括：接收所述应用的管理节点为所述用户节点分配的部署令牌；响应于所述部署令牌，向所述管理节点发送第一请求，所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包括所述部署令牌；响应于所述部署令牌验证通过，从所述管理节点接收所述用户节点的应用部署文件；根据所述用户节点的应用部署文件，在所述用户节点处自动部署所述应用。

第二方面，提供一种部署应用的方法，所述方法应用于所述应用的管理节点，所述方法包括：从用户节点接收第一请求，所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包含所述管理节点为所述用户节点分配的部署令牌；对所述部署令牌进行验证；响应于所述部署令牌验证通过，向所述用户节点发送所述用户节点的应用部署文件，以触发所述用户节点根据所述应用部署文件在所述用户节点处自动部署所述应用。

第三方面，提供一种部署应用的装置，所述装置位于用户节点，所述装置包括：第一接收模块，被配置为接收所述应用的管理节点为所述用户节点分配的部署令牌；第一发送模块，被配置为响应于所述部署令牌，向所述管理节点发送第一请求，所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包括所述部署令牌；第二接收模块，被配置为响应于所述部署令牌验证通过，从所述管理节点接收所述用户节点的应用部署文件；部署模块，被配置为根据所述用户节点的应用部署文件，在所述用户节点处自动部署所述应用。

第四方面，提供一种部署应用的装置，所述装置位于所述应用的管理节点，所述装置包括：第一接收模块，被配置为从用户节点接收第一请求，所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包含所述管理节点为所述用户节点分配的部署令牌；验证模块，被配置为对所述部署令牌进行验证；第一发送模块，被配置为响应于所述部署令牌验证通过，向所述用户节点发送所述用户节点的应用部署文件，以触发所述用户节点根据所述应用部署文件在所述用户节点处自动部署所述应用。

第五方面，提供一种部署应用的装置，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器被配置为执行所述可执行代码，以实现如第一方面或第二方面所述的方法。

第六方面，提供一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第二方面所述的方法。

第七方面，提供一种计算机程序产品，包括可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第二方面所述的方法。

本公开实施例提供了一种基于令牌的应用部署方案，能够在令牌的触发下自动完成应用的部署，避免了运维人员手动操作带来的效率和成功率低的问题，进而提高了应用部署的效率和成功率。此外，基于令牌的应用部署方案逻辑简单，而且非常安全。

附图说明

图1为本公开实施例提供的一系统框架示例图。

图2为本公开实施例提供的另一系统框架示例图。

图3为本公开实施例提供的又一系统框架示例图。

图4是本公开第一实施例提供的部署应用的方法的流程示意图。

图5是图4所示的方法应用于多方安全计算场景下的部署流程示例图。

图6是图4所示的方法应用于多方安全计算场景下的另一部署流程示例图。

图7是本公开第二实施例提供的部署应用的方法的流程示意图。

图8是图7所示的方法应用于多方安全计算场景下的部署流程示例图。

图9是本公开第三实施例提供的管理节点的内部结构的示例图。

图10是本公开第四实施例提供的一部署应用的装置的结构示意图。

图11是本公开第四实施例提供的另一部署应用的装置的结构示意图。

图12是本公开第四实施例提供的又一部署应用的装置的结构示意图。

具体实施方式

下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本公开一部分实施例，而不是全部的实施例。

图1是本公开实施例提供的系统架构的示例图。如图1所示，该系统可以包括管理节点110、镜像仓库120以及用户节点130。管理节点110、镜像仓库120和用户节点130可以通过网络140进行通信和数据交互。

管理节点110也可称为manager。管理节点110例如可以是一台或多个服务器或其他类型的计算机。管理节点110可以指为用户节点130提供应用部署文件的任一网络节点。在一些实施例中，管理节点110可用于对某个应用进行管理(或维护)。例如，管理节点110可用于对应用进行版本管理和/或用户管理。

版本管理例如可以是对应用的以下信息中的一种或多种进行存储、记录、添加、删除、更新：发布的各个版本的版本号、各个版本的代码(即代码管理)、各个版本的版本参数、各个版本的发布时间以及发布者。

用户在有些实施例中可称为商户，因此，本公开实施提及的用户管理有时也可称为商户管理。用户管理例如可以是对应用的以下信息中的一种或多种进行存储、记录、添加、删除、更新：用户标识(也可称为商户标识)，用户的入驻时间(如用户订购该应用的时间)，用户绑定的应用版本(即用户期望使用或用户目前正在使用的应用的版本)，以及用户的一些用户个性化参数等。

镜像仓库120可用于存储镜像。该镜像仓库120可以是公共的镜像仓库，也可以是私有的镜像仓库，如可以是阿里云的镜像仓库。由于应用可能会具有多个版本，因此，该镜像仓库120可以存储该应用的各个版本的镜像，供用户根据实际需要选择。

本公开实施例提及的应用可以指单容器应用，也可以指多容器应用。多容器应用通常能够在一项应用中支持多个应用模块(或称服务(service))，并为每个应用模块配置一个或多个容器。如果是多容器应用，镜像仓库120可以存储每个应用模块对应的容器。此外，由于一个应用模块也可以具有多个不同的版本(需要解释的是，应用的版本以及应用中的应用模块的版本是两个不同的版本；通常来讲，应用的版本确定下来，该版本的应用中的应用模块的版本也就随之确定，但本公开实施例也不限于此，同一版本的应用也可以支持不同版本的应用模块)，相应地，针对一个应用模块，镜像仓库120也可以存储该应用模块的各个版本对应的镜像。

以多方安全计算为例，多方安全计算应用至少能够支持以下应用模块：安全计算、安全发布、安全查询、安全模型等。由此可见，多方安全计算应用为一种多容器应用。

用户节点130可以指希望或正在使用该应用的用户的机器或设备。作为一个示例，用户节点130可以是真实的物理机，例如可以是服务器，普通的计算机，或者也可以是如手机、笔记本电脑等移动终端。作为另一示例，用户节点130可以是虚拟机，例如可以是能够在云上创建并运行的弹性云服务器(Elastic Cloud Server，ECS)。

在使用某项应用之前，通常需要先在用户节点130处进行应用部署。具体而言，应用的提供方的运维人员一般需要先确定用户希望部署什么版本的应用。对于多容器应用，该运维人员可能还需要确定用户希望该应用支持什么样的应用模块。等上述信息确定之后，传统的应用部署方式首先需要运维人员手动生成应用部署文件，然后到用户处或以远程登录的方式将应用部署文件拷贝和安装到用户节点130。

应用部署文件可以指docker部署文件，如docker-compose文件或k8s文件。该应用部署文件可以包含部署应用所需的各种文件或配置参数，例如可以包含应用的版本参数，用户节点需要部署的各个应用模块的配置参数(如应用模块在用户节点的存储路径，应用模块的镜像在镜像仓库中的存储位置)等。

该应用部署文件被安装到用户节点130之后，运维人员可以根据该应用部署文件，帮助用户去镜像仓库拉取该应用的镜像，并在用户节点130处运行该镜像，从而创建或更新容器。待容器创建或更新之后，该应用的部署流程。

但是，不同用户节点130处的机器(如机器的操作系统)和网络环境(如网络类型)差异较大，且不同用户对应用的版本、应用需要支持的模块的需求也存在较大差异。因此，如果按照传统的由运维人员进行手工部署的方式对用户的机器逐台进行应用部署，操作会非常复杂，效率低下且很容易出错。

上述问题在集群部署场景下显得更为突出。如图2所示，集群通常由很多的节点(或称网络节点)组成。集群可以包括主节点和从节点，主节点和从节点可以根据各节点在集群中的角色的不同而定义。以多方安全计算为例，主节点130A例如可以是提供多方安全计算服务的服务节点，从节点130例如可以是参与多方安全计算的计算节点(多方安全计算的详细介绍参见后文)。但是，本公开实施例对主节点和从节点的定义方式不限于此，本公开实施例中，主节点也可以指集群中的第一个完成某个应用部署的节点，从节点可以指在主节点的帮助下完成该应用部署的节点。

在集群部署场景中，通常需要在集群上的各个节点均部署该应用，这无疑进一步增大了运维人员的工作量。此外，即使部署同一应用，由于集群中的不同角色的节点需要完成的功能可能不同，因此不同节点上需要的部署文件可能也是不相同，这又增大了运维人员在部署过程中出错的概率。

下面结合图3，以多方安全计算为例，对传统应用部署方式存在的问题进行更为详细的举例说明。

为了便于理解，在对多方安全计算应用的部署进行介绍之前，先对多方安全计算的相关概念进行简单的介绍。

在大数据时代，多个数据持有方可以持有同一对象的数据。在这种情况下，在对该对象的数据进行数据计算时，会涉及多个数据持有方，可能需要该多个数据持有方合作才能完成该数据计算。然而，由于不同数据持有方之间出于竞争或者隐私保护方面的考虑，不能或者不愿意泄露各自持有的数据。

例如，同一个自然人可以在不同的P2P(peer-to-peer，点对点)平台借款。因此，各P2P平台均可能存储有该自然人在本平台的借款数额。当需要统计该自然人在多个P2P平台的借款总额时，往往需要联合该多个P2P平台的数据才能完成该统计计算。在这个例子中，P2P平台是数据持有方，该自然人的借款数额是数据持有方持有的数据，计算自然人借款总额为期望完成的数据计算。

又如，每个共享单车平台都可以为用户提供单车使用服务。各共享单车平台均存储有该平台每天共享单车的使用量。在希望统计共享单车在某一天的使用总量时，往往需要联合多个共享单车平台的数据完成统计计算。在这个例子中，共享单车平台是数据持有方，这一天共享单车的使用量是数据持有方持有的数据，这一天共享单车的使用总量为期望完成的数据计算。

又如，每个电子商务平台均可能存储相同或不同消费群体的消费数据。为了更好地了解消费者的习惯和选择营销活动的目标群体，往往需要联合多个电子商务平台的消费数据进行模型训练。在这个例子中，电子商务平台为数据持有方，各自记录的消费数据为数据持有方持有的数据，利用这些数据进行模型训练为期望完成的数据计算。

为了联合多个数据持有方的数据进行数据计算，同时保护该多个数据持有方的数据，多方安全计算逐渐被广泛应用。

多方安全计算可以在保护数据隐私的前提下进行通用计算。例如，多方安全计算使非互信的多个数据持有方之间可以在数据相互保密的前提下进行高效数据计算，从而做到既使用多源数据进行指定的数据计算，又保证使用过程中数据隐私不被泄漏，真正实现数据的可用而不可见。

参见图3，多方安全计算一般由一个或多个服务节点130A以及多个计算节点130B～130N(可以对应于上文介绍的多个数据持有方)共同参与。服务节点130A指的是提供多方安全计算服务的节点。例如，存在多方安全计算需求的一方可以向服务节点130A发起多方安全计算的请求，服务节点130A可以根据该请求，调度多个计算节点130B～130N共同进行多方安全计算，然后返回多方安全计算的结果。例如，某人或某企业可以向服务节点130A发起查询某人在多家银行的贷款总额。服务节点130A可以向该多家银行发起多方安全计算，并在保护各家银行的数据隐私的前提下，向查询者返回查询结果。在有些实施例中，也可以将服务节点130A称为多方安全计算应用的生产节点或产品端节点。

为了实现多方安全计算，不但需要在服务节点130A上部署多方安全计算应用，也需要在多个计算节点130B～130N上部署多方安全计算应用。此外，服务节点130A和计算节点130B～130N需要部署的应用模块通常是不同的，不同计算节点130B～130N之间需要部署的应用模块可能相同，也可能不同。

例如，服务节点130A可能需要部署的是应用中的管控模块(该管控模块例如能够发起多方安全计算，输出计算结果，并对计算节点进行管理或控制)；而计算节点130B～130N主要需要部署的是能够实现某种数据计算的计算模块，如实现安全建模的模块或实现安全统计的模块。由于不同节点需要部署的应用模块可能不同，不同节点需要安装和运行的应用部署文件可能就会不同。如果采用传统的应用部署方式(即由运维人员进行手工部署)，效率会非常低，会大大推迟多方安全计算产品上线的时间。

综上可知，无论是对单个用户节点进行应用部署，还是对集群进行应用部署，均亟需提供一种快速、高效的应用部署方式。

为了解决上述问题，本公开实施例提出一种基于令牌(token)的应用部署方式，能够实现应用的快速部署，并提高应用部署的成功率。

需要说明的是，本公开实施例提及的应用部署，可以指在用户节点对应用进行初始部署，也可以指在用户节点部署新版本应用(即对旧版本应用进行升级)。所谓应用的初始部署，例如可以是在从未部署过该应用的用户节点首次部署该应用，或者可以在之前部署过该应用但由于某种原因删除了该应用的用户节点再次部署该应用。

实施例一

图4是本公开实施例提供的部署应用的方法的流程示意图。图4的方法由用户节点和管理节点执行。用户节点例如可以是前文描述的用户节点130。管理节点例如可以是前文描述的管理节点110。该用户节点可以是独立的用户节点，也可以是集群中的某一节点。当用户节点130为集群中的某一节点时，该用户节点130可以是集群中的主节点，也可以是集群中的从节点。例如，用户节点为提供多方安全计算服务的服务节点或参与多方安全计算的计算节点。

在步骤S402，用户节点接收部署令牌。该部署令牌可以是管理节点为用户节点分配的或授权用户使用的令牌。

用户节点获取部署令牌的方式可以有多种。作为一个示例，当用户节点初始部署某个应用时，由于用户节点处还未安装该应用，管理节点无法通过应用将其为用户节点分配的部署令牌发送至用户节点。在这种情况下，管理节点或管理节点的运维人员可以通过邮件、短信等方式向用户或用户节点提供该部署令牌，以授权用户节点使用该部署令牌；或者，管理节点或管理节点的运维人员也可以通知用户到指定的云存储设备上下载该部署令牌，并告知用户可以将该部署令牌手动输入至用户节点。本公开实施例将这种令牌提供方式称为令牌的手动授权。

作为另一示例，当用户节点上安装有旧版本应用时(即用户节点部署该应用旨在对该旧版本应用进行升级)，管理节点可以与该旧版本应用进行通信，并通过该旧版本应用向用户节点发送该部署令牌。

作为又一示例，如果用户节点为集群中的从节点，且集群中的主节点已经完成了应用部署，则用户节点可以通过主节点的应用获取到该部署令牌。

在步骤S404，响应于部署令牌，用户节点向管理节点发送第一请求。换句话说，部署令牌可用于触发用户节点向管理节点发送第一请求。第一请求可用于请求获取用户节点的应用部署文件；或第一请求可用于请求下载用户节点的应用部署文件。

在步骤S406，管理节点对第一请求中包含或携带的部署令牌进行验证。如果部署令牌验证通过(如管理节点验证部署令牌有效)，则可以执行后续的步骤S408；如果验证不通过，则可以忽略该第一请求或向用户节点返回验证结果，指示部署令牌的验证失败。如果验证通过，管理节点还可以从部署令牌中解析出用户标识(可以是用户的唯一标识)，并根据该用户标识确定用户节点的应用部署文件。

在步骤S408，响应于部署令牌验证通过，管理节点向用户节点发送用户节点的应用部署文件。

在向用户节点发送用户节点的应用部署文件前，管理节点可以先生成该应用部署文件。本公开实施例对用户节点的应用部署文件的生成方式不做具体限定，例如可以由编程人员手动输入代码，或者也可以利用一个或多个模板文件自动化生成应用部署文件，这样可以简化操作，提高效率。详细描述可以参见实施例三。

在步骤S410，用户节点在接收到应用部署文件之后，可以根据该应用部署文件自动部署应用。例如，用户节点可以根据该应用部署文件，从镜像仓库(如图1中的镜像仓库120)中拉取该应用的镜像。然后，用户节点可以在用户节点处自动运行该镜像，得到该应用的容器。如果是应用的初次部署，则用户节点可以根据应用的镜像创建容器；如果是对已部署的旧版本应用进行升级，则用户节点可以根据应用的镜像更新本地已有的容器。

根据以上内容可以看出，本公开实施例提供的应用部署方案能够在令牌的触发下在用户节点处自动完成应用的部署，一定程度上避免了运维人员手动操作带来的效率和成功率低的问题。

为了便于在用户节点处自动进行应用部署，具体实现时，可以在用户节点处安装专门的帮助系统(helper)。该帮助系统可以是为了实现本公开实施例而专门为用户节点设计的一段应用程序。图4中的由用户节点执行的各个步骤实际上可以由该帮助系统执行。例如，该帮助系统可以在部署令牌的触发下自动与管理节点进行通信，获取用户节点的应用部署文件，并根据该应用部署文件，按照前文描述的方式，实现应用的自动部署。

该帮助系统可以独立于需要部署的应用而存在。例如，为了自动部署应用，用户节点可以先从管理节点下载该帮助系统，并在部署该应用前将该安装到用户节点上。当帮助系统的版本被更新时，用户节点也可以从管理节点下载该帮助系统的最新版本。

下面结合图5和图6，以多方安全计算应用的初始部署和部署升级两个场景为例，对实施例一提供的应用部署方式进行更为详细的举例说明。需要说明的是，图5和图6均是以用户节点为预先安装了帮助系统的弹性云服务器为例进行说明的。

图5示出的是在弹性云服务器上初始部署多方安全计算应用的流程。参见图5，在步骤S502～S506，用户将部署令牌手动输入至弹性云服务器130的帮助系统，以触发该帮助系统向管理节点110发送第一请求。该第一请求可用于从管理节点110下载该弹性云服务器130的应用部署文件，且该第一请求包含部署令牌。管理节点110收到第一请求之后，会先对该部署令牌进行验证；如果验证通过，则允许帮助系统将该应用部署文件下载到弹性云服务器130的存储层。接着，帮助系统可以自动运行该应用部署文件，并根据该应用部署文件中的配置，通过步骤S508～S510，从镜像仓库120拉取镜像，并在弹性云服务器130上创建容器，使得多方安全计算应用可以在该容器提供的环境中被正确地运行。

在创建容器的过程中，帮助系统还可以记录日志(log)，如可以记录哪些容器被创建成功以及创建成功的时间，或者哪些容器创建失败以及创建失败的原因等。

此外，当管理节点110发布了帮助系统的新版本之后，帮助系统还可以去管理节点110下载最新版本的帮助系统。

由此可见，本公开实施例提供的帮助系统能够在部署令牌的触发下帮助用户自动完成应用的部署。整个过程基本不需要运维人员进行复杂的手工操作，提高了应用部署的效率和成功率。

图6示出的是在该弹性云服务器上对多方安全计算应用进行升级的流程。参见图6，在步骤S602，旧版本多方安全计算应用向帮助系统发送部署令牌，以触发帮助系统对该旧版本多方安全计算应用进行升级。该部署令牌可以由旧版本多方安全计算应用直接从管理节点110处获取(管理节点110与多方安全计算应用均属于多方安全计算系统的一部分，因此二者可以直接通信)。步骤S604～步骤S614与步骤S504～步骤S514基本一致，区别在于步骤S510为创建容器，步骤S610为更新容器(即更新旧版本多方安全计算应用的容器)，其他内容可以参见图5的相关描述。

由此可见，本公开实施例提供的帮助系统能够基于令牌帮助用户自动完成应用的升级。整个过程基本不需要运维人员进行复杂的手工操作，提高了应用部署的效率和成功率。

实施例二

实施例二描述的是如何根据本公开实施例对集群进行应用部署。需要说明的是，实施例二是在假定集群的主节点已经完成了应用部署的前提下，详细描述从节点如何进行应用部署。主节点可以按照实施例一提供的应用部署方式提前进行应用部署。还需要说明的是，实施例一描述的是一种通用的应用部署方式，其既可以应用于实施例二中的主节点的应用部署，也可以应用于实施例二中的从节点的应用部署。

如图7所示，在步骤S702，主节点向管理节点发送第二请求。该第二请求可用于请求管理节点为集群的从节点分配部署令牌(部署令牌的介绍请参见实施例一)。

在步骤S704～S708，管理节点为从节点分配部署令牌，并通过主节点将该部署令牌转发至从节点。从节点在该部署令牌的触发下，执行步骤S710～S716，从而完成应用的自动部署。步骤S710～S716的描述与图4中的步骤S404～S410相互对应，可以参见实施例一的相关描述，为了简洁，此处不再详述。

作为一种可能的实现方式，集群中的从节点可以预先安装帮助系统(帮助系统的描述也请参见实施例一)。在接收到主节点的第二请求之后，管理节点首先将该从节点的部署令牌发送至主节点上的应用(由于主节点已经完成了应用部署，因此管理节点可以直接与主节点上的应用进行通信)，然后由主节点的应用将从节点的部署令牌转发至从节点的帮助系统，以触发从节点的帮助系统按照实施例一描述的方式帮助从节点自动完成应用部署。

仍以多方安全计算场景为例，参见图8，主节点130A完成多方安全计算应用的部署之后，可以通过该多方安全计算应用请求管理节点110为各个从节点130B～130N分配部署令牌，不同从节点130B～130N的部署令牌可以不同。在接收到该请求之后，管理节点110将其为各个从节点130B～130N分配的部署令牌发送至主节点130A的多方安全计算应用(步骤S802)。接着，主节点130A的多方安全计算应用可以将各个从节点130B～130N的部署令牌发送至对应的从节点上预先安装的帮助系统(步骤S804a～S804c)。从节点130B～130N的帮助系统可以在部署令牌的触发下，向管理节点110发送下载各自对应的应用部署文件的请求(步骤S806a～S806c)。在下载到应用部署文件之后，从节点130B～130N的帮助系统就可以在本地部署多方安全计算应用或对对旧版本应用进行升级(步骤S808a～S808c)。

由此可见，本公开实施例可以基于令牌，快速高效地完成应用在集群中的各个节点的自动部署，而无需运维人员进行繁琐的手工操作，提高了应用的集群部署效率和成功率。

实施例三

实施例三给出的是管理节点生成应用部署文件的方式的示例。应理解，实施例三可以应用于前文提及的任一实施例。例如，在实施例一的步骤S408之前或在实施例二的步骤S714之前，可以先基于实施例三，生成应用部署文件。下面对实施例三进行详细描述。

管理节点在向用户节点发送应用部署文件之前，需要先得到该应用部署文件。传统的应用部署文件是需要运维人员通过手动输入代码的方式生成的。例如，运维人员需要预先与用户确定用户期望部署的应用的版本。对于支持多个应用模块的应用(即多容器应用)，该运维人员可能还需要确定用户希望该应用支持什么样的应用模块。等上述信息确定之后，运维人员需要按照应用部署文件的代码格式要求手动输入代码，以生成应用部署文件。

由于不同用户期望部署的版本和应用模块可能不同，需要为每个用户提供的应用部署文件也不尽相同。假设用户希望其部署的应用能够支持5个应用模块，则在该应用对应的应用部署文件中，需要记录该5个应用模块的配置参数，则运维人员可能需要在每个应用模块对应的配置区域输入用户标识、应用模块的版本、获取该应用模块的镜像需要的公网IP、内网IP等等。手动输入上述配置参数绝非一件容易的事情，仅用户标识一项参数就可能是很长的一串数字和字母的组合，输入一旦出错，整个应用的部署就会失败。而且，上述手动输入工作存在大量的重复工作，比如，运维人员可能需要在每个应用模块的配置区域重复输入用户标识。由此可见，传统的应用部署文件生成方式不但效率很低，还非常容易出错。

为了进一步提高应用部署效率和成功率，本公开实施例提供一种基于模板的应用部署文件生成方式。下面结合图9和图10，对该生成方式进行详细描述。

如图9所示，管理节点110可以不但可以执行版本管理和用户管理(版本管理和用户管理的相关描述请参见前文中的与图1相关的内容)，还可以进一步完成模板管理。

模板管理指的是对应用部署文件的模板进行管理和维护，如对模板的存储、更新、删除、替换等。用户绑定的版本不同，管理节点110为用户绑定的模板也会相应不同。

应用部署文件的模板可以是一个完整的模板，也可以包括多个子模板。例如，假设应用支持多个应用模块，则可以为每个应用模块设置一个模板。如果一个应用模块具有多个版本，还可以为该应用模块的每个版本设置对应的模板，也就是说，一个应用模块也可以对应多个模板。

在准备应用部署文件的模板之前，可以先与用户沟通，确定用户期望部署的应用的版本以及期望该应用支持的应用模块，当用户选定期望部署的版本和应用模块之后，需要为用户提供的应用部署文件的模板也就随之确定下来。

应用部署文件的模板可以保留应用部署文件中的取值固定不变的参数。应用部署文件的模板中的取值变化的参数可以被抽取出来，制作成版本参数和/或用户个性化参数。版本参数可以包括应用部署文件中的随着版本的变化而变化的参数，如应用中的各个应用模块的版本号，各个应用模块在镜像仓库中的存放位置等。用户个性化参数可以包括用户标识、与用户通信所需的公钥和私钥等。

相应地，应用部署文件的模板中的版本参数和用户个性化参数的对应位置可以设置成变量。当管理节点准备生成应用部署文件时，直接利用用户绑定的版本的版本参数和用户个性化参数填充模板即可。所谓填充模块，可以是指利用用户绑定的版本的版本参数和用户个性化参数为模板中的变量赋值。

在一些实施例中，管理节点110确定用户绑定的版本和模板之后，可以先建立和维护三者之间的绑定关系，而暂时不生成应用部署文件，以节省存储空间。在建立三者之间的绑定关系之后，管理节点110可以为用户或用户节点分配前文提及的部署令牌，以便用户节点将该部署令牌返回管理节点110之后，根据该绑定关系为用户或用户节点生成应用部署文件。由于应用部署文件采用自动填充的方式生成，整个过程可以很快地完成。

由此可见，本公开实施例提供了一种基于模板的应用部署文件的生成方式，可以简化运维人员的操作，进一步提升应用的部署效率。

需要说明的是，前文各个实施例提及的用户节点与用户有时是可以相互替换的。比如，用户绑定的版本有时也可看成是用户节点绑定的版本。又如用户节点的应用部署文件也可以理解为是用户的应用部署文件。又如，管理节点为某个用户节点分配的部署令牌实际上可以理解为该用户节点的用户分配的部署令牌。

实施例四

上文结合图1至图9，详细描述了本公开的方法实施例，下面结合图10至图12，详细描述本公开的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

图10是本公开一实施例提供的部署应用的装置的示意性结构图。图10的装置1000可以位于(或安装在)应用的用户节点处。该装置1000可以包括第一接收单元1010，第一发送单元1020，第二接收单元1030以及部署单元1040。下面对这些单元进行详细介绍。

第一接收单元1010可以被配置为接收所述应用的管理节点为所述用户节点分配的部署令牌。

第一发送单元1020可以被配置为响应于所述部署令牌，向所述管理节点发送第一请求。所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包括所述部署令牌。

第二接收单元1030可以被配置为响应于所述部署令牌验证通过，从所述管理节点接收所述用户节点的应用部署文件。

部署单元1040可以被配置为根据所述用户节点的应用部署文件，在所述用户节点处自动部署所述应用。

可选地，所述用户节点为集群的主节点，所述装置1000还可包括：第二发送单元，被配置为向所述管理节点发送第二请求，所述第二请求用于请求所述管理节点为所述集群的从节点分配部署令牌；第三接收单元，被配置为从所述管理节点接收所述从节点的部署令牌；第三发送单元，被配置为向所述从节点转发所述从节点的部署令牌，以触发所述从节点从所述管理节点获取所述从节点的应用部署文件，并根据所述从节点的应用部署文件在所述从节点处自动部署所述应用。

可选地，所述用户节点为集群的从节点，所述第一接收单元进一步被配置为从所述集群的主节点接收所述部署令牌。

可选地，所述用户节点处安装有旧版本应用，所述部署令牌是所述旧版本应用从所述管理节点处获取的。

可选地，所述部署单元进一步被配置为根据所述用户节点的应用部署文件，从镜像仓库中拉取所述应用的镜像；在所述用户节点处运行所述应用的镜像，得到所述应用的容器。

可选地，所述应用为多方安全计算应用，所述用户节点为提供多方安全计算服务的服务节点或参与多方安全计算的计算节点。

图11是本公开另一实施例提供的部署应用的装置的示意性结构图。图11的装置1100可以位于应用的管理节点。装置1100可以包括第一接收单元1110、验证单元1120以及第一发送单元1130。下面对这些单元进行详细介绍。

第一接收单元1110可以被配置为从用户节点接收第一请求。所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包含所述管理节点为所述用户节点分配的部署令牌。

验证单元1120可以被配置为对所述部署令牌进行验证。

第一发送单元1130可以被配置为响应于所述部署令牌验证通过，向所述用户节点发送所述用户节点的应用部署文件，以触发所述用户节点根据所述应用部署文件在所述用户节点处自动部署所述应用。

可选地，所述用户节点为集群的主节点，所述部署应用的装置1110还可包括：第二接收单元，被配置为从所述主节点接收第二请求，所述第二请求用于请求所述管理节点为所述集群的从节点分配部署令牌；第二发送单元，被配置为通过所述主节点向所述从节点发送所述从节点的部署令牌，以触发所述从节点从所述管理节点获取所述从节点的应用部署文件，并根据所述从节点的应用部署文件在所述从节点处自动部署所述应用。

可选地，所述装置1110还可包括：确定单元，被配置为在所述向所述用户节点发送所述用户节点的应用部署文件之前，确定用户绑定的所述应用的版本和应用部署文件的模板；填充单元，被配置为利用所述版本的版本参数以及所述用户的个性化参数填充所述模板，以生成所述应用部署文件。

可选地，所述用户节点处安装有旧版本应用，所述部署令牌是所述旧版本应用从所述管理节点处获取的。

可选地，所述应用为多方安全计算应用，所述用户节点为提供多方安全计算服务的服务节点或参与多方安全计算的计算节点。

图12是本公开又一实施例提供的部署应用的装置的结构示意图。图12所示的装置1200可以是能够执行多方安全计算的任意网络节点。该装置1200例如可以是具有计算功能的计算设备。比如，装置1200可以是移动终端或者服务器。装置1200可以包括存储器1210和处理器1220。存储器1210可用于存储可执行代码。处理器1220可用于执行所述存储器1210中存储的可执行代码，以实现前文描述的各个方法中的步骤。在一些实施例中，该装置1200还可以包括网络接口1230，处理器1220与外部设备的数据交换可以通过该网络接口1230实现。

需要说明的是，为了进一步提高应用的部署效率和成功率，应用提供方还可以对用户节点的机器和网络环境提出统一的要求。例如，可以要求用户节点均支持centos 7.2及以上版本，并均预先安装docker环境。这样可以减少不同用户节点之间的环境差异，降低应用部署过程的环境依赖。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其他任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如数字视频光盘(Digital Video Disc，DVD))、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

本领域普通技术人员可以意识到，结合本公开实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims (20)

1.一种部署应用的方法，所述方法应用于用户节点，所述方法包括：

接收所述应用的管理节点为所述用户节点分配的部署令牌；

响应于所述部署令牌，向所述管理节点发送第一请求，所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包括所述部署令牌；

响应于所述部署令牌验证通过，从所述管理节点接收所述用户节点的应用部署文件；

根据所述用户节点的应用部署文件，在所述用户节点处自动部署所述应用。

2.根据权利要求1所述的方法，所述用户节点为集群的主节点，

所述方法还包括：

向所述管理节点发送第二请求，所述第二请求用于请求所述管理节点为所述集群的从节点分配部署令牌；

从所述管理节点接收所述从节点的部署令牌；

向所述从节点转发所述从节点的部署令牌，以触发所述从节点从所述管理节点获取所述从节点的应用部署文件，并根据所述从节点的应用部署文件在所述从节点处自动部署所述应用。

3.根据权利要求1所述的方法，所述用户节点为集群的从节点，

所述接收所述应用的管理节点为所述用户节点分配的部署令牌，包括：

从所述集群的主节点接收所述部署令牌。

4.根据权利要求1所述的方法，所述用户节点处安装有旧版本应用，所述部署令牌是所述旧版本应用从所述管理节点处获取的。

5.根据权利要求1所述的方法，所述根据所述用户节点的应用部署文件，在所述用户节点处自动部署所述应用，包括：

根据所述用户节点的应用部署文件，从镜像仓库中拉取所述应用的镜像；

在所述用户节点处运行所述应用的镜像，得到所述应用的容器。

6.根据权利要求1所述的方法，所述应用为多方安全计算应用，所述用户节点为提供多方安全计算服务的服务节点或参与多方安全计算的计算节点。

7.根据权利要求1所述的方法，所述应用部署文件为docker部署文件。

8.一种部署应用的方法，所述方法应用于所述应用的管理节点，所述方法包括：

从用户节点接收第一请求，所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包含所述管理节点为所述用户节点分配的部署令牌；

对所述部署令牌进行验证；

响应于所述部署令牌验证通过，向所述用户节点发送所述用户节点的应用部署文件，以触发所述用户节点根据所述应用部署文件在所述用户节点处自动部署所述应用。

9.根据权利要求8所述的方法，所述用户节点为集群的主节点，

所述方法还包括：

从所述主节点接收第二请求，所述第二请求用于请求所述管理节点为所述集群的从节点分配部署令牌；

通过所述主节点向所述从节点发送所述从节点的部署令牌，以触发所述从节点从所述管理节点获取所述从节点的应用部署文件，并根据所述从节点的应用部署文件在所述从节点处自动部署所述应用。

10.根据权利要求8所述的方法，在所述向所述用户节点发送所述用户节点的应用部署文件之前，所述方法还包括：

确定用户绑定的所述应用的版本和应用部署文件的模板；

利用所述版本的版本参数以及所述用户的个性化参数填充所述模板，以生成所述应用部署文件。

11.根据权利要求8所述的方法，所述用户节点处安装有旧版本应用，所述部署令牌是所述旧版本应用从所述管理节点处获取的。

12.根据权利要求8所述的方法，所述应用为多方安全计算应用，所述用户节点为提供多方安全计算服务的服务节点或参与多方安全计算的计算节点。

13.根据权利要求8所述的方法，所述应用部署文件为docker部署文件。

14.一种部署应用的装置，所述装置位于所述应用的管理节点，所述装置包括：

第一接收单元，被配置为从用户节点接收第一请求，所述第一请求用于请求所述用户节点的应用部署文件，且所述第一请求包含所述管理节点为所述用户节点分配的部署令牌；

验证单元，被配置为对所述部署令牌进行验证；

第一发送单元，被配置为响应于所述部署令牌验证通过，向所述用户节点发送所述用户节点的应用部署文件，以触发所述用户节点根据所述应用部署文件在所述用户节点处自动部署所述应用。

15.根据权利要求14所述的装置，所述用户节点为集群的主节点，

所述装置还包括：

第二接收单元，被配置为从所述主节点接收第二请求，所述第二请求用于请求所述管理节点为所述集群的从节点分配部署令牌；

第二发送单元，被配置为通过所述主节点向所述从节点发送所述从节点的部署令牌，以触发所述从节点从所述管理节点获取所述从节点的应用部署文件，并根据所述从节点的应用部署文件在所述从节点处自动部署所述应用。

16.根据权利要求14所述的装置，所述装置还包括：

确定单元，被配置为在所述向所述用户节点发送所述用户节点的应用部署文件之前，确定用户绑定的所述应用的版本和应用部署文件的模板；

填充单元，被配置为利用所述版本的版本参数以及所述用户的个性化参数填充所述模板，以生成所述应用部署文件。

17.根据权利要求14所述的装置，所述用户节点处安装有旧版本应用，所述部署令牌是所述旧版本应用从所述管理节点处获取的。

18.根据权利要求14所述的装置，所述应用为多方安全计算应用，所述用户节点为提供多方安全计算服务的服务节点或参与多方安全计算的计算节点。

19.根据权利要求14所述的装置，所述应用部署文件为docker部署文件。

20.一种部署应用的装置，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器被配置为执行所述可执行代码，以实现权利要求1-13中任一项所述的方法。

Images