Jenkins 最新公告称将与 Microsoft 合作基于 Azure 运行自己的项目基础结构。其中包括但不限于 Jenkins 开发者基础结构，例如该公司旗下的开发者维基、问题跟踪管理软件、数据库，以及静态内容。迁移至 Azure 可为自己的工作负载提供更高灵活性，同时能为 Jenkins 的诸多服务提供额外的资源。
该公司目前的基础结构由大量物理和虚拟计算机组成，其核心计算机托管在 OSUOSL ，其余系统分散托管在 AWS、Rackspace，以及物理数据中心内。InfoQ 就此次合作对 Jenkins 的意义等细节问题采访了 Jenkins 社区领导人 R. Tyler Croy。
项目的有机增长逐渐成为常态，Jenkins 的基础结构在各方面也有了显著增长，根据 Croy 的介绍，整合至一个云平台可以在不同方面为该公司带来巨大的收益。这样的整合是否需要对整个基础结构服务的工作方式进行大规重新设计？Croy 称他们正在“重新评估分发 / 下载中心，以及为内核和插件开发者提供构建 / 测试服务的基础结构设计（例如 Jenkins on Jenkins），”同时他还补充说：
迁移工作本身可以带来诸多收益，大量服务可以默认实现更大的缩放规模，能为各种数据库端服务提供托管式 / 可缩放的数据库后端，并能通过写代码的方式定义实际采用的基础结构拓扑，毕竟一切都能通过 API 的方式使用。通过使用现成的服务（例如 CDN、Azure 容器服务、SQL Server），还能省略我们基础结构中的部分内容，降低我们必须自行承担的运营工作负担。
迁移到云端还能更好地应对难以预测的流量。对 Jenkins 来说，流量的多少取决于具体服务。诸如开发者基础结构（维基、问题跟踪管理软件、其他服务）等服务会随着社区规模的增长以可预测的形式增长，但诸如分发网络或构建 / 发布基础结构等服务的工作负载对弹性要求更高，Croy 如是说。计算和网络吞吐率的需求也存在这样的弹性。最近发布的 Jenkins 2 已经导致分发网络请求数激增。
在将负载迁移至云端的过程中，还需要考虑安全问题。Jenkins 上个月就报告过一次可能的安全事件。造成此次事件的原因正是因为目前基础结构中同一个组件运行了太多服务。
Croy 针对这个问题进一步补充说：“项目基础结构资源的缺乏导致 Jenkins 需要用同一台服务器同时运行太多服务。通过 Azure 对我们基础结构的不同职能进行分割，使用最少量（适当规模）的实例，由每个实例提供一种服务，这样的做法对我们很有帮助，此外我们还可以对多个虚拟网络进行分层，这有助于隔离和预防任何潜在的后续问题。”
查看英文原文： Microsoft and Jenkins Partner to Run Project Infrastructure on Azure
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论