一种容器配置更新方法、装置、系统、存储介质及电子设备

技术领域

本发明涉及虚拟化技术领域，具体涉及一种容器配置更新方法、装置、系统、存储介质及电子设备。

背景技术

容器(docker)是一种内核轻量级的操作系统层虚拟化技术，一个容器包含了完整的运行时环境：一个应用、这个应用所需的全部依赖、类库、其他二进制文件以及配置文件，它们统一被打入一个包中。通过将应用平台及其依赖容器化，抽象掉操作系统发行版本和其他基础环境造成的差异，其中，应用是针对使用者的某种应用目的所编写的软件。

容器配置：软件项目在生命周期中，可能会部署到不同的环境中，比如说开发过程中部署在开发环境下进行功能验证，在完成开发后会部署到生产环境提交给用户使用，在不同的环境下需要使用不同的配置。

对于软件项目，基于容器(docker)技术解决了运行环境开箱即用的需求，但是良好的封装性使得容器环境下的配置更新和维护的成本较高，为了获取较好的配置更新便捷和效率，通常需要人工或者在代码层面做订制开发，占用大量的时间，同时增加了运维复杂度。

现有的针对不同容器环境的部署方案，常见下述几个方法：

(一)人工维护容器配置

1)开发人员根据配置需求修改配置文件，人工进行打包。

2)将打包文件构建容器镜像，推送到镜像仓库。

3)开发人员或者自动化平台登录到服务器，拉取镜像，启动服务。

(二)通过编写代码实现容器配置

1)通过中间件或者代码编写配置接口。

2)构建容器镜像，推送到镜像仓库。

3)开发人员或者自动化平台登录到服务器，拉取镜像，启动服务。

4)向容器发送指令，更新容器配置。

以上两种方法，需要开发人员具备构建镜像的知识储备和技能，每次对应不同的容器部署环境构建不同的镜像，过程复杂度随配置复杂度递增，易发生错漏导致应用部署事故。

发明内容

本发明提供一种容器配置更新方法、装置、系统、存储介质及电子设备，旨在降低容器配置的复杂度和减少配置成本。

第一方面，本发明提供一种容器配置更新方法，包括：

获取到部署镜像指令时，启动容器进程及常驻进程文件对应的常驻进程；

其中，所述常驻进程文件是根据应用资料生成的进程文件，所述常驻进程文件能够更新应用资料对应的配置，以及拉起和检测应用资料对应的应用进程；

将所述应用进程阻塞，所述常驻进程进行配置更新；

拉起所述应用进程。

根据本发明的实施例，优选地，上述容器配置更新方法中，在获取到部署镜像指令时，启动容器进程及常驻进程文件对应的常驻进程之前，所述方法还包括：从镜像仓库拉取镜像，其中，所述镜像是利用根据应用资料生成的常驻进程文件而生成的镜像描述文件构建的。

根据本发明的实施例，优选地，上述容器配置更新方法中，所述常驻进程进行配置更新，包括：

所述常驻进程检测是否存在新的配置；

若存在新的配置，则获取该新的配置进行配置更新，并在配置更新成功后拉起所述应用资料对应的应用进程；

若不存在新的配置，则直接拉起所述应用资料对应的应用进程。

根据本发明的实施例，优选地，上述容器配置更新方法中，所述常驻进程检测是否存在新的配置，包括：

所述常驻进程对当前的配置数据和待更新的配置数据进行比对：

若当前的配置数据和待更新的配置数据不一致，则存在新的配置。

根据本发明的实施例，优选地，上述容器配置更新方法中，所述拉起所述应用进程之后，所述方法还包括：

所述常驻进程检测所述应用资料对应的应用进程的状态并退出。

根据本发明的实施例，优选地，上述容器配置更新方法，还包括：

若所述应用进程的状态为运行成功，则容器处于运行状态；

若所述应用进程的状态为运行失败，则容器处于停止状态。

第二方面，本发明提供一种容器配置更新装置，包括：

启动模块，用于获取到部署镜像指令时，启动容器进程及常驻进程文件对应的常驻进程；

其中，所述常驻进程文件是根据应用资料生成的进程文件，所述常驻进程文件能够更新应用资料对应的配置，以及拉起和检测应用资料对应的应用进程；

更新模块，用于将所述应用进程阻塞，所述常驻进程进行配置更新；

拉起模块，用于拉起所述应用进程。

第三方面，本发明提供一种存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被一个或多个处理器执行时，实现第一方面所述的容器配置更新方法。

第四方面，本发明提供一种电子设备，包括存储器和处理器，所述存储器上存储有计算机程序，所述计算机程序被所述处理器执行时实现第一方面所述的容器配置更新方法。

第五方面，本发明提供一种容器配置更新系统，包括：

构建镜像服务器，用于解析镜像描述文件以获取应用资料，根据所述应用资料生成常驻进程文件，根据所述常驻进程文件生成新的镜像描述文件，根据新的镜像描述文件构建镜像，其中，所述常驻进程文件能够更新应用资料对应的配置，以及拉起和检测应用资料对应的应用进程；

镜像仓库服务器，用于保存构建的镜像；

容器配置服务器，用于保存容器的配置；

容器运行环境服务器，用于实现第一方面所述的容器配置更新的方法。

与现有技术相比，本发明至少具有如下有益效果：

本发明提供一种容器配置更新方法、装置、系统、存储介质及电子设备，容器部署方便、快捷，为容器的配置提供了一种新的方法，降低了容器配置的难度和成本，同时增加可靠性，有效降低了容器配置的复杂度和减少配置成本，用户通过发送镜像构建、推送、部署指令启动容器进程，容器进程首先通过启动常驻进程确保容器正常启动，然后完成容器环境的加载和配置后，随后通过常驻进程启动应用进程，常驻进程生命周期始终伴随应用进程生命周期，保证容器原生特性。

附图说明

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

图1是本发明实施例一提供的一种容器配置更新方法流程图；

图2是本发明实施例一提供的一种容器配置更新流程示意图；

图3是本发明实施例二提供的一个实例中配置更新前的配置文件；

图4是本发明实施例二提供的一个实例中配置更新后的配置文件；

图5是本发明实施例二提供的另一个实例中配置更新前的配置文件；

图6是本发明实施例二提供的另一个实例中配置更新后的配置文件；

图7是本发明实施例三提供的一种容器配置更新装置框图；

图8是本发明实施例六提供的一种容器配置更新系统拓扑图。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1示出了一种容器配置更新方法流程图，图2示出了一种容器配置更新流程示意图；如图1至图2所示，本实施例提供一种容器配置更新方法，包括如下步骤：

步骤S110、获取到部署镜像指令时，启动容器进程及常驻进程文件对应的常驻进程。

其中，常驻进程文件是根据应用资料生成的进程文件，常驻进程文件能够更新应用资料对应的配置，以及拉起和检测应用资料对应的应用进程。

优选地，可以解析应用资料(包括启动命令、工作路径、参数等)，通过python脚本生成常驻进程文件。

上述容器配置更新方法中，在步骤S110获取到部署镜像指令时，启动容器进程及常驻进程文件对应的常驻进程之前，该方法还包括：

步骤S100、从镜像仓库拉取镜像，其中，镜像是利用根据应用资料生成的常驻进程文件而生成的镜像描述文件构建的。

具体来说，镜像是这样构建出来的：

首先，解析容器(docker)的镜像描述文件dockerfile以获取应用资料。

其中，获取到的应用资料可以包括：启动命令、工作路径、应用的运行介质包等，应用的运行介质包，例如可以是jar包、war包等。

其次，根据应用资料生成常驻进程文件，该常驻进程文件能够更新应用资料对应的配置，以及拉起和检测应用资料对应的应用进程。

具体地，常驻进程文件在容器启动后，可以作为主进程文件，执行相应的进程(即常驻进程)，在应用进程拉起之前，先启动常驻进程进行应用资料对应的配置更新，以实现无需通过代码侵入方式修改用户的应用资料，即可完成容器的配置更新。

然后，根据常驻进程文件生成新的镜像描述文件dockerfile。

最后，根据新的镜像描述文件dockerfile构建出镜像。

可以理解的是，构建出的镜像推送至镜像仓库服务器的镜像仓库中进行保存，以供容器运行环境服务器部署镜像时拉取。

步骤S120、将应用进程阻塞，常驻进程进行配置更新。

具体地，通过在启动应用进程前，先将应用进程阻塞，启动常驻进程，保证整个容器的正常运行，此时，容器的状态为running，即运行状态，由常驻进程进行配置更新操作后，再由常驻进程根据镜像描述文件dockerfile中生成常驻进程文件所用的应用资料将对应的应用进程拉起。

上述常驻进程进行配置更新，还包括如下子步骤：

步骤S120-1、常驻进程检测是否存在新的配置。

具体地，常驻进程可以通过从容器配置服务器获取容器的配置数据，将获取的配置数据与当前的配置数据进行比对，以实现检测是否存在新的配置。优选地，常驻进程检测是否存在新的配置，进一步包括：

常驻进程对当前的配置数据和待更新的配置数据进行比对：

若当前的配置数据和待更新的配置数据不一致，则存在新的配置。

可以理解的是，若一致，则不存在新的配置。

步骤S120-2、若存在新的配置，则获取该新的配置进行配置更新，并在配置更新成功后拉起应用资料对应的应用进程。

具体地，当存在新的配置时，常驻进程可以从容器配置服务器中自动拉取新的配置数据，完成当前容器的配置更新。

步骤S120-3、若不存在新的配置，则直接拉起应用资料对应的应用进程。

具体地，当不存在新的配置时，常驻进程可以根据镜像描述文件dockerfile中生成常驻进程文件所用的应用资料将对应的应用进程拉起。

步骤S130、拉起应用进程。

在一种优选的实现方式中，在步骤S130拉起所述应用进程之后，本方法还包括：

步骤S140、常驻进程检测应用资料对应的应用进程的状态并退出。常驻进程生命周期始终伴随应用进程生命周期，保证容器原生特性。

若应用进程的状态为运行成功，则容器处于运行状态Running；

若应用进程的状态为运行失败，则容器处于停止状态Stopped。

本实施例通过在启动应用进程前，先将应用进程阻塞，启动常驻进程，保证整个容器的正常运行，由常驻进程进行配置更新操作后，再由常驻进程根据镜像描述文件dockerfile中的应用资料将对应的应用进程拉起，实现了无需通过代码侵入方式修改用户的应用资料，即可完成容器的配置更新。

下面结合一个实际应用示例，来说明本方法的应用。

已知一个java应用，通过解析在其dockerfile中的定义，获得该java应用的应用资料如下：应用介质名称cds.war，工作路径为/usr/local/tomcat，依赖版本为jdk8和tomcat8，启动命令为catalina.sh run，端口为8080。用户指定其应用的配置文件为/usr/local/tomcat/webapps/cds/WEB-INF/classes/conf/jdbc.properties。将以上应用资料通过python脚本生成可以执行的常驻进程文件，并生成以常驻进程文件为主要内容描述的新的镜像描述文件dockerfile，进而构建出java应用镜像推送至镜像仓库。

例如，用户在容器配置服务器定义新的配置文件版本jdbc.properties，将之前构建的镜像部署到容器运行环境中，进入容器运行环境查看，此时运行的配置文件版本为：jdbc.properties。在以上过程中，常驻进程完成了使用容器配置服务器上jdbc.properties版本的配置文件更新的过程。jdbc.properties更新前如图3所示，jdbc.properties更新后如图4所示。

再例如，用户在配置服务器继续定义新的配置文件版本为config.properties，将镜像部署到容器运行环境中，进入容器运行环境查看，此时运行的配置文件版本为：config.properties。在以上过程中，常驻进程完成了使用配置服务器上config.properties版本配置文件替换的过程。config.properties更新前如图5所示，config.properties更新后如图6所示。

与实施例一对应地，本实施例提供一种容器配置更新装置，如图7所示，包括如下模块：

启动模块210，用于获取到部署镜像指令时，启动容器进程及常驻进程文件对应的常驻进程。

其中，常驻进程文件是根据应用资料生成的进程文件，常驻进程文件能够更新应用资料对应的配置，以及拉起和检测应用资料对应的应用进程。

更新模块220，用于将应用进程阻塞，常驻进程进行配置更新。

拉起模块230，用于拉起应用进程。

可以理解的是，启动模块210可以用于执行实施例一中的步骤S110，更新模块220可以用于执行实施例一中的步骤S120，拉起模块230可以用于执行实施例一中的步骤S130，拉起模块230还可以用于执行实施例一中的步骤S140。

各步骤的具体实现方式请参见实施例一的相关内容，此处不再赘述。

显然本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这一本发明不限制于任何限定的硬件和软件结合。

本发明提供一种存储介质，该存储介质上存储有计算机程序，该计算机程序被一个或多个处理器执行时，实现实施例一的容器配置更新方法。

本实施例中，存储介质可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，例如静态随机存取存储器(Static Random Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-Only Memory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。

本发明提供一种电子设备，包括存储器和处理器，该存储器上存储有计算机程序，该计算机程序被该处理器执行时实现实施例一的容器配置更新方法。

本实施例中，电子设备可以是服务器，处理器可以是专用集成电路(ApplicationSpecific Integrated Circuit，简称ASIC)、数字信号处理器(Digital SignalProcessor，简称DSP)、数字信号处理设备(Digital Signal Processing Device，简称DSPD)、可编程逻辑器件(Programmable Logic Device，简称PLD)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述实施例中的容器配置更新方法。在处理器上运行的计算机程序被执行时所实现的方法可参照本发明实施例一提供的容器配置更新方法的具体实施例，此处不再赘述。

如图8所示，本实施例提供一种容器配置更新系统，包括：

构建镜像服务器，用于解析镜像描述文件以获取应用资料，根据应用资料生成常驻进程文件，根据常驻进程文件生成新的镜像描述文件，根据新的镜像描述文件构建镜像，其中，常驻进程文件能够更新应用资料对应的配置，以及拉起和检测应用资料对应的应用进程；

镜像仓库服务器，用于保存构建的镜像；

容器配置服务器，用于保存容器的配置；

容器运行环境服务器，用于实现实施例一的容器配置更新的方法。

其中，容器运行环境服务器可以为一个服务器集群。

本实施例中，构建镜像服务器通过解析镜像描述文件以获取应用资料，根据应用资料生成常驻进程文件，根据常驻进程文件生成新的镜像描述文件，根据新的镜像描述文件构建镜像，构建的镜像推送到镜像仓库服务器的镜像仓库中保存，以供容器运行环境服务器部署镜像时拉取，在启动应用进程前，先将应用进程阻塞，启动常驻进程，保证整个容器的正常运行，由常驻进程进行配置更新操作后，再由常驻进程根据镜像描述文件dockerfile中的应用资料将对应的应用进程拉起，实现了无需通过代码侵入方式修改用户的应用资料，即可完成容器的配置更新。

在本发明实施例所提供的几个实施例中，应该理解到，所揭露的系统和方法，也可以通过其它的方式实现。以上所描述的系统和方法实施例仅仅是示意性的。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

虽然本发明所揭露的实施方式如上，但所述的内容只是为了便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属技术领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式上及细节上作任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。