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

了解一个团队在开发支持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团队所获得的知识远远超过了我为用户组演示运行一次性云的经验。