在为OpenStack构建Zuul 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团队联系以获取更多信息。