CN115599405A - 一种基于docker的扩展服务管理方法及相关装置 - Google Patents

Abstract

本申请公开了一种基于docker的扩展服务管理方法，包括：获取安装包；对所述安装包进行校验；当校验通过时，对所述安装包进行解压，得到目标数据；当所述目标数据的安装状态为初次安装时，基于所述目标数据进行服务安装，并基于所述目标数据对扩展服务信息表新增扩展信息；当所述目标数据的安装状态为升级时，基于所述目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。以提高拓展服务的解耦性，提高服务的开发效率。本申请还公开了一种基于docker的扩展服务管理装置、终端设备以及计算机可读存储介质，具有以上有益效果。

Description

一种基于docker的扩展服务管理方法及相关装置

技术领域

本申请涉及计算机技术领域，特别涉及一种基于docker的扩展服务管理方法、扩展服务管理装置、终端设备以及计算机可读存储介质。

背景技术

随着软件开发迭代过程中需求的不断增加，项目所需开发的功能模块越来越多，一些相对独立的功能模块也需要加入到主服务的项目中，这就导致项目结构逐渐臃肿；一些定制服务在开发时，总是需要从主服务拉分支进行开发，这一流程重复性高且繁琐。因此提出扩展程序管理的概念，将一些相对独立的功能模块或定制开发服务封装成扩展程序，安装挂载到主服务中。

相关技术中，类似的比如有智能设备上安装的app应用，应用市场有各种各样的app，用户可以根据自己的需求进行下载安装。但是这种模式是在设备上进行软件方面的功能扩展，而不是在已有系统平台上进行功能的扩展。

因此，如何提高拓展服务的解耦性，提高服务的开发效率是本领域技术人员关注的重点问题。

发明内容

本申请的目的是提供一种基于docker的扩展服务管理方法、扩展服务管理装置、终端设备以及计算机可读存储介质，以提高拓展服务的解耦性，提高服务的开发效率。

为解决上述技术问题，本申请提供一种基于docker的扩展服务管理方法，包括：

获取安装包；

对所述安装包进行校验；

当校验通过时，对所述安装包进行解压，得到目标数据；

当所述目标数据的安装状态为初次安装时，基于所述目标数据进行服务安装，并基于所述目标数据对扩展服务信息表新增扩展信息；

当所述目标数据的安装状态为升级时，基于所述目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。

可选的，对所述安装包进行校验，包括：

基于MD5对所述安装包进行校验。

可选的，当所述目标数据的安装状态为初次安装时，基于所述目标数据进行服务安装，并基于所述目标数据对扩展服务信息表新增扩展信息，包括：

判断主服务的配置信息中是否存在对应扩展服务的安装容器；

若是，则基于所述扩展服务的安装容器进行服务安装；

若否，则基于所述主服务的元数据信息配置对应的安装容器，并基于所述安装容器进行服务安装。

可选的，当所述目标数据的安装状态为升级时，基于所述目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份，包括：

确定所述扩展服务的安装路径，并对所述目标数据进行再次校验；

当所述再次校验通过时，基于所述安装路径进行服务升级。

可选的，还包括：

当响应于异步安装指令时，提取并配置权限配置文件和网络配置文件；

将安装包拷贝到服务器容器，通过安装脚本对安装包进行安装。

本申请还提供一种基于docker的扩展服务管理装置，包括：

安装包获取模块，用于获取安装包；

校验模块，用于对所述安装包进行校验；

安装包解压模块，用于当校验通过时，对所述安装包进行解压，得到目标数据；

初次安装模块，用于当所述目标数据的安装状态为初次安装时，基于所述目标数据进行服务安装，并基于所述目标数据对扩展服务信息表新增扩展信息；

服务升级模块，用于当所述目标数据的安装状态为升级时，基于所述目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。

可选的，所述校验模块，具体用于基于MD5对所述安装包进行校验。

可选的，所述初次安装模块，具体用于判断主服务的配置信息中是否存在对应扩展服务的安装容器；若是，则基于所述扩展服务的安装容器进行服务安装；若否，则基于所述主服务的元数据信息配置对应的安装容器，并基于所述安装容器进行服务安装。

本申请还提供一种终端设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上所述的扩展服务管理方法的步骤。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的扩展服务管理方法的步骤。

本申请所提供的一种基于docker的扩展服务管理方法，包括：获取安装包；对所述安装包进行校验；当校验通过时，对所述安装包进行解压，得到目标数据；当所述目标数据的安装状态为初次安装时，基于所述目标数据进行服务安装，并基于所述目标数据对扩展服务信息表新增扩展信息；当所述目标数据的安装状态为升级时，基于所述目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。

通过获取安装包并进行校验，当校验通过后解压得到目标数据，最后基于目标数据的安装状态确定执行何种安装操作，实现了自动化进行扩展服务的管理，提高了扩展服务的解耦性，提高了服务的开发效率。

本申请还提供一种基于docker的扩展服务管理装置、终端设备以及计算机可读存储介质，具有以上有益效果，在此不作赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例所提供的一种基于docker的扩展服务管理方法的流程图；

图2为本申请实施例所提供的一种基于docker的扩展服务管理装置的结构示意图；

图3本申请实施例所提供的一种终端设备的结构示意图。

具体实施方式

本申请的核心是提供一种基于docker的扩展服务管理方法、扩展服务管理装置、终端设备以及计算机可读存储介质，以提高拓展服务的解耦性，提高服务的开发效率。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

相关技术中，类似的比如有智能设备上安装的app应用，应用市场有各种各样的app，用户可以根据自己的需求进行下载安装。但是这种模式是在设备上进行软件方面的功能扩展，而不是在已有系统平台上进行功能的扩展。

因此，本申请提供一种基于docker的扩展服务管理方法，通过获取安装包并进行校验，当校验通过后解压得到目标数据，最后基于目标数据的安装状态确定执行何种安装操作，实现了自动化进行扩展服务的管理，提高了扩展服务的解耦性，提高了服务的开发效率。

以下通过一个实施例，对本申请提供的一种基于docker的扩展服务管理方法进行说明。

请参考图1，图1为本申请实施例所提供的一种基于docker的扩展服务管理方法的流程图。

本实施例中，该方法可以包括：

S101，获取安装包；

本步骤旨在获取安装包。

其中，安装包就是扩展服务对应的安装包。通过该安装包可以在对应的容器中安装对应的扩展服务。

S102，对安装包进行校验；

在S101的基础上，本步骤旨在对安装包进行校验。

进一步的，本步骤可以包括：

基于MD5对安装包进行校验。

可见，本可选方案中主要是说明如何进行校验。本可选方案中，主要是通过MD5值对安装包进行校验。此外，还可以基于安装包的名称进行校验，以便提高校验的效果。

S103，当校验通过时，对安装包进行解压，得到目标数据；

在S102的基础上，本步骤旨在当校验通过时，对安装包进行解压，得到目标数据。可见，本步骤中主要是是指对安装包进行解压，然后得到目标数据。

其中，对安装包进行解压的过程可以参考现有技术提供的任意一种解压方式，在此不做具体限定。

S104，当目标数据的安装状态为初次安装时，基于目标数据进行服务安装，并基于目标数据对扩展服务信息表新增扩展信息；

在S103的基础上，本步骤旨在当目标数据的安装状态为初次安装时，基于目标数据进行服务安装，并基于目标数据对扩展服务信息表新增扩展信息。也就是说，当获取到目标数据后，执行的安装操作存在两种状态，一种是基于目标数据的扩展服务安装，一种是基于目标数据的扩展服务的升级操作。

进一步的，本步骤可以包括：

步骤1，判断主服务的配置信息中是否存在对应扩展服务的安装容器；

步骤2，若是，则基于扩展服务的安装容器进行服务安装；

步骤3，若否，则基于主服务的元数据信息配置对应的安装容器，并基于安装容器进行服务安装。

可见，本可选方案中主要是说明如何进行扩展安装。本可选方案中，判断主服务的配置信息中是否存在对应扩展服务的安装容器；若是，则基于扩展服务的安装容器进行服务安装；若否，则基于主服务的元数据信息配置对应的安装容器，并基于安装容器进行服务安装。

S105，当目标数据的安装状态为升级时，基于目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。

在S103的基础上，本步骤旨在当目标数据的安装状态为升级时，基于目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。也就是，当目标服务的安装状态为升级时，进行扩展服务的服务升级操作。

进一步的，本步骤可以包括：

步骤1，确定扩展服务的安装路径，并对目标数据进行再次校验；

步骤2，当再次校验通过时，基于安装路径进行服务升级。

可见，本可选方案中主要是说明如何进行服务升级。本可选方案中，确定扩展服务的安装路径，并对目标数据进行再次校验；当再次校验通过时，基于安装路径进行服务升级。

进一步的，为了应对多种安装情况，本实施例还可以包括：

步骤1，当响应于异步安装指令时，提取并配置权限配置文件和网络配置文件；

步骤2，将安装包拷贝到服务器容器，通过安装脚本对安装包进行安装。

可见，本可选方案中主要是说明如何进行异步安装。本可选方案中，当响应于异步安装指令时，提取并配置权限配置文件和网络配置文件；将安装包拷贝到服务器容器，通过安装脚本对安装包进行安装。

综上，本实施例通过获取安装包并进行校验，当校验通过后解压得到目标数据，最后基于目标数据的安装状态确定执行何种安装操作，实现了自动化进行扩展服务的管理，提高了扩展服务的解耦性，提高了服务的开发效率。

以下通过另一具体的实施例，对本申请提供的一种基于docker的扩展服务管理方法做进一步说明。

本实施例的扩展服务管理中，包括：服务安装，卸载，重启，停止等操作。

其中，扩展服务的安装/更新的过程，可以包括：

步骤1，用户在前端页面将*.zip安装包传到后台，后台根据扩展服务包命名规则对.zip安装包名进行校验，校验会产生三种结果，分别为：“安装包名称不合法”、“安装包版本过低”和“校验通过”。只有包名校验通过后，安装包才会上传至后台相应目录下。

步骤2，尝试获取操作锁，如果获取成功则进行以下步骤；如果获取失败则向前端返回“安装异常：系统繁忙，请稍后安装”的响应信息。

步骤3，后台接收到*.zip安装包后，放到指定目录进行解压，然后对解压后的tar包进行MD5校验；只有MD5校验通过后，程序才会进行下一步安装流程。

步骤4，后台解压tar包，提取并解析扩展服务程序的元数据文件meta_info.data，该过程会对meta_info.data文件中的code、name字段做非空校验(code是区别其他扩展服务的唯一标识；name是该服务的中文名称)，对version字段做格式校验(version是该服务的版本号)；然后查询数据库判断此次操作是升级还是安装(扩展服务的相关信息(包括状态信息，版本信息等)是存储在MySQL的)：

其中，如果是首次安装，则会查看主服务是否配置了扩展服务的安装容器ext_docker_id，如果主服务没有配置该参数，则根据meta_info.data文件配置的dockerId进行安装，如果主服务和mete_info.data文件中均未配置，则安装到默认容器1.extensions1。

其中，如果是服务升级，则不改变原有服务的dockerId和deployPath(安装路径)；然后对扩展服务的运行状态进行校验(“安装中”、“安装失败”、“卸载中”均无法进行升级)，然后停止扩展服务并再次对版本信息进行校验(此步骤防止*.zip安装包的包名被篡改)。以上所有校验都通过后，程序才会进行下一步的安装流程；如果校验不通过，则会向前端返回相关响应信息(如“安装包经过篡改”、“安装包版本过低”等提示信息)。

步骤5，后台往数据库的extension_info表新增或更新扩展服务的数据信息，此时扩展服务的状态为“安装中(installing)”。

步骤6，如果是升级操作，还会对扩展服务的部署目录进行备份。如果升级失败，方便回滚老版本。

步骤7，后台向前端返回“扩展服务正在安装中”的响应信息，同时异步安装扩展服务并释放操作锁。

进一步的，异步安装扩展服务的过程，可以包括：

步骤1，提取并解析权限配置文件permission.json。该文件中有服务需要的一些参数(比如，parentCode挂载到指定菜单下级，选填，为空挂载到根菜单；operations操作权限；name菜单中文名等)。

步骤2，拷贝该服务程序的nginx配置到指定目录并重载nginx配置。

步骤3，将tar包拷贝到指定的扩展服务容器(调用Linux的scp命令，拷贝到指定容器中)。

步骤4，通过ssh远程控制扩展服务容器执行扩展服务的安装脚本ext-install.sh。

步骤5，如果安装成功，往数据库的extension_history表新增安装/更新成功的记录，然后更新extension_info中该服务的状态为“运行中(running)”。然后向nacos注册该服务，nacos提供对服务的实时的健康检查。

步骤6，在扩展服务所在容器中添加该扩展服务开机自启动的定时任务(修改crontab文件：/var/spool/cron/root)。目的是如果服务器重启了，扩展服务可以恢复到运行状态。

步骤7，安装成功后删除扩展服务容器的安装文件和主服务容器的安装文件。

步骤8，安装过程如下，其中，如果安装过程发生异常，则安装失败；

步骤8.1，如果是首次安装，则删除扩展服务的nginx配置、部署目录；往数据库的extension_history表新增安装失败的记录(并在result字段中记录错误详情)，然后更新extension_info中的状态为“安装失败(aborted)”。

步骤8.2，如果是更新操作，则先删除扩展服务的部署目录，然后尝试进行版本回滚。如果回滚成功，则扩展服务恢复到更新前的版本，extension_info表中也将还原上个版本的所有信息，状态为“已停用(stopped)”，在extension_history表新增更新失败的记录并在result字段记录错误详情以及回滚成功的结果；如果回滚失败，则删除扩展服务的nginx配置、扩展服务的部署目录，往数据库的extension_history表新增更新失败的记录(并在result字段中记录错误详情以及回滚失败的结果)，然后更新extension_info中的状态为“安装失败(aborted)”。

步骤8.3，最后删除扩展服务容器的安装文件与主服务容器的安装文件。

其中，扩展服务的启动、停止、重启的过程，可以包括：

步骤1，尝试获取操作锁，如果获取成功则进行以下步骤；如果获取失败则向前端返回“${操作}异常：系统繁忙，请稍后${操作}”的响应信息。

步骤2，对扩展服务状态做校验，校验当前状态下能否执行该操作；校验通过后根据操作类型修改数据库extension_info表中扩展服务的状态信息(“启动中(starting)”、“停用中(stopping)”或“重启中(restarting)”)并向前端发送请求成功的响应信息，页面实时显示最新状态；同时异步操作扩展服务并释放操作锁。

其中，异步操作扩展服务的过程，可以包括：

步骤1，通过ssh远程控制扩展服务容器执行扩展服务控制脚本ext-cli.sh(start|stop|restart)。

步骤2，根据执行结果修改数据库extension_info表中扩展服务的状态，启动及重启成功是“运行中(running)”，关闭成功是“已停用(stopped)”，启动、重启及停止失败是“操作失败(failure)”；同时更新结果信息，成功的话为(“启动成功”或“关闭成功”)，操作失败会记录操作失败的原因(“重启失败：...”)。

步骤3，如果为停止操作，需要禁用扩展服务所属的权限项，并从菜单中剔除；从crontab中移除开机自启动的定时任务。

步骤4，如果为启动或重启操作，需要启用扩展服务所属的权限项，并挂载到菜单中；在crontab中添加开机自启动的定时任务。

其中，扩展服务的卸载的过程，可以包括：

步骤1，尝试获取操作锁，如果获取成功则进行以下步骤；如果获取失败则向前端返回“卸载异常：系统繁忙，请稍后卸载”的响应信息。

步骤2，对扩展服务状态做校验，校验当前状态下能否卸载；校验通过后修改数据库extension_info表中扩展服务的状态信息为“正在卸载(uninstalling)”并向前端发送请求成功的响应信息，同时异步卸载扩展服务并释放操作锁。

步骤3，异步卸载扩展服务逻辑如下：

步骤3.1，删除扩展服务的nginx配置文件并重载nginx配置。

步骤3.2，通过ssh远程控制扩展服务容器执行扩展服务控制脚本ext-cli.sh(stop)，停止扩展服务。

步骤3.3，删除扩展服务部署目录。

步骤3.4，在数据库extension_info表中删除该扩展服务的记录，在数据库的extension_history表新增卸载扩展服务的记录。从nacos注销该服务。

步骤3.5，删除扩展服务所属的权限项，并从菜单中剔除；从crontab中移除开机自启动的定时任务。

进一步的，扩展服务相关信息(包括运行状态信息)是存储在MySQL表中的，如果用户直接在后台通过命令启停扩展服务的话，MySQL表中存储的该服务的状态是不会发生变化的，但会发生以下情况：

其中，“运行中”这一状态比较特殊，如果扩展服务在MySQL表中的状态是“运行中”，不会直接返回“运行中”的状态给前端，还需要在nacos上查到该扩展服务是健康的才会返回“运行中”的状态，否则返回“异常”状态给前端。所以如果页面上扩展服务处于“运行中”的状态，用户直接在后台通过命令把该服务停掉，那么主服务在nacos上查不到该拓展服务的健康状态，则会返回“异常”状态给前端。

此外，如果扩展服务处于“已停用”状态，用户直接在后台通过命令启动该服务，由于MySQL表中的状态还是“已停用”，主服务不会主动查nacos获取该扩展服务的健康状态，因此即使扩展服务已经在后台运行，但由于不是通过主服务启动的，所以前端还是会显示“已停用”的状态，而且该服务的菜单也不会挂载，用户也就无法访问。

其中，操作加锁逻辑(启动、停止、重启、安装、卸载)的过程，可以避免极端情况的出现(如升级操作，上传安装包后，MySQL的状态还未更改为installing时，另一用户则对该扩展服务进行卸载操作)，对这五种涉及到状态更变的操作进行加锁：当某个操作持有锁时，无法进行其他操作。

在操作执行之前，程序会先尝试请求获取操作锁，如果获取成功，则正常进行操作；如果获取失败，则向前端返回“系统繁忙，请稍后重试”的提示信息。其中，启动、停止、重启、卸载这四个操作持有锁的时间非常短，在MySQL表中的状态变更完成后，就释放锁(比如原本是停止状态，点击启动按钮，此时启动操作持有锁；当表中状态变成“启动中”时，就会释放锁)。而安装/升级这一操作，由于在状态变更前需要做一系列的校验，因此持有锁的时间会比较长(时间主要耗费在MD5的校验以及安装文件的存储)，在所有校验完成后，将MySQL的状态更改为installing时，则会释放锁。

可见，本实施例通过获取安装包并进行校验，当校验通过后解压得到目标数据，最后基于目标数据的安装状态确定执行何种安装操作，实现了自动化进行扩展服务的管理，提高了扩展服务的解耦性，提高了服务的开发效率。

下面对本申请实施例提供的扩展服务管理装置进行介绍，下文描述的扩展服务管理装置与上文描述的基于docker的扩展服务管理方法可相互对应参照。

请参考图2，图2为本申请实施例所提供的一种基于docker的扩展服务管理装置的结构示意图。

本实施例中，该装置可以包括：

安装包获取模块100，用于获取安装包；

校验模块200，用于对安装包进行校验；

安装包解压模块300，用于当校验通过时，对安装包进行解压，得到目标数据；

初次安装模块400，用于当目标数据的安装状态为初次安装时，基于目标数据进行服务安装，并基于目标数据对扩展服务信息表新增扩展信息；

服务升级模块500，用于当目标数据的安装状态为升级时，基于目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。

可选的，该校验模块200，具体用于基于MD5对安装包进行校验。

可选的，该初次安装模块400，具体用于判断主服务的配置信息中是否存在对应扩展服务的安装容器；若是，则基于扩展服务的安装容器进行服务安装；若否，则基于主服务的元数据信息配置对应的安装容器，并基于安装容器进行服务安装。

本申请还提供了一种终端设备，请参考图3，图3本申请实施例所提供的一种终端设备的结构示意图，该终端设备可包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时可实现如上述任意一种基于docker的扩展服务管理方法的步骤。

如图3所示，为终端设备的组成结构示意图，终端设备可以包括：处理器10、存储器11、通信接口12和通信总线13。处理器10、存储器11、通信接口12均通过通信总线13完成相互间的通信。

在本申请实施例中，处理器10可以为中央处理器(Central Processing Unit，CPU)、特定应用集成电路、数字信号处理器、现场可编程门阵列或者其他可编程逻辑器件等。

处理器10可以调用存储器11中存储的程序，具体的，处理器10可以执行异常IP识别方法的实施例中的操作。

存储器11中用于存放一个或者一个以上程序，程序可以包括程序代码，程序代码包括计算机操作指令，在本申请实施例中，存储器11中至少存储有用于实现以下功能的程序：

获取安装包；

对安装包进行校验；

当校验通过时，对安装包进行解压，得到目标数据；

当目标数据的安装状态为初次安装时，基于目标数据进行服务安装，并基于目标数据对扩展服务信息表新增扩展信息；

当目标数据的安装状态为升级时，基于目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。

在一种可能的实现方式中，存储器11可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及至少一个功能所需的应用程序等；存储数据区可存储使用过程中所创建的数据。

此外，存储器11可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。

通信接口12可以为通信模块的接口，用于与其他设备或者系统连接。

当然，需要说明的是，图3所示的结构并不构成对本申请实施例中终端设备的限定，在实际应用中终端设备可以包括比图3所示的更多或更少的部件，或者组合某些部件。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现如上述任意一种基于docker的扩展服务管理方法的步骤。

该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

对于本申请提供的计算机可读存储介质的介绍请参照上述方法实施例，本申请在此不做赘述。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的一种基于docker的扩展服务管理方法、扩展服务管理装置、终端设备以及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

Claims (10)

1.一种基于docker的扩展服务管理方法，其特征在于，包括：

获取安装包；

对所述安装包进行校验；

当校验通过时，对所述安装包进行解压，得到目标数据；

当所述目标数据的安装状态为初次安装时，基于所述目标数据进行服务安装，并基于所述目标数据对扩展服务信息表新增扩展信息；

当所述目标数据的安装状态为升级时，基于所述目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。

2.根据权利要求1所述的扩展服务管理方法，其特征在于，对所述安装包进行校验，包括：

基于MD5对所述安装包进行校验。

3.根据权利要求1所述的扩展服务管理方法，其特征在于，当所述目标数据的安装状态为初次安装时，基于所述目标数据进行服务安装，并基于所述目标数据对扩展服务信息表新增扩展信息，包括：

判断主服务的配置信息中是否存在对应扩展服务的安装容器；

若是，则基于所述扩展服务的安装容器进行服务安装；

若否，则基于所述主服务的元数据信息配置对应的安装容器，并基于所述安装容器进行服务安装。

4.根据权利要求1所述的扩展服务管理方法，其特征在于，当所述目标数据的安装状态为升级时，基于所述目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份，包括：

确定所述扩展服务的安装路径，并对所述目标数据进行再次校验；

当所述再次校验通过时，基于所述安装路径进行服务升级。

5.根据权利要求1所述的扩展服务管理方法，其特征在于，还包括：

当响应于异步安装指令时，提取并配置权限配置文件和网络配置文件；

将安装包拷贝到服务器容器，通过安装脚本对安装包进行安装。

6.一种基于docker的扩展服务管理装置，其特征在于，包括：

安装包获取模块，用于获取安装包；

校验模块，用于对所述安装包进行校验；

安装包解压模块，用于当校验通过时，对所述安装包进行解压，得到目标数据；

初次安装模块，用于当所述目标数据的安装状态为初次安装时，基于所述目标数据进行服务安装，并基于所述目标数据对扩展服务信息表新增扩展信息；

服务升级模块，用于当所述目标数据的安装状态为升级时，基于所述目标数据进行服务升级，并对对应的扩展服务的部署目标进行备份。

7.根据权利要求6所述的扩展服务管理装置，其特征在于，所述校验模块，具体用于基于MD5对所述安装包进行校验。

8.根据权利要求6所述的扩展服务管理装置，其特征在于，所述初次安装模块，具体用于判断主服务的配置信息中是否存在对应扩展服务的安装容器；若是，则基于所述扩展服务的安装容器进行服务安装；若否，则基于所述主服务的元数据信息配置对应的安装容器，并基于所述安装容器进行服务安装。

9.一种终端设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至5任一项所述的扩展服务管理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至5任一项所述的扩展服务管理方法的步骤。

Images