CN110032376A - 基于Docker的自动化软件部署方法及装置 - Google Patents

Abstract

本发明公开了一种基于Docker的自动化软件部署方法及装置，所述方法包括：从被部署软件的部署描述信息中找到被部署软件所需全部运行环境所对应的全部Docker镜像，或者，找到被部署软件所需部分运行环境所对应的部分Docker镜像；将全部Docker镜像文件和被部署软件包，或者，将部分Docker镜像、被部署软件包和未制作为Docker镜像的依赖软件包分发到部署节点并进行解压缩；实例化镜像，启动容器，并将被部署软件包，或者，将被部署软件包和依赖软件包挂载于所述容器中。

Description

基于Docker的自动化软件部署方法及装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于Docker的自动化软件部署 方法及装置。

背景技术

在现有技术中，云时代的自动化软件部署方法按技术路线可分为两种。第 一种方案以云主机为部署基质。其软件部署步骤为：步骤1，创建软件运行所 需的云主机；步骤2，执行脚本在创建好的云主机中安装配置依赖软件；步骤3， 复制软件并配置软件参数；步骤4，调用脚本启动软件。

由于依赖软件的安装配置情况复杂，故而该方案的一种变化是使用已配置 好依赖软件的云主机镜像来创建软件所需云主机，将安装配置依赖软件的过程 提前到自动化部署过程之外，由人工介入规避掉安装配置依赖软件的复杂性， 降低方案的整体技术难度。变化后的软件部署步骤为步骤1、3、4。该变化带来 的问题是云主机镜像数量的激增。设环境中操作系统数量为M，依赖软件的数 量为N，若每个操作系统中提前预置一个依赖软件，则所需云主机镜像数量为 M×N。每个软件的依赖软件数目通常不止一个。若每个操作系统中提前预置两 个依赖软件，则所需云主机镜像数量为那么，若每个操作系统中提前预 置1到P(P>0)个依赖软件，则所需云主机镜像数为当N较大时， 这个数字是很大的。当然，并不是每种依赖软件的组合都是有意义的，然而， 每个软件对依赖软件的配置要求也是不完全相同的，一增一减之下，所需云主 机镜像的数量仍是很大的数字。该变化的好处是回避了技术问题，坏处是带来 了管理问题。

第二种方案是以Docker镜像为部署基质。其软件部署步骤为：步骤1，分 发Docker镜像；步骤2，将软件参数附在启动命令中启动分发的Docker镜像。

由于Docker镜像中包含了软件的运行环境，故而这种方案的步骤比第一种 方案更简捷，技术难度也更低。镜像数量与软件数量一致，也未给管理上带来 额外的负担。第一种方案所用的云主机技术，在硬件层面实现虚拟化，需要有 额外的虚拟机管理应用和虚拟机操作系统。而Docker容器是在操作系统层面实 现虚拟化，直接复用本机操作系统，因此更加轻量级，性能方面也更加高效。 Docker的轻量级，体现在镜像小、启动快、资源占用少三个方面。性能方面， Docker容器有接近原生系统的表现，云主机则明显弱于原生系统。这些特点使 其更适用于云时代的软件自动化部署，目前已经大量作为PaaS产品的环境基础在使用。总体上来讲，第二种方案优于第一种方案。在实践中，第二种方案被 越来越多地使用，第一种方案正在逐渐地淘汰。

但上述第二种方案仍旧存在需要完善的地方，具体地：

1、毒镜像问题。由于Docker镜像是由被部署软件的提供者自行准备的， 故其来源是不可控的。被部署软件提供者所使用的基础镜像可能含有恶意程序 而其不自知，其也有可能有意在docker镜像中置入恶意程序以达成某些不可告 人的目的。毒镜像中可能的木马、后门等程序对整个系统而言是巨大的安全威 胁。毒镜像的识别在技术上而言是无法做到百分百检出的，只有控制镜像来源 才能杜绝毒镜像的问题。

2、镜像漏洞问题。漏洞问题对于软件来说是普遍存在的。目前从公共渠道 获取的Docker镜像中普遍存在有漏洞的软件，在被部署软件提供者的配合下， 可以通过扫描漏洞并升级软件或打补丁的方式解决漏洞问题。但漏洞问题会引 起麻烦的地方在于软件的漏洞是逐渐发现的，今时今日被视作安全的软件在未 来的某一天会被发现仍旧存在漏洞。对Docker镜像来说，升级软件或打补丁是 一个不能完成的操作。当发现一个镜像有漏洞时，只能放弃它，然后重新做一 个镜像。这意味着，在发现镜像有漏洞时，需要等待其提供者来修复该漏洞。 若提供者响应或处置不及时，对系统安全防护会造成很大的压力。当镜像中普 通存在的软件被发现有漏洞时，大批量镜像的更新升级是一个艰巨的工作。

3、镜像臃肿问题。由于技术水平的差异，同一个软件由不同的人作出的镜 像是有大有小的。镜像越小，启动越快，资源消耗越少。少量部署时，镜像大 小的影响不明显。规模大到一定程度后，资源的消耗就是一个不得不重视的问 题，镜像的精简不再是一个可做可不做的事情。Docker镜像是否足够精简很难 通过对Docker镜像外部特征的观测来判断，需要具备专业水平的人来制作镜像 来能作到最大化的精简，这也是大家都基于公开仓库中的基础镜像制作自己镜 像的原因之一。对自动化的软件部署系统而言，来自外部的镜像是臃肿还是精 简是未知的。可以要求软件提供者对镜像作精简，但其效果很难度量。

发明内容

本发明实施例提供一种基于Docker的自动化软件部署方法及装置，用以解 决现有技术中的上述问题。

本发明实施例提供一种基于Docker的自动化软件部署方法，包括：

从被部署软件的部署描述信息中找到被部署软件所需全部运行环境所对应 的全部Docker镜像，或者，找到被部署软件所需部分运行环境所对应的部分 Docker镜像；

将全部Docker镜像文件和被部署软件包，或者，将部分Docker镜像、被部 署软件包和未制作为Docker镜像的依赖软件包分发到部署节点并进行解压缩；

实例化镜像，启动容器，并将被部署软件包，或者，将被部署软件包和依 赖软件包挂载于所述容器中。

优选地，将全部Docker镜像文件和被部署软件包，分发到部署节点并进行 解压缩具体包括：

分发全部Docker镜像文件和被部署软件包到选定的部署节点；

将被部署软件包解压缩到第一目录D。

优选地，实例化镜像，启动容器，并将被部署软件包挂载于所述容器中具 体包括：

实例化镜像，启动容器，并通过启动参数将所述第一目录D挂载为容器内 的第一预定目录X。

优选地，将部分Docker镜像、被部署软件包和未制作为Docker镜像的依赖 软件包分发到部署节点并进行解压缩具体包括：

从被部署软件的部署描述信息中找到未被制作为Docker镜像的n个依赖软 件包；

分发部分Docker镜像文件、被部署软件包、以及依赖软件包到选定的部署 节点；

将依赖软件包解压缩到第二目录P_i，其中1<i<n；

将被部署软件包解压缩到第一目录D。

优选地，实例化镜像，启动容器，并将被部署软件包和依赖软件包挂载于 所述容器中具体包括：

实例化镜像，启动容器，并通过启动参数将所述第一目录D挂载为容器内 的第一预定目录X，将第二目录P_i挂载为容器内的第二预定目录Q_i。

优选地，将被部署软件包解压缩到第一目录D之后，所述方法进一步包括：

如果被部署软件有需要修改参数的配置文件，则对配置文件中的配置参数 进行修改。

优选地，将依赖软件包解压缩到第二目录P_i之后，所述方法进一步包括：

如果依赖软件有需要修改参数的配置文件，则对配置文件中的配置参数进 行修改。

优选地，所述第一预定目录X为容器预留的用于放置被部署软件的目录， 于制作Docker镜像时确定。

优选地，所述第二预定目录Q_i为容器中依赖软件的部署路径，其中，每个 依赖软件的部署路径均为固定的，在制作依赖软件包时指定。

本发明实施例还提供一种基于Docker的自动化软件部署装置，包括：存储 器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所 述计算机程序被所述处理器执行时实现上述方法的步骤。

采用本发明实施例，在基于容器技术的自动化软件部署系统中实现了对镜 像的完全控制，杜绝了由外部向自动化软件部署系统中输入毒镜像的可能，回 避了因容器中已知的软件漏洞导致的系统安全问题，解决了镜像臃肿问题，支 持了传统的通过配置文件来配置参数的软件的容器化部署。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术 手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、 特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领 域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并 不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的 部件。在附图中：

图1是本发明实施例的基于Docker的自动化软件部署方法的流程图；

图2是本发明实施例中基本软件部署的流程图；

图3是本发明实施例中外挂依赖软件部署的流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了 本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被 这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本 公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明实施例在现有技术中所述的第二种软件自动化部署方案的基础上构 建，从而形成一个更安全、更高效的软件自动化部署方案。

本发明实施例分离软件核心本体和软件运行支撑环境，将后者制作为docker 镜像，前者在容器启动时挂载于容器中。分离之后，docker镜像可以由自动化 软件部署系统的开发方或运维方集中制作，有效杜绝了毒镜像的出现，并保证 了镜像的精简程度在自动化软件部署系统的所有方可接受的范围内，可以全面 封堵镜像中已知的软件漏洞。在新的软件漏洞被发现后，也可以迅速地通过升 级软件或打补丁等方式更新镜像，及时封堵漏洞。

根据本发明的实施例，提供了一种基于Docker的自动化软件部署方法，图 1是本发明实施的基于Docker的自动化软件部署方法的流程图，如图1所示， 具体包括：

步骤1，从被部署软件的部署描述信息中找到被部署软件所需全部运行环境 所对应的全部Docker镜像，或者，找到被部署软件所需部分运行环境所对应的 部分Docker镜像；

步骤2，将全部Docker镜像文件和被部署软件包，或者，将部分Docker镜 像、被部署软件包和未制作为Docker镜像的依赖软件包分发到部署节点并进行 解压缩；

其中，将全部Docker镜像文件和被部署软件包，分发到部署节点并进行解 压缩具体包括：

分发全部Docker镜像文件和被部署软件包到选定的部署节点；

将被部署软件包解压缩到第一目录D。

其中，将部分Docker镜像、被部署软件包和未制作为Docker镜像的依赖软 件包分发到部署节点并进行解压缩具体包括：

从被部署软件的部署描述信息中找到未被制作为Docker镜像的n个依赖软 件包；

分发部分Docker镜像文件、被部署软件包、以及依赖软件包到选定的部署 节点；

将依赖软件包解压缩到第二目录P_i，其中1<i<n；

将被部署软件包解压缩到第一目录D。

步骤3，实例化镜像，启动容器，并将被部署软件包，或者，将被部署软件 包和依赖软件包挂载于容器中。

其中，实例化镜像，启动容器，并将被部署软件包挂载于容器中具体包括：

实例化镜像，启动容器，并通过启动参数将第一目录D挂载为容器内的第 一预定目录X。

其中，实例化镜像，启动容器，并将被部署软件包和依赖软件包挂载于容 器中具体包括：

实例化镜像，启动容器，并通过启动参数将第一目录D挂载为容器内的第 一预定目录X，将第二目录P_i挂载为容器内的第二预定目录Q_i。

在本发明实施例中，将被部署软件包解压缩到第一目录D之后，进一步包 括：

如果被部署软件有需要修改参数的配置文件，则对配置文件中的配置参数 进行修改。

在本发明实施例中，将依赖软件包解压缩到第二目录P_i之后，进一步包括：

如果依赖软件有需要修改参数的配置文件，则对配置文件中的配置参数进 行修改。

需要说明的是，第一预定目录X为容器预留的用于放置被部署软件的目录， 于制作Docker镜像时确定。第二预定目录Q_i为容器中依赖软件的部署路径，其 中，每个依赖软件的部署路径均为固定的，在制作依赖软件包时指定。

以下对本发明实施例的上述技术方案的两种实现方式分别进行说明。

根据本发明实施例的软件部署步骤见图1所述，具体包括如下处理：

步骤1，从软件的部署描述信息中找到被部署软件所需运行环境(含操作系 统及依赖软件)对应的镜像；

步骤2，分发镜像文件及被部署软件包至选定的部署节点；

步骤3，解压被部署软件包，记解压后的目录为D，如果软件有需要修改参 数的配置文件，执行步骤5，否则，执行步骤5；

步骤4，如果软件有需要修改参数的配置文件，则修改配置文件中的配置参 数

步骤5，实例化镜像，启动容器，并通过启动参数将目录D挂载为容器内 的目录X，其中，X是容器预留的用于放置软件的目录，制作镜像时确定。

对每一种可能的软件运行环境制作一个镜像，会出现背景技术中所述变化 的第一种方案遭遇的问题。为避免陷入这种困境，本发明实施例只制作常用软 件运行环境的镜像。不常用的软件运行环境通过在常用软件运行环境容器中挂 载所缺依赖软件的方式实现，这种情况下的软件部署步骤见图2所述，具体包 括：

步骤1，从软件的部署描述信息中找到被部署软件所需运行环境(含操作系 统及部分依赖软件)对应的镜像及其他的依赖软件包；设依赖软件包有n个；

步骤2，分发镜像文件、依赖软件包、被部署软件包至选定的部署节点；

步骤3，解压依赖软件包，记解压后的目录为Pi，1<i<n；如果软件有需要 修改参数的配置文件，执行步骤5，否则，执行步骤5；

步骤4，如果依赖软件有需要修改参数的配置文件，则修改文件中的配置参 数

步骤5，解压软件包，记解压后的目录为D；如果软件有需要修改参数的配 置文件，执行步骤6，否则，执行步骤7；

步骤6，如果软件有需要修改参数的配置文件，则修改文件中的配置参数；

步骤7，实例化镜像，启动容器，并通过启动参数将目录D挂载为容器内 的目录X，将目录Pi挂载为容器内的目录Qi，1<i<n。X是容器预留的用于放 置软件的目录，制作镜像时确定。Qi是依赖软件的部署路径，每个软件的部署 路径均是固定的，在制作依赖软件包时指定。

如上所述，本发明实施例提供了一种分离被部署软件和其运行环境的容器 化部署方案。有别于一般的将被部署软件和其运行环境整合为一个镜像的容器 使用方式，本发明实施例仅将被部署软件的运行环境做作为镜像，而后在启动 容器时通过挂载外部目录的方式将被部署软件置入其运行环境镜像生成的容器 中。即未运行时，软件与其运行环境分别管理，运行时，软件与其运行环境按 需组合。

本发明实施例还提供了一种分割常用依赖软件和非常用依赖软件的镜像管 理及使用方案。将软件运行环境进一步分割，常用的操作系统加依赖软件组合 封装为镜像，不常用的依赖软件单独管理，启动容器时通过挂载外部目录的方 式将这部分依赖软件置入所需容器中。即未运行时，软件运行环境分割为常用 组合及其他依赖软件分别管理，运行时，常用组合与其他依赖软件重新组成完 整运行环境。需要指出的是，软件运行环境并不限于这一种分割方式，如分割 为操作系统和依赖软件两部分，或分割为操作系统加无法挂载的依赖软件和其 他依赖软件两部分等方式均是可行的。

综上所述，本发明实施例具有如下有益效果：

1、在基于容器技术的自动化软件部署系统中实现了对镜像的完全控制。有 别于一般基于容器技术的自动玸部署系统中镜像由用户自动制作并提供的模 式，采用本发明的所述方案的自动化软件部署系统中，镜像是由自动化软件部 署系统的研制方或运维方制作并提供的，不会有无法追溯清楚来源的镜像出现。

2、杜绝了由外部向自动化软件部署系统中输入毒镜像的可能。基于前一效 果，有效控制了镜像的来源，使从外部输入毒镜像的途径消失。

3、回避了因容器中已知的软件漏洞导致的系统安全问题。因所有镜像均是 内部制作，处于完全受控状态，故可达成所有镜像中不存在已知软件漏洞这一 目标。当新的软件漏洞被发现时，可快速及时响应，升级镜像并替换有软件漏 洞的容器。从而回避了一般自动化软件部署系统中存在的因容器中已知软件漏 洞导致的安全问题。

4、解决了镜像臃肿问题。因所有镜像均是内部制作，可实施对镜像质量的 控制措施，从而保证镜像足够精简。此外，由于镜像中仅含软件运行环境，进 一步降低了镜像的大小，并同时减少了镜像的数量。

5、支持了传统的通过配置文件来配置参数的软件的容器化部署。镜像在实 例化为容器前及实例化为容器时，无法对修改镜像中的文件作修改，因此，比 较传统的通过配置文件来配置参数的软件是不适宜容器化的。本发明中，仅将 软件运行环境制作为镜像。在启动容器前，软件本体中的配置文件处于随时可 修改的状态。因此，采用本发明的所述方案的自动化软件部署系统中，支持传 统的通过配置文件来配置参数的软件的容器化部署。

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

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

Claims (10)

1.一种基于Docker的自动化软件部署方法，其特征在于，包括：

从被部署软件的部署描述信息中找到被部署软件所需全部运行环境所对应的全部Docker镜像，或者，找到被部署软件所需部分运行环境所对应的部分Docker镜像；

将全部Docker镜像文件和被部署软件包，或者，将部分Docker镜像、被部署软件包和未制作为Docker镜像的依赖软件包分发到部署节点并进行解压缩；

实例化镜像，启动容器，并将被部署软件包，或者，将被部署软件包和依赖软件包挂载于所述容器中。

2.如权利要求1所述的方法，其特征在于，将全部Docker镜像文件和被部署软件包，分发到部署节点并进行解压缩具体包括：

分发全部Docker镜像文件和被部署软件包到选定的部署节点；

将被部署软件包解压缩到第一目录D。

3.如权利要求2所述的方法，其特征在于，实例化镜像，启动容器，并将被部署软件包挂载于所述容器中具体包括：

实例化镜像，启动容器，并通过启动参数将所述第一目录D挂载为容器内的第一预定目录X。

4.如权利要求1所述的方法，其特征在于，将部分Docker镜像、被部署软件包和未制作为Docker镜像的依赖软件包分发到部署节点并进行解压缩具体包括：

从被部署软件的部署描述信息中找到未被制作为Docker镜像的n个依赖软件包；

分发部分Docker镜像文件、被部署软件包、以及依赖软件包到选定的部署节点；

将依赖软件包解压缩到第二目录P_i，其中1<i<n；

将被部署软件包解压缩到第一目录D。

5.如权利要求4所述的方法，其特征在于，实例化镜像，启动容器，并将被部署软件包和依赖软件包挂载于所述容器中具体包括：

实例化镜像，启动容器，并通过启动参数将所述第一目录D挂载为容器内的第一预定目录X，将第二目录P_i挂载为容器内的第二预定目录Q_i。

6.如权利要求2或4所述的方法，其特征在于，将被部署软件包解压缩到第一目录D之后，所述方法进一步包括：

如果被部署软件有需要修改参数的配置文件，则对配置文件中的配置参数进行修改。

7.如权利要求4所述的方法，其特征在于，将依赖软件包解压缩到第二目录P_i之后，所述方法进一步包括：

如果依赖软件有需要修改参数的配置文件，则对配置文件中的配置参数进行修改。

8.如权利要求3或5所述的方法，其特征在于，所述第一预定目录X为容器预留的用于放置被部署软件的目录，于制作Docker镜像时确定。

9.如权利要求5所述的方法，其特征在于，所述第二预定目录Q_i为容器中依赖软件的部署路径，其中，每个依赖软件的部署路径均为固定的，在制作依赖软件包时指定。

10.一种基于Docker的自动化软件部署装置，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至9中任一项所述的步骤。