CN110674043B - 应用调试的处理方法及服务器 - Google Patents

Abstract

本申请提供一种应用调试的处理方法及服务器，该方法包括：在拉取目标服务对应的应用镜像后，对应用镜像进行修改，获得修改后的应用镜像，修改后的应用镜像包括修改后的启动命令和调试托管程序的挂载信息；基于修改后的启动命令和调试托管程序的挂载信息，创建目标容器；在需要启动目标容器时，基于修改后的启动命令，启动调试托管程序的进程，控制调试托管程序的进程拉起目标服务对应的目标应用进程。实现了通过在容器云平台动态封装容器启动命令及挂载通用的调试托管程序，使得在应用程序退出时，容器能够保持而不被销毁，开发人员不必在容器中适配进程托管工具，有效减少开发人员的工作量。

Description

应用调试的处理方法及服务器

技术领域

本申请涉及互联网技术领域，尤其涉及一种应用调试的处理方法及服务器。

背景技术

随着容器技术的不断发展，容器服务逐渐成为各厂商的重要方向。容器服务作为一种高性能的容器管理服务，支持在一组云服务器上通过容器来部署或编排应用，容器云平台的用户不再需要安装、运维、扩展自己的集群管理基础设施，而是可以直接通过容器云平台的控制台图形化界面或者API(Application Programming Interface,应用程序编程接口)进行容器操作和生命周期管理。而应用的容器化，给应用带来了诸多好处，越来越多的服务端应用运行在了容器之中。

但是，容器的实现，使用了PID命名空间技术，对于每个容器都会新建一个PID命名空间，且为启动进程分配PID为1，也就是说，在该PID命名空间内，应用启动进程就是系统初始化进程，应用启动进程退出后，容器即被销毁，用户也就无法登录到容器内，查看问题发生时的系统状态、日志等信息，很不方便去调查当时发生了什么导致异常退出。

为了解决上述问题，现有技术中，通常是在容器内集成一个进程托管程序，由进程托管程序负责拉起应用进程，这样只要进程托管程序不退出，容器就不会销毁，应用进程异常退出时，用户可以进入到容器进行调查。但是，现有技术的进程托管程序，需要开发人员在开发过程中进行适配，增加了开发人员的适配工作量。

发明内容

本申请提供一种应用调试的处理方法及服务器，以解决现有技术开发人员工作量大等缺陷。

本申请第一个方面提供一种应用调试的处理方法，包括：

在拉取目标服务对应的应用镜像后，对所述应用镜像进行修改，获得修改后的应用镜像，所述修改后的应用镜像包括修改后的启动命令和调试托管程序的挂载信息；

基于所述修改后的启动命令和调试托管程序的挂载信息，创建目标容器；

在需要启动所述目标容器时，基于所述修改后的启动命令，启动所述调试托管程序的进程，控制所述调试托管程序的进程拉起所述目标服务对应的目标应用进程。

可选地，所述对所述应用镜像进行修改，获得修改后的应用镜像，包括：

将所述应用镜像的原启动命令替换为修改后的启动命令，并对所述应用镜像添加调试托管程序的挂载信息，获得所述修改后的应用镜像，所述修改后的启动命令包括启动所述调试托管程序的进程的命令。

可选地，基于所述修改后的启动命令和调试托管程序的挂载信息，创建目标容器，包括：

基于所述调试托管程序的挂载信息，将所述调试托管程序从物理机挂载到所述目标容器中。

可选地，在启动所述目标容器后，若所述目标应用进程退出时，所述目标容器不销毁，以使用户访问所述目标容器。

可选地，所述方法还包括：

控制所述调试托管程序的进程接收容器云平台发送的预设类型的信号，并发送给对应的应用进程，以使所述应用进程根据所述信号进行相应的处理。

可选地，所述方法还包括：

当所述目标应用进程退出后，根据所述目标应用进程的退出码及预设规则判断是否自动拉起所述目标应用进程；

若是，则进行自动拉起所述目标应用进程的处理。

可选地，若在预设次数的自动拉起处理后，仍未拉起所述目标应用进程，则结束自动拉起处理。

可选地，在对所述应用镜像进行修改，获得修改后的应用镜像之前，所述方法还包括：

判断用户是否选择了调试托管；

所述对所述应用镜像进行修改，获得修改后的应用镜像，包括：

若确定用户选择了调试托管，则对所述应用镜像进行修改，获得修改后的应用镜像。

本申请第二个方面提供一种服务器，包括：

托管检查模块，用于在拉取目标服务对应的应用镜像后，对所述应用镜像进行修改，获得修改后的应用镜像，所述修改后的应用镜像包括修改后的启动命令和调试托管程序的挂载信息；

容器创建模块，用于基于所述修改后的启动命令和调试托管程序的挂载信息，创建目标容器；

容器启动模块，用于在需要启动所述目标容器时，基于所述修改后的启动命令，启动所述调试托管程序的进程，控制所述调试托管程序的进程拉起所述目标服务对应的目标应用进程。

可选地，所述托管检查模块，具体用于：

将所述应用镜像的原启动命令替换为修改后的启动命令，并对所述应用镜像添加调试托管程序的挂载信息，获得所述修改后的应用镜像，所述修改后的启动命令包括启动所述调试托管程序的进程的命令。

可选地，所述容器创建模块，具体用于：

基于所述调试托管程序的挂载信息，将所述调试托管程序从物理机挂载到所述目标容器中。

可选地，所述容器启动模块，还用于：

在启动所述目标容器后，若所述目标应用进程退出时，所述目标容器不销毁，以使用户访问所述目标容器。

可选地，所述托管检查模块，还用于：

控制所述调试托管程序的进程接收容器云平台发送的预设类型的信号，并发送给对应的应用进程，以使所述应用进程根据所述信号进行相应的处理。

可选地，所述容器启动模块，还用于：

当所述目标应用进程退出后，根据所述目标应用进程的退出码及预设规则判断是否自动拉起所述目标应用进程；

若是，则进行自动拉起所述目标应用进程的处理。

可选地，所述容器启动模块，还用于：

若在预设次数的自动拉起处理后，仍未拉起所述目标应用进程，则结束自动拉起处理。

可选地，所述托管检查模块，还用于：

判断用户是否选择了调试托管；

所述托管检查模块，具体用于：

若确定用户选择了调试托管，则对所述应用镜像进行修改，获得修改后的应用镜像。

本申请第三个方面提供一种计算机设备，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一个方面以及第一个方面各种可能的设计所述的方法。

本申请第四个方面提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第一个方面以及第一个方面各种可能的设计所述的方法。

本申请提供的应用调试的处理方法及服务器，通过在拉取目标服务对应的应用镜像后，对所述应用镜像进行修改，获得修改后的应用镜像，基于所述修改后的启动命令和调试托管程序的挂载信息，创建目标容器，在需要启动所述目标容器时，基于所述修改后的启动命令，启动所述调试托管程序的进程，控制所述调试托管程序的进程拉起所述目标服务对应的目标应用进程，实现了通过在容器云平台动态封装容器启动命令及挂载通用的调试托管程序，使得在应用程序退出时，容器能够保持而不被销毁，开发人员不必在容器中适配进程托管工具，有效减少开发人员的工作量。

附图说明

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

图1为本申请实施例基于的容器云系统的结构示意图;

图2为本申请一实施例提供的应用调试的处理方法的流程示意图；

图3为本申请一实施例提供的Docker容器的结构示意图；

图4为本申请一实施例提供的启动容器的流程框图；

图5为本申请一实施例提供的应用启动命令替换前后的文件层结构对比结果示意图；

图6为本申请另一实施例提供的应用调试的处理方法的流程示意图；

图7为本申请一实施例提供的信号代理示意图；

图8为本申请一实施例提供的服务器的结构示意图；

图9为本申请一实施例提供的计算机设备的结构示意图。

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

具体实施方式

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

首先对本申请所涉及的名词进行解释：

docker daemon：运行在宿主机上，是Docker的守护进程，用户通过Docker Client(Docker命令)通过命令行与Docker Damon通信交互，完成Docker相关操作。Docker是CS架构，主要有两个概念：即Docker daemon和Docker client。Docker client是Docker命令行工具，是用户使用Docker的主要方式，Docker client与Docker daemon通信并将结果返回给用户，Docker client也可以通过socket或者RESTful API访问远程的Docker daemon。

当前，各云厂商的容器云服务平台(也可称容器云平台)，通常不提供容器主进程异常退出时调测的能力，只有一些控制台日志可以看，开发人员只能线下尽量调测充分，或者基于日志上报，容器销毁后通过查看上报的日志定位问题，或者集成进程托管工具，应用进程异常退出时容器不销毁，从而可以进入容器调查。但是需要开发人员进行适配，需要进行充分的准备工作，来避免部署时遇到未知的异常退出问题，然而，往往仍会发生很多开发人员无法预知的问题。

为了解决上述问题，本申请实施例提供一种应用调试的处理方法，适用于容器云环境下的应用调试场景。如图1所示，为本申请实施例基于的容器云系统结构示意图。该容器云系统包括容器云平台和至少一个用户终端。其中，容器云平台中可以包括至少一个节点，即计算机设备。可以预先在容器云平台集成托管检查程序(或称托管检查模块)init-checker模块，用户可以通过用户终端在页面新建服务，创建服务名称，选择提供的应用镜像，点击创建服务后，用户终端向容器云平台提交服务创建请求，容器云平台根据服务需要的资源及网络环境等信息将服务创建请求调度到目标节点，目标节点则可以根据服务创建请求，拉取服务对应的应用镜像，init-checker模块解析应用镜像得到容器启动命令，比如java-jar app.jar，对应用镜像进行修改，获得修改后的应用镜像，具体来说对容器启动命令进行修改，比如将启动命令java-jar app.jar替换为/ubin/init--java-jar app.jar，获得修改后的启动命令，并在应用镜像中添加调试托管程序(比如上述的init程序)的挂载信息，使得修改后的启动命令在启动容器时，先启动调试托管程序的进程，由调试托管程序的进程拉起服务对应的应用进程。如此，应用进程作为调试托管程序的进程的子进程，在应用进程退出时，调试托管进程未退出则容器不会销毁，且本申请的调试托管程序是在容器云平台适配的，可以供所有开发人员使用，开发人员不必在容器适配进程托管工具，有效减少开发人员的工作量。

此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。

下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。

本申请一实施例提供一种应用调试的处理方法，用于容器云环境下的应用调试。本实施例的执行主体为服务器，该服务器可以设置在容器云平台，作为容器云平台的节点。

如图2所示，为本实施例提供的应用调试的处理方法的流程示意图，该方法包括：

步骤101，在拉取目标服务对应的应用镜像后，对应用镜像进行修改，获得修改后的应用镜像，修改后的应用镜像包括修改后的启动命令和调试托管程序的挂载信息。

具体的，可以预先在容器云平台集成托管检查程序(或称托管检查模块)init-checker模块，用户可以通过用户终端在页面新建服务(称为目标服务)，创建服务名称，选择提供的应用镜像，点击创建服务后，用户终端向容器云平台提交服务创建请求，容器云平台根据目标服务需要的资源及网络环境等信息将服务创建请求调度到目标节点，目标节点则可以根据服务创建请求，拉取目标服务对应的应用镜像，应用镜像包括启动命令、日志、开放端口等信息。对应用镜像进行修改，获得修改后的应用镜像。具体来说，可以是init-checker模块解析应用镜像得到容器启动命令(可以称为原启动命令)，比如java-jarapp.jar，对应用镜像进行修改，获得修改后的应用镜像，具体来说对容器原启动命令进行修改，比如将原启动命令java-jar app.jar替换为/ubin/init--java-jar app.jar，获得修改后的启动命令，并在应用镜像中添加调试托管程序(比如上述的init程序)的挂载信息，具体是将调试托管程序的挂载信息添加到应用镜像的描述信息中，使得修改后的启动命令在启动容器时，先启动调试托管程序的进程，由调试托管程序的进程拉起目标服务对应的应用进程。如此，应用进程作为调试托管程序的进程的子进程，在应用进程退出时，调试托管进程未退出则容器不会销毁，且本申请的调试托管程序是在容器云平台适配的，可以供所有开发人员使用，开发人员不必在容器适配进程托管工具，有效减少开发人员的工作量。

步骤102，基于修改后的启动命令和调试托管程序的挂载信息，创建目标容器。

具体地，在获得修改后的应用镜像后，可以基于修改后的应用镜像中的修改后的启动命令和调试托管程序的挂载信息创建目标容器。可以理解地，在应用镜像中还包括很多其他用于创建目标容器的信息，比如日志、开放端口等，其为现有技术，在此不再赘述。

步骤103，在需要启动目标容器时，基于修改后的启动命令，启动调试托管程序的进程，控制调试托管程序的进程拉起目标服务对应的目标应用进程。

具体的，在创建了目标容器后，在需要启动目标容器时，可以基于修改后的启动命令，先启动调试托管程序的进程，然后由调试托管程序的进程拉起目标服务对应的目标应用进程。这样，应用进程作为调试托管程序的进程的子进程，在应用进程退出时，调试托管进程未退出则容器不会销毁，且本申请的调试托管程序是在容器云平台适配的，可以供所有开发人员使用，开发人员不必在容器适配进程托管工具，有效减少开发人员的工作量。

示例性的，如图3所示，为本实施例提供的Docker容器的结构示意图。Docker容器采用了分层的文件系统结构，其中：

1、内核层(Kernel)。

2、基础镜像层(Base Image)，例如CentOS、Debian、BusyBox等。

3、应用层，主要是应用程序运行依赖，比如JDK、各种web server等。

4、容器层(Container)，Container只有这一层是可读写的，其他层都是只读的，应用的启动命令运行在该层。比如启动命令java-jar app.jar启动一个java程序。

需要说明的是，具体的Docker容器的结构为现有技术，在此不再赘述。

容器云环境下，每个节点都部署了docker daemon服务，负责本节点上的容器生命周期管理，包括新建、销毁等。现有技术中，docker daemon启动应用容器时，会给应用容器分配单独的PID命名空间，并指定应用启动命令，为容器的初始化进程。此时在容器内执行ps命令，可以看到应用启动程序的pid为1：

这就意味着，应用程序一旦异常退出，整个容器也就被销毁了。

应用如果集成了托管程序，以supervisord为例，用户指定应用的启动命令为supervisord，由supervisord负责启动应用程序，docker daemon启动容器后，进入容器可以看到进程结构如下示例：

可以看到，supervisord进程的pid为1，应用进程作为supervisord的子进程。这样即使应用程序异常退出，只要supervisord不退出，容器就不会销毁，用户就可以登录到容器内查看系统信息进行定位。此种方式，需要用户打包应用镜像时，提前安装进程托管程序、提供应用启动配置等，有一定的适配工作量。

本申请实施例，是在应用部署时，动态地封装替换应用启动命令，并注入进程初始化管理工具，从而达到对应用进程进行托管的效果。具体如下：

以上述java应用为例：

1、在应用构建镜像时，依旧是指定启动命令为java-jar app.jar。

2、在容器云平台提交部署请求之后，容器云平台会将容器启动任务调度给平台中的一个节点(称为目标节点)，由目标节点上的docker daemon服务负责启动容器。现有技术中docker daemon原本启动容器分为3步：

1)拉取镜像。

2)创建容器。

3)启动容器。

本申请实施例集成init-checker模块之后，启动容器分为4步：

1)拉取镜像。镜像即为上述的应用镜像。

2)修改镜像读写层描述信息：包括替换镜像启动命令、添加调试托管程序的挂载信息。

3)创建容器。具体是基于修改后的镜像来创建目标容器。

4)启动容器。即启动目标容器

如图4所示，为本实施例提供的启动容器的流程框图。docker daemon拉取镜像后，init-checker解析该镜像得到容器启动命令java-jar app.jar，然后将其修改为/ubin/init--java-jar app.jar。如图5所示，为本实施例提供的应用启动命令替换前后的文件层结构对比结果示意图。可见，容器内原本不存在/ubin/init程序，由init-checker给容器添加mount挂载，从物理机挂载而来。容器内查看如下：

sh-4.2$mount|grep init

/dev/mapper/initchecker on/ubin/init type xfs(rw,relatime,seclabel,attr2,inode64,logbsize＝256k,sunit＝512,swidth＝512,noquota)。

最终容器启动时，是先启动的init进程(即调试托管程序/ubin/init的进程)，然后init进程拉起应用进程(即目标应用进程)，如下所示：

从而应用异常退出时，可以维持容器不销毁，用户可以进入容器进行定位问题。

这里只是以java程序为例，实际应用不限于java程序，可以是任意的应用程序，本申请实施例提供的方法与应用程序解耦，应用程序开发人员在开发过程中无需关注，没有适配工作量；并且可以支持多种镜像运行环境(如centos/debian/busybox等)，为用户提供方便地定位应用进程异常退出问题的通道。

本实施例提供的应用调试的处理方法，通过在拉取目标服务对应的应用镜像后，对应用镜像进行修改，获得修改后的应用镜像，基于修改后的启动命令和调试托管程序的挂载信息，创建目标容器，在需要启动目标容器时，基于修改后的启动命令，启动调试托管程序的进程，控制调试托管程序的进程拉起目标服务对应的目标应用进程，实现了通过在容器云平台动态封装容器启动命令及挂载通用的调试托管程序，使得在应用程序退出时，容器能够保持而不被销毁，开发人员不必在容器中适配进程托管工具，有效减少开发人员的工作量。

本申请另一实施例对上述实施例提供的方法做进一步补充说明。

如图6所示，为本实施例提供的应用调试的处理方法的流程示意图。

作为一种可实施的方式，在上述实施例的基础上，可选地，步骤101具体包括：

步骤1011，在拉取目标服务对应的应用镜像后，将应用镜像的原启动命令替换为修改后的启动命令，并对应用镜像添加调试托管程序的挂载信息，获得修改后的应用镜像，修改后的启动命令包括启动调试托管程序的进程的命令。

示例性的，可以预先在容器云平台集成托管检查程序(或称托管检查模块)init-checker模块，在拉取目标服务对应的应用镜像后，init-checker模块解析应用镜像得到容器启动命令(可以称为原启动命令)，比如java-jar app.jar，将原启动命令java-jarapp.jar替换为/ubin/init--java-jar app.jar，获得修改后的启动命令。并在应用镜像中添加调试托管程序(比如上述的init程序)的挂载信息，具体是将调试托管程序的挂载信息添加到应用镜像的描述信息中，使得修改后的启动命令在启动容器时，先启动调试托管程序的进程，由调试托管程序的进程拉起目标服务对应的应用进程。

作为另一种可实施的方式，在上述实施例的基础上，可选地，步骤102具体包括：

步骤1021，基于调试托管程序的挂载信息，将调试托管程序从物理机挂载到目标容器中。

具体的，由于修改后的应用镜像中添加了调试托管程序的挂载信息，在创建容器时，需要基于调试托管程序的挂载信息进行挂载操作，将调试托管程序从物理机挂载到目标容器中，以使在目标容器能够启动进程来运行调试托管程序，达到调试托管的目的，使得在应用进程异常退出后，维持目标容器不会销毁，方便用户进入容器定位问题，为用户提供通道。

作为另一种可实施的方式，在上述实施例的基础上，可选地，在启动目标容器后，若目标应用进程退出时，目标容器不销毁，以使用户访问目标容器。

具体的，在目标应用进程退出时，由于目标应用进程是调试托管程序的进程的子进程，所以即使目标应用进程退出，目标容器也会维持而不会销毁，方便用户进入容器定位问题，为用户提供通道

作为另一种可实施的方式，在上述实施例的基础上，可选地，该方法还包括：

控制调试托管程序的进程接收容器云平台发送的预设类型的信号，并发送给对应的应用进程，以使应用进程根据信号进行相应的处理。

具体的，应用进程可以对特定信号有定制逻辑，比如平滑停止等功能。本申请实施例在集成了init-checker模块，挂载了调试托管程序后，调试托管程序同时可以具有信号代理功能，保证各类定制信号能够传递给应用进程。

示例性的，如图7所示，为本实施例提供的信号代理示意图。信号(signal)类型具体可以根据实际需求设置，比如信号9表示强制杀掉进程，信号15表示要把进程杀掉了。当调试托管程序的进程接收到容器云平台要向某应用进程(subprocess)发送信号15，调试托管程序的进程init则将信号15传递给该应用进程，信号15表示要杀掉该应用进程了，该应用进程接收到信号15后，如果是有定制逻辑，该应用进程则不再接收新的工作，完成剩余的一些工作后，可以自己停止。如果该应用进程不管该信号15继续进行新的工作，容器云平台还可以通过调试托管程序的进程向该应用进程发送信号9，强制杀掉该应用进程。

作为另一种可实施的方式，在上述实施例的基础上，可选地，该方法还包括：

步骤2011，当目标应用进程退出后，根据目标应用进程的退出码及预设规则判断是否自动拉起目标应用进程。

步骤2012，若是，则进行自动拉起目标应用进程的处理。

可选地，若在预设次数的自动拉起处理后，仍未拉起目标应用进程，则结束自动拉起处理。

具体的，当目标应用进程退出后，会产生退出码，可以根据退出码及预设规则来判断是否自动拉起目标应用进程。预设规则可以是指定的哪些类型的退出码要自动拉起。比如有些退出码，在应用进程退出后能够自动拉起，则可以指定当出现这些退出码时，自动拉起退出的应用进程。当确定需要自动拉起时，则自动拉起目标应用进程。否则不再拉起。

本申请实施例中，拉起即表示启动的意思。

若自动拉起失败，还可以再次拉起，也可以设置预设次数，允许重复自动拉起操作预设次数，若仍未拉起，则停止拉起，避免一直拉起占用资源。

作为另一种可实施的方式，在上述实施例的基础上，可选地，在对应用镜像进行修改，获得修改后的应用镜像之前，该方法还包括：

步骤2021，判断用户是否选择了调试托管。

对应用镜像进行修改，获得修改后的应用镜像，包括：

步骤2022，若确定用户选择了调试托管，则对应用镜像进行修改，获得修改后的应用镜像。

具体的，还可以设置开关控制，由用户来选择是否进行调试托管。用户通过开关控制是否启用调试托管功能，只有在用户选择了启用调试托管时，在拉取镜像后，才会对镜像读写层描述信息进行修改，若用户选择不启用，则按照现有的容器启动方式进行启动。

需要说明的是，本实施例中各可实施的方式可以单独实施，也可以在不冲突的情况下以任意组合方式结合实施本申请不做限定。

本实施例提供的应用调试的处理方法，通过在拉取目标服务对应的应用镜像后，对应用镜像进行修改，获得修改后的应用镜像，基于修改后的启动命令和调试托管程序的挂载信息，创建目标容器，在需要启动目标容器时，基于修改后的启动命令，启动调试托管程序的进程，控制调试托管程序的进程拉起目标服务对应的目标应用进程，实现了通过在容器云平台动态封装容器启动命令及挂载通用的调试托管程序，使得在应用程序退出时，容器能够保持而不被销毁，开发人员不必在容器中适配进程托管工具，有效减少开发人员的工作量。

本申请再一实施例提供一种服务器，用于执行上述实施例提供的方法。

如图8所示，为本实施例提供的服务器的结构示意图。该服务器30包括托管检查模块31、容器创建模块32和容器启动模块33。

其中，托管检查模块，用于在拉取目标服务对应的应用镜像后，对应用镜像进行修改，获得修改后的应用镜像，修改后的应用镜像包括修改后的启动命令和调试托管程序的挂载信息；容器创建模块，用于基于修改后的启动命令和调试托管程序的挂载信息，创建目标容器；容器启动模块，用于在需要启动目标容器时，基于修改后的启动命令，启动调试托管程序的进程，控制调试托管程序的进程拉起目标服务对应的目标应用进程。

关于本实施例中的服务器，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

根据本实施例提供的服务器，通过在拉取目标服务对应的应用镜像后，对应用镜像进行修改，获得修改后的应用镜像，基于修改后的启动命令和调试托管程序的挂载信息，创建目标容器，在需要启动目标容器时，基于修改后的启动命令，启动调试托管程序的进程，控制调试托管程序的进程拉起目标服务对应的目标应用进程，实现了通过在容器云平台动态封装容器启动命令及挂载通用的调试托管程序，使得在应用程序退出时，容器能够保持而不被销毁，开发人员不必在容器中适配进程托管工具，有效减少开发人员的工作量。

本申请又一实施例对上述实施例提供的服务器做进一步补充说明。

作为一种可实施的方式，在上述实施例的基础上，可选地，托管检查模块，具体用于：

将应用镜像的原启动命令替换为修改后的启动命令，并对应用镜像添加调试托管程序的挂载信息，获得修改后的应用镜像，修改后的启动命令包括启动调试托管程序的进程的命令。

作为另一种可实施的方式，在上述实施例的基础上，可选地，容器创建模块，具体用于：

基于调试托管程序的挂载信息，将调试托管程序从物理机挂载到目标容器中。

作为另一种可实施的方式，在上述实施例的基础上，可选地，容器启动模块，还用于：

在启动目标容器后，若目标应用进程退出时，目标容器不销毁，以使用户访问目标容器。

作为另一种可实施的方式，在上述实施例的基础上，可选地，托管检查模块，还用于：

控制调试托管程序的进程接收容器云平台发送的预设类型的信号，并发送给对应的应用进程，以使应用进程根据信号进行相应的处理。

作为另一种可实施的方式，在上述实施例的基础上，可选地，容器启动模块，还用于：

当目标应用进程退出后，根据目标应用进程的退出码及预设规则判断是否自动拉起目标应用进程；

若是，则进行自动拉起目标应用进程的处理。

可选地，容器启动模块，还用于：

若在预设次数的自动拉起处理后，仍未拉起目标应用进程，则结束自动拉起处理。

作为另一种可实施的方式，在上述实施例的基础上，可选地，托管检查模块，还用于：

判断用户是否选择了调试托管；

托管检查模块，具体用于：

若确定用户选择了调试托管，则对应用镜像进行修改，获得修改后的应用镜像。

关于本实施例中的服务器，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

需要说明的是，本实施例中各可实施的方式可以单独实施，也可以在不冲突的情况下以任意组合方式结合实施本申请不做限定。

根据本实施例的服务器，通过在拉取目标服务对应的应用镜像后，对应用镜像进行修改，获得修改后的应用镜像，基于修改后的启动命令和调试托管程序的挂载信息，创建目标容器，在需要启动目标容器时，基于修改后的启动命令，启动调试托管程序的进程，控制调试托管程序的进程拉起目标服务对应的目标应用进程，实现了通过在容器云平台动态封装容器启动命令及挂载通用的调试托管程序，使得在应用程序退出时，容器能够保持而不被销毁，开发人员不必在容器中适配进程托管工具，有效减少开发人员的工作量。

本申请再一实施例提供一种计算机设备，用于执行上述实施例提供的方法。

如图9所示，为本实施例提供的计算机设备的结构示意图。该计算机设备50包括：至少一个处理器51和存储器52；

存储器存储计算机执行指令；至少一个处理器执行存储器存储的计算机执行指令，使得至少一个处理器执行如上任一实施例提供的方法。

根据本实施例的计算机设备，通过在拉取目标服务对应的应用镜像后，对应用镜像进行修改，获得修改后的应用镜像，基于修改后的启动命令和调试托管程序的挂载信息，创建目标容器，在需要启动目标容器时，基于修改后的启动命令，启动调试托管程序的进程，控制调试托管程序的进程拉起目标服务对应的目标应用进程，实现了通过在容器云平台动态封装容器启动命令及挂载通用的调试托管程序，使得在应用程序退出时，容器能够保持而不被销毁，开发人员不必在容器中适配进程托管工具，有效减少开发人员的工作量。

本申请又一实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现如上任一实施例提供的方法。

根据本实施例的计算机可读存储介质，通过在拉取目标服务对应的应用镜像后，对应用镜像进行修改，获得修改后的应用镜像，基于修改后的启动命令和调试托管程序的挂载信息，创建目标容器，在需要启动目标容器时，基于修改后的启动命令，启动调试托管程序的进程，控制调试托管程序的进程拉起目标服务对应的目标应用进程，实现了通过在容器云平台动态封装容器启动命令及挂载通用的调试托管程序，使得在应用程序退出时，容器能够保持而不被销毁，开发人员不必在容器中适配进程托管工具，有效减少开发人员的工作量。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (9)

1.一种应用调试的处理方法，其特征在于，包括：

在拉取目标服务对应的应用镜像后，对所述应用镜像进行修改，获得修改后的应用镜像，所述修改后的应用镜像包括修改后的启动命令和调试托管程序的挂载信息，所述调试托管程序是在容器云平台适配的，所述调试托管程序的进程用于拉起目标服务对应的应用进程；

基于所述修改后的启动命令和调试托管程序的挂载信息，创建目标容器，以将所述调试托管程序从物理机挂载到所述目标容器中；

在需要启动所述目标容器时，基于所述修改后的启动命令，先启动所述调试托管程序的进程，并控制启动后的所述调试托管程序的进程拉起所述目标服务对应的目标应用进程，以使得所述目标容器在所述目标应用进程退出时不被销毁。

2.根据权利要求1所述的方法，其特征在于，所述对所述应用镜像进行修改，获得修改后的应用镜像，包括：

将所述应用镜像的原启动命令替换为修改后的启动命令，并对所述应用镜像添加调试托管程序的挂载信息，获得所述修改后的应用镜像，所述修改后的启动命令包括启动所述调试托管程序的进程的命令。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

控制所述调试托管程序的进程接收容器云平台发送的预设类型的信号，并发送给对应的应用进程，以使所述应用进程根据所述信号进行相应的处理。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述目标应用进程退出后，根据所述目标应用进程的退出码及预设规则判断是否自动拉起所述目标应用进程；

若是，则进行自动拉起所述目标应用进程的处理。

5.根据权利要求4所述的方法，其特征在于，若在预设次数的自动拉起处理后，仍未拉起所述目标应用进程，则结束自动拉起处理。

6.根据权利要求1-5任一项所述的方法，其特征在于，在对所述应用镜像进行修改，获得修改后的应用镜像之前，所述方法还包括：

判断用户是否选择了调试托管；

所述对所述应用镜像进行修改，获得修改后的应用镜像，包括：

若确定用户选择了调试托管，则对所述应用镜像进行修改，获得修改后的应用镜像。

7.一种服务器，其特征在于，包括：

托管检查模块，用于在拉取目标服务对应的应用镜像后，对所述应用镜像进行修改，获得修改后的应用镜像，所述修改后的应用镜像包括修改后的启动命令和调试托管程序的挂载信息，所述调试托管程序是在容器云平台适配的，所述调试托管程序的进程用于拉起目标服务对应的应用进程；

容器创建模块，用于基于所述修改后的启动命令和调试托管程序的挂载信息，创建目标容器，以将所述调试托管程序从物理机挂载到所述目标容器中；

容器启动模块，用于在需要启动所述目标容器时，基于所述修改后的启动命令，启动所述调试托管程序的进程，并控制启动后的所述调试托管程序的进程拉起所述目标服务对应的目标应用进程，以使得所述目标容器在所述目标应用进程退出时不被销毁。

8.根据权利要求7所述的服务器，其特征在于，所述托管检查模块，具体用于：

将所述应用镜像的原启动命令替换为修改后的启动命令，并对所述应用镜像添加调试托管程序的挂载信息，获得所述修改后的应用镜像，所述修改后的启动命令包括启动所述调试托管程序的进程的命令。

9.根据权利要求7所述的服务器，其特征在于，所述容器创建模块，具体用于：

基于所述调试托管程序的挂载信息，将所述调试托管程序从物理机挂载到所述目标容器中。