CN108920250B - 应用程序容器化的方法及装置 - Google Patents

Abstract

本申请实施例提供了一种应用程序容器化的方法及装置，其中方法包括：确定待容器化的目标应用程序，并获取目标应用程序对应的源代码；根据目标应用程序对应的目标技术栈的类型，在源代码中添加声明信息；其中，声明信息用于声明结合目标应用程序对应的运行依赖文件，建立目标应用程序对应的目标镜像；根据目标应用程序对应的目标技术栈的类型，对添加后的源代码进行修改，以将目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求；根据修改后的源代码，自动建立目标应用程序对应的目标镜像；其中，目标镜像用于使目标应用程序运行在容器平台上。通过本申请实施例，能够提高应用程序容器化的效率。

Description

应用程序容器化的方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用程序容器化的方法及装置。

背景技术

目前，应用程序在开发、测试和运维过程中存在诸多不足，至少包括应用程序持续集成困难，开发、测试、运维环境不一致，硬件资源不足等。

为应对上述问题，现有技术提出了应用程序容器化，应用程序容器化后，能够运行在容器平台上。应用程序运行在容器平台上时，应用程序的依赖集成进镜像中，从而解决开发、测试、运维环境不一致的问题。应用程序运行在容器平台上时，容器与容器之间的、容器与主机之间的隔离性，使得一台主机可以运行多个容器并互不影响，从而解决硬件资源不足的问题。

并且，容器技术可以显著改善企业软件研发流程、提升企业DevOps(Developmentand Operations，开发和运营)效率。借助容器技术，企业可以对现有IT系统进行一次梳理，解决IT软件系统部署、升级难的顽疾，重新释放企业生产力，降低企业成本。

现有技术在实现应用程序容器化时，需要人工手动建立应用程序对应的镜像，建立过程耗时长、成本高，通常需要多名研发人员共同努力，因此，现有技术在实现应用程序容器化时，存在效率低下的问题。

发明内容

本申请实施例的目的是提供一种应用程序容器化的方法及装置，以提高应用程序容器化的效率。

为达到上述目的，本申请实施例是这样实现的：

第一方面，本申请实施例提供了一种应用程序容器化的方法，包括：

确定待容器化的目标应用程序，并获取所述目标应用程序对应的源代码；

根据所述目标应用程序对应的目标技术栈的类型，在所述源代码中添加声明信息；其中，所述声明信息用于声明结合所述目标应用程序对应的运行依赖文件，建立所述目标应用程序对应的目标镜像；

根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求；

根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像用于使所述目标应用程序运行在容器平台上。

第二方面，本申请还实施例提供了一种应用程序容器化的装置，包括：

第一确定模块，用于确定待容器化的目标应用程序，并获取所述目标应用程序对应的源代码；

信息添加模块，用于根据所述目标应用程序对应的目标技术栈的类型，在所述源代码中添加声明信息；其中，所述声明信息用于声明结合所述目标应用程序对应的运行依赖文件，建立所述目标应用程序对应的目标镜像；

代码修改模块，用于根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求；

镜像建立模块，用于根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像用于使所述目标应用程序运行在容器平台上。

第三方面，本申请实施例提供了一种应用程序容器化的设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上述第一方面所述的应用程序容器化的方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的应用程序容器化的方法的步骤。

通过本申请实施例，能够把目标应用程序抽象成目标技术栈，根据目标技术栈的类型修改目标应用程序的源代码，进而根据修改后的源代码自动建立目标应用程序对应的目标镜像，以实现目标应用程序的容器化，使得目标应用程序基于目标镜像运行在容器平台上，解决应用程序开发、测试、运维环境不一致和硬件资源不足等问题。并且，应用程序容器化的过程不需要人工干预，能够自动实现应用程序的容器化，相比手动实现应用程序容器化的方式极大提高了效率，解决了手动实现应用程序容器化实现时间长、成本高的问题。并且，结合目标应用程序对应的运行依赖文件，建立目标应用程序对应的目标镜像，能够避免目标应用程序运行在容器平台上时，由于缺少运行依赖文件导致运行失败的问题。

附图说明

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

图1为申请一实施例提供的应用程序容器化的方法的流程示意图；

图2为本申请另一实施例提供的应用程序容器化的方法的流程示意图；

图3为本申请一实施例提供的应用程序容器化的装置的模块组成示意图；

图4为本申请一实施例提供的应用程序容器化的设备的结构示意图。

具体实施方式

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

为提高应用程序容器化的效率，本申请实施例提供了一种应用程序容器化的方法及装置，能够自动实现应用程序容器化，使得应用程序运行在各种容器平台上，相比手动实现应用程序容器化的方式极大提高了效率。

图1为申请一实施例提供的应用程序容器化的方法的流程示意图，该方法能够由服务器设备执行，特别由用于进行应用程序容器化的服务器执行，如图1所示，该方法包括：

步骤S102，确定待容器化的目标应用程序，并获取目标应用程序对应的源代码；

步骤S104，根据目标应用程序对应的目标技术栈的类型，在源代码中添加声明信息；其中，该声明信息用于声明结合目标应用程序对应的运行依赖文件，建立目标应用程序对应的目标镜像；

步骤S106，根据目标应用程序对应的目标技术栈的类型，对添加后的源代码进行修改，以将目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求；

步骤S108，根据修改后的源代码，自动建立目标应用程序对应的目标镜像；其中，目标镜像用于使目标应用程序运行在容器平台上。

可见，通过本申请实施例，能够把目标应用程序抽象成目标技术栈，根据目标技术栈的类型修改目标应用程序的源代码，进而根据修改后的源代码自动建立目标应用程序对应的目标镜像，以实现目标应用程序的容器化，使得目标应用程序基于目标镜像运行在容器平台上，解决应用程序开发、测试、运维环境不一致和硬件资源不足等问题。并且，应用程序容器化的过程不需要人工干预，能够自动实现应用程序的容器化，相比手动实现应用程序容器化的方式极大提高了效率，解决了手动实现应用程序容器化实现时间长、成本高的问题。并且，结合目标应用程序对应的运行依赖文件，建立目标应用程序对应的目标镜像，能够避免目标应用程序运行在容器平台上时，由于缺少运行依赖文件导致运行失败的问题。

由于在应用程序容器化的过程中，每个应用程序需要对应建立一个镜像，且需要根据应用程序的源代码建立对应的镜像，因此上述步骤S102中，确定待容器化的目标应用程序，如目标应用程序为拍照相关的应用程序，并获取目标应用程序对应的源代码，以便于实现目标应用程序的容器化。

在执行上述步骤S104之前，本申请实施例中的方法还包括：根据目标应用程序的源代码的目录结构和/或源代码的文件类型，确定目标应用程序对应的目标技术栈。

能够理解，目标应用程序依赖于对应的目标技术栈运行。本实施例中预设有第一对应关系，第一对应关系可以是不同类型的技术栈与不同的代码目录结构之间的对应关系，比如，技术栈spring对应的代码目录结构为A，技术栈python对应的代码目录结构为B，因此本实施例中，可以根据目标应用程序的源代码的目录结构，确定目标应用程序对应的目标技术栈，比如，目标应用程序的源代码的目录结构为A，则目标应用程序对应的目标技术栈为spring，目标应用程序的源代码的目录结构为B，则目标应用程序对应的目标技术栈为python。

另一方面，本实施例中预设有第二对应关系，第二对应关系可以是不同类型的技术栈与不同的文件类型之间的对应关系，技术栈用于支持对应的文件类型，比如spring对应并支持.class文件，python对应并支持.py文件，则本实施例中，还可以根据目标应用程序的源代码的文件类型，确定目标应用程序对应的目标技术栈，比如，目标应用程序的源代码的文件类型为.class文件，则目标应用程序对应的目标技术栈为spring，目标应用程序的源代码的文件类型为.py文件，则目标应用程序对应的目标技术栈为python。

一个实施例中，根据目标应用程序的源代码的目录结构，确定目标应用程序对应的目标技术栈。另一个实施例中，根据目标应用程序的源代码的文件类型，确定目标应用程序对应的目标技术栈。在另一个实施例中，首先根据目标应用程序的源代码的目录结构，确定目标应用程序对应的目标技术栈，若确定得到对应的目标技术栈的数量不唯一，则再进一步根据目标应用程序的源代码的文件类型，确定目标应用程序对应的目标技术栈。可选地，一个目标应用程序对应一个技术栈。由于源代码的文件类型只有一个，因此根据源代码的文件类型确定得到的目标技术栈也只有一个。

本申请实施例中，首先确定目标技术栈，将目标应用程序抽象成目标技术栈，再进一步根据目标技术栈的类型，对目标应用程序的源代码进行修改。

对于一个应用程序而言，若其运行时需要依赖另一个文件(如数据库)，则这个文件就是该应用程序的运行依赖文件。

上述步骤S104中，根据目标应用程序对应的目标技术栈的类型，在源代码中添加声明信息，其中，该声明信息用于声明结合目标应用程序对应的运行依赖文件，建立目标应用程序对应的目标镜像，具体为：

(a1)根据目标应用程序对应的目标技术栈的类型，确定目标应用程序对应的运行依赖文件；

(a2)根据该运行依赖文件生成声明信息，并将生成的声明信息添加在源代码中，其中，声明信息用于声明结合运行依赖文件建立目标镜像。

本实施例中预设有第三对应关系，第三对应关系可以是不同类型的技术栈与不同的依赖文件之间的对应关系，比如，Spring对应的依赖文件为web.xml，django对应的依赖文件为requirements.txt。上述动作(a1)中，确定目标技术栈的类型，比如目标技术栈是Spring或者django，然后，根据预设的第三对应关系，确定该类型的目标技术栈对应的依赖文件，将确定的依赖文件作为目标应用程序对应的运行依赖文件。

上述动作(a2)中，根据运行依赖文件生成声明信息，并将生成的声明信息添加在源代码中，其中，声明信息用于声明结合运行依赖文件建立目标镜像。一种情况下，目标应用程序对应的运行依赖文件为多个，则上述动作(2)中，生成每个运行依赖文件对应的声明信息，并将每个声明信息均添加在源代码中，从而通过声明信息声明结合目标应用程序对应的全部运行依赖文件建立目标镜像。

一个具体的实施例中，确定目标技术栈的类型为django，并根据第三对应关系，确定django对应的依赖文件为requirements.txt，则将依赖文件requirements.txt，作为目标应用程序对应的运行依赖文件。在源代码中增加声明信息，该声明信息用于声明，在建立目标镜像的过程中，获取运行依赖文件requirements.txt并安装，从而使得建立好的目标镜像中安装有运行依赖文件requirements.txt。

本实施例中，在建立目标镜像的过程中，根据上述声明信息获取目标应用程序的运行依赖文件并安装，以使建立好的目标镜像中安装有运行依赖文件，能够避免目标应用程序运行在容器平台上时，由于缺少运行依赖文件导致运行失败的问题，保证目标应用程序在容器平台上的顺利运行。

上述步骤S106中，根据目标应用程序对应的目标技术栈的类型，对添加后的源代码进行修改，以将目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求，包括：

(b1)根据目标应用程序对应的目标技术栈的类型，在添加后的源代码中确定目标应用程序对应的日志处理代码；

(b2)对日志处理代码进行修改，以将目标应用程序的日志输出路径修改为满足镜像建立要求的指定路径。其中，日志处理信息包括日志输出路径。

本申请实施例中，可以根据应用容器引擎Docker建立目标镜像，因此预设的镜像建立要求可以是根据应用容器引擎Docker建立镜像时需要满足的要求。一个实施例中，镜像建立要求为，应用程序的日志输出路径指向设备的屏幕，即将日志输出至设备的屏幕上。

本实施例中预设有第四对应关系，第四对应关系可以是不同类型的技术栈与其对应的程序源代码中，日志处理代码的对应关系，比如，spring对应的程序源代码中，日志处理代码为“log4j.propertie”代码段，django对应的程序源代码中，日志处理代码为python内建的logging模块建造的系统日志的代码段。

基于此，上述动作(b1)中，根据目标应用程序对应的目标技术栈的类型，在添加后的源代码中确定目标应用程序对应的日志处理代码。比如，目标技术栈为spring，则添加后的源代码中目标应用程序对应的日志处理代码为“log4j.propertie”代码段。

然后，上述动作(b2)中，对目标应用程序的日志处理代码进行修改，以将目标应用程序的日志输出路径修改为满足镜像建立要求的指定路径，其中，指定路径可以为指向设备的屏幕的路径，即日志的标准输出路径。

本申请实施例中，将目标应用程序的日志输出路径修改为满足镜像建立要求的指定路径，也即，将目标应用程序对应的日志处理信息调整至满足镜像建立要求，能够保证顺利建立得到目标镜像。

当然，在其他实施例中，日志处理信息还可以包括日志输出格式，除将目标应用程序的日志输出路径修改为满足镜像建立要求的指定路径以外，还可以将目标应用程序的日志输出格式修改为满足镜像建立要求的指定格式，指定格式可以是txt格式等。

上述步骤S108中，根据修改后的源代码，自动建立目标应用程序对应的目标镜像，具体为：

(c1)根据修改后的源代码、目标技术栈对应的原始镜像和目标技术栈对应的启动脚本，生成Dockerfile脚本文件；

(c2)根据Dockerfile脚本文件，自动建立目标应用程序对应的目标镜像；其中，目标镜像中安装有运行依赖文件。

上述动作(c1)具体为：获取Dockerfile脚本文件模板，该模板包括四部分，然后，在第一部分中写入目标技术栈对应的原始镜像的信息，在第二部分中写入修改后的源代码，在第三部分中根据源代码中增加的声明信息，写入运行依赖文件的安装指令，在第四部分中写入目标技术栈对应的启动脚本，写入这四部分内容后的Dockerfile脚本文件模板，即为Dockerfile脚本文件。其中，目标技术栈对应的原始镜像可以为预先获取的目标技术栈的官方镜像。本申请实施例中为了能够适应不同技术栈，可以预先获取不同技术栈的官方镜像并存储，比如，预先获取java、C、php、python、ruby、spring、django、nodejs、wordpress等主流技术栈的官方镜像并存储。

上述动作(c2)中，自动运行Dockerfile脚本文件，建立目标应用程序对应的目标镜像。由于Dockerfile脚本文件写有运行依赖文件的安装指令，因此生成的目标镜像中安装有目标应用程序的运行依赖文件。

本实施例中，在建立目标镜像的过程中，根据上述声明信息获取目标应用程序的运行依赖文件并安装，以使建立好的目标镜像中安装有运行依赖文件，能够避免目标应用程序运行在容器平台上时，由于缺少运行依赖文件导致运行失败的问题，保证目标应用程序在容器平台上的顺利运行。

本申请实施例中，在建立目标镜像后，还目标镜像保存至镜像仓库；其中，镜像仓库用于包括至少一个镜像。

图2为本申请另一实施例提供的应用程序容器化的方法的流程示意图，该方法能够由服务器设备执行，特别由用于进行应用程序容器化的服务器执行，如图2所示，该流程包括：

步骤S202，确定待容器化的目标应用程序，并获取目标应用程序对应的源代码。

该步骤具体同步骤S102，这里不做重复。

步骤S204，根据源代码的目录结构和/或源代码的文件类型，确定目标应用程序对应的目标技术栈。

该步骤可以参考前述内容，这里不做重复。

步骤S206，根据目标应用程序对应的目标技术栈的类型，在源代码中添加声明信息；其中，该声明信息用于声明结合目标应用程序对应的运行依赖文件，建立目标应用程序对应的目标镜像。

该步骤具体同步骤S104，这里不做重复。

步骤S208，根据目标应用程序对应的目标技术栈的类型，对添加后的源代码进行修改，以将目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求。

该步骤具体同步骤S106，这里不做重复。

步骤S210，根据目标应用程序对应的目标技术栈的类型，确定目标应用程序对应的运行监控模块。其中，运行监控模块用于获取目标应用程序的运行信息并输出。

本申请实施例中，预设有第五对应关系，第五对应关系可以包括不同类型的技术栈与不同的运行监控模块之间的对应关系，比如，spring对应第一监控模块，django对应第二监控模块。能够理解，由于不同类型的技术栈所用的编程语言可能不同，因此不同类型的技术栈对应不同的运行监控模块，不同运行监控模块可以采用不同编程语言编写。

每个技术栈对应的监控模块均用于在应用程序运行过程中，获取应用程序的运行信息作为被监控信息并输出，不同技术栈对应的监控模块，其获取的被监控信息和被监控信息的输出路径有所不同。比如，spring对应的第一监控模块用于获取应用程序的全部运行信息作为被监控信息并输出至屏幕，django对应的第二监控模块用于获取应用程序的部分运行信息作为被监控信息并输出至指定文件夹。

当然，不同技术栈对应的监控模块，其获取的被监控信息和被监控信息的输出路径也可以均相同，如均获取应用程序的全部运行信息作为被监控信息并输出至指定监控平台。

本步骤中，基于第五对应关系，根据目标应用程序对应的目标技术栈的类型，确定目标技术栈对应的运行监控模块，将该运行监控模块，确定为目标应用程序对应的运行监控模块。

一个具体的实施例中，运行监控模块为metrics模块，目标技术栈为spring，则将spring对应的metrics-spring模块，确定为目标应用程序对应的运行监控模块。

步骤S212，在修改后的源代码中添加运行监控模块，并将添加有运行监控模块的源代码确定为用于建立目标镜像的修改后的源代码。

运行监控模块可以为一段代码，该代码的语言为目标技术栈能够支持的语言，在修改后的源代码中添加运行监控模块，可以是在修改后的源代码中添加一段代码，以实现监控目标应用程序运行的效果。

本步骤与图1的区别在于，将添加有运行监控模块的源代码确定为用于建立目标镜像的修改后的源代码，并执行步骤S214。

步骤S214，根据修改后的源代码，自动建立目标应用程序对应的目标镜像；其中，目标镜像用于使目标应用程序运行在容器平台上。

该步骤具体同步骤S108，这里不做重复。

图2中的方法与图1中的方法的区别在于，还在目标应用程序的源代码中增加运行监控模块，运行监控模块用于获取目标应用程序的运行信息并输出，从而起到在目标应用程序运行过程中，对目标应用程序的监控作用，以方便研发人员进一步研发目标应用程序，其中，目标应用程序的运行信息可以为目标应用程序的运行结果信息，或者为研发人员提前在运行监控模块中定义的，目标应用程序在运行过程中需要输出的信息。

考虑到目标应用程序容器化后，需要能够运行在各种容器平台上，本申请实施例中的方法还包括：

根据目标应用程序对应的目标技术栈的类型，获取目标技术栈对应的配置信息；

在目标应用程序基于目标镜像运行在容器平台上之前，将配置信息输出至容器平台的环境变量中。

一种情况下，本申请实施例中预设有第六对应关系，第六对应关系可以包括不同类型的技术栈与不同的配置文件之间的对应关系，比如spring对应的配置文件为web.xml，django对应的配置文件为settings.py，然后，基于该第六对应关系，确定目标技术栈对应的配置文件，并将配置文件中的信息作为配置信息。

另一种情况下，目标应用程序的源文件中记录有目标技术栈的配置信息，则，直接从源文件中获取目标技术栈的配置信息。比如，在上述步骤S104之前，从源代码中读取目标技术栈对应的配置信息，其中，目标技术栈对应的配置信息位于目标应用程序的源代码中。

然后，在目标应用程序基于目标镜像运行在容器平台上之前，将配置信息输出至容器平台的环境变量中。具体地，将配置信息抽取成key/value形式，输出至容器平台的环境变量中。

由于将目标技术栈的配置信息输出至容器平台的环境变量中，因此目标应用程序基于目标镜像运行在该容器平台上之后，能够避免因为缺少技术栈的配置信息而运行失败的问题，从而保证技术栈的顺利运行。

并且，获取目标技术栈对应的配置信息，并将配置信息输出至容器平台的环境变量中，能够使得目标应用程序容器化后，可以运行在各种容器平台上，从而扩大目标应用程序的运行场景。

进一步地，本申请实施例中，还可以在建立目标镜像时，在目标镜像增加目标应用程序的水平扩展模块、健康检查模块和自动恢复模块，其中，水平扩展模块用于自动实现应用程序的复制化运行，比如，当目标应用程序在一个容器中运行时，自动将目标应用程序扩展成多份，并运行在对应的多个容器中(可以每个容器运行一个目标应用程序)，从而使目标应用程序适应更大的数据访问量。

健康检查模块用于对目标应用程序进行运行情况检查，并在确定目标应用程序出现设定问题(如卡顿)时，输出提示信息。自动恢复模块用于在目标应用程序异常退出后，自动恢复目标应用程序。

综上，通过本申请实施例，能够实现目标应用程序的容器化，使得目标应用程序基于目标镜像运行在容器平台上，解决应用程序开发、测试、运维环境不一致和硬件资源不足等问题。并且，应用程序容器化的过程不需要人工干预，能够自动实现应用程序的容器化，相比手动实现应用程序容器化的方式极大提高了效率，解决了手动实现应用程序容器化实现时间长、成本高的问题。

对应上述的方法，本申请实施例还提供了一种应用程序容器化的装置，图3为本申请一实施例提供的应用程序容器化的装置的模块组成示意图，如图3所示，该装置包括：

第一确定模块31，用于确定待容器化的目标应用程序，并获取所述目标应用程序对应的源代码；

信息添加模块32，用于根据所述目标应用程序对应的目标技术栈的类型，在所述源代码中添加声明信息；其中，所述声明信息用于声明结合所述目标应用程序对应的运行依赖文件，建立所述目标应用程序对应的目标镜像；

代码修改模块33，用于根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求；

镜像建立模块34，用于根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像用于使所述目标应用程序运行在容器平台上。

可选地，还包括：

第二确定模块，用于根据所述源代码的目录结构和/或所述源代码的文件类型，确定所述目标应用程序对应的目标技术栈。

可选地，所述信息添加模块32具体用于：

根据所述目标应用程序对应的目标技术栈的类型，确定所述目标应用程序对应的运行依赖文件；

根据所述运行依赖文件生成声明信息，并将生成的所述声明信息添加在所述源代码中；

其中，所述声明信息用于声明结合所述运行依赖文件建立所述目标镜像。

可选地，所述代码修改模块33具体用于：

根据所述目标应用程序对应的目标技术栈的类型，在添加后的所述源代码中确定所述目标应用程序对应的日志处理代码；

对所述日志处理代码进行修改，以将所述目标应用程序的日志输出路径修改为满足所述镜像建立要求的指定路径；其中，所述日志处理信息包括所述日志输出路径。

可选地，还包括监控设置模块，用于：

在所述根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像之前，根据所述目标应用程序对应的目标技术栈的类型，确定所述目标应用程序对应的运行监控模块；

在修改后的所述源代码中添加所述运行监控模块，并将添加有所述运行监控模块的所述源代码确定为用于建立所述目标镜像的所述修改后的所述源代码；

其中，所述运行监控模块用于获取所述目标应用程序的运行信息并输出。

可选地，所述镜像建立模块34具体用于：

根据修改后的所述源代码、所述目标技术栈对应的原始镜像和所述目标技术栈对应的启动脚本，生成Dockerfile脚本文件；

根据所述Dockerfile脚本文件，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像中安装有所述运行依赖文件。

可选地，还包括信息输出模块，用于：

根据所述目标应用程序对应的目标技术栈的类型，获取所述目标技术栈对应的配置信息；

在所述目标应用程序基于所述目标镜像运行在容器平台上之前，将所述配置信息输出至所述容器平台的环境变量中。

通过本申请实施例，能够把目标应用程序抽象成目标技术栈，根据目标技术栈的类型修改目标应用程序的源代码，进而根据修改后的源代码自动建立目标应用程序对应的目标镜像，以实现目标应用程序的容器化，使得目标应用程序基于目标镜像运行在容器平台上，解决应用程序开发、测试、运维环境不一致和硬件资源不足等问题。并且，应用程序容器化的过程不需要人工干预，能够自动实现应用程序的容器化，相比手动实现应用程序容器化的方式极大提高了效率，解决了手动实现应用程序容器化实现时间长、成本高的问题。并且，结合目标应用程序对应的运行依赖文件，建立目标应用程序对应的目标镜像，能够避免目标应用程序运行在容器平台上时，由于缺少运行依赖文件导致运行失败的问题。

进一步地，基于上述的方法，本申请实施例还提供了一种应用程序容器化的设备，图4为本申请一实施例提供的应用程序容器化的设备的结构示意图。

如图4所示，应用程序容器化的设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器701和存储器702，存储器702中可以存储有一个或一个以上存储应用程序或数据。其中，存储器702可以是短暂存储或持久存储。存储在存储器702的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对应用程序容器化的设备中的一系列计算机可执行指令。更进一步地，处理器701可以设置为与存储器702通信，在应用程序容器化的设备上执行存储器702中的一系列计算机可执行指令。应用程序容器化的设备还可以包括一个或一个以上电源703，一个或一个以上有线或无线网络接口704，一个或一个以上输入输出接口705，一个或一个以上键盘706等。

在一个具体的实施例中，应用程序容器化的设备包括处理器，存储器，存储在存储器上并可在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述应用程序容器化的方法实施例的各个过程，具体包括以下步骤：

确定待容器化的目标应用程序，并获取所述目标应用程序对应的源代码；

根据所述目标应用程序对应的目标技术栈的类型，在所述源代码中添加声明信息；其中，所述声明信息用于声明结合所述目标应用程序对应的运行依赖文件，建立所述目标应用程序对应的目标镜像；

根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求；

根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像用于使所述目标应用程序运行在容器平台上。

可选地，计算机可执行指令在被执行时，还包括：

根据所述源代码的目录结构和/或所述源代码的文件类型，确定所述目标应用程序对应的目标技术栈。

可选地，计算机可执行指令在被执行时，所述根据所述目标应用程序对应的目标技术栈的类型，在所述源代码中添加声明信息；其中，所述声明信息用于声明结合所述目标应用程序对应的运行依赖文件，建立所述目标应用程序对应的目标镜像，包括：

根据所述目标应用程序对应的目标技术栈的类型，确定所述目标应用程序对应的运行依赖文件；

根据所述运行依赖文件生成声明信息，并将生成的所述声明信息添加在所述源代码中；

其中，所述声明信息用于声明结合所述运行依赖文件建立所述目标镜像。

可选地，计算机可执行指令在被执行时，所述根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求，包括：

根据所述目标应用程序对应的目标技术栈的类型，在添加后的所述源代码中确定所述目标应用程序对应的日志处理代码；

对所述日志处理代码进行修改，以将所述目标应用程序的日志输出路径修改为满足所述镜像建立要求的指定路径；其中，所述日志处理信息包括所述日志输出路径。

可选地，计算机可执行指令在被执行时，在所述根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像之前，还包括：

根据所述目标应用程序对应的目标技术栈的类型，确定所述目标应用程序对应的运行监控模块；

在修改后的所述源代码中添加所述运行监控模块，并将添加有所述运行监控模块的所述源代码确定为用于建立所述目标镜像的所述修改后的所述源代码；

其中，所述运行监控模块用于获取所述目标应用程序的运行信息并输出。

可选地，计算机可执行指令在被执行时，所述根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像，包括：

根据修改后的所述源代码、所述目标技术栈对应的原始镜像和所述目标技术栈对应的启动脚本，生成Dockerfile脚本文件；

根据所述Dockerfile脚本文件，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像中安装有所述运行依赖文件。

可选地，计算机可执行指令在被执行时，还包括：

根据所述目标应用程序对应的目标技术栈的类型，获取所述目标技术栈对应的配置信息；

在所述目标应用程序基于所述目标镜像运行在容器平台上之前，将所述配置信息输出至所述容器平台的环境变量中。

通过本申请实施例，能够把目标应用程序抽象成目标技术栈，根据目标技术栈的类型修改目标应用程序的源代码，进而根据修改后的源代码自动建立目标应用程序对应的目标镜像，以实现目标应用程序的容器化，使得目标应用程序基于目标镜像运行在容器平台上，解决应用程序开发、测试、运维环境不一致和硬件资源不足等问题。并且，应用程序容器化的过程不需要人工干预，能够自动实现应用程序的容器化，相比手动实现应用程序容器化的方式极大提高了效率，解决了手动实现应用程序容器化实现时间长、成本高的问题。并且，结合目标应用程序对应的运行依赖文件，建立目标应用程序对应的目标镜像，能够避免目标应用程序运行在容器平台上时，由于缺少运行依赖文件导致运行失败的问题。

进一步地，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述应用程序容器化的方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(RandomAccess Memory，简称RAM)、磁碟或者光盘等。

具体地，该计算机程序被处理器执行时，实现以下流程：

确定待容器化的目标应用程序，并获取所述目标应用程序对应的源代码；

根据所述目标应用程序对应的目标技术栈的类型，在所述源代码中添加声明信息；其中，所述声明信息用于声明结合所述目标应用程序对应的运行依赖文件，建立所述目标应用程序对应的目标镜像；

根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求；

根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像用于使所述目标应用程序运行在容器平台上。

可选地，该计算机程序被处理器执行时，还包括：

根据所述源代码的目录结构和/或所述源代码的文件类型，确定所述目标应用程序对应的目标技术栈。

可选地，该计算机程序被处理器执行时，所述根据所述目标应用程序对应的目标技术栈的类型，在所述源代码中添加声明信息；其中，所述声明信息用于声明结合所述目标应用程序对应的运行依赖文件，建立所述目标应用程序对应的目标镜像，包括：

根据所述目标应用程序对应的目标技术栈的类型，确定所述目标应用程序对应的运行依赖文件；

根据所述运行依赖文件生成声明信息，并将生成的所述声明信息添加在所述源代码中；

其中，所述声明信息用于声明结合所述运行依赖文件建立所述目标镜像。

可选地，该计算机程序被处理器执行时，所述根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求，包括：

根据所述目标应用程序对应的目标技术栈的类型，在添加后的所述源代码中确定所述目标应用程序对应的日志处理代码；

对所述日志处理代码进行修改，以将所述目标应用程序的日志输出路径修改为满足所述镜像建立要求的指定路径；其中，所述日志处理信息包括所述日志输出路径。

可选地，该计算机程序被处理器执行时，在所述根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像之前，还包括：

根据所述目标应用程序对应的目标技术栈的类型，确定所述目标应用程序对应的运行监控模块；

在修改后的所述源代码中添加所述运行监控模块，并将添加有所述运行监控模块的所述源代码确定为用于建立所述目标镜像的所述修改后的所述源代码；

其中，所述运行监控模块用于获取所述目标应用程序的运行信息并输出。

可选地，该计算机程序被处理器执行时，所述根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像，包括：

根据修改后的所述源代码、所述目标技术栈对应的原始镜像和所述目标技术栈对应的启动脚本，生成Dockerfile脚本文件；

根据所述Dockerfile脚本文件，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像中安装有所述运行依赖文件。

可选地，该计算机程序被处理器执行时，还包括：

根据所述目标应用程序对应的目标技术栈的类型，获取所述目标技术栈对应的配置信息；

在所述目标应用程序基于所述目标镜像运行在容器平台上之前，将所述配置信息输出至所述容器平台的环境变量中。

通过本申请实施例，能够把目标应用程序抽象成目标技术栈，根据目标技术栈的类型修改目标应用程序的源代码，进而根据修改后的源代码自动建立目标应用程序对应的目标镜像，以实现目标应用程序的容器化，使得目标应用程序基于目标镜像运行在容器平台上，解决应用程序开发、测试、运维环境不一致和硬件资源不足等问题。并且，应用程序容器化的过程不需要人工干预，能够自动实现应用程序的容器化，相比手动实现应用程序容器化的方式极大提高了效率，解决了手动实现应用程序容器化实现时间长、成本高的问题。并且，结合目标应用程序对应的运行依赖文件，建立目标应用程序对应的目标镜像，能够避免目标应用程序运行在容器平台上时，由于缺少运行依赖文件导致运行失败的问题。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种应用程序容器化的方法，其特征在于，包括：

确定待容器化的目标应用程序，并获取所述目标应用程序对应的源代码；

根据所述源代码的目录结构和/或所述源代码的文件类型，确定所述目标应用程序对应的目标技术栈；

根据所述目标应用程序对应的目标技术栈的类型和预设的第三对应关系，确定所述目标应用程序对应的运行依赖文件；所述第三对应关系是技术栈与依赖文件之间的对应关系；

根据所述运行依赖文件生成声明信息，并将生成的所述声明信息添加在所述源代码中；其中，所述声明信息用于声明结合所述目标应用程序对应的运行依赖文件，建立所述目标应用程序对应的目标镜像；

根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求；

获取Dockerfile脚本文件模板；

在所述Dockerfile脚本文件模板包括的四个部分分别写入所述目标技术栈对应的原始镜像的信息、修改后的所述源代码、所述运行依赖文件的安装指令以及所述目标技术栈对应的启动脚本，以生成Dockerfile脚本文件；所述安装指令根据所述声明信息写入；

根据所述Dockerfile脚本文件，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像用于使所述目标应用程序运行在容器平台上。

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求，包括：

根据所述目标应用程序对应的目标技术栈的类型，在添加后的所述源代码中确定所述目标应用程序对应的日志处理代码；

对所述日志处理代码进行修改，以将所述目标应用程序的日志输出路径修改为满足所述镜像建立要求的指定路径；其中，所述日志处理信息包括所述日志输出路径。

3.根据权利要求1所述的方法，其特征在于，在所述根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像之前，还包括：

根据所述目标应用程序对应的目标技术栈的类型，确定所述目标应用程序对应的运行监控模块；

在修改后的所述源代码中添加所述运行监控模块，并将添加有所述运行监控模块的所述源代码确定为用于建立所述目标镜像的所述修改后的所述源代码；

其中，所述运行监控模块用于获取所述目标应用程序的运行信息并输出。

4.根据权利要求1所述的方法，其特征在于，所述根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像，包括：

根据修改后的所述源代码、所述目标技术栈对应的原始镜像和所述目标技术栈对应的启动脚本，生成Dockerfile脚本文件；

根据所述Dockerfile脚本文件，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像中安装有所述运行依赖文件。

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

根据所述目标应用程序对应的目标技术栈的类型，获取所述目标技术栈对应的配置信息；

在所述目标应用程序基于所述目标镜像运行在容器平台上之前，将所述配置信息输出至所述容器平台的环境变量中。

6.一种应用程序容器化的装置，其特征在于，包括：

第一确定模块，用于确定待容器化的目标应用程序，并获取所述目标应用程序对应的源代码；

第二确定模块，用于根据所述源代码的目录结构和/或所述源代码的文件类型，确定所述目标应用程序对应的目标技术栈；

第三确定模块，用于根据所述目标应用程序对应的目标技术栈的类型和预设的第三对应关系，确定所述目标应用程序对应的运行依赖文件；所述第三对应关系是技术栈与依赖文件之间的对应关系；

信息添加模块，用于根据所述运行依赖文件生成声明信息，并将生成的所述声明信息添加在所述源代码中；其中，所述声明信息用于声明结合所述目标应用程序对应的运行依赖文件，建立所述目标应用程序对应的目标镜像；

代码修改模块，用于根据所述目标应用程序对应的目标技术栈的类型，对添加后的所述源代码进行修改，以将所述目标应用程序对应的日志处理信息调整至满足预设的镜像建立要求；

模板获取模块，用于获取Dockerfile脚本文件模板；

文件生成模块，用于在所述Dockerfile脚本文件模板包括的四个部分分别写入所述目标技术栈对应的原始镜像的信息、修改后的所述源代码、所述运行依赖文件的安装指令以及所述目标技术栈对应的启动脚本，以生成Dockerfile脚本文件；所述安装指令根据所述声明信息写入；

镜像建立模块，用于根据所述Dockerfile脚本文件，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像用于使所述目标应用程序运行在容器平台上。

7.根据权利要求6所述的装置，其特征在于，所述代码修改模块具体用于：

根据所述目标应用程序对应的目标技术栈的类型，在添加后的所述源代码中确定所述目标应用程序对应的日志处理代码；

对所述日志处理代码进行修改，以将所述目标应用程序的日志输出路径修改为满足所述镜像建立要求的指定路径；其中，所述日志处理信息包括所述日志输出路径。

8.根据权利要求6所述的装置，其特征在于，还包括监控设置模块，用于：

在所述根据修改后的所述源代码，自动建立所述目标应用程序对应的目标镜像之前，根据所述目标应用程序对应的目标技术栈的类型，确定所述目标应用程序对应的运行监控模块；

在修改后的所述源代码中添加所述运行监控模块，并将添加有所述运行监控模块的所述源代码确定为用于建立所述目标镜像的所述修改后的所述源代码；

其中，所述运行监控模块用于获取所述目标应用程序的运行信息并输出。

9.根据权利要求6所述的装置，其特征在于，所述镜像建立模块具体用于：

根据修改后的所述源代码、所述目标技术栈对应的原始镜像和所述目标技术栈对应的启动脚本，生成Dockerfile脚本文件；

根据所述Dockerfile脚本文件，自动建立所述目标应用程序对应的目标镜像；其中，所述目标镜像中安装有所述运行依赖文件。

10.根据权利要求6至9任一项所述的装置，其特征在于，还包括信息输出模块，用于：

根据所述目标应用程序对应的目标技术栈的类型，获取所述目标技术栈对应的配置信息；

在所述目标应用程序基于所述目标镜像运行在容器平台上之前，将所述配置信息输出至所述容器平台的环境变量中。

Images