CN113238763A - 应用部署的方法、设备、存储介质及程序产品 - Google Patents

Abstract

本发明实施例提供一种应用部署的方法、设备、存储介质及程序产品，该方法包括：获取目标应用部署任务，目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息；根据第一Chart标识信息从预设的依赖关系数据库中确定目标应用是否存在依赖应用，依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系；若确定目标应用存在依赖应用，则获取依赖应用的第二Chart标识信息；根据第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态；若确定依赖应用对应的Chart部署状态为已部署正常状态，则将目标应用部署任务通过执行器提交给Kubernetes集群。

Description

应用部署的方法、设备、存储介质及程序产品

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种应用部署的方法、设备、存储介质及程序产品。

背景技术

随着互联网、大数据及人工智能等技术领域的发展，作为这些技术领域的基础支撑，云计算技术也得到了突飞猛进地发展。由于Kubernetes具有成熟稳定的架构，无需关心底层平台的资源调度过程，所以被广泛使用在应用的部署、上线、下线、迁移、动态伸缩等常见任务中。在Kubernetes在部署应用时，需要包管理工具Helm将应用的资源描述信息预先定义并赋值然后打包成软件包Chart发布。

而在Kubernetes部署应用时，经常会出现多应用相互依赖的场景。虽然Helm自身具备依赖处理机制，能够通过文件声明的方式进行垂直依赖定义。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题，通过文件声明的方式，只能适合垂直依赖的多应用部署，不能适配更为复杂的依赖关系，导致无法高效地进行应用的部署。

发明内容

本发明实施例提供一种应用部署的方法、设备、存储介质及程序产品，用以解决现有技术中无法对依赖进行更细粒度地控制，难以适配更为复杂的应用场景的技术问题。

第一方面，本发明实施例提供一种应用部署的方法，包括：

获取目标应用部署任务，所述目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息；

根据所述第一Chart标识信息从预设的依赖关系数据库中确定所述目标应用是否存在依赖应用，所述依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系；

若确定所述目标应用存在依赖应用，则获取所述依赖应用的第二Chart标识信息；

根据所述第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态，所述状态服务器中预先存储有各预设应用对应的Chart的部署状态；

若确定所述依赖应用对应的Chart部署状态为已部署正常状态，则将所述目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。

第二方面，本发明实施例提供一种应用部署的设备，包括：

获取模块，用于获取目标应用部署任务，所述目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息；

判断模块，用于根据所述第一Chart标识信息从预设的依赖关系数据库中确定所述目标应用是否存在依赖应用，所述依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系；

所述获取模块，还用于若确定所述目标应用存在依赖应用，则获取所述依赖应用的第二Chart标识信息；

所述获取模块，还用于根据所述第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态，所述状态服务器中预先存储有各预设应用对应的Chart的部署状态；

提交模块，用于若确定所述依赖应用对应的Chart部署状态为已部署正常状态，则将所述目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。

第三方面，本发明实施例提供一种控制服务器，包括：至少一个处理器，存储器及收发器；

所述处理器、所述存储器与所述收发器通过电路互联；

所述存储器存储计算机执行指令；所述收发器，用于与依赖关系数据库、状态服务器及Kubernetes集群收发数据；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如第一方面所述的方法。

第四方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面所述的方法。

第五方面，本发明实施例提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面所述的方法。

本发明实施例提供的应用部署的方法、设备、存储介质及程序产品，通过获取目标应用部署任务，所述目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息；根据所述第一Chart标识信息从预设的依赖关系数据库中确定所述目标应用是否存在依赖应用，所述依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系；若确定所述目标应用存在依赖应用，则获取所述依赖应用的第二Chart标识信息；根据所述第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态，所述状态服务器中预先存储有各预设应用对应的Chart的部署状态；若确定所述依赖应用对应的Chart部署状态为已部署正常状态，则将所述目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。由于预先通过依赖关系数据库对各预设应用的Chart之间的依赖关系进行了集中管理，并预先通过状态服务器对各预设应用的Chart的部署状态进行了集中管理，所以在部署目标应用时，即使是存在复杂的依赖关系，也能够通过查询依赖关系数据库快速获知目标应用是否存在依赖应用，通过查询状态服务器快速查询依赖应用的部署状态，进而能够对目标应用进行高效地部署。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是可以实现本发明实施例的应用部署的方法的网络架构图；

图2是本发明一实施例提供的应用部署的方法的流程示意图；

图3是本发明另一实施例提供的应用部署的方法的流程示意图；

图4是本发明另一实施例提供的应用部署的方法中步骤202的流程示意图；

图5是本发明另一实施例提供的应用部署的方法中步骤204的流程示意图；

图6是本发明一实施例提供的应用部署的设备的结构示意图；

图7是用来实现本发明实施例的应用部署的方法的控制服务器的第一框图；

图8是用来实现本发明实施例的应用部署的方法的控制服务器的第二框图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

首先对本发明实施例所涉及的名词进行解释：

Kubernetes：简称K8s，是用8代替8个字符“ubernete”而成的缩写。Kubernetes提供了应用部署，规划，更新，维护的一种机制。用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效。

Helm：是指用于Kubernetes的包管理工具，主要用来管理软件包Chart。

Chart：Helm的软件包，采用tar格式，其中包含运行一个应用所需的所有镜像/依赖/资源定义等，还可能包含Kubernetes集群中服务定义。

为了清楚理解本申请的技术方案，首先对现有技术的方案进行详细介绍。

在Kubernetes在部署应用时，需要包管理工具Helm将应用的资源描述信息预先定义并赋值然后打包成软件包Chart发布，所以在部署应用时，需要部署应用对应的Chart。

而在Kubernetes部署应用时，经常会出现多应用相互依赖的场景。即多应用对应的Chart相互依赖的场景。例如一个应用软件的前端应用A，后端应用B和数据库应用C的Chart分别通过Kubernetes部署。而Kubernetes在部署前端应用A的Chart时，是依赖后端应用B的Chart和数据库应用C的Chart的。

现有技术中一般Helm通过文件声明的方式进行这种依赖关系定义。具体地，Helm需要通过Chart中的values.yaml文件来为依赖的Chart预先定义。如在values.yaml文件中定义出某应用的Chart依赖的Chart分别为“apache”、“mysql”和“redis”。但是现有技术中通过文件声明的方式来进行这种依赖关系定义，只能进行垂直依赖关系的定义，如应用A的Chart依赖于应用B的Chart，应用B的Chart依赖于应用C的Chart。但对于更加复杂的依赖关系，如对于交叉依赖的情况，如应用A1的Chart和应用A2的Chart均依赖于应用B的Chart，Helm是难以获知Kubernetes中已经存在的被依赖Chart的部署状态的。如Kubernetes需要部署应用A1，而应用A2已经部署，由于应用A2的Chart依赖于应用B的Chart。所以应用B的Chart也已经部署。但在A1的文件声明中虽然声明其依赖应用B的Chart，但在文件声明中并不能获知应用B的Chart已经部署了。所以文件声明的方式并不能适配更加复杂的依赖关系，进而导致无法高效地进行应用的部署。

所以面对现有技术中的技术问题时，发明人通过创造性的研究发现，可预先通过依赖关系数据库对各预设应用对应的Chart之间的依赖关系进行集中管理，并且可通过状态服务器对各预设应用对应的Chart的部署状态进行集中管理。那么在具有目标应用部署任务时，可根据目标应用对应的Chart的标识信息确定该目标应用是否存在依赖应用，若存在依赖应用，则获取依赖应用Chart的部署状态，若依赖应用Chart的部署状态为已部署正常状态，则对目标应用进行部署。若依赖应用Chart的部署状态为未部署状态，则在对依赖应用进行部署后，再对目标应用进行部署。由于预先通过依赖关系数据库对各预设应用对应的Chart之间的依赖关系进行了集中管理，并预先通过状态服务器对各预设应用对应的Chart的部署状态进行了集中管理，所以在部署目标应用时，即使是存在复杂的依赖关系，也能够通过查询依赖关系数据库快速获知目标应用是否存在依赖应用，通过查询状态服务器快速查询依赖应用的部署状态，进而能够对目标应用进行高效地部署。

所以发明人基于上述的创造性发现，提出了本发明实施例的技术方案。下面对本发明实施例提供的应用部署的方法的网络架构进行介绍。本实施例中提供的应用部署的方法的网络架构中包括：控制服务器1，依赖关系数据库2，状态服务器3、Kubernetes集群4、Helm数据库5及镜像数据库6。其中，控制服务器1分别与依赖关系数据库2、状态服务器3及Kubernetes集群4通信连接。状态服务器3与Kubernetes集群4通信连接，Kubernetes集群4与Helm数据库5及镜像数据库6通信连接。在依赖关系数据库2中预先存储有各预设应用的Chart之间的依赖关系。状态服务器3监测Kubernetes集群4中对各预设应用的Chart的部署状态，并对各预设应用的Chart的部署状态进行存储及更新。在Helm数据库5中预先存储有各预设应用的Chart。在镜像数据库6中预先存储有各应用对应的应用镜像。则控制服务器1获取目标应用部署任务，在目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息。控制服务器1根据第一Chart标识信息从依赖关系数据库2中确定目标应用是否存在依赖应用。控制服务器1若确定目标应用存在依赖应用，则从状态服务器3中获取依赖应用对应的Chart的部署状态。如图1所示，若控制服务器确定依赖应用对应的Chart部署状态为已部署正常状态，则将目标应用部署任务通过执行器提交给Kubernetes集群4。Kubernetes集群4从Helm数据库5中获取目标应用对应的Chart，及镜像数据库6中获取目标应用对应的应用镜像，并启动应用镜像，以完成对目标应用的部署。

可以理解的是，若控制服务器确定依赖应用对应的Chart部署状态为未部署状态，则将依赖应用部署任务通过执行器提交到Kubernetes集群4，Kubernetes集群4对依赖应用进行部署后，再进行目标应用的部署。

下面以具体地实施例对本发明的技术方案以及本发明的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。

实施例一

图2是本发明一实施例提供的应用部署的方法的流程示意图，如图2所示，本实施例提供的应用部署的方法的执行主体为应用部署的设备，应用部署的设备位于控制服务器中，则本实施例提供的应用部署的方法包括以下步骤：

步骤101，获取目标应用部署任务，目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息。

本实施例中，终端设备可向控制服务器发送目标应用部署任务，控制服务器获取到目标应用部署任务。控制服务器对目标应用部署任务进行解析，获取到目标应用对应的Chart标识信息。目标应用对应的Chart标识信息为第一Chart标识信息。

其中，目标应用为需要部署的应用。Chart标识信息可以包括：Chart的名称及版本信息，或者其他能够表示唯一的Chart的信息，本实施例中对此不作限定。

步骤102，根据第一Chart标识信息从依赖关系数据库中确定目标应用是否存在依赖应用。

其中，依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系。

本实施例中，预先在依赖关系数据库中存储有各个预设应用对应的Chart的依赖关系。控制服务器可向依赖关系数据库发送依赖关系查询请求，在依赖关系查询请求中包括：第一Chart标识信息。依赖关系数据库根据第一Chart标识信息查询目标应用对应的Chart是否存在依赖的Chart，若确定目标应用对应的Chart存在依赖的Chart，则确定目标应用存在依赖应用。反之，若确定目标应用对应的Chart不存在依赖的Chart，则确定目标应用不存在依赖应用。

步骤103，若确定目标应用存在依赖应用，则获取依赖应用的第二Chart标识信息。

本实施例中，在依赖关系数据库存储各个预设应用对应的Chart的依赖关系时，存储有每个预设应用对应的Chart的标识信息，所以在确定出目标应用对应的依赖应用后，从依赖关系数据库中获取到依赖应用对应的Chart标识信息。

其中，依赖应用对应的Chart标识信息表示为第二Chart标识信息。

步骤104，根据第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态。

其中，状态服务器中预先存储有各预设应用对应的Chart的部署状态。

本实施例中，在状态服务器中预先对各预设应用的Chart的部署状态进行了存储。所以控制服务器可向状态服务器发送部署状态查询请求。在部署状态查询请求中包括：第二Chart标识信息。以使状态服务器根据部署状态查询请求中的第二Chart标识信息查询目标应用对应的依赖应用Chart的部署状态，并将依赖应用对应的Chart的部署状态发送给控制服务器。

其中，依赖应用Chart的部署状态可以为已部署正常状态、已部署异常状态、未部署状态中的任意一种。

步骤105，若确定依赖应用对应的Chart部署状态为已部署正常状态，则将目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。

本实施例中，控制服务器判断依赖应用对应的Chart部署状态是否为已部署正常状态，若确定依赖应用对应的Chart部署状态为已部署正常状态，则说明满足目标应用部署条件，则将目标应用部署任务通过执行器提交给Kubernetes集群。Kubernetes集群从Helm数据库中获取目标应用对应的Chart，并从镜像数据库中获取目标应用对应的应用镜像，并启动应用镜像，以完成对目标应用的部署。

需要说明的是，若确定依赖应用对应的Chart部署状态为未部署状态，则说明不满足目标应用部署条件，则将依赖应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对依赖应用进行部署，在依赖应用成功进行部署，满足目标应用部署条件时，将目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。

本实施例提供的应用部署的方法，通过获取目标应用部署任务，目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息；根据第一Chart标识信息从预设的依赖关系数据库中确定目标应用是否存在依赖应用，依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系；若确定目标应用存在依赖应用，则获取依赖应用的第二Chart标识信息；根据第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态，状态服务器中预先存储有各预设应用对应的Chart的部署状态；若确定依赖应用对应的Chart部署状态为已部署正常状态，则将目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。由于预先通过依赖关系数据库对各预设应用的Chart之间的依赖关系进行了集中管理，并预先通过状态服务器对各预设应用的Chart的部署状态进行了集中管理，所以在部署目标应用时，即使是存在复杂的依赖关系，也能够通过查询依赖关系数据库快速获知目标应用是否存在依赖应用，通过查询状态服务器快速查询依赖应用的部署状态，进而能够对目标应用进行高效地部署。

实施例二

图3是本发明另一实施例提供的应用部署的方法的流程示意图，如图3所示，本实施例提供的应用部署的方法在本发明实施例一的基础上，对步骤102，步骤104的进一步细化，并且还包括了其他步骤，则本实施例提供的应用部署的方法包括以下步骤：

步骤201，获取目标应用部署任务，目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息。

本实施例中，步骤201的实现方式与本发明实施例一中的步骤101的实现方式类似，在此不再一一赘述。

步骤202，根据第一Chart标识信息从预设的依赖关系数据库中确定目标应用是否存在依赖应用，若是，则执行步骤203，否则执行步骤206。

其中，依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系。

作为一种可选实施方式，本实施例中，如图4所示，步骤202包括以下步骤：

步骤2021，向依赖关系数据库发送依赖关系查询请求，依赖关系查询请求中包括：第一Chart标识信息。

其中，依赖关系查询请求用于指示依赖关系数据库查询是否存在第一Chart标识信息所依赖的Chart标识信息。

本实施例中，依赖关系数据库在存储各预设应用对应的Chart之间的依赖关系时，可通过各预设应用对应的Chart的标识信息表示各预设应用对应的Chart，用指针指向表示依赖关系。如“A—>B—>C”表示的是Chart A依赖于Chart B,Chart B依赖于Chart C。

本实施例中，控制服务器向依赖关系数据库发送依赖关系查询请求，在依赖关系查询请求中包括：第一Chart标识信息。依赖关系数据库根据第一Chart标识信息对已存储的依赖关系进行遍历，判断是否存在包括第一Chart标识信息的依赖关系。若确定存在包括第一Chart标识信息的依赖关系，则依赖关系数据库继续判断是否存在第一Chart标识信息所依赖的Chart标识信息，即第一Chart标识信息是否存在指针指向的Chart标识信息。若确定存在第一Chart标识信息所依赖的Chart标识信息，则生成依赖关系查询结果，在依赖关系查询结果中包括第一Chart标识信息所依赖的Chart标识信息。若不存在第一Chart标识信息所依赖的Chart标识信息，则生成的依赖关系查询结果中可以不包括任何Chart标识信息。

步骤2022，接收依赖关系数据库发送的依赖关系查询结果。

步骤2023，若确定依赖关系查询结果中包括第一Chart标识信息所依赖的Chart标识信息，则确定目标应用存在依赖应用。

步骤2024，若确定依赖关系查询结果中不包括任何Chart标识信息，则确定目标应用不存在依赖应用。

本实施例中，控制服务器对依赖关系查询结果进行解析，若在依赖关系查询结果中包括除第一Chart标识信息外的其他Chart标识信息，则将该其他Chart标识信息确定为第一Chart标识信息所依赖的Chart标识信息，进而确定目标应用存在依赖应用。若在依赖关系查询结果中不包括任何Chart标识信息，则说明第一Chart标识信息没有所依赖的Chart标识信息，则确定目标应用不存在依赖应用。

步骤203，获取依赖应用的第二Chart标识信息。

本实施例中，步骤203的实现方式与本发明实施例一中的步骤103的实现方式类似，在此不再一一赘述。

步骤204，根据第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态。

其中，状态服务器中预先存储有各预设应用对应的Chart的部署状态。

作为一种可选实施方式，本实施例中，如图5所示，步骤204包括以下步骤：

步骤2041，向状态服务器发送部署状态查询请求，部署状态查询请求中包括：第二Chart标识信息，第二Chart标识信息用于指示状态服务器对对应的依赖应用的Chart部署状态进行查询。

步骤2042，接收状态服务器发送的依赖应用对应的Chart的部署状态。

本实施例中，在状态服务器中预先存储有各预设应用对应的Chart的部署状态，还存储有各预设应用的依赖关键信息。其中，依赖关键信息可以包括：服务名、服务地址、服务端口等。依赖关键信息表示目标应用对依赖应用进行依赖的关键信息，通过依赖关键信息，目标应用可访问到依赖应用，进而使目标应用能够实现部署。

具体地，本实施例中，控制服务器向状态服务器发送部署状态查询请求。状态服务器对部署状态查询请求进行解析，解析出依赖应用的第二Chart标识信息，根据第二Chart标识信息查找到依赖应用对应的Chart的部署状态，并将依赖应用对应的Chart的部署状态发送给控制服务器，控制服务器获取到依赖应用对应的Chart的部署状态。

其中，依赖应用对应的Chart的部署状态可以为已部署正常状态，已部署异常状态及未部署状态。

步骤205，若确定依赖应用对应的Chart部署状态为已部署正常状态，则从状态服务器中获取依赖应用对应的依赖关键信息，将依赖关键信息携带到目标应用部署任务中。

本实施例中，控制服务器在获取到依赖应用对应的Chart的部署状态后，对依赖应用对应的Chart的部署状态进行判断，若确定依赖应用对应的Chart部署状态为已部署正常状态，则说明满足目标应用部署条件，则控制服务器可向状态服务器发送依赖关键信息查询请求，在依赖关键信息查询请求中可包括：第二Chart标识信息。状态服务器根据第二Chart标识信息获取依赖应用对应的依赖关键信息，并发送给控制服务器，控制服务器获取到依赖关键信息，并将依赖关键信息携带到目标应用部署任务中，以能够顺利完成目标应用的部署。

步骤206，将目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。

步骤207，若确定依赖应用对应的Chart部署状态为未部署状态，则根据第二Chart标识信息确定依赖应用是否存在至少一个嵌套依赖应用，若是，则执行步骤208，否则执行步骤211。

本实施例中，由于依赖应用的Chart部署状态为未部署状态，所以不能确定依赖应用是否还存在其自身依赖的应用，即相对于目标应用来说是嵌套依赖应用，所以控制器根据第二Chart标识信息向依赖关系数据库发送依赖关系查询请求，依赖关系服务器根据第二Chart标识信息判断依赖应用是否存在嵌套依赖应用，并确定嵌套依赖应用的个数。向控制服务器发送依赖关系查询结果。控制服务器对依赖关系查询结果进行解析，确定依赖应用是否存在嵌套依赖应用，若确定存在嵌套依赖应用，解析出嵌套依赖应用的个数。

例如在依赖关系数据库中，目标应用为A，存储的A的依赖关系是：A对应的依赖应用为B，存储的B的依赖关系是：B对应的依赖应用为C，存储的C的依赖关系是：C对应的依赖应用为D，则确定依赖应用A存在两个嵌套依赖应用，分别为C和D。D为最深层次的嵌套依赖应用，C为次深层次的嵌套依赖应用。

步骤208，从状态服务器中依次获取各嵌套依赖应用对应的Chart的部署状态。

本实施例中，在步骤207中的依赖关系查询结果中若存在嵌套依赖应用，则在依赖关系查询结果中还包括嵌套依赖应用的Chart的标识信息。则控制服务器向状态服务器发送部署状态查询请求，在部署状态查询请求中包括嵌套依赖应用的Chart的标识信息，状态服务器根据嵌套依赖应用的Chart的标识信息查询各嵌套依赖应用对应的Chart的部署状态。并将各嵌套依赖应用对应的Chart的部署状态发送给控制服务器，控制服务器获取到各嵌套依赖应用对应的Chart的部署状态。

步骤209，判断至少一个嵌套依赖应用对应的Chart部署状态是否为未部署状态，若是，则执行步骤210，否则执行步骤211。

其中，各嵌套依赖应用对应的Chart的部署状态可以为已部署正常状态，已部署异常状态及未部署状态。

步骤210，从最深层次嵌套依赖应用开始依次将状态为未部署状态对应的嵌套依赖应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群依次对状态为未部署状态对应的嵌套依赖应用进行部署。

本实施例中，控制服务器对各嵌套依赖应用对应的Chart的部署状态进行解析，判断各嵌套依赖应用对应的Chart的部署状态是否为未部署状态，若确定至少一个嵌套依赖应用对应的Chart部署状态为未部署状态，则首先将最深层次的部署状态为未部署状态的嵌套依赖应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群先对最深层次的部署状态为未部署状态的嵌套依赖应用进行部署。然后将与最深层次最近邻的部署状态为未部署状态的嵌套依赖应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对与最深层次最近邻的部署状态为未部署状态的嵌套依赖应用进行部署。依次递归，直到所有部署状态为未部署状态的嵌套依赖应用部署完成为止。

示例性地，若上述举例中的嵌套依赖应用C和D的部署状态均为未部署状态，最深层次的嵌套依赖应用为D,则首先对嵌套依赖应用D进行部署，然后对次深层次的嵌套依赖应用C进行部署。

步骤211，将依赖应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对依赖应用进行部署。

本实施例中，在嵌套依赖应用成功部署完毕后，状态服务器更新各嵌套依赖应用对应的部署状态为已部署正常状态。则控制服务器检测状态服务器中嵌套依赖应用对应的Chart的部署状态均为已部署正常状态后，将依赖应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对依赖应用进行部署。

步骤212，检测状态服务器中依赖应用对应的Chart的部署状态。

步骤213，若确定依赖应用对应的Chart的部署状态为已部署正常状态，则将目标应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对目标应用部署任务进行部署。

同理，本实施例中，若依赖应用成功部署完毕后，状态服务器更新依赖应用对应的部署状态为已部署正常状态。则控制服务器检测状态服务器中依赖应用对应的Chart的部署状态为已部署正常状态后，获取依赖关键信息，携带到应用部署任务中，并将目标应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对目标应用进行部署。

步骤214，若确定依赖应用对应的Chart部署状态为已部署异常状态，则生成并显示依赖应用部署异常提示信息，根据依赖应用部署异常提示信息拒绝将目标应用部署任务通过执行器提交给Kubernetes集群。

具体地，本实施例中，在Kubernetes集群对依赖应用进行部署时，并不能保证依赖应用会被成功部署，若依赖应用不能被成功部署，则状态服务器将依赖应用对应的部署状态更新为已部署异常状态。控制服务器检测状态服务器中依赖应用对应的Chart的部署状态为部署异常状态后，生成并显示依赖应用部署异常提示信息。还可将依赖应用部署异常提示信息发送给终端设备。该依赖应用部署异常提示信息可提示用户由于依赖应用的部署异常导致目标应用不能被部署。并且由于目标应用的部署依赖于依赖应用的部署，所以为了防止目标应用部署时也会发生异常，则根据依赖应用部署异常提示信息拒绝将目标应用部署任务通过执行器提交给Kubernetes集群。在依赖应用进行成功部署，即状态服务器中的依赖应用的部署状态为已部署正常状态时，才允许继续将目标应用部署任务通过执行器提交给Kubernetes集群。

本实施例提供的应用部署的方法，若确定依赖应用对应的Chart部署状态为未部署状态时，根据第二Chart标识信息确定依赖应用是否存在至少一个嵌套依赖应用；若确定存在至少一个嵌套依赖应用，则从状态服务器中依次获取各嵌套依赖应用对应的Chart的部署状态；若确定至少一个嵌套依赖应用对应的Chart部署状态为未部署状态，则从最深层次嵌套依赖应用开始依次将状态为未部署状态对应的嵌套依赖应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群依次对状态为未部署状态对应的嵌套依赖应用进行部署；将依赖应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对依赖应用进行部署，即使在多个嵌套依赖应用均未部署时，也能够按照依赖关系一一进行部署，进而提高了目标应用部署的成功率。

本实施例提供的应用部署的方法，若确定依赖应用对应的Chart部署状态为已部署异常状态，则生成并显示依赖应用部署异常提示信息；根据依赖应用部署异常提示信息拒绝将目标应用部署任务通过执行器提交给Kubernetes集群，能够在不满足目标应用部署条件时，有效停止对目标应用进行部署。

实施例三

图6是本发明一实施例提供的应用部署的设备的结构示意图，如图6所示，本实施例提供的应用部署的设备位于控制服务器中，则本实施例提供的应用部署的设备30包括：获取模块31，判断模块32，提交模块33。

其中，获取模块31，用于获取目标应用部署任务，目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息。判断模块32，用于根据第一Chart标识信息从预设的依赖关系数据库中确定目标应用是否存在依赖应用，依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系。获取模块31，还用于若确定目标应用存在依赖应用，则获取依赖应用的第二Chart标识信息。获取模块31，还用于根据第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态，状态服务器中预先存储有各预设应用对应的Chart的部署状态。提交模块33，用于若确定依赖应用对应的Chart部署状态为已部署正常状态，则将目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。

可选地，判断模块32，具体用于：

向依赖关系数据库发送依赖关系查询请求，依赖关系查询请求中包括：第一Chart标识信息，依赖关系查询请求用于指示依赖关系数据库查询是否存在第一Chart标识信息所依赖的Chart标识信息；接收依赖关系数据库发送的依赖关系查询结果；对依赖关系查询结果进行解析；若确定依赖关系查询结果中包括第一Chart标识信息所依赖的Chart标识信息，则确定目标应用存在依赖应用。

可选地，获取模块31，在根据第二Chart标识信息获取依赖应用对应的Chart的部署状态时，具体用于：

向状态服务器发送部署状态查询请求，部署状态查询请求中包括：第二Chart标识信息，部署状态查询请求用于指示状态服务器对第二Chart标识信息对应的依赖应用的Chart部署状态进行查询；接收状态服务器发送的依赖应用对应的Chart的部署状态。

可选地，若确定依赖应用对应的Chart部署状态为已部署正常状态，则获取模块31，还用于：

从状态服务器中获取依赖应用对应的依赖关键信息；将依赖关键信息携带到目标应用部署任务中。

可选地，若确定依赖应用对应的Chart部署状态为未部署状态，则判断模块32，还用于根据第二Chart标识信息确定依赖应用是否存在至少一个嵌套依赖应用。获取模块31，还用于若确定存在至少一个嵌套依赖应用，则从状态服务器中依次获取各嵌套依赖应用对应的Chart的部署状态。提交模块33，还用于若确定至少一个嵌套依赖应用对应的Chart部署状态为未部署状态，则从最深层次嵌套依赖应用开始依次将状态为未部署状态对应的嵌套依赖应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群依次对状态为未部署状态对应的嵌套依赖应用进行部署；提交模块33，还用于将依赖应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对依赖应用进行部署。

可选地，本实施例提供的应用部署的设备，还包括：检测模块。

其中，检测模块，用于检测状态服务器中依赖应用对应的Chart的部署状态。提交模块33，还用于若确定依赖应用对应的Chart的部署状态为已部署正常状态，则将目标应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对目标应用部署任务进行部署。

可选地，若确定依赖应用对应的Chart部署状态为已部署异常状态，则还包括：生成模块和拒绝提交模块。

其中，生成模块，用于生成并显示依赖应用部署异常提示信息。拒绝提交模块，用于根据依赖应用部署异常提示信息拒绝将目标应用部署任务通过执行器提交给Kubernetes集群。

本实施例提供的处理进线任务的对象数量确定设备可以执行图2-图5所示方法实施例的技术方案，其实现原理和技术效果与图2-图5所示方法实施例类似，在此不再一一赘述。

实施例四

图7是用来实现本发明实施例的应用部署的方法的控制服务器的第一框图。如图7所示，本实施例提供的控制服务器40包括：存储器41，处理器42及收发器43。

处理器42、存储器41与收发器43通过电路互联；

存储器41存储计算机执行指令；收发器43，用于与依赖关系数据库、状态服务器及Kubernetes集群收发数据；

至少一个处理器42执行存储器存储的计算机执行指令，使得至少一个处理器执行上述实施例一或实施例二中的方法。

实施例五

图8是用来实现本发明实施例的应用部署的方法的控制服务器的第二框图，该控制服务器500可以为刀片式服务器、机架式服务器、塔式服务器、服务器集群等。

控制服务器500可以包括以下一个或多个组件：处理组件502，存储器504，电源组件506，多媒体组件508，音频组件510，输入/输出(I/O)接口512，传感器组件514，以及通信组件516。

处理组件502通常控制控制服务器500的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件502可以包括一个或多个处理器520来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件502可以包括一个或多个模块，便于处理组件502和其他组件之间的交互。例如，处理组件502可以包括多媒体模块，以方便多媒体组件508和处理组件502之间的交互。

存储器504被配置为存储各种类型的数据以支持在控制服务器500的操作。这些数据的示例包括用于在控制服务器500上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器504可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件506为控制服务器500的各种组件提供电力。电源组件506可以包括电源管理系统，一个或多个电源，及其他与为控制服务器500生成、管理和分配电力相关联的组件。

多媒体组件508包括在控制服务器500和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件508包括一个前置摄像头和/或后置摄像头。当控制服务器500处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件510被配置为输出和/或输入音频信号。例如，音频组件510包括一个麦克风(MIC)，当控制服务器500处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器504或经由通信组件516发送。在一些实施例中，音频组件510还包括一个扬声器，用于输出音频信号。

I/O接口512为处理组件502和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件514包括一个或多个传感器，用于为控制服务器500提供各个方面的状态评估。例如，传感器组件514可以检测到控制服务器500的打开/关闭状态，组件的相对定位，例如组件为控制服务器500的显示器和小键盘，传感器组件514还可以检测控制服务器500或控制服务器500一个组件的位置改变，用户与控制服务器500接触的存在或不存在，控制服务器500方位或加速/减速和控制服务器500的温度变化。传感器组件514可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件514还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件514还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件516被配置为便于控制服务器500和其他设备之间有线或无线方式的通信。控制服务器500可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件516经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件516还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，控制服务器500可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器504，上述指令可由控制服务器500的处理器520执行以完成上述方法。例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

一种非临时性计算机可读存储介质，当该存储介质中的指令由控制服务器的处理器执行时，使得控制服务器能够执行上述实施例一或实施例二中提供的方法。

在示例性实施例中，还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行上述实施例一或实施例二中提供的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本发明旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。

Claims (17)

1.一种应用部署的方法，其特征在于，包括：

获取目标应用部署任务，所述目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息；

根据所述第一Chart标识信息从预设的依赖关系数据库中确定所述目标应用是否存在依赖应用，所述依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系；

若确定所述目标应用存在依赖应用，则获取所述依赖应用的第二Chart标识信息；

根据所述第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态，所述状态服务器中预先存储有各预设应用对应的Chart的部署状态；

若确定所述依赖应用对应的Chart部署状态为已部署正常状态，则将所述目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一Chart标识信息从预设的依赖关系数据库中确定所述目标应用是否存在依赖应用，包括：

向依赖关系数据库发送依赖关系查询请求，所述依赖关系查询请求中包括：第一Chart标识信息，所述依赖关系查询请求用于指示所述依赖关系数据库查询是否存在第一Chart标识信息所依赖的Chart标识信息；

接收依赖关系数据库发送的依赖关系查询结果；

对所述依赖关系查询结果进行解析；

若确定所述依赖关系查询结果中包括第一Chart标识信息所依赖的Chart标识信息，则确定所述目标应用存在依赖应用。

3.根据权利要求1所述的方法，其特征在于，所述根据所述第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态，包括：

向状态服务器发送部署状态查询请求，所述部署状态查询请求中包括：第二Chart标识信息，所述部署状态查询请求用于指示所述状态服务器对第二Chart标识信息对应的依赖应用的Chart部署状态进行查询；

接收所述状态服务器发送的依赖应用对应的Chart的部署状态。

4.根据权利要求3所述的方法，其特征在于，所述若确定所述依赖应用对应的Chart部署状态为已部署正常状态，则还包括：

从所述状态服务器中获取依赖应用对应的依赖关键信息；

将所述依赖关键信息携带到所述目标应用部署任务中。

5.根据权利要求1所述的方法，其特征在于，若确定所述依赖应用对应的Chart部署状态为未部署状态，则还包括：

根据所述第二Chart标识信息确定所述依赖应用是否存在至少一个嵌套依赖应用；

若确定存在至少一个嵌套依赖应用，则从状态服务器中依次获取各嵌套依赖应用对应的Chart的部署状态；

若确定至少一个嵌套依赖应用对应的Chart部署状态为未部署状态，则从最深层次嵌套依赖应用开始依次将状态为未部署状态对应的嵌套依赖应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群依次对状态为未部署状态对应的嵌套依赖应用进行部署；

将依赖应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对依赖应用进行部署。

6.根据权利要求5所述的方法，其特征在于，所述将依赖应用部署任务通过执行器提交到Kubernetes集群之后，还包括：

检测状态服务器中依赖应用对应的Chart的部署状态；

若确定依赖应用对应的Chart的部署状态为已部署正常状态，则将目标应用部署任务通过所述执行器提交到Kubernetes集群，以使Kubernetes集群对所述目标应用部署任务进行部署。

7.根据权利要求1-6任一项所述的方法，其特征在于，若确定所述依赖应用对应的Chart部署状态为已部署异常状态，则还包括：

生成并显示依赖应用部署异常提示信息；

根据所述依赖应用部署异常提示信息拒绝将所述目标应用部署任务通过执行器提交给Kubernetes集群。

8.一种应用部署的设备，其特征在于，包括：

获取模块，用于获取目标应用部署任务，所述目标应用部署任务中包括：目标应用对应的第一软件包Chart标识信息；

判断模块，用于根据所述第一Chart标识信息从预设的依赖关系数据库中确定所述目标应用是否存在依赖应用，所述依赖关系数据库中预先存储有各预设应用对应的Chart之间的依赖关系；

所述获取模块，还用于若确定所述目标应用存在依赖应用，则获取所述依赖应用的第二Chart标识信息；

所述获取模块，还用于根据所述第二Chart标识信息从预设的状态服务器中获取依赖应用对应的Chart的部署状态，所述状态服务器中预先存储有各预设应用对应的Chart的部署状态；

提交模块，用于若确定所述依赖应用对应的Chart部署状态为已部署正常状态，则将所述目标应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群对目标应用进行部署。

9.根据权利要求8所述的设备，其特征在于，所述判断模块，具体用于：

向依赖关系数据库发送依赖关系查询请求，所述依赖关系查询请求中包括：第一Chart标识信息，所述依赖关系查询请求用于指示所述依赖关系数据库查询是否存在第一Chart标识信息所依赖的Chart标识信息；

接收依赖关系数据库发送的依赖关系查询结果；

对所述依赖关系查询结果进行解析；

若确定所述依赖关系查询结果中包括第一Chart标识信息所依赖的Chart标识信息，则确定所述目标应用存在依赖应用。

10.根据权利要求8所述的设备，其特征在于，所述获取模块，在根据所述第二Chart标识信息获取依赖应用对应的Chart的部署状态时，具体用于：

向状态服务器发送部署状态查询请求，所述部署状态查询请求中包括：第二Chart标识信息，所述部署状态查询请求用于指示所述状态服务器对第二Chart标识信息对应的依赖应用的Chart部署状态进行查询；

接收所述状态服务器发送的依赖应用对应的Chart的部署状态。

11.根据权利要求10所述的设备，其特征在于，若确定所述依赖应用对应的Chart部署状态为已部署正常状态，则所述获取模块，还用于：

从所述状态服务器中获取依赖应用对应的依赖关键信息；

将所述依赖关键信息携带到所述目标应用部署任务中。

12.根据权利要求8所述的设备，其特征在于，若确定所述依赖应用对应的Chart部署状态为未部署状态，则所述判断模块，还用于根据所述第二Chart标识信息确定所述依赖应用是否存在至少一个嵌套依赖应用；

所述获取模块，还用于若确定存在至少一个嵌套依赖应用，则从状态服务器中依次获取各嵌套依赖应用对应的Chart的部署状态；

所述提交模块，还用于若确定至少一个嵌套依赖应用对应的Chart部署状态为未部署状态，则从最深层次嵌套依赖应用开始依次将状态为未部署状态对应的嵌套依赖应用部署任务通过执行器提交给Kubernetes集群，以使Kubernetes集群依次对状态为未部署状态对应的嵌套依赖应用进行部署；

所述提交模块，还用于将依赖应用部署任务通过执行器提交到Kubernetes集群，以使Kubernetes集群对依赖应用进行部署。

13.根据权利要求12所述的设备，其特征在于，还包括：

检测模块，用于检测状态服务器中依赖应用对应的Chart的部署状态；

所述提交模块，还用于若确定依赖应用对应的Chart的部署状态为已部署正常状态，则将目标应用部署任务通过所述执行器提交到Kubernetes集群，以使Kubernetes集群对所述目标应用部署任务进行部署。

14.根据权利要求8-13任一项所述的设备，其特征在于，若确定所述依赖应用对应的Chart部署状态为已部署异常状态，则还包括：

生成模块，用于生成并显示依赖应用部署异常提示信息；

拒绝提交模块，用于根据所述依赖应用部署异常提示信息拒绝将所述目标应用部署任务通过执行器提交给Kubernetes集群。

15.一种控制服务器，其特征在于，包括：至少一个处理器，存储器及收发器；

所述处理器、所述存储器与所述收发器通过电路互联；

所述存储器存储计算机执行指令；所述收发器，用于与依赖关系数据库、状态服务器及Kubernetes集群收发数据；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求1-7任一项所述的方法。

16.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1-7任一项所述的方法。

17.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1-7任一项所述的方法。

Images