一种基于kolla-ansible的OpenStack跨版本升级方法

摘要

本申请公开了一种基于kolla‑ansible的OpenStack跨版本升级方法，在确定OpenStack的目标版本之后，能够根据目标版本，重装集群节点的底层操作系统，并对集群节点的python软件包进行升级；之后在部署节点上安装基础包及依赖文件，并根据目标版本对部署节点上的kolla‑ansible进行升级，对kolla‑ansible的关联文件和部署配置进行更新；最终执行kolla‑ansible，将OpenStack跨版本升级至目标版本。可见，该方法通过滚动升级集群中各节点底层操作系统版本，对控制层面和计算层面分别进行滚动升级，修改kolla‑ansible部署脚本，实现了OpenStack跨版本升级。此外，本申请提供了一种基于kolla‑ansible的OpenStack跨版本升级装置、设备及可读存储介质，其技术效果与上述方法的技术效果相对应。

说明书

技术领域

本申请涉及计算机技术领域，特别涉及一种基于kolla-ansible的OpenStack跨版本升级方法、装置、设备及可读存储介质。

背景技术

OpenStack是一个开源的云计算管理平台，发展至今已拥有众多版本，其版本是按照字母表逐一增加，当前最新的版本是V版。虽然OpenStack版本众多，但社区提供的升级方式仅能从当前版本升级到下一个版本。对于较老版本，例如O版本，若想要升级到U版本，按照社区升级方式需要进行6次逐次升级，而且从O版本升级到U版本的过程中，若底层操作系统采用centos，期间还涉及到操作系统版本升级。存在工作量巨大、升级过程繁琐的缺陷，而且多次升级增加了升级风险。

发明内容

本申请的目的是提供一种基于kolla-ansible的OpenStack跨版本升级方法、装置、设备及可读存储介质，用以解决目前的OpenStack升级方案只支持逐个版本升级，在当前版本和目标版本相差较多时，需要重复多次升级过程，非常繁琐的问题。其具体方案如下：

第一方面，本申请提供了一种基于kolla-ansible的OpenStack跨版本升级方法，包括：

根据升级指令，确定OpenStack的目标版本；

根据所述目标版本，重装集群节点的底层操作系统；

根据所述目标版本，对所述集群节点的python软件包进行升级；

在部署节点上安装基础包及依赖文件，并根据所述目标版本对所述部署节点上的kolla-ansible进行升级；

对kolla-ansible的关联文件和部署配置进行更新；

执行kolla-ansible，将所述OpenStack跨版本升级至目标版本。

优选的，所述根据所述目标版本，重装集群节点的底层操作系统，包括：

在集群节点的底层操作系统不为Centos8且所述目标版本大于T版本时，将所述集群节点的底层操作系统重装为Centos8。

优选的，所述集群节点包括控制节点，所述根据所述目标版本，重装集群节点的底层操作系统，包括：

对所述控制节点的docker数据文件及配置文件进行备份；

将所述控制节点的底层操作系统重装为Centos8；

在所述控制节点上安装Python的基础包；

还原所述控制节点上的所述docker数据文件及配置文件；

判断所述控制节点上是否存在openvswitch-agent容器；

若存在，则将所述openvswitch-agent容器升级为所述目标版本，并将所述openvswitch-agent容器内的代码替换为OpenStack的当前版本。

优选的，所述集群节点包括计算节点，所述根据所述目标版本，重装集群节点的底层操作系统，包括：

对所述计算节点的docker数据文件及配置文件进行备份；

判断所述计算节点上是否存在虚拟机；若存在，则将所述虚拟机迁移至另一计算节点；

将所述计算节点的的底层操作系统重装为Centos8；

在所述控制节点上安装Python的基础包；

还原所述控制节点上的所述docker数据文件及配置文件；

将所述控制节点上的openvswitch-agent容器升级为所述目标版本，并将所述openvswitch-agent容器内的代码替换为OpenStack的当前版本。

优选的，所述根据所述目标版本，对所述集群节点的python软件包进行升级，包括：

在所述目标版本大于T版本时，将所述集群节点中python软件包的版本升级为3.6。

优选的，所述对kolla-ansible的关联文件和部署配置进行更新，包括：

合并kolla-ansible升级前的password.yml文件和kolla-ansible升级后的password.yml文件；

将kolla-ansible升级前的multinode文件和global.yml文件，更新到kolla-ansible升级后的multinode文件和global.yml文件。

优选的，所述对kolla-ansible的关联文件和部署配置进行更新，包括：

将本地仓库中当前版本的镜像文件更新为所述目标版本的镜像文件；

将kolla-ansible中目标变量的值更新为false，所述目标变量用于表示升级过程中是否显示敏感信息；

在cinder数据库中将云硬盘的类型设置为默认云硬盘。

第二方面，本申请提供了一种基于kolla-ansible的OpenStack跨版本升级装置，包括：

目标版本确定模块：用于根据升级指令，确定OpenStack的目标版本；

系统重装模块：用于根据所述目标版本，重装集群节点的底层操作系统；

Python升级模块：用于根据所述目标版本，对所述集群节点的python软件包进行升级；

部署脚本升级模块：用于在部署节点上安装基础包及依赖文件，并根据所述目标版本对所述部署节点上的kolla-ansible进行升级；

部署配置更新模块：用于对kolla-ansible的关联文件和部署配置进行更新；

跨版本升级模块：用于执行kolla-ansible，将所述OpenStack跨版本升级至目标版本。

第三方面，本申请提供了一种基于kolla-ansible的OpenStack跨版本升级设备，包括：

存储器：用于存储计算机程序；

处理器：用于执行所述计算机程序，以实现如上所述的基于kolla-ansible的OpenStack跨版本升级方法。

第四方面，本申请提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现上所述的基于kolla-ansible的OpenStack跨版本升级方法。

本申请所提供的一种基于kolla-ansible的OpenStack跨版本升级方法，包括：根据升级指令，确定OpenStack的目标版本；根据目标版本，重装集群节点的底层操作系统；根据目标版本，对集群节点的python软件包进行升级；在部署节点上安装基础包及依赖文件，并根据目标版本对部署节点上的kolla-ansible进行升级；对kolla-ansible的关联文件和部署配置进行更新；执行kolla-ansible，将OpenStack跨版本升级至目标版本。

可见，该方法通过滚动升级集群中各节点底层操作系统版本，对控制层面、计算层面分别进行滚动升级，修改kolla-ansible部署脚本，实现了OpenStack跨版本升级。

此外，本申请提供了一种基于kolla-ansible的OpenStack跨版本升级装置、设备及可读存储介质，其技术效果与上述方法的技术效果相对应，这里不再赘述。

附图说明

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

图1为本申请所提供的基于kolla-ansible的OpenStack跨版本升级方法实施例一的流程图；

图2为本申请所提供的基于kolla-ansible的OpenStack跨版本升级方法实施例一的细化流程图图一；

图3为本申请所提供的基于kolla-ansible的OpenStack跨版本升级装置实施例一的细化流程图图二；

图4为本申请所提供的基于kolla-ansible的OpenStack跨版本升级装置实施例的功能框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

当前OpenStack社区仅提供逐个版本的升级方案，OpenStack社区的升级脚本不支持OpenStack跨版本升级，仅能从当前版本升级到下一个版本。若强行使用社区提供的升级脚本进行跨版本升级，则会出现升级失败现象。本实施例通过对升级脚本进行个性化修改，修复了跨版本升级过程中出现的问题，使得跨版本升级能够实现。

本申请的核心是提供一种基于kolla-ansible的OpenStack跨版本升级方法、装置、设备及可读存储介质，通过滚动升级集群中各节点底层操作系统版本，对控制层面、计算层面分别进行滚动升级，修改kolla-ansible部署脚本，实现了OpenStack跨版本升级。

下面对本申请提供的一种基于kolla-ansible的OpenStack跨版本升级方法实施例一进行介绍，参见图1，实施例一包括：

S101、根据升级指令，确定OpenStack的目标版本。

上述目标版本是指OpenStack预期升级至的版本，本实施例的目的在于将OpenStack从当前版本跨版本升级至目标版本。

S102、根据所述目标版本，重装集群节点的底层操作系统。

上述底层操作系统主要指Centos系统。具体的，当集群节点的底层操作系统版本不为Centos8且目标版本大于等于T(Train)版本时，将集群节点的底层操作系统滚动重装成Centos8系统；若集群节点的底层操作系统版本为Centos8或目标版本小于T版本，则不需要重装。比如，当前版本为O(Ocata)版本，底层操作系统是centos7，且目标版本是Q(Queues)版本，则不用重装底层操作系统。再比如，当前版本为O版本，底层操作系统是centos7，目标版本是U(Ussuri)版本，则需重装底层操作系统版本为centos8。

S103、根据所述目标版本，对所述集群节点的python软件包进行升级。

具体的，若目标版本小于T版本，不用升级Python软件包，若目标版本大于等于T版本，则需要进行升级。比如，当前版本为O版本，目标版本是Q版本，则不用升级python软件包。再比如，当前版本为O版本，目标版本是U版本，则需升级python软件包。

具体的，在对python软件包进行升级时，具体升级至3.6版本。

S104、在部署节点上安装基础包及依赖文件，并根据所述目标版本对所述部署节点上的kolla-ansible进行升级。

部署节点是一种专门用于部署openstack的节点，其可以在控制节点上，也可以在计算节点上，也可以单独作为一个节点。kolla-ansible是一个软件包，用于实现对OpenStack的升级操作。

升级OpenStack前，先将kolla-ansible升级到对应版本。比如，如果想要将OpenStack从O版本升级到Q版本，则需将部署节点的kolla-ansible软件先卸载掉，然后安装Q版本的kolla-ansible。再比如，如果想要将OpenStack从O版本升级到U版本，则需将部署节点的kolla-ansible软件先卸载掉，然后安装U版本的kolla-ansible。

S105、对kolla-ansible的关联文件和部署配置进行更新。

在一些具体的实施例中，所述对kolla-ansible的关联文件和部署配置进行更新，包括：合并kolla-ansible升级前的password.yml文件和kolla-ansible升级后的password.yml文件；将kolla-ansible升级前的multinode文件和global.yml文件，更新到kolla-ansible升级后的multinode文件和global.yml文件。

在一些具体的实施例中，所述对kolla-ansible的关联文件和部署配置进行更新，包括：将本地仓库中当前版本的镜像文件更新为所述目标版本的镜像文件；将kolla-ansible中目标变量的值更新为false，所述目标变量用于表示升级过程中是否显示敏感信息；在cinder数据库中将云硬盘的类型设置为默认云硬盘。

S106、执行kolla-ansible，将所述OpenStack跨版本升级至目标版本。

在实际应用中，集群节点包括两种角色，即控制节点和计算节点，在重装底层操作系统时，可以分别从控制层面和计算层面进行底层操作系统的滚动升级。

控制节点和计算节点具体可以是一台或多台服务器，在对控制节点或计算节点进行底层操作系统的升级时，具体可以采用滚动升级的方式，即一台机器一台机器的升级。

如图2所示，为控制节点升级底层操作系统的过程具体如下：

S201、对所述控制节点的docker数据文件及配置文件进行备份；

S202、将所述控制节点的底层操作系统重装为Centos8；

S203、在所述控制节点上安装Python的基础包；

S204、还原所述控制节点上的所述docker数据文件及配置文件；

S205、判断所述控制节点上是否存在openvswitch-agent容器；若存在，则进入S206，否则不做处理；

S206、将所述openvswitch-agent容器升级为所述目标版本，并将所述openvswitch-agent容器内的代码替换为OpenStack的当前版本。

如图3所示，为计算节点升级底层操作系统的过程具体如下：

S301、对所述计算节点的docker数据文件及配置文件进行备份；

S302、判断所述计算节点上是否存在虚拟机；若存在，则将所述虚拟机迁移至另一计算节点；

S303、将所述计算节点的的底层操作系统重装为Centos8；

S304、在所述控制节点上安装Python的基础包；

S305、还原所述控制节点上的所述docker数据文件及配置文件；

S306、将所述控制节点上的openvswitch-agent容器升级为所述目标版本，并将所述openvswitch-agent容器内的代码替换为OpenStack的当前版本。

可以看出，不同于控制节点，计算节点都有openvswitch-agent容器，所以不需要判断节点上是否存在openvswitch-agent容器。

本实施例所提供一种基于kolla-ansible的OpenStack跨版本升级方法，通过滚动升级集群中各节点底层操作系统版本，对控制层面、计算层面分别进行滚动升级，修改kolla-ansible部署脚本，实现了OpenStack跨版本升级。

下面开始详细介绍本申请提供的一种基于kolla-ansible的OpenStack跨版本升级方法实施例二。

实施例二以从R版本升级到U版本为例，对OpenStack跨版本升级过程进行说明。具体方式如下：

S401、将所有R版的控制节点底层操作系统滚动重装成Centos8系统。具体包括以下步骤：

1、停止该控制节点上的容器，并备份docker数据文件及配置文件。

2、重装一台R版控制节点的底层操作系统为centos8。

3、安装基础包，此处的基础包是指Python构建所依赖的安装包。

4、还原备份的docker容器文件及配置文件，重启docker服务。

5、如果控制节点有openvswitch-agent容器，则升级成U版本的openvswitch-agent容器，将容器内替换成R版本的代码。

S402、将所有R版的计算节点底层操作系统滚动重装为Centos8系统。具体包括以下步骤：

1、迁移虚拟机到其他计算节点，滚动重装宿主机操作系统到Centos8。

2、停止该计算节点上的容器，并备份docker数据文件及配置文件。

3、安装基础包。

4、还原备份的docker容器文件及配置文件，重启docker服务。

5、升级该控制节点的openvswitch-agent U版本容器，容器内替换成R版本代码，其他模块保持为R版本。这里的其他模块是指其他安装在计算节点的模块，一般包含：nova、openvswitch、chrony、kolla_toolbox、cron、fluent等容器。

6、迁回虚拟机。

S403、R版本Python软件包版本为2.7，升级到U版本后，Python软件包需升级到3.6。因此，将所有节点的python软件包版本从2.7升级到3.6。

S404、安装基础包及依赖，将部署节点kolla-ansible升级到10.1.0版本。kolla-ansible是一个软件包，其10.1.0版本对应于OpenStack的U版本。

S405、合并password.yml文件；更新multinode文件，更新global.yml文件。

合并password.yml文件，该文件是存储Openstack各个组件的密码，其在部署云平台时已存在，需按照顺序先升级kolla-ansible，才能够合并该文件。相关代码如下：

$mv/etc/kolla/passwords.yml passwords.yml.old

$cp kolla-ansible/etc/kolla/passwords.yml passwords.yml.new

$kolla-genpwd-p passwords.yml.new

$kolla-mergepwd--old passwords.yml.old--new passwords.yml.new–final/etc/kolla/passwords.yml

更新multinode文件，更新global.yml文件。具体的，将未升级kolla-ansible前的multinode、global.yml文件内容更新到升级后的multionde、global.yml文件中。

S406、更新本地仓库。本地仓库为OpenStack各个服务镜像文件，更新前改仓库内镜像文件为上一个OpenStack版本镜像文件，更新后为新版本OpenStack镜像文件。

S407、修改kolla-ansible部署脚本；修改云硬盘类型。

部署脚本文件下有个no_log变量，将该值改成False，no_log的作用在于执行ansible脚本时不显示敏感信息。具体的，把～roles/mariadb/tasks/lookup_cluster.yml:43的no_log值改为false。

修改cinder数据库中的volume表的volume_type_id值，给没有云硬盘类型的云硬盘选择默认云硬盘值。cinder数据库一般部署在控制节点，由mariadb容器提供服务。

S408、在部署节点执行kolla-ansible-i multinode upgrade操作进行升级。

可见，本实施例提供的一种基于kolla-ansible的OpenStack跨版本升级方法，可实现一次将OpenStack从R版升级到U版本，简化了openstack跨多版本升级步骤，减少客户业务停机时间，降低升级风险。

下面对本申请实施例提供的基于kolla-ansible的OpenStack跨版本升级装置进行介绍，下文描述的基于kolla-ansible的OpenStack跨版本升级装置与上文描述的基于kolla-ansible的OpenStack跨版本升级方法可相互对应参照。

如图4所示，本实施例的基于kolla-ansible的OpenStack跨版本升级装置，包括：

目标版本确定模块401：用于根据升级指令，确定OpenStack的目标版本；

系统重装模块402：用于根据所述目标版本，重装集群节点的底层操作系统；

Python升级模块403：用于根据所述目标版本，对所述集群节点的python软件包进行升级；

部署脚本升级模块404：用于在部署节点上安装基础包及依赖文件，并根据所述目标版本对所述部署节点上的kolla-ansible进行升级；

部署配置更新模块405：用于对kolla-ansible的关联文件和部署配置进行更新；

跨版本升级模块406：用于执行kolla-ansible，将所述OpenStack跨版本升级至目标版本。

本实施例的基于kolla-ansible的OpenStack跨版本升级装置用于实现前述的基于kolla-ansible的OpenStack跨版本升级方法，因此该装置中的具体实施方式可见前文中的基于kolla-ansible的OpenStack跨版本升级方法的实施例部分，例如，目标版本确定模块401，系统重装模块402，Python升级模块403，部署脚本升级模块404，部署配置更新模块405，跨版本升级模块406，分别用于实现上述基于kolla-ansible的OpenStack跨版本升级方法中步骤S101，S102，S103，S104，S105，S106。所以，其具体实施方式可以参照相应的各个部分实施例的描述，在此不再展开介绍。

另外，由于本实施例的基于kolla-ansible的OpenStack跨版本升级装置用于实现前述的基于kolla-ansible的OpenStack跨版本升级方法，因此其作用与上述方法的作用相对应，这里不再赘述。

此外，本申请还提供了一种基于kolla-ansible的OpenStack跨版本升级设备，包括：

存储器：用于存储计算机程序；

处理器：用于执行所述计算机程序，以实现如上文所述的基于kolla-ansible的OpenStack跨版本升级方法。

最后，本申请提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现上文所述的基于kolla-ansible的OpenStack跨版本升级方法。

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

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的方案进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。