CN114416109B - 程序部署方法及其装置、计算机设备、存储介质 - Google Patents

Abstract

本公开实施例提供一种程序部署方法及其装置、计算机设备、存储介质，属于软件开发技术领域，所述方法包括：获取机器仓库配置文件，根据所述机器仓库配置文件获取来自待部署目标机器的第一配置数据；获取程序仓库配置文件，根据所述程序仓库配置文件获取来自待部署程序的第二配置数据；接收程序部署请求；响应于所述程序部署请求，根据所述第一配置数据识别所述待部署目标机器；根据第二配置数据获取所述待部署程序，并将所述待部署程序发送至所述待部署目标机器以执行部署并得到部署后的目标程序；启动部署后的所述目标程序；识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果。程序部署流程依靠配置文件进行，操作简单。

Description

程序部署方法及其装置、计算机设备、存储介质

技术领域

本发明涉及软件开发技术领域，尤其涉及一种程序部署方法及其装置、计算机设备、存储介质。

背景技术

目前，行业内的程序部署工具不但资源占用高，而且需要根据具体使用场景做一定适配与调整。在使用装置时，需要用户学习一些专业技术知识才能操作，同时需要引入大量多余的组件和功能，不仅造成资源浪费，而且增加了复杂组件的学习成本和使用成本。

发明内容

本公开实施例的主要目的在于提出一种程序部署方法及其装置、计算机设备、存储介质，无需引入多余组件和功能，能够根据配置文件的配置数据完成程序的部署，无需引入多余组件和功能，使用户用较少的操作完成程序的部署，操作简单，资源占用小。

为实现上述目的，本公开实施例的第一方面提出了一种程序部署方法，所述方法包括：

获取机器仓库配置文件，根据所述机器仓库配置文件获取来自待部署目标机器的第一配置数据；

获取程序仓库配置文件，根据所述程序仓库配置文件获取来自待部署程序的第二配置数据；

接收程序部署请求；

响应于所述程序部署请求，根据所述第一配置数据识别所述待部署目标机器；

根据第二配置数据获取所述待部署程序，并将所述待部署程序发送至所述待部署目标机器以执行部署并得到部署后的目标程序；

启动部署后的所述目标程序；

识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果。

在一些实施例，所述启动部署后的所述目标程序，包括：

获取程序包命令配置文件；

根据所述程序包命令配置文件启动部署后的所述目标程序。

在一些实施例，所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果，包括：

部署后的所述目标程序在目标机器运行时，获取部署后的所述目标程序的程序日志事件配置文件；

根据所述程序日志事件配置文件获取所述目标程序的日志文件和日志信息；

根据所述日志文件和所述日志信息，获取所述目标程序的运行状态；

根据所述运行状态得到所述目标程序的识别结果。

在一些实施例，所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果，包括：

部署后的目标程序在目标机器运行时，获取部署后的所述目标程序的第一进程id；

根据所述第一进程id，获取所述目标程序的运行状态；

根据所述运行状态得到所述目标程序的识别结果。

在一些实施例，所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果，包括：

部署后的目标程序在目标机器运行时，获取部署后的所述目标程序的程序端口配置文件；

根据所述程序端口配置文件，获取所述目标程序的端口文件和端口属性信息；

根据所述端口文件和所述端口属性信息，获取所述目标程序的运行状态；

根据所述运行状态得到所述目标程序的识别结果。

在一些实施例，在所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果之后，所述方法还包括：

获取待监控程序的第二进程id；

根据所述第二进程id，获取所述程序的运行状态；

若所述程序的运行状态为宕机状态，获取系统基础配置文件；

根据所述系统基础配置文件获取第一接收方信息；

根据所述第一接收方信息，向第一接收方发送第一通知消息。

在一些实施例，在所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果之后，所述方法还包括：

根据所述程序仓库配置文件获取待监控程序的版本号；

根据所述版本号，获取所述程序的更新信息；

根据所述更新信息更新所述程序；

获取系统基础配置文件；

根据所述系统基础配置文件获取第二接收方信息；

根据所述第二接收方信息，向所述第二接收方发送第二通知消息。

本公开实施例的第二方面提出了一种程序部署装置，所述装置包括：

第一获取模块，用于获取机器仓库配置文件，根据所述机器仓库配置文件获取来自待部署目标机器的第一配置数据；

第二获取模块，用于获取程序仓库配置文件，根据所述程序仓库配置文件获取来自待部署程序的第二配置数据；

第一识别模块，用于接收程序部署请求；响应于所述程序部署请求，根据所述第一配置数据识别所述待部署目标机器；

第三获取模块，用于根据第二配置数据获取所述待部署程序，并将所述待部署程序发送至所述待部署目标机器以执行部署并得到部署后的目标程序；

程序启动模块，用于启动部署后的所述目标程序；

第二识别模块，用于识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果。

本公开实施例的第三方面提出了一种计算机设备，所述计算机设备包括存储器和处理器，其中，所述存储器中存储有程序，所述程序被所述处理器执行时所述处理器用于执行如本申请第一方面实施例任一项所述的方法。

本公开实施例的第四方面提出了一种存储介质，该存储介质为计算机可读存储介质，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行如本申请第一方面实施例任一项所述的方法。

本公开实施例提出的程序部署方法及其装置、计算机设备、存储介质，通过获取机器仓库配置文件，根据机器仓库配置文件获取来自待部署目标机器的第一配置数据，通过获取程序仓库配置文件，根据程序仓库配置文件获取来自待部署程序的第二配置数据，接收程序部署请求，响应于程序部署请求，根据第一配置数据识别待部署目标机器，根据第二配置数据获取待部署程序，并将待部署程序发送至待部署目标机器以执行部署并得到部署后的目标程序，启动部署后的目标程序，识别部署后的目标程序的运行状态，根据运行状态得到目标程序的识别结果。通过机器仓库配置文件获取第一配置数据，通过程序仓库配置文件获取第二配置数据，根据第一配置数据和第二配置数据执行程序部署，识别部署后程序的运行状态，使程序的部署依靠配置文件就能完成，无需引入多余组件和功能，用户可以用较少的操作完成程序的部署，操作简单，资源占用小。

附图说明

图1是本公开实施例提供的程序部署方法的第一流程图；

图2是图1中的步骤S160的流程图；

图3是图1中的步骤S170的第一流程图；

图4是图1中的步骤S170的第二流程图；

图5是图1中的步骤S170的第三流程图；

图6是本公开实施例提供的程序部署方法的第二流程图；

图7是本公开实施例提供的程序部署方法的第三流程图；

图8是本公开实施例提供的程序部署装置的模块结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本发明实施例的目的，不是旨在限制本发明。

目前，行业内的持续集成工具很多，也有很多成功的CI/CD(持续集成/持续交付)经验，例如Jenkins、GitLab、TeamCity、Bamboo，但这些工具存在以下缺点，一是工具流程、工具内部概念多，导致工具使用复杂，用户需要花费时间和精力学习Python、Grovvy、Docker等专业技术知识，学习成本高；二是工具在使用时需要引入大量多余组件和功能，造成资源浪费；三是工具包含过多功能，资源占用高，工具启动时即使没有做任何事也会立刻占用数百兆内存，如果考虑了负载、高可用等场景，资源占用会更高；四是工具场景契合度不足，使用行业内的通用工具需要遵循该通用工具的规范，需要根据使用场景在工具的程序内部做一定的适配与调整才能支持该工具的正常运行。

基于此，本公开实施例的主要目的在于提出一种程序部署方法，通过机器仓库配置文件识别目标机器，通过程序仓库配置文件获取待部署程序以使待部署程序在目标机器上部署，识别部署后程序的运行状态，得到部署后程序的识别结果。整个程序部署流程依靠配置文件进行，用户可以通过浏览器进行配置使用，快速把程序部署起来，操作简单，且不需要引入多余组件和功能，资源占用小。

本公开实施例提供的程序部署方法及其装置、计算机设备、存储介质，具体通过如下实施例进行说明，首先描述本公开实施例中的程序部署方法。

参照图1，根据本公开实施例第一方面实施例的程序部署方法，包括但不限于步骤S110至步骤S160。

S110，获取机器仓库配置文件，根据机器仓库配置文件获取来自待部署目标机器的第一配置数据；

S120，获取程序仓库配置文件，根据程序仓库配置文件获取来自待部署程序的第二配置数据；

S130，接收程序部署请求；

S140，响应于程序部署请求，根据第一配置数据识别待部署目标机器；

S150，根据第二配置数据获取待部署程序，并将待部署程序发送至待部署目标机器以执行部署并得到部署后的目标程序；

S160，启动部署后的目标程序；

S170，识别部署后的目标程序的运行状态，根据运行状态得到识别结果。

在步骤S110中，机器仓库配置文件采用json格式定义，命名为repository-machine.json。该机器仓库配置文件定义了程序部署过程中需要用到的待部署目标机器的ip、账号、密码，以识别目标机器，完成待部署程序在对应目标机器上的部署。第一配置数据为待部署目标机器的ip、账号、密码等。机器仓库配置文件的格式为：

在步骤S120中，与机器仓库配置文件相同，程序仓库配置文件也采用json格式定义，命名为repository-module.json。程序仓库用于管理程序，该程序仓库配置文件定义了程序部署过程中需要用到的程序仓库，配置项包括四个属性信息，分别为url、username、password、type，其中url表示程序仓库的目录，可以填写程序仓库的根目录，若填写的是程序仓库的根目录，会自动以根目录为起点扫描该仓库，向下遍历找出该根目录下的所有程序包；username表示程序仓库的账号；password表示程序仓库的密码；type表示程序仓库的类型，分为SVN和GIT两种。根据程序仓库配置文件对程序仓库进行扫描并识别出可部署的程序包，提供到web界面供用户选择。第二配置数据为程序仓库的url、username、password、type等。程序仓库配置文件的格式为：

需要说明的是，结合程序仓库配置文件和已知程序包名称配置文件，在扫描程序仓库时，若程序仓库目录树中包含该已知程序包名称，web界面提供的下拉框中会包含该已知程序包，让用户从已知程序包中选择待部署程序。通过在已知程序包名称配置文件中内置已知程序包名称，基本无需维护已知程序包名称配置文件，只需要根据实际情况添加程序仓库配置文件的配置项即可。若程序仓库中无待部署程序，可以由开发人员或用户在程序仓库配置文件和已知程序包名称配置文件中添加待部署程序的配置项。

需要进一步说明的是，已知程序包名称配置文件命名为module-name.json，用于提高程序识别的准确率，已知程序包名称配置文件格式为：

["ump-mtreceiver","cmpp2gate","centrumserver"]，其中ump-mtreceiver、cmpp2gate和centrumserver均为已知程序包的名称。

需要进一步说明的是，本公开实施例涉及的配置文件均采用json格式定义。

在步骤S140中，根据待部署目标机器的ip、账号、密码，识别待部署目标机器。

在步骤S150中，根据程序仓库的url、username、password、type从程序仓库中获取待部署程序，采用Java远程连接待部署目标机器，设置待部署程序在待部署目标机器上的部署路径、程序重命名的名称、是否在待部署目标机器上自动完成程序的更新等，将待部署程序发送至待部署目标机器在指定的部署路径进行部署，得到部署后的目标程序。

需要说明的是，在将待部署程序发送至待部署目标机器前，可以对配置文件的配置项参数进行修改。

在一些实施例中，如图2所示，步骤S160具体包括步骤：

S210，获取程序包命令配置文件；

S220，根据程序包命令配置文件启动部署后的目标程序。

在步骤S210中，程序包命令配置文件命名为module-command.json，该配置文件定义了一组程序部署过程中需要用到的程序执行命令，配置项中包括四个属性，即moduleName、type、executeDir和script。其中moduleName为程序包名称，type分为START和STOP两种，START表示为程序启动命令，STOP表示为程序停止命令，executeDir为程序启动或程序停止命令执行时需要先预跳转的目录，可以是绝对路径，也可以是相对路径。在执行启动命令前会先定位到需要启动的程序包目录，然后再切换到该路径。同样地，执行停止命令也需先定位到需要停止的程序包目录，在此不做赘述。script为该程序包命令的具体内容。当待部署程序在目标机器部署后，将根据程序包命令配置文件启停程序包。程序包命令配置文件的格式为：

在步骤S220中，若需要启动的目标程序为mtreceiver，则程序包命令配置文件中的配置项moduleName为mtreceiver，type为START，executeDir为目标程序在目标机器上的安装路径，script为启动命令的具体内容，通过执行mtreceiver.sh脚本实现目标程序的启动。

需要说明的是，script采用shell脚本实现，以控制程序的启动或停止，其中script中的sh、start为脚本的传入参数。

在一些实施例中，如图3所示，步骤S170具体包括步骤：

S310，部署后的目标程序在目标机器运行时，获取部署后的目标程序的程序日志事件配置文件；

S320，根据程序日志事件配置文件获取目标程序的日志文件和日志信息；

S330，根据日志文件和日志信息，获取目标程序的运行状态；

S340，根据运行状态得到目标程序的识别结果。

在步骤S310中，程序日志事件配置文件命名为module-recognition-log.json，该配置文件定义了程序运行过程中的日志事件，配置项中包括四个属性，即moduleName、actionType、logFile和logMsg。其中moduleName为程序包名称，actionType分为START和STOP两种，START表示为程序启动事件，STOP表示为程序停止事件，logMsg为程序启动或程序停止产生的日志内容，logFile为程序启动或程序停止产生的日志文件，当logFile中出现logMsg中的日志内容时，则表示对应actionType事件的发生。程序日志事件配置文件的格式为：

在步骤S320中，获取程序日志事件配置文件的配置项logFile和logMsg，其中logFile为日志文件，logMsg为日志信息。

在步骤S330中，读取日志文件logFile的内容，若logFile出现LogMag配置的信息，则触发相关事件。例如，若启动目标程序mtreceiver，其产生的日志文件为info.log，启动产生的日志信息为mtreceiver,Http2mtreceiver,Rest2mtreceiver server started，若info.log中出现该日志信息，则目标程序的运行状态为程序启动成功；若初始时刻目标程序的运行状态为程序启动成功，持续预设时长后，info.log中出现涉及程序停止的日志信息，则目标程序的运行状态为程序启动失败；若info.log中出现涉及宕机的日志信息，则目标程序的运行状态为程序宕机。可以理解的是，本领域技术人员可根据实际情况配置logMsg，本公开实施例不对logMsg的具体内容进行限制。

在步骤S340中，根据目标程序的不同运行状态得到不同的识别结果。若目标程序的运行状态为程序启动成功，则目标程序的识别结果为程序启动成功；若目标程序的运行状态为程序启动失败，则目标程序的识别结果为程序启动失败；若目标程序的运行状态为程序宕机，则目标程序的识别结果为程序宕机。

在一些实施例中，如图4所示，步骤S170具体包括步骤：

S410，部署后的目标程序在目标机器运行时，获取部署后的目标程序的第一进程id；

S420，根据第一进程id，获取目标程序的运行状态；

S430，根据运行状态得到目标程序的识别结果。

在步骤S410中，在linux系统上，可以采用“ps-ef|grep"<程序包名称>"|grep-vgrep|awk'{print$2}'”输出程序的进程id。

在步骤S420中，若初始时刻能够获取目标程序的第一进程id，持续预设时长后，依旧能够获取目标程序的第一进程id，则认为目标程序的运行状态为程序启动成功；若初始时刻能够获取目标程序的第一进程id，持续预设时长后，无法获取目标程序的第一进程id，则认为目标程序的运行状态为程序启动失败；若目标程序启动运行时，始终无法获取目标程序的第一进程id，则认为目标程序的运行状态为程序宕机。

在一些实施例中，如图5所示，步骤S170具体包括步骤：

S510，部署后的目标程序在目标机器运行时，获取部署后的目标程序的程序端口配置文件；

S520，根据程序端口配置文件，获取目标程序的端口文件和端口属性信息；

S530，根据端口文件和端口属性信息，获取目标程序的运行状态；

S540，根据运行状态得到目标程序的识别结果。

在步骤S510中，程序端口配置文件命名为module-recognition-port.json，该配置文件定义了程序运行过程中需要占用的端口信息，配置项中包括三个属性，分别是moduleName、configFile、portPropertity，其中moduleName为程序包名称，configFile为程序端口所在的配置文件，可以为绝对路径，也可以为相对路径，在读取端口占用信息配置时会先定位到需要启动的程序包目录，然后再根据该路径定位到程序的具体配置文件，configFile支持的配置文件格式包括json、yml、properties、xml，portPropertity为程序端口占用信息在configFile配置文件中对应的配置项。程序端口配置文件的格式为：

在步骤S520中，端口文件为configFile，端口属性信息为portPropertity。

在步骤S530中，读取目标程序的configFile，首先根据configFile的配置定位到目标程序的配置文件并读取该配置文件，然后根据portPropertity的配置在该配置文件中查找该portPropertity配置项的值，最后根据该配置项的值在目标程序所在的目标机器上查找是否有进程监听端口。例如，首先找到目标程序mtreceiver的configFile为ams-conf.json，在ams-conf.json中查找http.serverPort的值，即端口号。若在目标机器上能够找到该端口的监听进程，则认为程序启动成功，若无法查询到该端口的监听进程，则认为程序启动失败或程序宕机。当预设时长内，一直无法查询到该端口的监听进程，则认为程序宕机，若初始时刻有该端口的监听进程，一段时间后，无该端口的监听进程，则认为程序启动失败。

需要说明的是，每个程序可以有多个相同或不同文件格式的配置文件，所以相同的moduleName可以分别对应不同的configFile。例如，

在一些实施例，如图6所示，在步骤S170之后，程序部署方法包括但不限于步骤S610至S650。

S610，获取待监控程序的第二进程id；

S620，根据第二进程id，获取程序的运行状态；

S630，若程序的运行状态为宕机状态，获取系统基础配置文件；

S640，根据系统基础配置文件获取第一接收方信息；

S650，根据第一接收方信息，向第一接收方发送第一通知消息。

在步骤S610中，待监控程序可以是部署后的目标程序，以检查目标程序的健康状况。

在步骤S620中，根据待监控程序的第二进程id、目标机器的ip、待监控程序在目标机器上的路径，获取待监控程序在目标机器上的运行状态。

在步骤S630中，系统基础配置文件命名为system.json，该配置文件定义了系统运行的基础配置项，可以理解的是，系统为具有程序部署功能的装置或工具。系统基础配置文件的配置项中包括七个属性，分别是serverPort、mail.server、mail.serverPort、mail.sender、mail.password、mail.receiver和vx.webhook，其中serverPort为对外http接口，用于配置修改和流程控制，mail.server为邮件提醒功能邮件发出方的服务器地址，mail.serverPort为邮件提醒功能邮件发出方的服务器端口，mail.sender为邮件提醒功能邮件发出方的发送人邮箱，mail.password为邮件提醒功能邮件发出方的密码，mail.receiver为邮件提醒功能邮件接收方的邮箱，vx.webhook为企业微信机器人群聊数据操作接口地址。系统基础配置文件的格式为：

需要说明的是，serverPort可以接收通过网络发送的数据，以远程修改配置文件的配置或控制程序部署流程。配置修改除通过浏览器进行远程修改的方式外，还可以在本地手动修改。通过对配置文件增删改查以实现对配置文件的管理，配置文件的管理功能包括机器仓库配置管理、程序仓库配置管理、已知程序包名称配置管理、程序包命令配置管理、程序日志事件配置管理、程序端口配置管理、系统配置管理。

机器仓库配置管理：对应为repository-machine.json中的数据，删除数据时在表单中提供该配置文件中的ip属性即可，添加和更新数据时需要在表单中提供该配置文件中的所有属性，并对历史数据做追加或以ip为唯一判断依据做覆盖，并将该配置文件数据持久化到磁盘。

已知程序包名称配置管理：对应为module-name.json中的数据，删除数据时在表单中提供该配置文件中的具体数据值即可，添加和更新数据时直接提供具体数据值，对历史数据做追加或以数据值为唯一判断依据做覆盖，并将该配置文件数据持久化到磁盘。

程序包命令配置管理，对应为module-command.json中的数据，删除数据时在表单中提供该配置文件中的moduleName和type属性即可，添加和更新数据时需要在表单中提供该配置文件中的所有属性，对历史数据做追加或以moduleName和type为唯一判断依据做覆盖，并将该配置文件数据持久化到磁盘。

程序日志事件配置管理，对应为module-recognition-log.json中的数据，删除数据时在表单中提供该配置文件中的moduleName和actionType属性即可，添加和更新数据时需要在表单中提供配置文件中的所有属性，对历史数据做追加或以moduleName和actionType为唯一判断依据做覆盖，并将该配置文件数据持久化到磁盘。

程序端口配置管理，对应为module-recognition-port.json中的数据，删除、添加和更新数据时均需要在表单中提供该配置文件中的所有属性，对历史数据做追加或以所有属性为组合为唯一判断依据做覆盖，并将该配置文件数据持久化到磁盘。

系统配置管理，对应为system.json中的数据，该配置文件仅供更新功能，更新数据时需要在表单中提供配置文件中的具体属性以及对应的值，对相应的属性值做覆盖，并将该配置文件数据持久化到磁盘。

需要进一步说明的是，以机器仓库配置管理为例，持久化到磁盘是将机器仓库配置文件即repository-machine.json数据写入到磁盘，如果磁盘存在则直接覆盖，不存在则创建新的文件写入到磁盘。对历史数据做追加或以ip为唯一判断依据做覆盖是对repository-machine.json的内容处理，以免repository-machine.json中出现重复的多余的数据。

当利用网络远程管理配置文件时，可使用restful风格将请求发送至serverPort端口。若serverPort端口的配置参数为9000，执行程序部署的装置部署在192.168.112.112上，下面以repository-machine.json为例进行说明。

查询数据时，向serverPort端口发送查询请求，该装置响应该查询请求。

查询请求为：GET http://192.168.112.112:9000/repository-machine.json。

响应为：

删除数据时，在表单中提供ip属性，向serverPort端口发送删除请求提交表单，该装置响应删除请求。

删除请求为：DELETE http://192.168.112.112:9000/repository-machine.json。

响应为：

表示数据删除成功。

更新数据时，在表单中提供全部属性，向serverPort端口发送更新请求提交表单，该装置响应更新请求。

更新请求为：POST http://192.168.112.112:9000/repository-machine.json。

响应为：

表示数据更新成功。

新增数据时，在表单中提供全部属性，向serverPort端口发送新增请求提交表单，该装置响应新增请求。

新增请求为：PUT http://192.168.112.112:9000/repository-machine.json。

响应为：

表示数据新增成功。

其他配置文件repository-module.json、module-name.json、module-command.json、module-recognition-log.json、module-recognition-port.json、system.json均与机器仓库配置文件repository-machine.json的操作方式相同，均采用restful方式操作对应文件，在此不做赘述。

在步骤S640和S650中，可以通过获取系统配置文件的mail.server、mail.serverPort、mail.sender、mail.password、mail.receiver，将宕机通知指定的邮箱，也可以通过获取vx.webhook，将宕机通知发送给企业微信机器人，便于个人或企业获取待监控程序的运行状态信息，并采取相应措施。

需要说明的是，第一接收方信息为mail.receiver或vx.webhook中的配置参数，第一通知消息为程序宕机消息。

在一些实施例，如图7所示，在步骤S170之后，程序部署方法包括但不限于步骤S710至S760。

S710，根据程序仓库配置文件获取待监控程序的版本号；

S720，根据版本号，获取程序的更新信息；

S730，根据更新信息更新程序；

S740，获取系统基础配置文件；

S750，根据系统基础配置文件获取第二接收方信息；

S760，根据第二接收方信息，向第二接收方发送第二通知消息。

在步骤S710中，待监控程序可以是部署后的目标程序，以检查目标程序的更新情况，完成已部署程序的无人工自动更新。

在步骤S750中，第二接收方信息为mail.receiver或vx.webhook中的配置参数，第二通知消息为程序可更新的消息或程序更新成功的消息。

需要说明的是，由于程序仓库使用的是SVN和GIT，有版本的概念，程序更新会有版本号的变化，根据版本号的变化，可获取程序的更新信息。

本公开实施例提出的程序部署方法，通过获取机器仓库配置文件，根据机器仓库配置文件获取来自待部署目标机器的第一配置数据，通过获取程序仓库配置文件，根据程序仓库配置文件获取来自待部署程序的第二配置数据，接收程序部署请求，响应于程序部署请求，根据第一配置数据识别待部署目标机器，根据第二配置数据获取待部署程序，并将待部署程序发送至待部署目标机器以执行部署并得到部署后的目标程序，启动部署后的目标程序，识别部署后的目标程序的运行状态，根据运行状态得到目标程序的识别结果。通过机器仓库配置文件获取第一配置数据，通过程序仓库配置文件获取第二配置数据，根据第一配置数据和第二配置数据执行程序部署，识别部署后程序的运行状态，使程序的部署依靠配置文件就能完成，无需引入多余组件和功能，用户可以用较少的操作完成程序的部署，操作简单，资源占用小。

本公开实施例还提供一种程序部署装置，如图8所示，可以实现上述程序部署方法，该装置包括第一获取模块810、第二获取模块820、第一识别模块830、第三获取模块840、程序启动模块850和第二识别模块860。其中第一获取模块810用于获取机器仓库配置文件，根据机器仓库配置文件获取来自待部署目标机器的第一配置数据；第二获取模块820用于获取程序仓库配置文件，根据程序仓库配置文件获取来自待部署程序的第二配置数据；第一识别模块830用于接收程序部署请求；响应于程序部署请求，根据第一配置数据识别待部署目标机器；第三获取模块840用于根据第二配置数据获取待部署程序，并将待部署程序发送至待部署目标机器以执行部署并得到部署后的目标程序；程序启动模块850用于启动部署后的目标程序；第二识别模块860用于识别部署后的目标程序的运行状态，根据运行状态得到识别结果。

需要说明的是，软件开发周期主要包括构建、测试和部署三个阶段，本公开实施例的程序部署装置集中于软件开发周期的部署阶段，该装置并没有构建和测试能力，目的是为了使用户用较少的操作完成程序的部署，提高程序部署效率。

需要进一步说明的是，程序部署装置采用java和shell实现，具有秒级别的启动速度，启动速度快，轻量且体积小，编译后总体大小为3.8M；资源占用少，运行常驻内存在50M左右。

需要进一步说明的是，在使用程序部署装置时，用户可以在装置提供的web页面中针对自身环境加以配置，该装置会对用户配置的数据进行识别，包括程序名称识别、程序仓库识别、机器识别、启动命令、日志事件识别，在对这些配置识别后会有一系列的动作，例如在用户配置了程序仓库后(通过SVN或者GIT)，程序部署装置会在后台自动校验仓库地址是否有效，对仓库地址内包含的程序进行识别，当用户进入部署流程时，自动提供识别结果，而无需用户做更多的操作。在后续的动作中，该装置还会对已部署程序进行监控，其一是对程序的仓库进行定时检查，若程序有更新，则执行更新(可配置是否自动更新)，其二是提供告警通知的功能，通过监控程序部署机器的基本情况(CPU、内存、磁盘等)、程序运行状态、以及上述的程序日志事件配置文件对程序进行监控，若有事件触发则通过企业微信机器人接口或者邮件发送通知。

本公开实施例的程序部署装置用于执行上述实施例中的程序部署方法，其具体处理过程与上述实施例中的程序部署方法相同，此处不再一一赘述。

本公开实施例提出的程序部署装置，通过机器仓库配置文件获取第一配置数据，通过程序仓库配置文件获取第二配置数据，根据第一配置数据和第二配置数据执行程序部署，识别部署后程序的运行状态，使程序的部署依靠配置文件就能完成，无需引入多余组件和功能，用户可以用较少的操作完成程序的部署，操作简单，资源占用小。

本公开实施例还提供了一种计算机设备，包括：

至少一个处理器，以及，

与至少一个处理器通信连接的存储器；其中，

存储器存储有指令，指令被至少一个处理器执行，以使至少一个处理器执行指令时实现如本申请第一方面实施例中任一项的方法。

该计算机设备包括：处理器、存储器、输入/输出接口、通信接口和总线。

处理器，可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本公开实施例所提供的技术方案；

存储器，可以采用ROM(Read Only Memory，只读存储器)、静态存储设备、动态存储设备或者RAM(Random Access Memory，随机存取存储器)等形式实现。存储器可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器中，并由处理器来调用执行本公开实施例的程序部署方法；

输入/输出接口，用于实现信息输入及输出；

通信接口，用于实现本设备与其他设备的通信交互，可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信；和

总线，在设备的各个组件(例如处理器、存储器、输入/输出接口和通信接口)之间传输信息；

其中处理器、存储器、输入/输出接口和通信接口通过总线实现彼此之间在设备内部的通信连接。

本公开实施例还提供一种存储介质，该存储介质是计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令用于使计算机执行本公开实施例的程序部署方法。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本公开实施例描述的实施例是为了更加清楚的说明本公开实施例的技术方案，并不构成对于本公开实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本公开实施例提供的技术方案对于类似的技术问题，同样适用。

本领域技术人员可以理解的是，图1至图7中示出的技术方案并不构成对本公开实施例的限定，可以包括比图示更多或更少的步骤，或者组合某些步骤，或者不同的步骤。

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

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上参照附图说明了本公开实施例的优选实施例，并非因此局限本公开实施例的权利范围。本领域技术人员不脱离本公开实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本公开实施例的权利范围之内。

Claims (9)

1.程序部署方法，其特征在于，所述方法包括：

获取机器仓库配置文件，根据所述机器仓库配置文件获取来自待部署目标机器的第一配置数据；所述第一配置数据包括所述待部署目标机器的ip、账号和密码；

获取程序仓库配置文件，根据所述程序仓库配置文件获取来自待部署程序的第二配置数据；所述第二配置数据包括程序仓库的url、账号、密码和类型；

接收程序部署请求；

响应于所述程序部署请求，根据所述第一配置数据识别所述待部署目标机器；

根据第二配置数据获取所述待部署程序，并将所述待部署程序发送至所述待部署目标机器以执行部署并得到部署后的目标程序；

启动部署后的所述目标程序；

识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果；

所述启动部署后的所述目标程序，包括：

获取程序包命令配置文件；所述程序包命令配置文件包括程序包名称、程序启动命令或程序停止命令、程序启动命令或程序停止命令执行时预先跳转的目录、程序启动命令或程序停止命令的内容；

根据所述程序包命令配置文件启动部署后的所述目标程序。

2.根据权利要求1所述的程序部署方法，其特征在于，所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果，包括：

部署后的所述目标程序在目标机器运行时，获取部署后的所述目标程序的程序日志事件配置文件；

根据所述程序日志事件配置文件获取所述目标程序的日志文件和日志信息；

根据所述日志文件和所述日志信息，获取所述目标程序的运行状态；

根据所述运行状态得到所述目标程序的识别结果。

3.根据权利要求1所述的程序部署方法，其特征在于，所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果，包括：

部署后的目标程序在目标机器运行时，获取部署后的所述目标程序的第一进程id；

根据所述第一进程id，获取所述目标程序的运行状态；

根据所述运行状态得到所述目标程序的识别结果。

4.根据权利要求1所述的程序部署方法，其特征在于，所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果，包括：

部署后的目标程序在目标机器运行时，获取部署后的所述目标程序的程序端口配置文件；

根据所述程序端口配置文件，获取所述目标程序的端口文件和端口属性信息；

根据所述端口文件和所述端口属性信息，获取所述目标程序的运行状态；

根据所述运行状态得到所述目标程序的识别结果。

5.根据权利要求1所述的程序部署方法，其特征在于，在所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果之后，所述方法还包括：

获取待监控程序的第二进程id；

根据所述第二进程id，获取所述程序的运行状态；

若所述程序的运行状态为宕机状态，获取系统基础配置文件；

根据所述系统基础配置文件获取第一接收方信息；

根据所述第一接收方信息，向第一接收方发送第一通知消息。

6.根据权利要求1所述的程序部署方法，其特征在于，在所述识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果之后，所述方法还包括：

根据所述程序仓库配置文件获取待监控程序的版本号；

根据所述版本号，获取所述程序的更新信息；

根据所述更新信息更新所述程序；

获取系统基础配置文件；

根据所述系统基础配置文件获取第二接收方信息；

根据所述第二接收方信息，向所述第二接收方发送第二通知消息。

7.程序部署装置，其特征在于，所述装置包括：

第一获取模块，用于获取机器仓库配置文件，根据所述机器仓库配置文件获取来自待部署目标机器的第一配置数据；所述第一配置数据包括所述待部署目标机器的ip、账号和密码；

第二获取模块，用于获取程序仓库配置文件，根据所述程序仓库配置文件获取来自待部署程序的第二配置数据；所述第二配置数据包括程序仓库的url、账号、密码和类型；

第一识别模块，用于接收程序部署请求；响应于所述程序部署请求，根据所述第一配置数据识别所述待部署目标机器；

第三获取模块，用于根据第二配置数据获取所述待部署程序，并将所述待部署程序发送至所述待部署目标机器以执行部署并得到部署后的目标程序；

程序启动模块，用于启动部署后的所述目标程序；

第二识别模块，用于识别部署后的所述目标程序的运行状态，根据所述运行状态得到识别结果；

所述程序部署装置还用于：获取程序包命令配置文件；所述程序包命令配置文件包括程序包名称、程序启动命令或程序停止命令、程序启动命令或程序停止命令执行时预先跳转的目录、程序启动命令或程序停止命令的内容；根据所述程序包命令配置文件启动部署后的所述目标程序。

8.计算机设备，其特征在于，所述计算机设备包括存储器和处理器，其中，所述存储器中存储有程序，所述程序被所述处理器执行时所述处理器用于执行：

如权利要求1至6中任一项所述的方法。

9.存储介质，所述存储介质为计算机可读存储介质，其特征在于，所述计算机可读存储介质 存储有计算机程序，在所述计算机程序被计算机执行时，所述计算机用于执行：

如权利要求1至6中任一项所述的方法。

Images