一种快速部署容器化的云计算测试平台的实现方法与流程

本发明涉及云计算技术领域，尤其涉及一种快速部署容器化的云计算测试平台的实现方法。

背景技术：

私有云(privateclouds)是为一个客户单独使用而构建的，因而提供对数据、安全性和服务质量的最有效控制。该公司拥有基础设施，并可以控制在此基础设施上部署应用程序的方式。私有云可部署在企业数据中心的防火墙内，也可以将它们部署在一个安全的主机托管场所，私有云的核心属性是专有资源。

随着云计算技术的快速发展，越来越多的公司尝试自己部署云计算平台，并在上面进行功能验证与测试，另外，也有大量的开发测试人员需要快速部署一套云计算平台用于开发测试。

openstack作为目前十分主流的私有云平台，已经被很多组织应用于其内部，提升其内部it基础架构运行和管理的效率。openstack部署一直是一个比较繁琐且容易出错但又非常重要的步骤，是一个组件私有云的前置环节。现有技术中，部署openstack的方案非常多，但是由于openstack自身的复杂性，以及部署环境的千差万别，导致部署起来十分困难。

目前，基于openstack的私有云进行快速部署的方法通常基于配置管理框架puppet管理openstack组件的软件安装、配置文件修改和资源依赖的处理等。该现有技术的缺陷：配置选项过多且许多配置需要根据系统环境的不同而进行手动调整，从而导致出错几率大大增加；同时，由于该现有技术无法自动安装linux操作系统。目前，兼容并运行openstack的linux操作系统需要预先安装完毕，并将相关信息(例如主机名称、ip地址)写入配置文件中，以便在部署openstack的时候进行读取，在此过程中仍然需要部署者进行人工参与干预并进行配置选项的调整，因此也会导致出错几率大大增加。

公开号为cn104580519a的中国发明专利申请公开了“一种快速部署openstack云计算平台的方法”。该现有技术的主要技术路线是将linux操作系统和openstack平台的各种服务、组件做成镜像模板，然后通过pxe、dhcp和tftp启动。该现有技术的缺陷：配置过程的操作过于复杂；此外，当已经部署的openstack中的某个节点需要重新配置时，需要重新制作镜像模板后重新部署，从而导致该现有技术存在不利于后期的维护及性能升级的缺陷；更重要的是，该现有技术无法适应不同厂商发布的不同版本的linux操作系统，openstack与不同厂商发布的不同版本的linux操作系统耦合严重，因此该现有技术也存在openstack与不同厂商发布的不同版本的linux操作系统兼容性不佳的问题。

有鉴于此，有必要对现有技术中的基于openstack云平台的部署方法予以改进，以解决上述问题。

技术实现要素：

本发明的目的在于公开一种快速部署容器化的云计算测试平台的实现方法，用以简化云计算测试平台的部署步骤，提高部署效率及部署过程的灵活性，提高openstack与不同厂商发布的不同版本的linux操作系统兼容性。

为实现上述目的，本发明提供了一种快速部署容器化的云计算测试平台的实现方法，包括以下步骤：

s1、使用vagrant的虚拟机描述文件配置部署节点的基本信息，运行vagrantup命令从公共仓库中拉取预装的linux操作系统，并在virtualbox中运行；在部署节点中安装docker并使用docker创建私有容器仓库；使用kolla制作openstack各个服务的容器镜像文件，保存至所述私有容器仓库中；

s2、遍历执行步骤s1的过程，以将所述容器镜像文件部署至目标节点。

作为本发明的进一步改进，步骤s1中的所述“在部署节点中安装docker并使用docker创建私有容器仓库”还包括：将ansible的配置文件配置完毕后，在虚拟机描述文件中加入调用ansible的命令，待部署节点正常运行后，通过调用ansible以自动安装docker。

作为本发明的进一步改进，还包括对对部署节点和目标节点中的虚拟机描述文件中的配置选项config.vm.box作修改的操作。

作为本发明的进一步改进，所述云计算测试平台为基于容器化的openstack云计算测试平台。

作为本发明的进一步改进，所述云计算测试平台运行于一个物理宿主机中。

作为本发明的进一步改进，所述步骤s2还包括当前一次容器镜像文件部署操作失败时，对目标节点中的残留dockervolume及挂载所述残留dockervolume的容器作手动清除操作或者自动清除操作，并将所述容器镜像文件重新部署至目标节点。

与现有技术相比，本发明的有益效果是：通过本发明，简化了云计算测试平台的部署步骤，提高了部署效率及部署过程的灵活性，提高了openstack与不同厂商发布的不同版本的linux操作系统兼容性。

附图说明

图1为基于本发明所示出的一种快速部署容器化的云计算测试平台的拓扑图；

图2为本发明所示出的一种快速部署容器化的云计算测试平台的实现方法中第一阶段的部署过程流程图；

图3为本发明所示出的一种快速部署容器化的云计算测试平台的实现方法中第二阶段的部署过程流程图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

在详细阐述本发明之前，对说明书涉及的主要技术名词作如下定义及解释：

1、openstack：基于开源的云计算管理平台项目，目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。

2、virtualbox：开源虚拟机软件。

3、vagrant：跨平台的虚拟机构建工具，能够通过一个配置文件来描述虚拟机，然后调用底层的virtualbox来创建虚拟机。

4、ansible：自动化部署运维工具，特点：分布式、无需客户端、轻量级。

5、kolla：将openstack各个服务进行容器化的项目，包括两部分：制作openstack各个服务对应的容器镜像文件；使用ansible部署容器镜像文件。

6、docker：开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的linux操作系统的计算机上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

7、公共仓库：docker公司搭建并面向所有用户的仓库。

接下来对本发明一种快速部署容器化的云计算平台的实现方法的具体实施方式作详细阐述。

参图1所示，在一台物理宿主机10上创建多台虚拟机(vm)，并其中一台虚拟机作为部署节点4，其他的虚拟机作为目标节点。部署节点4通过管理网络20耦合连接多个目标节点(即图1中的目标节点1、目标节点2、目标节点3……目标节点n)，用来存放openstack各个服务的容器镜像文件；其它的虚拟机作为部署的目标节点，这些目标节点作为最终部署的openstack的功能性节点。其中，目标节点n泛指上述目标节点1～3中任意一种功能性节点。

本实施方式所示出的一种快速部署容器化的云计算测试平台的实现方法所部署而成的云计算测试平台运行于一个物理宿主机10中，具有部署过程不受外界影响的有益效果。

参图1所示，该图1示出多个目标节点，分别是目标节点1(作为控制节点)、目标节点2(作为计算节点)和目标节点3(作为网络节点)。另外，可以根据需要和硬件配置相应增加目标节点的个数，并定义不同类型的目标节点。部署openstack时，按照图1中的箭头方向，将部署节点4上的openstack各个服务的容器镜像文件部署到各个目标节点上去，以完成整个基于openstack架构的云计算测试平台的部署。

在部署过程中可以使用kolla-ansibleprechecks命令来对部署环境进行预检，以便减少部署失败的风险；另外一旦部署过程发生错误，可以使用kolla-ansibledestroy--yes-i-really-really-mean-it命令来清除部署过程中的残留数据，在解决了出错问题并重新部署的时候，保证物理宿主机10中具备干净的部署环境，这样便保证了部署过程的幂等性，可以极大的降低了部署的失败几率。

在本实施方式中，该快速部署容器化的云计算测试平台的实现方法主要包括两个阶段。

参图2所示，第一阶段：制作openstack各个服务的容器镜像文件，并具体为下述第1步至第3步所示。

第1步：准备部署节点。

使用vagrant的虚拟机描述文件(vagrantfile)来配置部署节点4的基本信息，主要代码如下所示：

然后运行vagrantup命令。vagrant会从其公共仓库中拉取预装好的linux操作系统。为简化表述，在本说明书中，linux操作系统选用版本号为centos7的linux操作系统(以下简称“centos7”)。在virtualbox中将centos7运行，同时设置centos7在virtualbox中的名称，centos7运行后还会执行自动配置主机名称和ip地址的操作。

可以通过是否可以ssh到部署节点4中并验证ip地址和主机名称是否正确，来确定这一步是否被正确完成；如果有错误，可以先检查部署节点4的虚拟机描述文件(vagrantfile)、检查当前物理宿主机10和外网的连通性等来进行解决。具体的，可通过ping114.114.114.114(公开的dns服务器的地址)的ttl来进行与外网连通性的判断，只要有返回的数据包且没有丢包，可认定物理宿主机10与外网已经建立连接。

第2步：在部署节点中安装docker，并使用docker创建一个私有容器仓库(dockerregistry)。

优选的，在本实施方式中，所述在部署节点中安装docker并使用docker创建私有容器仓库还包括：将ansible的配置文件配置完毕后，在虚拟机描述文件(vagrantfile)中加入调用ansible的命令，待部署节点正常运行后，通过调用ansible以自动安装docker。从而使得安装docker的内容写在ansible的配置文件中。该第2步的主要代码如下所示。

其中，playbook.yml内容如下：

接着创建一个私有容器仓库(dockerregistry)，该创建操作对应命令的主要代码如下所示：

mkdir-p/root/image_repo

dockerrun-d-p4000:5000-v/root/image_repo:/var/lib/registry--restart＝always--nameregistryregistry:2

同时，在本实施方式中，还需要配置docker守护进程，使其可以使用刚才创建的私有容器仓库，可以通过在/lib/systemd/system/docker.service中加上启动参数。

execstart＝/usr/bin/dockerd--insecure-registry192.168.0.10:4000...

然后重启docker，代码为：systemctlrestartdocker。

这一步可以通过可以将任意一个容器镜像文件推送到刚创建的私有容器仓库中来验证是否已经正确执行；如果有错，可以检查docker配置和私有容器仓库的配置，查看是否正确启用了此私有容器仓库。

第3步：在部署节点4中使用kolla制作openstack各个服务的容器镜像文件并保存到私有容器仓库中。

具体的，首先下载并安装kolla，运行以下命令来制作所有的镜像并推送至私有容器仓库：

kolla-build--typesource--registry192.168.0.10:4000–push

这一步完后，可以查看私有容器仓库中是否所有的容器镜像文件都已经制作好来确定是否成功执行。由于需要从网络(具体为外网)上下载各种软件包和源代码，网络和软件源的不稳定等因素会造成执行失败，可以在稳定后进行重试，另外如果kolla的配置文件中有错误，也会造成创建容器镜像文件的失败。

具体的，采用命令：curl192.168.0.10:4000/v2/_catalog来查看私有容器仓库中的所有容器镜像文件。若结果与kolla-build--list-images命令列出的容器镜像文件一致，就可以认为所有的容器镜像文件都已经制作完毕。

参图1及图3所示，第二阶段、将制作好的容器镜像文件部署到目标节点上。

第4步、准备目标节点。

在vagrant的虚拟机描述文件(vagrantfile)中定义这三台目标节点的配置，主要代码如下所示：

可以看出定义了三个网段：管理网络20：192.168.0.0/24、计算网络30：192.168.1.0/24及外部网络40：192.168.2.0/24。外部网络40的作用是为openstack测试环境中的虚拟机提供访问外网的途径。

另外，在第1步中，定义的部署节点4的ip在管理网络20范围内，部署节点4便可以通过管理网络20来访问这目标节点、目标节点2及目标节点3。

虚拟机描述文件(vagrantfile)准备好之后运行vagrantup命令，同第1步中一样，vagrant会从公共仓库中拉取预装好的centos7，并在virtualbox中将centos7运行起来，同时会设置centos7在virtualbox中的名称，centos7运行后还会自动配置主机名称和ip地址。

同第1步中一样，可以通过是否可以ssh到部署节点4中，并验证ip和主机名称是否正确，从而确定这一步是否正确完成，如果有错误，可以先检查部署节点的虚拟机描述文件(vagrantfile)、检查当前物理机和外网的连通性等来进行解决。

第5步、在目标节点1、目标节点2及目标节点3中安装docker，并修改默认配置，使上述三个目标节点均可以使用部署节点4中已经被创建的私有容器仓库。通过配置docker守护进程，使述三个目标节点均可以使用已经被创建的私有容器仓库，可以通过在/lib/systemd/system/docker.service中加上启动参数，具体代码如下所示：

execstart＝/usr/bin/dockerd--insecure-registry192.168.0.10:4000...

然后重启docker，代码为：systemctlrestartdocker。

通过在这几台部署的目标节点中是否可以正确下载在第一阶段中创建的容器镜像文件，便可以验证当前这一步是否执行成功。如果有错，则检查当前节点的docker配置，确定是否正确启用了保存镜像的私有容器仓库。

具体的，若能够从第2步所述的私有容器仓库(dockerregistry)中拉取容器镜像文件，则证明第5步中的验证操作是否成功。具体代码为：

dockerpull192.168.0.10:4000/kolla/centos-source-nova-api，

其中，“kolla/centos-source-nova-api”是私有容器仓库(dockerregistry)中的一个容器镜像文件。

第6步：在部署节点4中使用kolla进行部署。

这一步需要做一点准备工作，即将3个目标节点的管理网络ip地址和每个节点对应的角色(例如控制节点、计算节点和网络节点)写入kolla的配置文件，以便使用kolla在部署openstack时便可以识别这些不同的目标节点。同样，这一步也可以通过调用ansible命令来自动完成。

通过这种方法将安装centos7与部署openstack这两个隔离的步骤融合到一起，便可以解决其它部署方式必须进行的大量手动配置的问题，既简化了容器化的云计算测试平台的部署流程，也有效的降低了由于配置错误所导致的部署失败的风险，从而大大提高了容器化的云计算测试平台的部署效率。

配置文件修改好之后就可以进行正式的部署了，运行下面的命令：

kolla-ansibledeploy

执行完成后一套完整的容器化的openstack的私有云平台已经就绪并部署完毕。

可以通过测试openstack各个功能是否可用来判断这一步是否成功执行，如果有任何问题，可以检查各openstack服务对应的容器运行状态和配置文件、检查kolla配置文件，发现问题之后重新运行命令进行部署即可。

具体的，如何验证第6步中是否成功执行具体为：

执行novaservice-list和neutronagent-list；如果执行成功，并且结果中可以分别列出计算节点(即目标节点2)和网络节点(即目标节点3)，并且都是active状态以及可以创建虚拟机和网络等资源证明使用kolla进行部署是否安装成功。

部署完成后，如果有扩容等需求，例如增加计算节点或者网络节点，可以按照本发明中第二阶段相同的步骤来进行扩容，由于在第一阶段已经准备好了私有容器仓库和容器镜像文件，所以第一阶段已经不需要重新执行；另外这种方式对于已经部署好的目标节点完全没有影响，这样便可以轻松方便地进行资源扩容。

本发明可以支持不同版本号、不同发行版的linux操作系统，我们上文中使用的是centos7的linux操作系统，也可以支持其它厂商或者不同版本的linux操作系统，比如主流的ubuntu/debian、suse等。我们需要做的只需要简单修改各个虚拟机配置文件(vagrantfile)中config.vm.box配置项即可实现自适应，具体代码如下所示：

config.vm.box＝"ubuntu/trusty64"，表示使用ubuntu14.0464bit；

config.vm.box＝"ubuntu/xenial64"，表示使用ubuntu16.0464bit；

config.vm.box＝"debian/jessie64"，表示使用debian864bit；

config.vm.box＝"suse/sles11sp3"，表示使用suse企业

版sles11sp3。

在第6步中，对第一次使用kolla进行部署时可能出现的部署失败的问题，本发明也提出了相应的解决方案，具体如下所示。

在部署过程中可能遇到部署失败的情况，出现mariadb数据库无法登录：

task[mariadb:creatinghaproxymysqluser]

failed-retrying:task:mariadb:creatinghaproxymysqluser(10retriesleft).

……

failed-retrying:task:mariadb:creatinghaproxymysqluser(2retriesleft).

failed-retrying:task:mariadb:creatinghaproxymysqluser(1retriesleft).

nomorehostsleft

toretry,use:--limit@/usr/share/kolla/ansible/site.retry

playrecap

controller1:ok＝49changed＝22unreachable＝0failed＝1

作为控制节点的目标节点1中包括数据库，并优先选用mariadb数据库。当第一次部署失败时，由于前一次使用kolla进行部署安装时的出错，导致控制节点中残留了一个dockervolume，而代码中存在bug。因此，在第二次使用kolla进行部署安装的时候一旦检测到了这个残留dockervolume，则会跳过初始化数据库(即mariadb数据库)的步骤，从而导致在两次配置过程中所设定的数据库密码的不同所导致的永远无法登录至mariadb数据库的问题，并最终导致无法成功部署的问题。

为此，在本实施方式中，在第6步中，还包括当前一次容器镜像文件部署操作失败时，对目标节点中的残留dockervolume及挂载所述残留dockervolume的容器作手动清除操作或者自动清除操作，并将所述容器镜像文件重新部署至目标节点。因此，需要清除mariadb中的dockervolume及相关的docker(容器)，然后重新进行部署。此时的docker为挂载有dockervolume的容器。为此可通过修改kolla本身的bug或者在部署前使用脚本清除所有残留数据(包括dockervolume及挂载有dockervolume的docker)来解决上述问题。

需要说明的是，此处所指的容器是指控制节点正在运行的容器。删除dockervolume的命令是dockervolumermmariadb，其中mariadb是dockervolume的名称，包含openstack中各组件数据库的数据。

具体的，手动清除残留dockervolume及挂载所述残留dockervolume的容器操作的方案具体为：

在所有的控制节点上运行以下命令清除dockervolume和正在运行的容器：

首先，在所有控制节点停止正在运行的mariadb容器，命令如下：

dockerstopmariadb；

然后，在所有控制节点删除容器，命令如下：

dockerstopmariadb；

最后，在所有控制节点清除dockervolume，命令如下：

dockervolumermmariadb。

自动清除残留dockervolume及挂载所述残留dockervolume的容器操作的方案具体为：

将以下内容写入ansible的配置文件中，通过运行ansible以自动清除控制节点上的残留dockervolume及挂载所述残留dockervolume的容器，其命令如下：

通过上述技术方案，可避免由于前后两次使用kolla进行部署安装时，避免由于两次配置过程中所设定的数据库密码的不同所导致的永远无法登录至mariadb数据库的问题，从而显著的提高了部署的成功率与简便性，防止出错。

在本实施方式中，采用vagrant与virtualbox的组合方案来统一部署openstack架构的云计算测试平台，将openstack部署在物理宿主机10的虚拟机中，并配置为具有不同功能的目标节点，解决了由于环境不一致所导致的部署失败的问题。同时，采用vagrant与ansible的组合，可支持不同版本的linux操作系统与部署openstack这两个独立的部署阶段实现有机整合，降低了用户部署难度。最后，由于采用私有容器仓库和容器镜像文件，从而大大降低了部署云计算测试平台的失败率。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。