Swift Package Index我们最近将为我们的兼容性和文档构建系统提供支持的 Mac 构建机器，从手动配置和维护的 Mac mini 机器集合，过渡到一个新的 MacStadium 的 Orka 集群。
旧的裸机系统
我们之前的构建系统从 2020 年年中一台单独的 MacStadium 托管的 Intel Mac mini 发展到四台 Apple silicon M1 和 M2 Mac mini，每台配备 16GB 内存，这些机器一直生产运行，直到我们切换到新的 Orka 集群。
我们使用 GitLab 的 CI 系统来调度和跟踪我们构建系统中各个作业，因此我们旧系统中的每台构建机器都使用 GitLab runner 监听新的工作。当每个构建作业开始时，构建机器会检出包源代码，运行干净构建，运行 DocC 文档构建（如果包作者选择加入），将构建日志和包文档上传到 AWS S3，然后通过 Swift Package Index 上的 API 报告构建结果。我们在每台 Mac mini 上运行四个并发作业，总并发数为 16 个构建。
这种运行构建系统的方法非常有效，但也有缺点。最重要的是，构建之间没有隔离。我们在每台机器上同时运行四个不同包的构建，即使 Swift 编译器在 macOS 上运行时是沙盒化的，但这对于安全性和一致性来说也不是理想的情况。构建机器还在重启之间运行了成千上万甚至数十万次构建。我们从未遇到与此相关的无法解决的问题，但这始终是一个担忧。
这个系统的另一个主要缺点是需要在不同的机器上维护多个 macOS 安装。我们需要有四个不同版本的 Xcode 可用于为你在我们的兼容性矩阵中看到的四个不同版本的 Swift 进行构建，有时这意味着需要三个不同版本的 macOS，具体取决于 Xcode 系统要求。这导致一些构建机器过载，而另一些构建机器则未被充分利用。
新的 MacStadium Orka 系统
我们新的基于 Orka 的系统使用了一种截然不同的方法，即使用临时的虚拟机 (VM) 来执行完全隔离的构建。这意味着对于每个包的每次构建，我们现在都会启动一个新的 macOS 虚拟机，并通过 SSH 连接到它，然后执行与上面提到的相同的步骤。构建完成后，虚拟机将被销毁，其状态将被回滚，以便下一个构建获得一个全新的环境。
如果你在尝试 Orka 之前问我这是否可行，我可能会猜测每周启动数十万个虚拟机的开销将是令人望而却步的，因此当我们第一次与 MacStadium 讨论 Orka 时，得知虚拟机在几秒钟内启动时，我们感到非常高兴。当“几”秒钟变成不到三秒时，我们更加高兴
除了我们从完全隔离中获得的安全性和一致性优势之外，这个系统还有很多优点。我们还可以充分高效地使用集群。每个 Orka 主机都可以启动我们准备的任何 VM 镜像，使用任何带有任何已安装 Xcode 版本的操作系统，这意味着我们拥有的机器之间不再存在不均衡的使用情况。我们还从整个集群都位于防火墙之后获得了更多的安全性。
MacStadium 确实提供了与 Orka 配合使用的 GitLab runner（以及其他服务的其他 runner），但我们最终为我们的情况编写了一些自定义软件。这可能并不令人意外，因为我们在这里运行的是一种非常独特的构建系统！我们认为没有其他人做着和我们完全相同的事情！不过，该软件的复杂性并不高，它负责启动虚拟机、通过 SSH 执行构建命令并在完成后删除它们。
最后，它也为我们提供了未来的可能性。到目前为止，我们根本无法支持需要安装任何操作系统依赖项的包。有了每个构建的新虚拟机，这现在是我们可以开始构建的东西。
如果不告诉你我们现在运行的所有硬件，我们就无法结束本文，因为它非常令人印象深刻。我们正在运行 8 台配备 128GB 内存的 Mac Studio M1 Ultra 机器。这意味着我们的集群总规模为 160 个 M1 核心，总共 1TB 内存！
我们对这次构建能力的巨大升级感到非常满意。我们还要非常感谢 MacStadium 想出了一种方法，让像这样的开源项目也能使用这项技术。多年来，那里的团队一直非常乐于合作，我们提出的每一个要求都得到了“让我们想办法”的态度回应。
生产环境上线
Swift Package Index 处理的所有兼容性构建现在都在这个集群上执行，并且运行得非常好。我们还通过该集群为我们的 为 Swift 6 做好准备 项目运行了超过 250,000 次构建，因此它一直在努力工作！
我们对新的 Mac 集群只有一个愿望，那就是希望 Apple 取消对一台主机上可以运行多少虚拟机的限制。它在软件中被限制为每台主机最多两个虚拟机，如果将其提高到四个或八个，将使我们能够更有效地利用这些硬件。当我们的集群以 100% 虚拟机容量完全分配时，整个集群的有效 CPU 负载约为 30%。这是因为平均 Swift 构建过程在编译过程前后有相当多的停机时间，例如检出 git 存储库或将文档集上传到 AWS S3。增加每台主机的并发构建数量将使我们能够更有效地利用我们拥有的硬件。
希望你喜欢阅读一些关于我们的构建系统如何工作的内容，并且现在对幕后发生的事情有了更多的了解，从而创建你在包页面上看到的兼容性矩阵。如果你对此有任何疑问，我们很乐意在我们的 Discord 服务器上回答它们，所以请随时 加入并聊天。
注意： 为了充分披露，MacStadium 从一开始就支持 Swift Package Index。最初是允许我们使用一些托管的 Mac mini 机器，现在是通过大幅折扣我们的 Orka 订阅。