为 OpenStack 等开源项目做贡献传统上包括个人和公司提供代码贡献，以添加新功能和修复错误。近两年来，我一直在使用裸机服务提供商 Packet 捐赠的硬件，在美国各地的用户组会议上运行一次性的 OpenStack 云，用于演示和实验室。六个月前，Packet 询问他们如何才能为社区做出更大的捐赠，这引导我们走上了构建社区云以支持 OpenStack 的道路。
每天，OpenStack 代码库中数百个代码提交都需要进行测试，作为由 Zuul 管理的持续集成系统的一部分，“Zuul 是一个驱动持续集成、交付和部署系统的程序，专注于项目门控和相互关联的项目。” 每个提交在人工审查之前都会经过一系列测试（或门控），并且门控在代码合并之前再次运行。所有这些门控都在由多家公共云提供商捐赠的虚拟机实例池（高峰时段超过 900 个实例）中运行。所有 OpenStack CI 都依赖于捐赠的计算资源。OpenStack Infra 团队协调所有这些云提供商，并作为我们捐赠这些资源的联系点。
我们着手构建一个云，其中所有计算资源都将专门用于 OpenStack Infra 计划。在构建我们的云时，我们必须满足 OpenStack Infra 团队设定的最低要求：支持 100 个并发 VM 实例，每个实例具有 8GB RAM、8 个 vCPU 和 80GB 存储空间。Packet 为我们分配了 11 台裸机服务器和一个 IPv4 /29 子网，用于浮动 IP。随着计算和网络资源的到位，我们继续进行 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 团队所获得的知识远远超过了我为用户组演示运行一次性云的经验。
如果您是 OpenStack 云提供商（公共或私有）并且有兴趣为 OpenStack 捐赠资源，我鼓励您与我或 OpenStack Infra 团队联系以获取更多信息。
John Studarus 将在 11 月 13 日至 15 日在柏林举行的 OpenStack 峰会上展示 我们构建 Zuul CICD 云的经验。
1 条评论