CentOS下搭建Teuthology Ceph自动化测试平台(一)

Ceph自动化测试环境teuthology的安装部署概要 ,这里转载一下别人的文章,介绍的很好。不过只需要注意ceph-qa-suite这个项目已经移动到ceph项目下就行 位于 ceph/qa/suite 目录下。另外作者的两篇文章都是基于Ubuntu搭建的,而我接下来介绍的是在CentOS下搭建的平台,这里再次感谢本文作者提供的文章。最后还会简单的写一篇使用介绍的文章 (绝不会像本文作者一样放鸽子,说好的install (3)呢,哈哈哈

Teuthology概述

teuthology是一款为了ceph而设计开发的自动化测试框架,主要使用的语言是Python,这是由于Python非常强大的多集群掌控能力,teuthology的主要功能是用来跑ceph开发的测试例,也就是ceph-qa-suite这个项目中写的那些测试配置,大多数为yaml风格的测试脚本。teuthology几乎可以说是无可取代的,因为ceph作为一个复杂的分布式存储系统,有着较高的复杂性的同时,带来了很多的不确定因素,这就需要一个强大的测试平台来保证它的可靠性,目前只有teuthology做到了这一点。
“teuthology”和“teuthology平台”是两个概念,teuthology本身仅仅相当于一个main函数,只是一个入口,当然,通过一些配置,你可以让teuthology跑的特别简单,但是那是毫无意义的,所以我们将讨论的是如何搭建teuthology平台。
本文致力于搭建一个公司内部使用的teuthology平台,当然,如果你的需求量不是特别大的话,你可以向ceph官方申请openvpn并使用他们提供的开放的teuthology平台,这样可以省去你很多的力气,但是如果你的开发团队比较大,而且一般是使用所谓的公司内网环境开发的话,那么本文可以很好的帮助到你。
在整个过程中,涉及到一些基本的shell知识,Python知识,虚拟机相关知识,Ubuntu作系统概念。本文只讨论teuthology在Ubuntu14.0LTS下的部署安装,ceph官方建议使用的是Ubuntu系统,甚至连内置的测试用户名称都被强制的Ubuntu。

关于我们:https://charpty.com
https://github.com/charpty
[email protected]

Teuthology安装步骤概述

按照安装步骤逐个介绍搭建teuthology平台需要的一些软件或者框架。
在此过程中也尽量是按照从简单到高级的顺序,后面某些功能如果是50人以下的ceph开发团队,我觉得也没有太大的必要进行配置,简单的teuthology平台以及能够满足大多数的测试要求。

1、pulpito

可以通过查看一下ceph官方的界面链接先睹为快:
http://pulpito.ceph.com/
这是ceph官方关于teuthology平台状态的展示界面,显示了目前ceph官方自己的teuthology平台共有多少资源,即拥有多少台机器(slave)来跑任务,它们的状态如何,当前有哪些任务在跑,成功还是失败,失败的日志是原因是什么,以及它们的日志展示等等,相当于一辆汽车的仪表盘。
pulpito是一个开源的项目:https://github.com/ceph/pulpito
该项目依赖于paddles项目

2、paddles

这是一个提供RESTful风格的API的Web项目,采用的是Json风格作为数据交互,相信做Web的人听了这个描述已经能够清晰知道了。不清楚的也没关系,大概的搜一下RESTful和JSon也能大概明白些。
通过类似于http://my-paddles.com/run/list 这样的请求,我们能方便的得到一串我们想要的Json风格数据。这个项目是pulpito项目的基石,pulpito只是一个展示的web界面,真正和数据打交道的是paddles,那么paddles到底把数据存到哪里了呢?这个可以通过配置paddles来决定,官方使用和推荐的是postgresql。你不需要太多的去了解这种数据库,甚至只需要会一两条命令即可,它的维护都是通过paddles来做的,你要做的只是告诉paddles它该把数据存到哪,它就会相应的把teuthology平台的数据都存到你指定的数据库中,并且当它接收到正确的HTTP请求时,它会把相应的数据从数据库中取出来,并以一定的格式返回给请求者。
同样的,这也是一个开源项目:https://github.com/ceph/paddles

3、supervisord

这是一个对进程进行守护、监控的软件,可以方便的管理进程,在本文中,它用户管理paddles和pulpito这两个项目对应的进程,为什么需要交给它管理,而不是直接运行paddles和pulpito呢,简单的,我们可以大家熟悉的inux自带的后台运行方式:

扫描二维码关注公众号,回复: 2347039 查看本文章
(bash xxx.sh)&
  
  
  • 1

来实现把我们的paddles或者pulpito运行到后台,这样做存在的问题是,我们不能随时的知道这两个进程的运行状态,虽然可以通过ps等命令查看,但是很不方便,如果出现崩溃,需要我们手工的去重启,如果整个机器重启了,也需要我们手工的去启动我们的paddles和pulpito,所以我们通过supervisord来管理我们的进程,这个工具使用非常的方便,基本上简简单的配置一次,再无后顾之忧。

4、ntp server

配置一台内部使用的ntp server,用于时间同步,这个很简单,配置文件改一两行就好了,就不说了。
这里也是举个例子,像这样确实十分简单的,大家都熟悉的安装组件,我们仅举这一个例子,后面还会碰到一些小巧型的组件需要安装,但是比较简单我们不在这里做描述,等安装到的时候自然会提到。

5、gitbuilder

首先你可以参考下ceph官方搭建好的gitbuilder
http://gitbuilder.ceph.com/
说白了这就是一个apt-get的源,你甚至可以通过apt-mirror实现将此源克隆岛你的本地,不过这只能是让你测试你有没有成功搭建teuthology平台而已,可以说是毫无意义的,我们要搭建自己的gitbuilder, 用与将我们自己的ceph代码编译成deb包并做成源(再次申明,本文只讨论Ubuntu14.0LTS下的情况),这样我们就可以在我们的teuthology中指定我们的gitbuilder地址,teuthology安装ceph时都将从这个地址来下载deb包并进行安装。
同时,这个模块也为公司内部的程序员提供了一个福利,开发者都知道,改过几行C++代码之后,要想测试,需要将其进行编译,如果只是客户端的代码,那么直接在本机make install就好了,但是如果涉及到系统结果的,需要在每个机器上都make install一下或者打deb到每个机器上进行安装,这个过程首先是非常慢的,而且由于各种依赖等原因,也是非常痛苦的,你搭建好gitbuilder之后,可以将你们公司感兴趣的使用ceph分支都编译一遍,然后告诉大家如何地址和如何配置,这样所有人都可以方便的通过apt-get install 命令安装各种分支,各种版本的ceph,非常方便。

6、git以及github

既然是要测试我们自己写的代码,那么我们的代码放在哪里呢?如何告诉teuthology呢?
这个方法非常的多,你可以自己搭一个git server,然后每次都从上面去获取,这样是我觉得teuthology一个奇怪的地方,它每次跑任务之前都会尝试去像指定的仓库更新代码,这样比较烦。所以我也做了一些更改,稍后具体安装时我们会提到。
这里说一下我们的做法,我们teuthology工作时指定的拉取所需项目的路径指定的是我们公司自己的github路径:
https://github.com/H3C
省去了自己去把所有的项目一个个的下载下来并做成仓库的麻烦步骤,当然我们teuthology的管理机器是可以上网的,当然,只需要上一次网即可,部署好了就都是内网环境了,实在不能上网的可以通过别的机器上网,然后拷贝到该机器上实现。
teuthology默认使用的是https://github.com/ceph,如果你不进行任何配置的话,使用的就是它了,我们不使用这个主要是公司力求稳定,不想项目的变化控制在他人手中,到时候他人随便改几行代码,然后我们已更新,都不知道为什么,而且我对其中个别项目进行了一定的修改,以便能够更好的在我们自己的环境中使用,大家也可以参考。
intel使用的是https://github.com/intel-bigdata

其实,teuthology工作时无非就拉取了以下几个项目:
首先,关于从teuthology从网上拉取项目,我想先说一下,我们公司虽然配置的是https://github.com/H3C是github.com的地址,但是只拉取一次,并且也只是teuthology管理节点需要上网,或者只需上一次网,甚至可以不上网,从别的机器上拷贝。teuthology每次跑任务的时候都会从网上拉取项目,这非常烦,我们将讨论如何让它就拉取一次就好,不重复拉取。拉取一次还有的好处就是不会因为别人修改代码导致你现有的已经可以正常运行的环境突然崩溃,如果真的需要更新直接通过git命令手动更新即可。

  1. ceph-qa-suite
    所有的测试脚本都在这里了,我们可以写一些自己的测试脚本放到这里
  2. ceph
    teuthology运行的时候也需要拉取ceph,你或许会奇怪,ceph不是在gitbuilder那里编译成deb并做成源了吗,teuthology按理说这要知道拉取这个源里的deb进行安装即可呀。是的,teuthology里的slave节点确实也就是这么做的,它们通过apt-get install的方式到gitbuilder上安装相应的ceph版本,但是它们还会去拉取一些测试脚本,这些脚本位于ceph代码中\qa\workunits下,他们将用于一些指定性的测试。默认的,teuthology将命令自己的slave节点到git.ceph.com上进行拉取,这就需要上网了,但是很明显,我们的teuthology管理节点也就一台机器,偶尔配置个代理(CCproxy)上个网,或者麻烦点从别的能上网的机器上拷贝一份都是可以的,但是我们的teuthology slave节点那么多,少则十几台,多则上百台,难道我们也需要给他们配置个代理,让他们上网吗,本文也将讨论这一问题,使其拉取我们指定的内网环境的git://my-git/qa/workunits以实现所有slave节点在跑测试任务时都无需上网的需求。
  3. ceph-cm-ansible
    就是ansible,只不过定义了很多的任务角色,你不太需要了解这个项目,只需要知道它是在teuthology跑任务的时候从你指定的基本地址中拉取的,例如我们公司指定的基本地址是:https://github.com/H3C,那么它就会拉取https://github.com/H3C/ceph-cm-ansible.git,就是这个意思,同样的,我们也有办法让这个项目只拉取一次,同样是为了照顾不能上网,或者说上网比较麻烦的朋友,如果没什么上网限制,只拉一次也好,每次都去拉取,浪费时间和网络,我个人认为只拉一次还有个好处就是避免因为别人改代码而引起你平台的错误,及时要更新,也应该是你主动的去指定git命令去更新,而不是莫名其妙的被teuthology更新了,整个teuthology使用过程中,我们都将贯穿这样的思想。
  4. teuthology
    是的,你没有看错,teuthology在运行的时候,还会尝试从网上或者你指定的路径拉取自身,它会想重置自身到master分支,然后尝试拉取,并执行初始化脚本,我们也会尝试避免这样的行为发生,如果你可以畅通上网,也不在乎网速,那倒无所谓。

总的来说,我们的策略是,复杂的,较多的项目管理,我们委托给github.com,这其实也只需要teuthology的管理节点能够上一次网,或者复制一次就能满足需求,然后简单的关于拉取ceph代码中的qa/workunits,我们就通过大家一个自己的git服务器来实现,这个git服务器上也就一个项目,那就是ceph,而且只用到它的读取功能即可,配置非常简单。

7、teuthology管理节点

好的,我们终于把前面的准备工作都做完了,现在我们要开始装teuthology本身了,我们将teuthology管理节点的安装分为两个部分:

  1. teuthology调度者
    它相当于是用户使用的入口,用户在该环境下执行命令,让teuthology开始执行用户指定的任务。我们通过创建一个用户来实现,我们直接创建一个用户名为:teuthology,让这个用户作为调度者,这个用户也就安装一些调度着的环境,其实很简单,就是几句简单的命令即可
  2. teuthology执行者
    它相当于是执行用户具体命令的环境,从任务队列中取出任务并到paddles中索要资源开始执行,最终把结果推送给paddles,以便在pulpito中展示。同样的,我们也给它创建一个用户:teuthworker,它的配置也是非常简单的。

8、teuthology slave节点

官方将其叫做任务资源,就是一些用来跑任务的机器,再说的直白一点,就是一些安装了ubuntu系统的实体机或者虚拟机,我们公司使用的是虚拟机,如果贵公司确实是有钱的话,可以准备50台物理机用于teuthology跑任务测试,性能和结果正确性都会提升。当然这些机器上要做一些基本的配置,比如说配置好ntp地址,清空掉apt-get的源,安装ceph相关的依赖等等。

9、autobuild-ceph

这个相当于是个扩展话题了,这个的应用场景是:你的公司开发的分支相当多,一个编译机器根本来不及编译,所以为了管理这些编译机器,你需要通过分布式的管理方法来管理这些编译机器,用的fabric实现。
目前看来很少有用得到的公司。

想必看到这里,你已经对teuthology的搭建步骤有了基本的了解,接下来我们进行实际的安装,由于篇幅问题,我将安装的步骤放在teuthology install(2) 中,以便你查看文章更加的方便。

猜你喜欢

转载自blog.csdn.net/csnd_pan/article/details/80985992