云中加速、构建具有扩展能力的DevOps平台

原创

zeyangcom 2021-07-26 16:08:58 ©著作权

文章标签 学习 文章分类 代码人生

©著作权归作者所有：来自51CTO博客作者zeyangcom的原创作品，请联系作者获取转载授权，否则将追究法律责任

云中加速、构建具有扩展能力的DevOps平台_学习

如果您是一名工程师，那么您很可能已经在使用 Jenkins — 或者至少听说过它。

Jenkins 是市场上最流行的开源持续集成和持续交付 (CI/CD) 工具。它受欢迎的原因是什么？CloudBees 等组织的坚实支持、出色的社区支持、拥有庞大开发人员基础的数千个插件，以及其设置和使用的绝对简单性。

这允许组织将 Jenkins 与流行的版本控制工具（如 Git、Subversion 和 Mercurial）连接起来；与 SonarQube 和 Fortify 等代码分析软件集成；运行 Maven 和 Gradle 构建；执行 JUnit 和 Selenium 测试；以及更多。

尽管它是一个强大的工具，Jenkins配置管理却毫不费力。您只需要一个 Java Web 服务器（例如 Tomcat）和免费提供的jenkins.war文件，就可以了。Jenkins 有多种使用方式，现在我将讨论一些典型的模式

独立的 Jenkins 服务器

在此设置中，有一个 Jenkins 服务器负责托管和构建所有作业，并使用出站 TCP 链接部署到远程服务器。这是最直接的配置，您无需担心任何其他变量。

云中加速、构建具有扩展能力的DevOps平台_学习_02

主与代理配置

使用独立的 Jenkins 服务器有其缺点。虽然您不必担心多个服务器和节点，但问题是您的服务器可能会因同时运行多个作业而过载。有一些方法可以通过增加 executor （执行器）的数量来解决这个问题，但很快就会遇到性能限制。

为了克服这个问题，您可以将一些作业分配到不同的称为 Jenkins 代理的机器上。Jenkins 代理运行一个小程序，该程序与 Jenkins 主机通信以检查它是否可以运行任何作业。当 Jenkins 找到已安排的作业时，它会将构建传输到代理服务器。问题解决了？好吧，继续阅读。

云中加速、构建具有扩展能力的DevOps平台_学习_03

可扩展的Jenkins

让我们更进一步。出于一个简单的原因，您不需要静态的服务器来运行您的 Jenkins 作业——CI 是高峰期。

您没有每周 7 天、每天 24 小时运行的构建，并且在服务器空闲的持续时间内，这其实是在浪费服务器资源。

如果你运行一个容器编排，比如 Kubernetes，你可以让 Jenkins 做更聪明的事情。这个想法很简单。您拥有负责托管配置和将作业分配给多个代理的 Jenkins 主控节点。但是，您不需要预先配置和部署代理——它们可以在需要时即时创建。

它在很多方面变得简单：

好处1：无需规划 Jenkins 服务器的容量

由于在 Kubernetes 集群上运行Jenkins，可以在您的集群中扩展，直到它具有可用的资源容量。由于多个应用程序共享一个 Kubernetes 集群，因此可以节省资源——因为当您的构建运行时，所有工作负载可能不会同时达到峰值。

当您像我们一样在云提供商（例如 Google Cloud Platform）中运行集群时，事情会变得更好。Google Kubernetes Engine (GKE) 不仅允许您水平扩展容器，还可以根据集群负载添加或删除集群的工作节点——这为您提供了近乎无限的扩展能力。

好处2：并行运行构建和负载均匀

您不再需要规划和限制执行者；相反，Jenkins 将动态根据需要启动一个代理实例并在其中运行您的构建。问题解决了！

Kubernetes 可以很好地管理负载，它将确保您的 Jenkins 代理在最佳可用服务器上启动，从而使您的构建更快、更高效。

好处3：自动修复是可能的

如果运行构建的代理被损坏，您不再需要担心 - Jenkins 将删除不健康的实例并启动一个新的实例。

这节省了大量的故障排除时间，因为代理现在是可有可无的资源。如果代理不起作用，Jenkins 会要求 Kubernetes 删除它并创建另一个代理。

云中加速、构建具有扩展能力的DevOps平台_学习_04

云中加速、构建具有扩展能力的DevOps平台_学习_05

使用Jenkins的故事

这家物流公司希望在组织内无缝启用 DevOps。那时他们决定将 Jenkins 迁移到云端，并将其迁移到 Kubernetes 集群。现在他们的构建速度提高了 10 倍。他们没有遇到性能瓶颈。

“Jenkins 允许我们以可扩展的方式和或多或少独立的方式运行构建。”

-Gaurav Agarwal，解决方案架构师

	组织机构	一家英国物流公司的开发项目
	编程语言	Java、PHP
	平台	Docker、Kubernetes、Linux
	版本控制系统	Bitbucket Server
	构建工具	Gradle、Maven、docker、Helm

背景

我们开始单独使用 Jenkins，并且它在六个月内运行良好。但是随着越来越多的团队使用该工具以及负载的增加，我们自然会遇到性能开销。

由于那时我们没有使用Kubernetes，我们唯一的选择是通过服务器添加主代理（master/agent）配置，或者通过添加更多 CPU 和内存来垂直扩展服务器。我们选择了后者，因为它对我们来说更快、更舒适。然而，我们意识到这不会持续很长时间，并开始寻找替代方案。最终，该公司的 CTO 决定继续实施云战略。那对我们有好处。

目标

我们的最终目标是在组织内无缝启用 DevOps。因此，我们决定将我们的 Jenkins 迁移到云端，并将其迁移到我们已经构建并将所有工具迁移到的 Kubernetes 集群。

解决方案

我们有两种选择：将 master 容器化并独立使用，或者使用 Kubernetes 构建可扩展的 Jenkins。我们提出了以下架构：Jenkins master 的一个副本作为控制节点运行。所有用户都登录到 master 来构建和管理他们的作业。使用 Jenkins Kubernetes 插件，然后当有人触发构建时，我们使用 Kubernetes 来启动额外的 Jenkins 代理容器。它在容器中运行作业，并在成功时删除容器。

Jenkins 允许我们以可扩展的方式和或独立的方式运行构建。这允许多个构建以近乎无限的扩展能力并行运行。由于 Kubernetes 基础架构和 Google Cloud 平台的总体弹性，它还帮助我们优化了成本。结果？