CN114879984B - 动态构建docker镜像减少离线文件体积的方法 - Google Patents

Abstract

本发明涉及动态构建docker镜像减少离线文件体积的方法，包括S1、根据不同的运行环境构建与运行环境相适配的基础镜像；S2、编译打包应用程序；S3、传输需要升级和更新的应用程序；S4、应用服务器上若干需要升级和更新的应用程序共用一个基础镜像，通过离线构建的方式在客户的应用服务器上依赖共用的基础镜像、Dockfile构建脚本进行本地构建和生成镜像。本发明提供的方法用于减少全量安装包和单服务镜像的大小、节约网络传输带宽，在网络环境差的情况下，有利于单个服务的快速构建和升级。

Description

动态构建docker镜像减少离线文件体积的方法

技术领域

本发明属于计算机软件开发运维领域，具体涉及一种动态构建docker镜像减少离线文件体积的方法。

背景技术

由于公司服务模块比较多，架构基于微服务和容器云架构，所以整体镜像个数比较多，单个镜像大小在600M左右，总体压缩下来有20G，未压缩情况下40G左右，因此在网络带宽传输速度比较低的情况下，工作效率非常低下，有可能安装包一天都传输不完。原有对于整体的镜像打包是基于每个镜像在编译服务器上面直接生成，相当于每个镜像都包含了基础镜像，一个基础镜像大小在500M左右，比如一个平台部署40个服务，这40个服务中每个服务都需要配置一个基础镜像，相当于40个基础镜像的大小都包含在安装包中。需要把每个服务在编译服务器上生产对应的镜像文件，然后在传送至客户的应用服务器。

现有技术至少存在以下不足：

1、在编译环境构建的单个镜像文件比较大，不方便传输。因为镜像包含太多的重复数据。重复数据就是打包到每一个服务镜像文件中的基础镜像，传统的基础镜像报系统、运行环境以及相对应的系统工具。

2、构建任务多的时候，服务器耗时比较长、资源比较多。要经过更新代码，编译，打包镜像，上传仓库，导出；

3、直接镜像体积比较大，服务器带宽有限，同时更新镜像会造成下载速度非常缓慢；

4、在无网络环境的时候，更新周期会比较长，主要问题在于传输体积大并且拷贝。

发明内容

有鉴于此，本发明的目的在于克服现有技术的不足，提供一种动态构建docker镜像减少离线文件体积的方法，以减小单个或者整体镜像的体积大小、优化镜像构建方案可以加快部署时间和减少网络资源传输。

为实现上述目的，本发明采用的技术方案为：动态构建docker镜像减少离线文件体积的方法，包括如下步骤：

S1、根据不同的运行环境构建与运行环境相适配的基础镜像；

根据运行环境将公共的资源、软件包、环境依赖类库放到同一个镜像中制作一份适配各种软件类型服务运行环境的基础镜像；

S2、编译打包应用程序；

把源文件从版本管理服务中拉取或更新到最新，通过相应的构建脚本编译打包成能够在运行环境中运行的应用程序；

S3、传输需要升级和更新的应用程序；

将编译打包后需要升级和更新的应用程序传输到客户的应用服务器上；

S4、由需要更新的应用服务器构建相应的镜像；

应用服务器上若干需要升级和更新的应用程序共用一个基础镜像，通过离线构建的方式在客户的应用服务器上依赖共用的基础镜像、Dockfile构建脚本进行本地构建和生成镜像。

进一步的，采用本方法初次全量安装的步骤如下：

步骤一、初次全量安装包含一个步骤S1中制作好的基础镜像、一键安装的脚本、一个以上的单服务的应用程序、Dockfile构建脚本以及编写形成的对应该应用程序服务镜像的Dockerfile文件；

步骤二、将步骤一中的初次全量安装包传送至客户的应用服务器上；

步骤三、通过执行一键安装的脚本将步骤S1中制作好的基础镜像加载到客户的应用服务器上；

步骤四、在客户的应用服务器上，通过Dockerfile文件把各个单服务的应用程序通过共用已加载的基础镜像再构建成各自单服务的应用程序相对应的新的镜像；

步骤五、最后把一个以上的各自单服务的应用程序相对应的新的镜像安装部署到客户的应用服务器上。

进一步的，在步骤四中，在加载完基础镜像之后，遍历各个单服务的应用程序，遍历之后执行各自单服务的应用程序所对应的Dockerfile文件，进行构建各自单服务的应用程序相对应的新的镜像。

进一步的，在某个服务开发了新的功能、发布补丁升级或者发布新的单个服务版本的时候，需要进行单个服务升级；

单个服务升级时，只需要提供更新的应用程序，执行安装脚本，在客户的应用服务器本地通过Dockerfile构建脚本构建生成对应的单个服务的镜像。

进一步的，单个服务升级安装的步骤如下：

第一步、在编译服务器完成代码的更新编译工作之后，将一个以上的编译打包好的单个服务的更新应用程序传送至客户的应用服务器上，存放到预定的位置；

第二步、当前应用服务器上已有基础镜像，步骤一中已编写的该应用程序服务镜像的Dockerfile文件、Dockerfile构建脚本以及第一步中本次传送的单个服务的更新应用程序；

在客户的应用服务器上，通过Dockerfile文件把接收到的第一步中各个单服务的更新应用程序通过共用已加载的基础镜像和Dockerfile构建脚本再构建成各自单服务的更新应用程序相对应的新的更新镜像；

第三步、最后把一个以上的各自单服务的更新应用程序相对应的新的更新镜像安装部署到客户的应用服务器上进行单个服务升级。

进一步的，利用docker分层思想，应用服务器的应用程序在后期更新升级的过程中，只是更新相对发生变动的应用程序，在编译服务器完成代码的更新编译工作之后，只传送相对发生变动的应用程序至应用服务器上进行再构建生成镜像，并进行安装部署。

进一步的，应用服务器上使用构建脚本通过docker build命令批量构建各个应用程序目录的应用程序文件到 docker镜像仓库中，之后部署安装到客户的应用服务器上。

进一步的，在步骤S1中，制作的基础镜像中包含系统、软件运行环境、系统配置以及便于调试的系统工具；其中，系统工具包括网络管理工具、带宽测试工具、应用程序调试工具、抓包工具和流量查看工具中的一种或者多种；

不同程序语言编写的代码，运行环境是不相同的，基础镜像中需要配置有各种语言代码编写的应用程序所对应的运行环境，并进行运行环境的相关配置，以便满足各种应用程序能够在客户的应用服务器上依赖共用的基础镜像进行本地构建和生成镜像，同时应用程序能够在客户的应用服务器上正常运行。

进一步的，在步骤S2中，编译服务器上对于获取的源文件，需要根据程序语言的不同，通过自动化构建工具或者构建脚本编译打包成能够在运行环境中运行的应用程序。

进一步的，编译打包应用程序完成之后，根据各应用程序所使用的程序语言，编写与各应用程序相对应的Dockerfile文件；

若某应用程序是初次安装，那需要将编译打包后的应用程序和对应的编写好的Dockerfile文件一并传送至客户的应用服务器上；

若某应用程序已经在应用服务器上安装过，属于后续的单个服务升级，那只需要将编译打包后的需要更新的应用程序传送至客户的应用服务器上。

本发明采用以上技术方案，具体如下有益效果：

1、原有整体的镜像打包是基于每个镜像在编译服务器上面直接生成，相当于每个镜像都包含了基础镜像，一个基础镜像大小在500M左右。假定一个平台部署了40个服务，原有的做法是每一个服务中都含有500M左右的基础镜像。这样导出的镜像文件比较大，包含太多的重复数据，不方便传输。这种直接镜像体积比较大，服务器带宽有限，同时更新镜像会造成下载速度非常缓慢。本发明公开的方法是根据不同的运行环境构建一份与运行环境相适配的基础镜像。只制作一份基础镜像作为共用的基础镜像，采用本发明提供的方法，第2至n(n为平台应用服务器上需要部署的应用程序)应用程序不再需要如原有那样在每个服务中包含基础镜像，而是只需将应用程序本身编译打包后传输至客户的应用服务器上。在应用服务器端本地构建，减少整体安装包的大小，方便传输，节约平台安装部署时间；

2、原来的做法是要在编译服务器完成各个服务编译，并在编译服务器上完成镜像文件的制作；本发明中将各个服务传输到客户的服务器上进行本地构建和生成镜像。针对服务器没有公网和镜像服务器的环境，采用本发明的方法减小单个或者整体镜像的体积大小、优化镜像构建方案可以加快部署时间和减少网络资源传输。

3、本发明提供的方法用于减少全量安装包和单服务镜像的大小、节约网络传输带宽，在网络环境差的情况下，有利于单个服务的快速构建和升级。

4、本发明提供的方法通过离线构建的方式减少编译服务器的编译时间、整体安装包和版本的生成时间。

5、本发明提供的方法通过离线构建的方式减少整体安装包的大小，同时在网络带宽比较差的情况下，可以到现场后在现场用户服务器上进行离线构建生成需要的镜像，可以加快安装包传输，方便现场人员快速安装和部署。

本发明提供的方法通过离线构建的方式，在现场用户服务器上进行本地构建和生成镜像，加快单个服务升级的时间。使用本发明提供的构建方式后，原来600M+更新文件，现在只需要15M左右就可以完成单个服务的升级和更新，整体安装包压缩控制在2G左右。

附图说明

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

图1是本发明动态构建docker镜像减少离线文件体积的方法流程图；

图2是本发明初次全量安装流程图；

图3是本发明单个服务升级安装流程图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

请参阅图1，本实施例提供一种动态构建docker镜像减少离线文件体积的方法，包括如下步骤：本发明的核心思想是把公共的资源放在同一个镜像中，作为基础镜像。在离线的时候构建完成后按照一定规则存放更新内容，最后通过一键脚本由需要更新的应用服务器去构建镜像。

S1、根据不同的运行环境构建与运行环境相适配的基础镜像；

根据运行环境将公共的资源、软件包、环境依赖类库放到同一个镜像中制作一份适配各种软件类型服务运行环境的基础镜像；

在步骤S1中，制作的基础镜像中包含系统、软件运行环境、系统配置以及便于调试的系统工具；其中，系统工具包括网络管理工具、带宽测试工具、应用程序调试工具、抓包工具和流量查看工具中的一种或者多种；在现场没有公网的情况下，方便现场排查问题。

不同程序语言编写的代码，运行环境是不相同的，基础镜像中需要配置有各种语言代码编写的应用程序所对应的运行环境，并进行运行环境的相关配置，以便满足各种应用程序能够在客户的应用服务器上依赖共用的基础镜像进行本地构建和生成镜像，同时应用程序能够在客户的应用服务器上正常运行。

需要补充说明的是，首先制作基础镜像，需要根据运行环境的不同制作不通的镜像，如果已经制作好基础镜像则跳过该步骤。一个具体的例子就是java公共镜像需要centos:7，其余的JRE，时区配置，字符集配置，应用依赖的jar包，这些构建成为一个镜像，作为java程序的基础镜像。

S2、编译打包应用程序；

把源文件从版本管理服务中拉取或更新到最新，通过相应的构建脚本编译打包成能够在运行环境中运行的应用程序；

进一步的，在步骤S2中，编译服务器上通过自动化工具，例如jenkins或者自定义的脚本进行编译，首先把源文件从版本管理服务中拉取或更新到最新，需要根据程序语言的不同，通过自动化构建工具或者构建脚本编译打包成能够在运行环境中运行的应用程序。

作为一种优选的实施方式，编译打包应用程序完成之后，根据各应用程序所使用的程序语言，编写与各应用程序相对应的Dockerfile文件；

若某应用程序是初次安装，那需要将编译打包后的应用程序和对应的编写好的Dockerfile文件一并传送至客户的应用服务器上；

若某应用程序已经在应用服务器上安装过，属于后续的单个服务升级，那只需要将编译打包后的需要更新的应用程序传送至客户的应用服务器上。

需要补充说明的是，编译打包应用程序完成之后，根据各应用程序所使用的程序语言，编写与各应用程序相对应的Dockerfile文件；如果已经有该文件的话就不需要再次创建了。Dockerfile中基础镜像采用上面已经制作好的基础镜像。接着需要按照一定规则去保存，这样可以更方便的维护版本信息。如这样的目录下update/vsrsion/imageName/tagName/xxx，同时把编译好的程序拷贝到当前目录中，需要更新的内容已经制作好了。

传统的相关技术中该步骤是应用程序编译好后的文件直接通过docker的构建命令打包到本地docker中，然后上传到私服或者直接导出。

采用本发明提供的方法不但减少了构建服务器的构建时间，同时也节约了一个镜像文件(600M左右)的磁盘空间。

S3、传输需要升级和更新的应用程序；

将编译打包后需要升级和更新的应用程序传输到客户的应用服务器上；

S4、由需要更新的应用服务器构建相应的镜像；

应用服务器上若干需要升级和更新的应用程序共用一个基础镜像，通过离线构建的方式在客户的应用服务器上依赖共用的基础镜像、Dockfile构建脚本进行本地构建和生成镜像。

传统的相关技术中，在编译环境（编译服务器）对每一个服务构建相对于的单个镜像，因为镜像包含太多的重复数据，文件比较大；传统中重复数据是打包到公共镜像的东西，运行环境，系统工具，以及系统

直接镜像体积比较大，服务器带宽有限，同时更新镜像会造成下载速度非常缓慢；特别是在构建任务多的时候，服务器耗时比较长、资源比较多，要经过更新代码，编译，打包镜像，上传仓库，导出。在无网络环境的时候，更新周期会比较长，主要问题在于传输体积大并且拷贝。

采用本发明提供的方法，在应用服务器端本地构建，减少整体安装包的大小，方便传输，节约平台安装部署时间；在编译服务器做代码更新，编译工作，减少了安装包和版本的构建时间。

原有对于整体的镜像打包是基于每个镜像在编译服务器上面直接生成，相当于每个镜像都包含了基础镜像，一个基础镜像大小在500M左右，40个服务中每个服务都需要配置一个基础镜像，相当于40个基础镜像的大小都包含在安装包中，同时需要把在编译服务器上生成的每一个镜像文件传输至客户的应用服务器上。

采用本发明提供的方法，支持在安装包中打包镜像构建文件和基础镜像，在网络比较差的情况下，特别是服务器没有公网和镜像服务器的环境，可以到现场后在现场应用服务器进行离线构建生成需要的镜像，减少整体安装包的体积大小。

使用此种构建方式后，原来600M+更新文件，现在只需要15M左右就可以完成单个服务的升级和更新，整体安装包压缩控制在2G左右。

作为一种优选的实施方式本，如图2所示，采用本方法初次全量安装的步骤如下：

步骤一、初次全量安装包含一个步骤S1中制作好的基础镜像、一键安装的脚本、一个以上的单服务的应用程序、Dockfile构建脚本以及编写形成的对应该应用程序服务镜像的Dockerfile文件；

步骤二、将步骤一中的初次全量安装包传送至客户的应用服务器上；

步骤三、通过执行一键安装的脚本将步骤S1中制作好的基础镜像加载到客户的应用服务器上；

步骤四、在客户的应用服务器上，通过Dockerfile文件把各个单服务的应用程序通过共用已加载的基础镜像再构建成各自单服务的应用程序相对应的新的镜像；

在步骤四中，在加载完基础镜像之后，遍历各个单服务的应用程序，遍历之后执行各自单服务的应用程序所对应的Dockerfile文件，进行构建各自单服务的应用程序相对应的新的镜像。

步骤五、最后把一个以上的各自单服务的应用程序相对应的新的镜像安装部署到客户的应用服务器上。

编译服务器构建生成安装包时，安装包只包含一个步骤S1中制作好的基础镜像、一键安装的脚本、一个以上的单服务的应用程序、Dockfile构建脚本以及编写形成的对应该应用程序服务镜像的Dockerfile文件；此种构建方式减少整体安装包的体积大小。通过脚本的形式，在现场应用服务器本地一键进行构建和生成相关的服务镜像，然后一键进行安装和部署。

作为一种优选的实施方式本，在某个服务开发了新的功能、发布补丁升级或者发布新的单个服务版本的时候，需要进行单个服务升级；

单个服务升级时，只需要提供更新的应用程序，执行安装脚本，在客户的应用服务器本地通过Dockerfile构建脚本构建生成对应的单个服务的镜像。单个服务升级时，网络传输过程中，只需要传递对应的应用程序到现场本地应用服务器，放到指定的目录下，然后在本地服务器通过Dockerfile生成单个服务的运行镜像。

需要补充说明的是，拷贝update目录到应用服务器，在应用服务器构建镜像。如果是第一次需要先把制作的基础镜像导入到docker中。以目前某一个平台中的应用程序计算，压缩后20G+，解压后40G+的空间，这需要浪费很长的时间，以及大概70G的硬盘空间。采用本发明的方案后C++和java基础镜像500M，然后每个应用程序15M左右，全部应用合计不到2G，可以节省95%的磁盘空间以及需要下载的时间。Java应用依赖类库比较统一，可以进一步优化，把依赖的类库打包到基础镜像中，每个应用基本1M足够。按照公司100M带宽，原来下载时间由一个半小时左右变成一分钟左右，再算放从本地拷贝到服务器的时间（无公共网络访问所以要在经过一次拷贝），可以节省两个多小时的时间。对于更新部署，也可以减少90%以上的时间。

如图3所示，单个服务升级安装的步骤如下：

第一步、在编译服务器完成代码的更新编译工作之后，将一个以上的编译打包好的单个服务的更新应用程序传送至客户的应用服务器上，存放到预定的位置；

第二步、当前应用服务器上已有基础镜像，步骤一中已编写的该应用程序服务镜像的Dockerfile文件、Dockerfile构建脚本以及第一步中本次传送的单个服务的更新应用程序；

在客户的应用服务器上，通过Dockerfile文件把接收到的第一步中各个单服务的更新应用程序通过共用已加载的基础镜像和Dockerfile构建脚本再构建成各自单服务的更新应用程序相对应的新的更新镜像；

第三步、最后把一个以上的各自单服务的更新应用程序相对应的新的更新镜像安装部署到客户的应用服务器上进行单个服务升级。

作为一种优选的实施方式，本实施例中利用docker分层思想，应用服务器的应用程序在后期更新升级的过程中，只是更新相对发生变动的应用程序，在编译服务器完成代码的更新编译工作之后，只传送相对发生变动的应用程序至应用服务器上进行再构建生成镜像，并进行安装部署。

进一步的，应用服务器上使用构建脚本通过docker build命令批量构建各个应用程序目录的应用程序文件到 docker镜像仓库中，之后部署安装到客户的应用服务器上。

现有的相关技术中该步骤是需要通过docker load进行导入，因为传统的做法是在编译服务器上制作打包好每一个服务的镜像文件导出传送至客户的应用服务器上进行导入。而本方案是将编译后的应用程序传送至客户的应用服务器上，在应用服务器上进行本地批量构建。采用该方案并没有增加耗时。

相关技术中使用比较多的减少镜像体积的方式是选择比较小的删减版本的基础镜像，同时较少镜像构建层级和不必要的软件或系统调试工具，从而减少镜像的大小。这种方法虽然选择了删减版的基础镜像，但还是需要在编译服务器上对每个服务生成对应的镜像文件导出传送至客户的应用服务器上，还是需要占用较多的构建时间，同时导出的文件还是含有基础镜像。

总体来说，而本发明提供的动态构建方法大大减少了文件的体积，节省了传输的时间本发明提供的方案在后续应用程序升级更新的情况，只有15M左右。在没有网络的应用服务器环境下，急需解决问题，可以采用手机网络进行更新，可节约了大量的时间和流量成本。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内包括可以对上述实施例进行变化、修改、替换和变型。

Claims (8)

1.动态构建docker镜像减少离线文件体积的方法，其特征在于：包括如下步骤：

S1、根据不同的运行环境构建与运行环境相适配的基础镜像；

根据运行环境将公共的资源、软件包、环境依赖类库放到同一个镜像中制作一份适配各种软件类型服务运行环境的基础镜像；

S2、编译打包应用程序；

把源文件从版本管理服务中拉取或更新到最新，通过相应的构建脚本编译打包成能够在运行环境中运行的应用程序；

S3、传输需要升级和更新的应用程序；

将编译打包后需要升级和更新的应用程序传输到客户的应用服务器上；

S4、由需要更新的应用服务器构建相应的镜像；

应用服务器上若干需要升级和更新的应用程序共用一个基础镜像，通过离线构建的方式在客户的应用服务器上依赖共用的基础镜像、Dockfile构建脚本进行本地构建和生成镜像；

在步骤S1中，制作的基础镜像中包含系统、软件运行环境、系统配置以及便于调试的系统工具；其中，系统工具包括网络管理工具、带宽测试工具、应用程序调试工具、抓包工具和流量查看工具中的一种或者多种；

不同程序语言编写的代码，运行环境是不相同的，基础镜像中需要配置有各种语言代码编写的应用程序所对应的运行环境，并进行运行环境的相关配置，以便满足各种应用程序能够在客户的应用服务器上依赖共用的基础镜像进行本地构建和生成镜像，同时应用程序能够在客户的应用服务器上正常运行；

采用本方法初次全量安装的步骤如下：

步骤一、初次全量安装包含一个步骤S1中制作好的基础镜像、一键安装的脚本、一个以上的单服务的应用程序、Dockfile构建脚本以及编写形成的对应该应用程序服务镜像的Dockerfile文件；

步骤二、将步骤一中的初次全量安装包传送至客户的应用服务器上；

步骤三、通过执行一键安装的脚本将步骤S1中制作好的基础镜像加载到客户的应用服务器上；

步骤四、在客户的应用服务器上，通过Dockerfile文件把各个单服务的应用程序通过共用已加载的基础镜像再构建成各自单服务的应用程序相对应的新的镜像；

步骤五、最后把一个以上的各自单服务的应用程序相对应的新的镜像安装部署到客户的应用服务器上。

2.根据权利要求1所述的动态构建docker镜像减少离线文件体积的方法，其特征在于：在步骤四中，在加载完基础镜像之后，遍历各个单服务的应用程序，遍历之后执行各自单服务的应用程序所对应的Dockerfile文件，进行构建各自单服务的应用程序相对应的新的镜像。

3.根据权利要求2所述的动态构建docker镜像减少离线文件体积的方法，其特征在于：在某个服务开发了新的功能、发布补丁升级或者发布新的单个服务版本的时候，需要进行单个服务升级；

单个服务升级时，只需要提供更新的应用程序，执行安装脚本，在客户的应用服务器本地通过Dockerfile构建脚本构建生成对应的单个服务的镜像。

4.据权利要求3所述的动态构建docker镜像减少离线文件体积的方法，其特征在于：单个服务升级安装的步骤如下：

第一步、在编译服务器完成代码的更新编译工作之后，将一个以上的编译打包好的单个服务的更新应用程序传送至客户的应用服务器上，存放到预定的位置；

第二步、当前应用服务器上已有基础镜像，步骤一中已编写的该应用程序服务镜像的Dockerfile文件、Dockerfile构建脚本以及第一步中本次传送的单个服务的更新应用程序；

在客户的应用服务器上，通过Dockerfile文件把接收到的第一步中各个单服务的更新应用程序通过共用已加载的基础镜像和Dockerfile构建脚本再构建成各自单服务的更新应用程序相对应的新的更新镜像；

第三步、最后把一个以上的各自单服务的更新应用程序相对应的新的更新镜像安装部署到客户的应用服务器上进行单个服务升级。

5.根据权利要求4所述的动态构建docker镜像减少离线文件体积的方法，其特征在于：利用docker分层思想，应用服务器的应用程序在后期更新升级的过程中，只是更新相对发生变动的应用程序，在编译服务器完成代码的更新编译工作之后，只传送相对发生变动的应用程序至应用服务器上进行再构建生成镜像，并进行安装部署。

6.根据权利要求1至5任一项所述的动态构建docker镜像减少离线文件体积的方法，其特征在于：应用服务器上使用构建脚本通过docker build命令批量构建各个应用程序目录的应用程序文件到 docker镜像仓库中，之后部署安装到客户的应用服务器上。

7.根据权利要求1至5任一项所述的动态构建docker镜像减少离线文件体积的方法，其特征在于：在步骤S2中，编译服务器上对于获取的源文件，需要根据程序语言的不同，通过自动化构建工具或者构建脚本编译打包成能够在运行环境中运行的应用程序。

8.根据权利要求7所述的动态构建docker镜像减少离线文件体积的方法，其特征在于：编译打包应用程序完成之后，根据各应用程序所使用的程序语言，编写与各应用程序相对应的Dockerfile文件；

若某应用程序是初次安装，那需要将编译打包后的应用程序和对应的编写好的Dockerfile文件一并传送至客户的应用服务器上；

若某应用程序已经在应用服务器上安装过，属于后续的单个服务升级，那只需要将编译打包后的需要更新的应用程序传送至客户的应用服务器上。

Images