带你解读苏研openstack持续集成实践

持续集成

持续集成(Continuous Integration,简称CI)是指软件开发过程中个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。

持续集成核心价值

持续集成中的任何一个环节都是自动完成的,无需太多的人工干预,有利于减少重复过程以节省时间、费用和工作量。

苏研Openstack持续集成背景简介

在未搭建CI环境之前,openstack研发组代码质量基本都由代码评审人员review,但是人工review无法验证最新的代码是否能完成环境部署,涉及的功能点是否能测试通过,并且无法保证某个模块的修改对其它模块是否会产生影响。

因此我们决定引入openstack社区CI环境,但是社区的CI环境是根据source code通过devstack完成openstack单节点环境部署,不满足苏研的需求。经过和研发同事的讨论决定模拟生产环境的部署方式,将source code打包成rpm包放入yum repo,通过苏研自动化部署工具完成一套openstack集群环境部署。

苏研Openstack持续集成流程

组件工作流程

Gerrit

Gerrit主要负责代码的管理

Zuul

Zuul通过捕获Gerrit事件,找到对应的pipeline进行后续处理,而pipeline中定义了需要执行哪些Jenkins任务,这些都是在Zuul的配置文件layout.yaml中定义的,如下为一个check pipeline的片段:

从中我们可以看到check这个pipeline由gerrit的patchset-created/change-restored或comment-added(如:recheck)触发,成功后会返回verified:1消息给gerrit,失败返回verified:-1。

以上是check pipeline of cinder project需要执行的任务。

引入Zuul而不是直接使用Gerrit触发Jenkins的原因是:Jenkins job每次只能执行一个任务,如果一个测试需要执行1小时,每天只能执行24次测试,只能对24个修改做出验证,通过引入Zuul使Jenkins并发测试成为可能。

Zuul同时还可以很好的处理具有复杂依赖关系的多个patch,它也能监控正在执行的任务。

Gearman

在原来的实现中,Zuul完成"事件-pipeline-任务"的匹配后,就可以调用Jenkins执行具体的任务开始实际的测试了。

Jenkins用的是master/slave架构,一台master管理所有slave节点,但是在Jenkins的slave节点增加到一定数量后(大约100台),Jenkins的master节点就会出现问题而成为瓶颈。

同时master节点是单点部署,无法完成HA,为了扩展Jenkins而引入了Gearman。

加入Gearman后,Zuul不再与Jenkins直接交互,而是提交执行任务的请求给Gearman服务器,由Gearman服务器完成任务的分发(因为苏研openstack项目每天代码提交量不是很大,jenkins只部署了一台)。

测试节点通过注册到Gearman服务器,使得Gearman获知其可用,并被分配任务。

Jenkins Master节点通过Gearman的插件连接到Gearman服务器并获得任务。

以下是通过gearman命令查询jenkins job可以使用的slave节点

nodepool

可用于CI环境中虚拟机资源的弹性管理,可以提高测试环境中虚拟机的使用效率:需要测试的时候创建虚拟机,测试完成后删除虚拟机,目前nodepool管理的虚拟机都是通过对接的openstack环境来维护。

苏研CI测试运行方式

根据openstack研发组实际的情况,现在CI测试运行方式分为以下2种:

Check

Check用于验证每个对Gerrit提交的patch,它是对提交的patch单独进行测试。

例如:A修改了nova某一行代码,部署环境时nova项目的rpm包来自于A的源码打包,而其他项目的rpm包来自于CI自己维护的yum repo。

Post

对merge的代码进行打包,并合入到CI自己维护的yum repo。

环境部署

对于单元测试可能不需要实际的Openstack环境去执行,而对于集成测试则需要一整套的Openstack组件。

对于这些测试Jenkins任务会根据苏研的自动化部署工具搭建一套完整的Openstack集群环境:

3个控制节点,2个计算节点, nova/neutron/cinder/glance/rabbitmq/mysql等等服务都是采用高可用方案,neutron采用openvswitch+vxlan模式,glance和cinder对接的是预先安装好的ceph集群。

部署所需的机器全部来自nodepool创建的虚拟机。

执行测试

1.Style测试

严格的pep8要求检查

2.单元测试、代码覆盖率统计

3.功能测试

实际执行的测试用例也是在Jenkins的任务中定义,通过调用Tempest去实现。

Tempest是一整套Openstack集成测试框架,它的实现基于python的unittest2测试框架和nose测试框架,Tempest对Openstack终端发起一系列API请求,并且对终端的响应进行验证。Tempest通过config文件来描述整个测试环境,包括compute API端点,Keystone server以及Glance server安装的镜像的UUID等信息。

测试的主要模块有如下几部分:

api主要测试OpenStack API部分的功能

scenario主要根据一些复杂场景进行测试

整个CI过程浏览

开发者提交了一个patch

Zuul状态监控

CI执行过程中日志

自动匹配jira工单

测试结果输出

Gerrit上自动添加测试结果

Hygieia仪表盘

通过Hygieia我们能实时看到jira工单的状态,对应jenkins job每天执行情况,以及单元测试结果和代码覆盖率统计结果。

总结

搭建一套CI环境需要考虑的问题有很多,以下列举了几个重要的问题:

问题

1.CI整个过程中日志收集,CI整个流程完成后资源回收

2.部署失败或者测试失败等等异常情况处理

3.搭建自己的pip源(苏研openstack代码基于kilo版本开发,因为该版本社区已经不维护了,导致CI过程中需要的某些python包官网已经没有了)

4.维护自己的tempest项目(如:社区测试时虚拟机都是采用本地虚拟机,而苏研现在大多采用卷虚拟机)

5.nodepool对接的openstack环境改造/性能调优/运维

END

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180123G0OKAE00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券