zuul zuul2 性能

传统上，对开源项目（例如贡献涉及个人和公司，他们提供代码贡献以添加新功能并修复错误。 近两年来，我一直在使用裸机服务提供商捐赠的硬件在美国各地的用户组会议上运行一次性的OpenStack云用于演示和实验室。 六个月前，Packet问他们如何向社区做出更大的捐赠，这使我们走上了构建社区云以支持OpenStack的道路。

每天，需要对数百个提交给OpenStack代码库的代码进行测试，并将其作为管理的持续集成系统的一部分，“ 是一个程序，用于驱动持续集成，交付和部署系统，重点是项目选通和相关项目。 ” 每次提交都要经过人工审查之前的一系列测试（或门），而门在代码合并之前再次运行。 所有这些门都运行在由许多公共云提供商提供的虚拟机实例池中（高峰时间超过900个实例）。 所有OpenStack CI都依赖于捐赠的计算资源。 团队协调所有这些云提供商，并成为我们捐赠这些资源的联络点。

所有测试实例和镜像实例均使用临时存储，而云的设置没有任何持久性存储。 尽管企业工作负载通常需要持久性存储，但是专用于运行连续集成作业实例的云并不需要。 当CI作业日志从云中拉回到中央服务器时，其余CI作业将在测试结束时处理。 这允许将原本应分配给持久性存储服务（即Cinder和Ceph）的硬件资源用于计算服务（Nova）。

与OpenStack Infra团队的合作使我对Zuul的功能以及该团队构建的框架大开眼界。 我有机会在最新的上赶上OpenStack Infra团队。 他们意识到Zuul可以给任何云带来压力，并乐于解决出现的问题。 更妙的是，他们运行了很多工具来提供度量指标，例如启动尝试失败和准备就绪的时间，使我能够尽快发现问题。

诸如Zuul之类的CI系统会不断旋转虚拟实例，从而给云环境带来了极大的负担。 虽然典型实例可能需要花费数周或数月的时间，但通过Zuul进行的CI实例平均只能存活几个小时。 这意味着控制平面始终忙于停止和启动服务。 通过OpenStack Infra团队提供的工具，我们能够确定性能问题。 在运营的最初几个月中，我们很快意识到我们必须扩大控制平面以处理工作量，并重新配置映像存储空间以处理Zuul每天创建的磁盘映像。

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

尽管我们一直在继续改善这个社区运营的云，但我们也期待探索我们可以在捐赠的硬件中提供什么。 具有驱动程序功能来处理OpenStack以外的资源，我们对使用自动化裸机支持感兴趣。 我们还希望通过相同的Zuul和Nodepool框架将CI资源扩展到其他开源项目。

设置和运行该云是一种有益的体验，特别是与OpenStack Infra团队合作并了解他们在Zuul上所做的一切。 我运行云以支持OpenStack Infra团队所获得的知识远远超出了我为用户组演示运行一次性云的经验。

如果您是OpenStack云提供商（公共或私有），并且有兴趣向OpenStack捐赠资源，我鼓励您与我或OpenStack Infra团队联系以获取更多信息。

John Studarus将在11月13日至15日在柏林举行的介绍学的内容。

翻译自:

zuul zuul2 性能