一种应用部署方法及装置

本申请涉及计算机技术领域，具体而言，涉及一种应用部署方法及装置。

云资源主要是通过虚拟化技术，被打包成不同类型的虚拟机去服务用户。云容器的出现为云资源的配置提供了另一种轻便灵活的方式。现有的基于云容器的应用部署方法，通常需要开发人员多次提交工单申请，每个工单申请都要经过不同负责人进行层层审批，全部审批通过时，再进行应用部署步骤。然而，在实践中发现，现有的应用部署方法，一次应用部署，需要多次提交各种工单申请且需要层层审批，整个流程节点多，持续时间长,导致应用部署效率低，且容易产生遗漏。可见，现有的应用部署方法效率低，且容易产生遗漏。

本申请实施例的目的在于提供一种应用部署方法及装置，只需要一次申请，就能够实现应用的部署，不需要层层审批，部署效率高，不容易产生遗漏。

本申请实施例第一方面提供了一种应用部署方法，包括：

接收针对目标应用的部署申请；

当所述部署申请通过审核时，采用预设的统一部署模板构建所述目标应用的部署数据；

根据所述部署数据对所述目标应用进行启动运行，以完成所述目标应用的部署操作。

在上述实现过程中，在进行目标应用的部署时，先接收针对目标应用的部署申请，并且当部署申请通过审核时，采用预设的统一部署模板构建目标应用的部署数据；然后再根据部署数据对目标应用进行启动运行，以完成目标应用的部署操作，只需要一次申请，就能够实现应用的部署，不需要层层审批，部署效率高，不容易产生遗漏。

进一步地，所述预设的统一部署模板至少包括服务应用镜像统一模板、启动脚本模板、平台部署模板。

在上述实现过程中，采用预设的统一部署模板，应用部署后即包含了日志、监控的能力，无需多次再提申请进行审核，进而有利于提升应用部署效率。

进一步地，所述采用预设的统一部署模板构建所述目标应用的部署数据，包括：

采用所述服务应用镜像统一模板，生成所述目标应用的第一层镜像数据；

为所述第一层镜像数据添加启动脚本，得到所述目标应用完整的镜像数据；

采用所述平台部署模板确定所述目标应用的部署参数，以及采用所述启动脚本模板生成所述目标应用的启动数据；

根据所述镜像数据、所述部署参数以及所述启动数据，生成所述目标应用的部署数据。

在上述实现过程中，实现了容器化平台应用的标准化、统一化，减少了应用的运维成本。

进一步地，所述采用所述服务应用镜像统一模板，生成所述目标应用的第一层镜像数据，包括：

获取基础镜像数据以及所述目标应用的开发数据；

采用所述服务应用镜像统一模板、所述基础镜像数据以及所述开发数据，生成所述目标应用的第一层镜像数据。

在上述实现过程中，采用服务应用镜像统一模板，一套模板适配所有应用，实现了容器化平台应用的标准化、统一化，减少了应用的运维成本。

进一步地，所述采用所述启动脚本模板为所述第一层镜像数据添加启动脚本，得到所述目标应用完整的镜像数据，包括：

获取启动脚本文件、下线脚本文件和实时监控接口文件；

将所述启动脚本文件、所述下线脚本文件以及所述实时监控接口文件添加至所述第一层镜像数据中，得到初处理镜像；

将所述初处理镜像中的所述启动脚本文件确定为所述目标应用的启动脚本，得到所述目标应用完整的镜像数据。

在上述实现过程中，将启动脚本文件、下线脚本文件和实时监控接口文件添加至第一层镜像数据中，并为第一层镜像数据指定启动脚本，进而得到完整的镜像数据。

进一步地，所述采用所述启动脚本模板生成所述目标应用的启动数据，包括：

根据所述启动脚本模板获取分配内存数据，并根据所述分配内存数据计算虚拟机内存数据；

根据所述部署数据确定所述目标应用的实时监控状态；

根据所述部署数据确定环境配置信息；

根据所述部署数据、所述虚拟机内存数据、所述实时监控状态、所述环境配置信息生成所述目标应用的启动数据。

在上述实现过程中，启动脚本根据容器分配内存资源大小动态计算jvm内存，根据部署环境参数判断是否接入ARMS监控，以及使用的apollo环境配置，进而得到目标应用的启动数据。

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

申请接收模块，用于接收针对目标应用的部署申请；

统一构建模块，用于当所述部署申请通过审核时，采用预设的统一部署模板构建所述目标应用的部署数据；

应用部模块，用于根据所述部署数据对所述目标应用进行启动运行，以完成所述目标应用的部署操作。

在上述实现过程中，在进行目标应用的部署时，申请接收模块先接收针对目标应用的部署申请，并且统一构建模块在当部署申请通过审核时，采用预设的统一部署模板构建目标应用的部署数据；然后再根据部署数据对目标应用进行启动运行，以完成目标应用的部署操作，只需要一次申请，就能够实现应用的部署，不需要层层审批，部署效率高，不容易产生遗漏。

进一步地，所述预设的统一部署模板至少包括服务应用镜像统一模板、启动脚本模板、平台部署模板。

在上述实现过程中，采用预设的统一部署模板，应用部署后即包含了日志、监控的能力，无需多次再提申请进行审核，进而有利于提升应用部署效率。

本申请实施例第三方面提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本申请实施例第一方面中任一项所述的应用部署方法。

本申请实施例第四方面提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本申请实施例第一方面中任一项所述的应用部署方法。

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

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

图2为本申请实施例提供的另一种应用部署方法的流程示意图；

图3为本申请实施例提供的一种应用部署装置的结构示意图；

图4为本申请实施例提供的另一种应用部署装置的结构示意图。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

请参看图1，图1为本申请实施例提供了一种应用部署方法的流程示意图。其中，该应用部署方法包括：

S101、接收针对目标应用的部署申请。

本申请实施例中，该方法应用于基于云容器的应用部署场景中，具体应用于基于云容器的应用上线或者扩容的场景中。

本申请实施例中，云容器具体为Spring Cloud应用云容器化平台，spring cloud的应用部署在docker容器中，docker容器运行在Node节点上，由kubernetes(容器编排管理工具)进行统一管理。

本申请实施例中，kubernetes，简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署、规划、更新、维护的一种机制。

本申请实施例中，docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器或Windows机器上。

本申请实施例中，Node节点即网络连接的端点，或两条(或多条)线路的连接点。Node节点可以是处理器、控制器或工作站。Node节点随其功能不同而各不相同，它们可以通过链路互联在一起，在网络中用作控制点。

本申请实施例中，网关的网络流量会很高，为了保障网关层的稳定性，网关不接入kubernetes集，但是要确保在一般情况，网关所在节点资源使用率保持在较低水位。

本申请实施例中，部署申请为扩容申请或者上线申请等，对此本申请实施例不作限定。

本申请实施例中，当有目标应用需要部署或扩容时，则需要提交针对目标应用的部署申请，当接收到该部署申请的通过审核信息时，则执行步骤S102～步骤S103，即可完成目标应用的部署，无需开发leader和OP leader多次审核，避免了由于多次人工审核导致的失误的发生，有利于提升部署效率。

本申请实施例中，部署申请包括申请表格，其中申请表格包括业务线(即目标应用所属公司业务类型)、应用类型(即目标应用服务使用的技术类型)、Git项目URI(即项目的gitlab代码仓库地址)、CPU信息(即分配给单个容器的cpu核心数)、内存信息(即分配给单个容器的内存大小)、容器数量(即容器副本数量)。

在步骤S101之后，还包括以下步骤：

S102、当部署申请通过审核时，采用预设的统一部署模板构建目标应用的部署数据。

本申请实施例中，预设的统一部署模板至少包括服务应用镜像统一模板、启动脚本模板、平台部署模板等，对此本申请实施例不作限定。

本申请实施例中，采用预设的统一部署模板，应用部署后即包含了日志、监控的能力，无需多次再提申请进行审核，进而有利于提升应用部署效率。

本申请实施例中，服务应用镜像统一模板用于构建应用的镜像数据，一套模板适配所有应用，实现了容器化平台应用的标准化、统一化，减少了应用的运维成本。

本申请实施例中，启动脚本模板用于根据容器分配内存资源大小动态计算jvm内存，并根据部署环境参数判断是否接入ARMS监控，以及使用的apollo环境配置。

本申请实施例中，JVM是Java Virtual Machine(Java虚拟机)的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。

本申请实施例中，平台部署模板，即Kubernetes部署模板，又称为k8s deployment模板，一套模板适配所有应用，平台部署模板中指定应用的部署环境、容器占用的cpu、内存资源、镜像标识、容器副本数量等，由部署jenkins在部署时完成参数的替换。

本申请实施例中，Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。

在步骤S102之后，还包括以下步骤：

S103、根据部署数据对目标应用进行启动运行，以完成目标应用的部署操作。

本申请实施例中，应用的服务注册发现仍然采用spring cloud的原生注册发现，对已有应用的影响小。

本申请实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。

可见，实施图1描述的应用部署方法，只需要一次申请，就能够实现应用的部署，不需要层层审批，部署效率高，不容易产生遗漏。

请参看图2，图2为本申请实施例提供的另一种应用部署方法的流程示意图。如图2所示，其中，该应用部署方法包括：

S201、接收针对目标应用的部署申请。

S202、当部署申请通过审核时，获取基础镜像数据以及目标应用的开发数据。

本申请实施例中，基础镜像数据包括基础系统和java环境镜像，可以从申请表格中获取。

本申请实施例中，目标应用的开发数据包括目标应用的JAR包、ARMS监控AgentJAR包。

本申请实施例中，JAR包(Java归档，英语：Java Archive)是一种软件包文件格式，通常用于聚合大量的Java类文件、相关的元数据和资源(文本、图片等)文件到一个文件，以便开发Java平台应用软件或库。JAR包件是一种归档文件，以ZIP格式构建，以.jar为文件扩展名。

本申请实施例中，ARMS(Application Real-Time Monitoring Service，应用实时监控服务)，即ARMS应用监控，是一款应用性能管理服务，无需修改代码，只需为应用安装一个探针(即ARMS监控Agent JAR包)，ARMS就能够对应用进行全方位监控，快速定位出错接口和慢接口、重现调用参数、发现系统瓶颈，从而大幅提升应用线上问题诊断的效率。

在步骤S202之后，还包括以下步骤：

S203、采用服务应用镜像统一模板、基础镜像数据以及开发数据，生成目标应用的第一层镜像数据。

本申请实施例中，服务应用镜像统一模板即服务应用docker镜像统一模板，生成的第一层镜像数据即第一层docker镜像。

本申请实施例中，实施上述步骤S202～步骤S203，能够当部署申请通过审核时，采用服务应用镜像统一模板，生成目标应用的第一层镜像数据。

S204、获取启动脚本文件、下线脚本文件和实时监控接口文件。

本申请实施例中，启动脚本文件为entrypoint.sh，下线脚本文件为gracefulshutdown.sh，实时监控接口文件为ARMS监控Agent JAR包，即arms-agent.jar。

本申请实施例中，服务应用docker镜像统一模板，将目标应用的JAR包，启动脚本文件统一命名加入目标应用的第一层镜像数据中。

S205、将启动脚本文件、下线脚本文件以及实时监控接口文件添加至第一层镜像数据中，得到初处理镜像。

作为一种可选的实施方式，将启动脚本文件、下线脚本文件以及实时监控接口文件添加至第一层镜像数据中，得到初处理镜像，可以包括以下步骤：

将启动脚本文件entrypoint.sh通过ADD命令添加到第一层镜像数据中，得到第一处理镜像；

将下线脚本文件为gracefulshutdown.sh通过ADD命令添加到第一处理镜像中，得到第二处理镜像；

将arms-agent.jar通过ADD命令添加到第二处理镜像中，得到初处理镜像。

在上述实施方式中，ADD命令，即ADD指令，是一种计算机指令，含义为两数相加(不带进位)。

作为一种可选的实施方式，启动脚本根据容器分配内存资源大小动态计算jvm内存，根据部署环境参数判断是否接入ARMS监控，以及使用的apollo环境配置。

在步骤S205之后，还包括以下步骤：

S206、将初处理镜像中的启动脚本文件确定为目标应用的启动脚本，得到目标应用完整的镜像数据。

本申请实施例中，将初处理镜像中的启动脚本文件确定为目标应用的启动脚本，具体可以为，通过ENTRYPOINT命令指定entrypoint.sh脚本为目标应用的启动脚本。

本申请实施例中，ENTRYPOINT命令可以将CMD命令作为参数使用。在使用dockerrun命令启动容器时，可以使用entrypoint参数指定，CMD命令用于指定默认的容器主进程启动命令的。

本申请实施例中，实施上述步骤S204～步骤S206，能够为第一层镜像数据添加启动脚本，得到目标应用完整的镜像数据。

在步骤S206之后，还包括以下步骤：

S207、采用平台部署模板确定目标应用的部署参数。

本申请实施例中，平台部署模板即Kubernetes部署模板。

本申请实施例中，部署参数包括应用标识、命名空间标识、副本数量、运行环境数据、应用镜像地址、应用容器CPU资源、应用容器内存大小中的一种或者多种，对此本申请实施例不作限定。

本申请实施例中，部署参数可以从申请表格中获取。

作为一种可选的实施方式，针对有些应用的特殊需求，还提供了kustomize工具对平台部署模板进行自定义的方案，既能继承基础平台部署模板中的配置，又能根据需要自定义应用的特殊配置。

在步骤S207之后，还包括以下步骤：

S208、根据启动脚本模板获取分配内存数据，并根据分配内存数据计算虚拟机内存数据。

本申请实施例中，分配内存数据包括容器分配内存资源大小，虚拟机内存数据包括JVM内存，可以从申请表格中获取。

S209、根据部署数据确定目标应用的实时监控状态。

本申请实施例中，目标应用的实时监控状态即ARMS监控状态。

本申请实施例中，部署数据包括部署参数，可以根据部署参数确定是否接入ARMS监控(即ARMS监控状态)。

S210、根据部署数据确定环境配置信息。

本申请实施例中，环境配置信息包括apollo环境配置。

本申请实施例中，apollo环境配置，即Apollo()是分布式配置中心，能够集中化管理应用不同环境、不同集的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

本申请实施例中，通过启动脚本模板，能够动态指定JVM内存大小，并能够根据目标应用启动所在的环境动态指定系统apollo环境配置的来源。

S211、根据部署数据、虚拟机内存数据、实时监控状态、环境配置信息生成目标应用的启动数据。

本申请实施例中，实施上述步骤S208～步骤S211，能够采用启动脚本模板生成目标应用的启动数据。

S212、根据镜像数据、部署参数以及启动数据，生成目标应用的部署数据。

本申请实施例中，实施上述步骤S202～步骤S211，能够实现在部署申请通过审核时，采用预设的统一部署模板构建目标应用的部署数据。

本申请实施例中，预设的统一部署模板至少包括服务应用镜像统一模板、启动脚本模板、平台部署模板。

S213、根据部署数据对目标应用进行启动运行，以完成目标应用的部署操作。

本申请实施例中，对目标应用进行启动运行时，可以通过java-jar命令对目标应用的app.jar进行启动运行。

本申请实施例中，app.jar即目标应用的JAR包。

本申请实施例中，容器化应用与ARMS应用实时监控的结合，目标应用启动直接接入ARMS监控。

本申请实施例中，k8s启动应用容器，运行entrypoint.sh启动脚本，目标应用完成启动，进而完成目标应用的部署操作。

本申请实施例中，部署数据包括镜像数据、部署参数以及启动数据。

作为一种可选的实施方式，根据部署数据对目标应用进行启动运行，以完成目标应用的部署操作时，通过k8s部署模板中的filebeat容器的定义，完成filebeat容器对目标应用的自动部署。

可见，实施图2所描述的应用部署方法，只需要一次申请，就能够实现应用的部署，不需要层层审批，部署效率高，不容易产生遗漏。

请参看图3，图3为本申请实施例提供的一种应用部署装置的结构示意图。如图3所示，该应用部署装置包括：

申请接收模块300，用于接收针对目标应用的部署申请。

统一构建模块400，用于当部署申请通过审核时，采用预设的统一部署模板构建目标应用的部署数据。

应用部署模块500，用于根据部署数据对目标应用进行启动运行，以完成目标应用的部署操作。

本申请实施例中，对于应用部署装置的解释说明可以参照实施例1或实施例2中的描述，对此本实施例中不再多加赘述。

可见，实施图3所描述的应用部署装置，只需要一次申请，就能够实现应用的部署，不需要层层审批，部署效率高，不容易产生遗漏。

请一并参阅图4，图4是本申请实施例提供的另一种应用部署装置的结构示意图。其中，图4所示的应用部署装置是由图3所示的应用部署装置进行优化得到的。如图4所示，统一构建模块400包括：

第一子模块410，用于当部署申请通过审核时，采用服务应用镜像统一模板，生成目标应用的第一层镜像数据。

第二子模块420，用于为第一层镜像数据添加启动脚本，得到目标应用完整的镜像数据。

第三子模块430，用于采用平台部署模板确定目标应用的部署参数。

第四子模块440，用于采用启动脚本模板生成目标应用的启动数据。

第五子模块450，用于根据镜像数据、部署参数以及启动数据，生成目标应用的部署数据。

本申请实施例中，预设的统一部署模板至少包括服务应用镜像统一模板、启动脚本模板、平台部署模板。

作为一种可选的实施方式，第一子模块410包括：

第一获取单元411，用于当部署申请通过审核时，获取基础镜像数据以及目标应用的开发数据。

第一生成单元412，用于采用服务应用镜像统一模板、基础镜像数据以及开发数据，生成目标应用的第一层镜像数据。

作为一种可选的实施方式，第二子模块420包括：

第二获取单元421，用于获取启动脚本文件、下线脚本文件和实时监控接口文件。

添加单元422，用于将启动脚本文件、下线脚本文件以及实时监控接口文件添加至第一层镜像数据中，得到初处理镜像。

第一确定单元423，用于将初处理镜像中的启动脚本文件确定为目标应用的启动脚本，得到目标应用完整的镜像数据。

作为一种可选的实施方式，第四子模块440包括：

第三获取单元441，用于根据启动脚本模板获取分配内存数据，并根据分配内存数据计算虚拟机内存数据。

第二确定单元442，用于根据部署数据确定目标应用的实时监控状态；以及根据部署数据确定环境配置信息。

第二生成单元443，用于根据部署数据、虚拟机内存数据、实时监控状态、环境配置信息生成目标应用的启动数据。

本申请实施例中，对于应用部署装置的解释说明可以参照实施例1或实施例2中的描述，对此本实施例中不再多加赘述。

可见，实施图4所描述的应用部署装置，只需要一次申请，就能够实现应用的部署，不需要层层审批，部署效率高，不容易产生遗漏。

本申请实施例提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本申请实施例1或实施例2中任一项应用部署方法。

本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本申请实施例1或实施例2中任一项应用部署方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

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

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