如何构建OpenStack产品CI-CD体系

对OpenStack等开源项目做出贡献往往意味著个人和公司提供代码增加新功能和修复bug。近两年来笔者一直在使用裸机服务提供商Packet捐赠的硬件,在美国各地的用户组会议上的演示囷实验室运行一次性OpenStack云六个月前,Packet表示希望为社区做出更大的贡献这让我们走上了构建社区云以支持OpenStack的道路。

每天需要对OpenStack代码库的數百个代码提交进行测试,作为由Zuul管理的持续集成系统的一部分——“这是一个推动持续集成、交付和部署系统的计划重点关注项目选通和相互关联的项目。”每次提交都会在人工审核之前运行一系列测试(或gate)并且在代码合并之前gate会再次运行。所有这些gate都通过一些公囿云提供商捐赠的虚拟机实例池(高峰时间超过900个实例)运行所有OpenStack CI都依赖于捐赠的计算资源。OpenStack Infra团队协调所有这些云提供商并是捐赠这些资源的联系人。

我们着手构建一个云其中所有计算资源都专用于OpenStack Infra计划。构建我们的云我们必须满足OpenStack Infra团队设置的较低要求:支持100个并發VM实例,每个实例具有8GB RAM、8个vCPU和80GB存储数据包为我们分配了11个裸机服务器和一个用于浮动IP的IPv4 / 29子网。随着计算和网络资源的到位我们继续推進OpenStack架构和实施。

所有测试实例和镜像实例都使用临时存储云的设置没有任何持久存储。虽然企业工作负载通常需要持久存储但这不是專用于运行持续集成作业实例的云所必需的。当CI作业日志从云端撤回到中央服务器时CI作业的其余部分将在测试结束时进行处理。这允许夲来可以分配给持久存储服务(即Cinder和Ceph)的硬件资源被用于计算服务(Nova)

与OpenStack Infra团队合作,笔者了解了Zuul的功能以及团队整合的框架笔者有机會在最近的Project Teams Gathering(PTG)中与OpenStack Infra团队交流。他们意识到Zuul可以对任何云造成压力并乐于解决出现的问题。更好的是他们运行了一系列工具,提供诸洳失败的启动尝试次数和准备时间等指标使我们能够尽快发现问题。

像Zuul这样的CI系统会给云环境带来极大的负担因为它会不断地在虚拟實例中上下旋转。虽然一般实例可能持续数周或数月但通过Zuul的CI实例平均只存在几个小时。这意味着控制平面总是忙于停止和启动服务通过OpenStack Infra团队提供的工具,我们能够识别性能问题在运维的前几个月,我们很快意识到我们必须升级控制平面以处理工作负载并重新配置镜潒存储空间以处理Zuul每天创建的磁盘镜像

这个云的限制因素之一是IPv4寻址的可用性。每个测试实例都需要一个浮动IP地址才能与Zuul进行通信因為我们有计算资源、RAM和CPU来分组云,所以我们打算开始使用IPv6地址配置测试实例 Zuul和OpenStack Infra项目都已经支持IPv6。

虽然我们正在继续改进这个社区运行的雲但我们也期待着探索我们还可以在这个捐赠的硬件上提供什么。Nodepool具有处理OpenStack之外资源的驱动程序功能我们对使用自动裸机支持感兴趣。我们也希望通过同样的Zuul和Nodepool框架将CI资源扩展到其他开源项目

建立和运行这样的云是一种有益的体验,特别是与OpenStack Infra团队合作并看到他们与Zuul一起做的一切笔者通过运行云来支持OpenStack Infra团队获得的知识远远超过了笔者为用户组演示运行一次性云的经验。

如果你是OpenStack云提供商(公有或私有)并且有兴趣向OpenStack捐赠资源建议与笔者或OpenStack Infra团队联系以获取更多信息。

声明:文章收集于网络如有侵权,请联系小编及时处理谢谢!

欢迎加入本站公开兴趣群

,C/C++Python,PHPRuby,shell等各种语言开发经验交流各种框架使用,外包项目机会学习、培训、跳槽等交流

兴趣范围包括:Hadoop源玳码解读,改进优化,

场景定制与Hadoop有关的各种开源项目,总之就是玩转Hadoop

我要回帖

 

随机推荐