详解 CloudBees CI，助力 Jenkins 用户顺利迁移并构建高效 CI/CD 平台

​

据调查显示，全球有超过 70%的开发者使用 Jenkins 构建其 CI 流水线。然而，Jenkins 在大规模团队集中管理、灵活性、插件管理、安全性、团队统一管理等方面存在明显的瓶颈与不足，越来越多的团队转向 Cloudbess CI （Jenkins 企业版）。

本篇文章中，龙智技术专家与客户（Jenkins 用户）进行了深入的探讨，不仅详细解读了 CloudBees 的功能与优势，还从权限管理、可扩展性、性能、迁移等方面回答了客户最关心的问题，分享了各种注意事项，以帮助 Jenkins 用户顺利迁移，构建更高效、更稳定的 CI 平台。

*DSD=龙智技术专家，C=某客户

精细化的权限管理

DSD：您现在公司是否有多个事业部？请问您在团队中担任何种角色？

C：是的，我们公司有多个业务部门，大家都会使用到 Jenkins。我们是公司专门的 Jenkins 团队，负责 Jenkins 的搭建、维护、培训和权限管理等工作。鉴于 Jenkins 权限管理的不足，为了防止业务部门随意创建项目，我们团队负责项目的创建和添加节点。而具体的业务流水线由各事业部负责。

DSD：CloudBees CI 可以有效解决您的权限管理问题。它可以集中管理每个用户在每个 Controller（实例）上的权限，实现精细化管理。

C：我们希望控制每个用户访问哪些资源，以及创建项目和添加节点的权限。同时，每个项目的权限也需要细分控制。如果能满足这些需求就太好了。

DSD：是的，权限管理至关重要。在 CloudBees CI 中，有一个 Operation Center 作为中心节点，您可以在其中定义全局权限、用户组和角色。同时，每个 Controller 上都可以定义每个实例的细分权限。通过组合这两种方式，我们可以实现精细、灵活的权限管理，而不需要在每个实例上花费大量时间配置。

C：我们的情况是，每个业务部门有自己的 Controller，由该部门管理员管理。能否实现管理员根据不同的小组和目录划分项目结构，并管理项目的细分权限？

DSD：可以实现。我们可以通过权限控制将一个团队限制在一个 Controller 上，对于其他 Controller，他们只能具有只读权限，即只能浏览不能操作。对于 Agent，我们可以指定特定的角色，并授予他们创建 Agent 的权限，然后将这些角色分配给相应的组和用户。

可轻松扩展，无缝迁移

DSD：您打算将 CloudBees CI 安装在虚拟机平台上还是 Kubernetes（K8s）上呢？

C：我们计划安装在 Kubernetes（K8s）上。

DSD：好的。在 K8s 上部署 CloudBees 能更好地发挥其功能。通过在类似 K8s 这样的平台上进行安装，我们可以采用滚动升级的方式实现零停机的要求。此外，可以通过监控 CPU 等资源的使用情况来确定是否需要增加新的节点，从而实现节点的弹性伸缩。您也可以手动实现弹性伸缩。

DSD：您公司使用 Jenkins 的人数是多少，有多少个应用和 master？

C：我们实际使用 Jenkins 的用户大概在 200 到 300 人之间，有 5 个节点。应用方面主要涉及芯片研发和嵌入式开发。

DSD：在节点管理方面，CloudBees 具有显著的优势。在开源的 Jenkins 中，缺乏中心管理节点，每个实例都是分散的。而在 CloudBees 中，有一个中心管理节点来集中管理所有的实例。举例来说，在 CloudBees 上，所有的实例无需配置运行节点，我们可以直接在中心管理节点上配置一个运行节点，并将其设置为动态的。这样一来，所有的实例都可以共享这个节点，当实例任务需要运行时，默认会从中心节点获取这个节点，这相当于将资源共享到所有实例上，而开源的 Jenkins 则缺乏这种能力。

C：我们的应用场景相对较为复杂，有些任务需要使用 CPU，有些任务需要使用 GPU，CloudBees 是否支持指定资源配额呢？比如说，我们某个任务需要 2 个 CPU，以及一定量的内存等。

DSD：支持。CloudBees 中心节点的优势在于，所有的资源都可以共享给所有的实例。对于受限的资源，比如您提到的 GPU 资源，由于有时这些资源无法进行虚拟化，只能使用实际的 GPU 代理来共享给所有用户。针对这种情况，我们有静态共享节点的解决方案。我们可以在中心节点上创建静态共享节点，并为所有实例提供使用。我们可以指定一个 Label，比如 GPU，当实例执行任务时，分配给该任务的 Label 会指定使用预先定义的 GPU 节点。

C：也就是说物理节点也可以共享资源。但我们使用的不是物理节点，而是自己搭建的 K8s，其中包含了 CPU 和 GPU 机器。是否能从开源的 Jenkins 平滑迁移到 CloudBees？

DSD：我们的平台运行有一个前提，就是 K8s 必须是 CNCF 兼容的，即一些主要的 API 没有进行修改，与开源的 K8s 完全兼容。我们了解到，有些客户可能对 K8s 进行了一些定制，导致一些 API 发生了变化。只要不涉及这种情况，就可以顺利迁移、运行。

C：我们所提到的集群是 Agent 集群，这个 CloudBees 能支持吗？

DSD：完全没问题。因为我们的平台集群上支持多个 cluster。您现有的设置可以保持不变，新建一个集群后，将现有的 cluster 定义为 CloudBees 的 Agent Cloud。在这个 Agent Cloud 中，您还可以继续使用原来的那些 Agent。

C：我们基于开源插件自行开发了一些插件，并进行了一些功能扩展，来对接我们自己的平台。这种情况 CloudBees 能够支持吗？

DSD：CloudBees CI可以被视为 Jenkins 的加强版，相同版本的 Jenkins 和相同版本的 CloudBees 是完全兼容的，只不过我们增加了一些私有的插件。因此，基本上如果您在开源的 Jenkins 上能够使用这些插件的话，那么在相同版本的 CloudBees 上也是可以使用的。关键问题可能在于版本兼容性。如果您所用的版本比较老旧，那么可能会出现不兼容的情况。如果您需要使用最新版本的话，可能需要做一些修改。

C：我们还是比较担心能否实现平滑迁移。

DSD：像刚才说的一样，如果我们使用的版本都比较新，并且与现有版本接近的话，迁移基本上是比较简单的。在开源的 Jenkins 上能够运行的流水线在 CloudBees 上也一定可以运行。但如果您使用的版本比较老旧，可能在 Jenkins 和 Jenkins 之间迁移时都会存在问题，更不用说迁移到 CloudBees 上了。所以关键问题就是我们现在所用的版本是多少？您目前正在使用的是哪个版本？

C：2.33 版本。

DSD：这个版本并不算太老，目前 CloudBees 的版本是 2.4，相差不远。一般情况下，如果我们没有使用特别多的、特别偏门的插件的话，迁移还是比较简单的。只需要将那些流水线平移到新环境下就可以了。换句话说，我们只需要安装那些插件，并将流水线平移过来，大多数情况下就可以正常工作了。当然，如果插件版本发生了变化，而恰好您的流水线使用插件的功能也发生了变化，那么可能流水线需要根据插件的升级进行一些调整。

C：我们使用的插件比较多，所以调整可能会比较繁琐。

DSD：这种情况确实需要仔细确认一下。因为 Jenkins 社区里有近两千个插件，我也不清楚您目前都在使用哪些，以及哪些插件有更新。有些插件的变化比较缓慢，而有些则变化比较快。如果有些插件变化非常快，需要使用最新版本，可能就需要对这些插件进行一些调整，包括可能需要对流水线的代码进行一些调整，甚至配置方面也可能需要做一些调整。

我们曾经遇到过一些客户，使用的是几年前的插件，因此迁移工作非常繁琐，需要调整很多方面。但是就目前而言，您所用的版本并不是很久远，所以大多数情况下问题不大。

DSD：我们的使用环境应该是有网络连接的，对吗？

C：可以开，但是我们真正的生产环境是不开外网的。

DSD：好的，我问这个问题是因为升级是可以自动完成的。如果有网络连接，我们可以直接将最新版本的更新推送过来，这样进行升级会非常方便。

举例来说，如果我们升级新版本，基本上那些核心插件不用过多关注兼容性问题。因为在升级的过程中，推过来的新版本会自带那些核心插件，而且这些插件的兼容性也经过了测试，因此无需过多担心兼容性问题。这也可以帮助我们解决很大的问题。所以如果有网络连接，效果会更好，因为所有操作可以自动完成。

释放强大、稳定的性能，实现高可用

C：CloudBees 在进行横向扩展时，会存在性能瓶颈吗？

DSD：性能瓶颈主要取决于我们所使用的 Kubernetes 集群的资源限制。

我们有一些大客户，比如美国的大型银行客户，在实例数量方面可能达到数千个。因此，就性能而言，并不存在内在的瓶颈，真正的限制在于我们能够提供多少资源。

C：关于高可用性方面，CloudBees 有何解决方案？

DSD：过去，Jenkins 实例是在一个容器或虚拟机中运行的单个进程。而现在，我们可以设计更加复杂的架构，加上前端的负载均衡，可以将任意数量的实例组合起来，共同发挥作用。这样做的好处之一就是通过负载均衡，可以避免单点故障。即使其中一个实例出现故障，其他实例仍可以继续正常运行，从而保证了更加稳定和优越的性能。

C：另外一个问题，比如我现在想要获取一些与 Jenkins 相关的数据用于分析，是否有相应的方案？

DSD：您可以通过 metrics 插件来收集 CloudBees 运行时生成的一些重要数据，并通过 Prometheus 和 Grafana 来展示这些数据。这样的配置可以在 Kubernetes 平台上完成，metrics 插件会收集 Kubernetes 的数据，并单独收集 Jenkins 的数据。

关于试用

DSD：如果进行试用，您计划邀请哪些人员参与呢？

C：我打算邀请不同业务部门的 DevOps 负责人参与试用。另外，试用的期限有多久？

DSD：试用许可的最长期限是一个月，但如果一个月的试用时间不够，我们可以提交申请，延长试用期限。

DSD：总体而言，我们建议在 Kubernetes 上搭建此平台，并让所有团队使用该平台上的实例。由我们的团队集中管理这些实例，并针对权限从全局的角度进行设计。此外，还有一些其他功能也非常有用，比如统一升级、统一安装插件、统一脚本等，这些都可以在试用过程中体验到。

关于 Cloudbees Platform

C：我还有一个问题。由于 Jenkins 对我们而言是一个 CI/CD 平台，我们计划在此基础上构建自己的平台，从代码层面、CI/CD，再到镜像，将所有环节串联起来。这样，研发只需要关注自己提交代码，而其他信息，比如构建失败信息，我们可以及时地推送给研发，而无需在多个平台之间跳转查看。

DSD：我理解您的意思，您可能打算构建一个内部开发者平台，将所有资源串联起来，提供自助服务的功能。我有个问题，您是否能访问www.cloudbees.io这个网站？CloudBees 最近发布了一个新产品，也是下一代的主要旗舰产品，名为 CloudBees Platform。在这个平台上，就能将所有可用资源串联起来，为开发人员提供自助服务的功能。

这个平台在销售时可以与 CloudBees CI 一起提供给用户。如果购买 CloudBees CI，自然也就会获得这个平台，功能将更加强大。除了 CloudBees CI 外，在这个平台上，它采用 Cloud Native 架构，我们可以迅速将各种功能以容器的方式集成进来。但关键问题是，需要网络访问这个产品，因为目前这个产品部署在 AWS 上，是基于 SaaS 的，将来可能会提供离线部署的方案。

​