Serverless Jenkins with Jenkins X_Serverless Jenkins w

Jenkins服务器最初以Hudson的形式于2004年创建。Jenkins在软件开发和交付中已成为我们许多人的家喻户晓的名字，并且是CI + CD工具的领导者。迄今为止，Jenkins的工作已超过2050万，并且正在运行近20万的Jenkins服务器。这是多么惊人的数字哇！

Serverless Jenkins with Jenkins X_Serverless Jenkins w_02

 

在此增长期间，诸如云和容器化等技术取得了重大进步，这意味着詹金斯的某些职责现在有了我们应该利用的更好的实现。如今，大多数公司都有Cloud计划，我们希望Jenkins与时俱进，走自己的Cloud Native历程。Jenkins应该继续发展，并提供许多人所依赖的自动化，可靠性和开发人员体验。

 

詹金斯的巨大成功也伴随着痛点。让我们快速回顾一下我们听到的一些最大的问题：

  • Jenkins服务器是一个单点故障，尤其是在任何维护停机期间都会错过git webhook事件

  • Jenkins服务器经常用尽磁盘空间，需要人员进行脚本编写和/或手动清理以保持亮起状态

  • 插件版本不匹配可能会导致升级期间发生冲突

  • GitHub速率限制，由多分支插件扫描引起

  • 大型JVM即使在没有构建正在运行的情况下也需要高内存，使用基于使用情况的定价时会导致不必要的成本

 

如果：

  • 我们可以通过仅在需要构建时运行Jenkins来处理管道来减少云计算费用

  • 运行临时管道引擎，在构建完成后将其丢弃，从而避免文件系统填满并最终用尽磁盘空间

  • 具有持续集成以验证是否安装了新的Jenkins插件或插件版本升级

  • 提供高可用性和可扩展的Webhook处理程序以解决SPOF

  • 避免进行GitHub API扫描，以降低速率受限的风险

  • 提供灾难恢复策略，其中所有作业配置都存储在git中

     

Jenkins X项目已于今年早些时候宣布，旨在为Kubernetes提供自动化的CI + CD，以及用于拉取请求的预览环境，并通过您的环境自动进行GitOps推广（测试->发布->生产）。Jenkins X还使用CRD（自定义资源定义）扩展Kubernetes，并编排Jenkins服务器和管道。

 

Jenkins X和Jenkins项目现在很高兴宣布无服务器Jenkins！现在，Jenkins X可以编排无服务器的Jenkins，静态的Jenkins Master或每个团队的Knative构建。因此，现在它是具有完整Knative构建支持的开源Jenkins云！

 

无服务器Jenkins使用成功且创新的开源项目来解决静态Jenkins管理员遇到的上述问题。Kubernetes现在是事实上的云实现，因此让我们关注那些使无服务器Jenkins成为可能的鲜为人知的项目：Prow和Knative构建。

 

      

什么是prow?

 

Prow来自Kubernetes生态系统，由Google的优秀人才创建，当时他们开始努力在Kubernetes GitHub存储库中使用Jenkins。Kubernetes是GitHub上最大，最成功的开源项目之一，其140个仓库以及Istio和Jetstack都使用了Prow。这是一个基于事件的解决方案，由多个微服务组成，每个微服务都有各自的职责，从而为云原生架构提供了理想的松散耦合架构。它提供了对合并到母版（在拉取请求构建运行之前和之后）的强大控制，并使用ChatOps与构建系统进行交互。

 

Prow包含一个可扩展且高度可用的Webhook事件处理程序，该事件处理程序基于git事件将ProwJob CRD写入Kubernetes，以便其他微服务（``监视''这些ProwJob事件的Kubernetes控制器）可以做出反应并执行诸如运行连续集成或交付管道之类的操作。这些git事件可以由新的PR和问题，评论，合并，推送等触发，因此我们可以对各种触发事件做出反应。

 

它还具有基于标签根据给定的一组可配置规则自动合并提取请求的功能。

有关Prow组件和说明的列表

https://github.com/kubernetes/test-infra/tree/master/prow

 

Prow还将其作业配置存储在Git中。这意味着在灾难恢复情况下，可以还原所有CI和CD作业。为了看到这样的示例，Jenkins X项目一如既往地首先采用了这种方法，以确保我们在发布给用户之前先进行验证和验证。你可以看到詹金斯X项目拥有为每个回购，我们有需要CI / CD船头配置在这里。

 

 

Knative Build

Knative Build是另一个云原生解决方案，它使用CRD扩展了Kubernetes，并为用户提供了从源代码构建应用程序的方法。Knative Build的主要功能之一是，您可以使用可在每个步骤之间共享状态的不同容器，将在同一Kubernetes窗格中顺序运行的简单步骤串在一起。这种方法使用Kubernetes初始化容器。

 

构建模板是引用创建以运行构建的Kubernetes容器类型的一种方式。它们允许您指定要在其中执行构建的docker映像，在构建时应存在哪些环境变量以及应安装哪些服务帐户，机密和卷。构建模板是Kubernetes CRD，并且在每个Jenkins X版本中都会自动升级。Jenkins X在创建或导入应用程序时生成的Prow配置引用了一个构建模板。在詹金斯X项目的一个例子是船头指向配置在BuildTemplate。

 

What is Serverless Jenkins?

 

在Kubernetes上使用Jenkins X将自动为您安装和配置Prow和Knative，以便您可以开始安装。jx CLI会生成所需的所有配置，并在创建或导入项目时更新git repo webhook端点。

 

现在，每个拉取请求或合并到主触发器都使用Knative在Kubernetes中触发临时的Jenkins，签出git修订版，配置所需的凭据，并使用其Jenkinsfile运行应用程序构建管道。一旦构建完成，它将丢弃Jenkinsfile运行程序容器。

 

多亏了Custom War Packager（CWP），Jenkins X发行过程才能构建包含必需构建工具的Jenkins服务器的各种形式。语言检测可确保使用正确的口味。我们还使用Configuration as Code插件（CasC）在构建时添加必要的Jenkins配置。CWP的一项令人敬畏的功能是它在无服务器Jenkins的构建过程中（而不是在无服务器Jenkins启动时）提取Jenkins插件，因此基于Jenkins X的Jenkins映像的容器和JVM启动时间不到5秒，相比之下，它可以花几分钟在Kubernetes上启动Jenkins服务器。

 

我们有一个monorepo，当我们发布Jenkins X时，可使用它来自动构建和发布这些特定于语言的Jenkins图像。

 

这也意味着，因为我们的插件是在yaml中定义的，并存储在git中，所以我们可以为CI和CD工具使用CI和CD。当我们要升级插件时，我们会发出拉动请求，以触发CI并构建预览Jenkins图像，确保不存在插件冲突，我们甚至可以运行模拟作业作为自动化测试（尽管我们尚未完成此部分）。每个人都可以采用完全相同的方法，并构建自定义的无服务器Jenkins映像，以相同的方式在其管道中使用。

 

需要强调的一件事是，当您切换到无服务器Jenkins时，内部版本之间没有存储状态（这意味着每个作业的内部版本号始终为1）。在Jenkins X中，我们为PipelineActivity创建了一个CRD，因此我们可以生成下一个内部版本号，并存储有关内部版本的信息，这使我们能够在完成一次完整的Jenkins构建之后可视化先前的内部版本管道。

 

当Prow收到一个webhook事件时，它将在Kubernetes中创建一个Knative构建资源。接下来，监视构建的Knative构建控制器将创建一个Kubernetes容器，并自动添加一个初始化容器来克隆PR或发布分支源代码。接下来，利用Jenkinsfile运行程序，在单独的步骤中启动Jenkins单步操作，该步骤可以访问Knative克隆的源代码并处理应用程序的Jenkinsfile。

 

How to try this out?

今天，Jenkins X在Gterra上通过Terraform通过

  •  
jx create terraformjx create cluster gke --prowjx install — prow

 

常见问题


Q1:如果没有运行的静态Jenkins服务器，我如何访问UI？

没有用于无服务器Jenkins的开源Jenkins UI。这非常重要，因此让我们尝试进行解释。Jenkins X具有IDE和CLI工具，可以与Jenkins X开发人员友好地工作，但是UI已经消失了。Prow有一个名为Deck的开源UI，Jenkins X会安装OOTB。CloudBees也可能很快会提供免费增值的UI，但有关此内容的更多详细信息将在后面介绍。

 

Q2:从哪里获取构建日志？

将会有一个更好的解决方案，但是到目前为止，JenkinsfileRunner将构建日志发送到标准输出，使我们能够利用Kubernetes集群的集中式日志记录解决方案，例如Stackdriver，CloudWatch。我们还提供“ jx logs -k”（在构建运行期间可用）和“ jx get build log”（可用几个小时）。

 

Q3:我是否需要更改依赖于$ JOB_NAME之类的特定Jenkins多分支插件环境变量的Jenkinsfile？

不，我们尝试确保所有与MBP相关的环境变量仍以相同格式添加。如果我们错过任何事情，请告诉我们。

 

如何迁移自己的Jenkinsfile以使用无服务器Jenkins？

Jenkins X项目本身已经从使用静态（始终在线）的Jenkins服务器迁移到Serveless Jenkins。是的，没错，我们已将Jenkins服务器缩小为0，并将所有Git存储库移至Prow和Serverless Jenkins。您可以在https://github.com/jenkins-x/ org上查看任何请求请求，以查看其运行情况。我们使用的是声明性样式的Jenkinsfile（这是在将新项目导入Jenkins X时添加的内容），这意味着迁移到Serverless Jenkins仅需对Jenkinsfile进行一些调整：

  • 将代理类型更改为“ any”，以便在临时Jenkins上执行流水线

  • 立即删除所有Jenkinsfile容器块，因为现在假设所有步骤都在一次Jenkins管道引擎中执行。

  • 对于任何带有标签的发布分支管道（它们都应该创建一个git标签！），我们必须从切换到checkout scm，git ‘github/foo.git’因为重新使用从Knative和Jenkinsfile运行器克隆的仓库存在问题，因为添加该标签时似乎使用了符号链接回购到Jenkins工作区。我们希望解决此问题。

  • 在此处可以看到上述更改的示例。要启用prow的ChatOps /approve注释，那么您还需要一个类似于OWNERS的文件，指向使用批准者GitHub ID的链接。

 

当前限制：

  • 目前仅GitHub，我们将为多个git提供者提供支持

  • Jenkins X使用叉子，但是它将在接下来的几周内切换回上游，使用前叉仓库

  • Jenkins X默认情况下会创建一个声明性管道Jenkinsfiles，尚未在脚本化和共享库Jenkinsfile管道上进行过测试，但如果此方法能按预期工作，我们希望获得反馈。

  • 目前尚不支持Kubernetes插件PodTemplates。我们不确定这是否是个好主意。这意味着，如果要迁移具有多个不同容器{…}块的现有Jenkins文件，则需要将每个容器的构建工具添加到上述CWP创建的单个Jenkins中。

  • 仍有工作要做，因此，如果您想参与进来，请在Jenkins X Kubernetes闲置房间打个招呼，解决问题，或者先尝试一下，让我们知道您的生活。

  • 现在下周来参加我们在詹金斯世界尼斯的活动还不算太晚，我们将在现场演示中与其他精彩的演讲一起展示这一点！


总结

Jenkins X是一站式商店，团队可以使用Prow ChatOps来安排其静态，无服务器或Knative构建工作，其中包括针对CI的自动CI / CD，以应对Kubernetes的工作负载，并提供更多的自动化功能。