zuul zuul2 性能

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

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

所有测试实例和镜像实例均使用临时存储，而云的设置没有任何持久性存储。 尽管企业工作负载通常需要持久性存储，但是专用于运行连续集成作业实例的云并不需要。 当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团队联系以获取更多信息。

John Studarus将在11月13日至15日在柏林举行的OpenStack峰会上介绍我们构建Zuul CICD云所学的内容。

翻译自: https://opensource.com/article/18/10/building-zuul-cicd-cloud

zuul zuul2 性能