学会如何构建Zuul CI/CD云[Openstack]

2019-11-12 11:04:37 浏览数 (1)

了解一个团队在开发支持OpenStack的社区云时获得的有价值的见解。

传统上,为OpenStack等开源项目做贡献需要个人和公司提供代码贡献,以添加新特性并修复bug。近两年来,我一直在使用裸机服务提供商Packet提供的硬件,为全美各地的用户组会议上的演示和实验室运行一次性的OpenStack云。6个月前,Packet询问如何向社区提供更多的捐助,这让我们开始构建支持OpenStack的社区云。

每天,数百个提交到OpenStack代码库的代码需要作为Zuul管理的持续集成系统的一部分进行测试,Zuul是“一个驱动持续集成、交付和部署系统的程序,其重点是项目限制和相关的项目。”每次提交在进行人工审查之前都要经过一系列测试(或门),然后在代码合并之前再次运行这些门。所有这些门都运行在虚拟机实例池中(在高峰时间超过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的能力和团队构建的框架。我有机会在最近的项目团队聚会(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团队所获得的知识远远超过了我为用户组演示运行一次性云的经验。

0 人点赞