【译】Serverless Jenkins with Jenkins X

原文连接：https://medium.com/@jdrawlings/serverless-jenkins-with-jenkins-x-9134cbfe6870

Jenkins服务来源于建立自2004年的Hudson.在软件行业中，Jenkins已是家喻户晓的明星产品，而且已是CI和CD的领头羊。到目前为止有超过2050万的jenkins任务，以及将近20万的jenkins服务在运行中。这真的是很是惊人的增加速度。

上面的增加图说明在技术领域已经有很大的进步，列如云计算和容器，这些变化说明jenkins在不少方面已经起到了很好的做用，咱们应该很好的利用这些影响力。现在，不少公司都开始进行容器化改造，咱们但愿jenkins能跟上时代的步伐，开始本身的云原生之路。jenkins应当继续成长，提供更多你们须要的自动化，可靠性，以及更好的开发体验。 jenkins在取得巨大成功的同时，也产生了一些问题。

下面让咱们来简要描述一些咱们了解到的比较重要的问题。

1. jenkins服务的单点问题。特别是在服务维护期间，git webhoot的操做都会被丢失.
2. jenkins服务常常将磁盘跑满，须要脚本或者人工清理以后，才能继续运行.
3. 在服务升级以后，plugin的版本会匹配不上.
4. 多分支扫描，常常致使github的速率被限制.
5. 在没有任何任务执行时，也须要占用巨大的内存，从基于使用状况来看，这是一种巨大的浪费.

将来的改进：

1. 下降云计算开销，只在有任务须要被构建时才执行jenkins服务.
2. 尽可能使用上一次的临时构建通道，避免磁盘被耗尽.
3. 经过持续集成进行插件的安装和插件的升级更新.
4. 提供高可用性和可伸缩性的webhook操做，来解决spof问题.
5. 避免因为github的api扫描致使的速度风险.
6. 提供灾难恢复策略，用来恢复存储在git上的全部配置信息.

Jenkins x项目在今年早些时候对外宣布为基于kubernetes的pull请求和gitops自动升级提供了CI和CD(Testing-->Staging-->Production).Jenkins X一样继承了kubernetes的CRDS特性(custom resource definitions),并为你的Jenkins服务和做业提供了编排功能。 Jenkins x和Jenkins激动的宣布无服务的Jenkins.Jenkins x既能编排无服务的jenkins，一个静态的jenkins master,也能为每个team提供Knative构建；所以如今开源的Jenkins云拥有完整的Knative构建支持。

无服务Jenkins使用成功的而且创新开源项目来解决和上述静态Jenkins master的问题。kubernetes如今是事实的云实现，所以如今让咱们专一在那些不太有名的，却能使得无服务的Jenkins成为可能的项目：Prow and Knative build。 在这片博客的底部，有一个连接到未经编辑的youtube记录，它演示了这系列的操做。

Prow是什么？

Prow来源于google的电子商务系统。被一帮纠结因而否须要使用Jenkins来构建那些基于kubernetes的github repos的优秀群体所建立。Kubernetes是github上最成功的项目之一。Prow被用于Istio和Jetstack的同时，还被140个项目使用。有许多不一样的职责的微服务组成的基于事件的解决方案--为一个云本地体系结构提供了理想的松散耦合体系结构。对于merge到master上请求，有了更加有力的方式（不论是在构建请求以前，仍是以后），可使用ChatOps和构建系统进行交互 Prow提供了可伸缩的，高可用的webhook事件处理器，能够将ProwJobs的CRDs请求写入到kubernetes,以致于像正在运行中的持续集成或者发布服务等其它微服务收到响应，并执行操做（kubernetes controllers对于ProwJob 事件进行了监听）。 These git events can be new PRs and issues, comments, merges, pushes等事件操做都会触发git events，所以咱们能对更多的事件请求响应。 对于一些已经提供了一组配置规则的目录，咱们提供了自动merge pull request功能。 对于Prow组件和描述参考以下连接https://github.com/kubernetes/test-infra/tree/master/prow。

Prow一样也将它的配置信息存储在git上，这样在出现问题时能够进行恢复。Jenkins X项目在向用户发布前已经进行了普遍的测试和验证。你能在以下地址上看到Jenkins X项目对于CI/CD提供了不少基于yaml的Prow配置https://github.com/jenkins-x/prow-config.

Knative Build

Knative Build是一个继承自kubernetes项目的云原生解决方案。让用户能够直接从源码进行构建。Knative Build最大的特点就是能够将一些简单的操做在同一个pod中的串联起来的执行，还能够在容器间进行状态的共享。这个特性经过Kubernetes init containers进行初始化。 Build Templates是能够经过kubernetes pod来直接运行你构建的项目。这个容许你在构建项目时，事先指定要须要运行的docker image,构建时须要用到的环境变量，service accounts， secrets,以及须要mount的存储卷。build template是kubernetes crd的集合。可使用jenkins x进行自动升级。经过build template建立或者引入一个应用时，可使用jenkins x产生Prow配置。在Jenkins x项目中有一个列子是在BuildTemplate中配置prow config pointing。

什么是无服务Jenkins

如今咱们已经了解了咱们正在作的事情的背景，咱们能够看看无服务Jenkins.云原生Jenkins正在努力帮助开发人员、团队和组织迁移到云，并确保Jenkins不只与云相关，还容许咱们利用云和Jenkins最擅长的东西。

The details:

使用基于Kubernetes的Jenkins X将会帮你自动安装和配置Prow和Knative，下面咱们开始准备进行安装。当建立项目或者引入项目时，jx cli生成了全部须要的配置，而且更新git repo webhook endpoints。

如今，每一个pull请求或合并到master的请求都会触发使用Knative在Kubernetes中产生一个临时的Jenkins操做，checkout git revision，配置所需的凭证，并使用Jenkinsfile运行应用程序构建管道。一旦构建完成，它将丢弃Jenkinsfile运行程序pod。

多亏了War Packager (CWP)， Jenkins X发布过程构建了不一样风格的Jenkins服务器，其中包含必要的构建工具。语言检测确保使用正确的风格。咱们还使用Configuration as Code plugin(CasC)在构建时添加必要的Jenkins配置。CWP很棒的特性之一是它提取詹金斯插件在构建serverless Jenkins(而不是当serverless Jenkins),因此在基于Jenkins image的容器和JVM在启动Jenkins X耗时5秒——相比之下,要花几分钟启动基于Kubernetes的Jenkins server。

每当咱们发布Jenkins X时，咱们有一个monorepo，它用于自动构建和发布这些程序指定的Jenkins image。

这也意味着，由于插件是在yaml中定义的，并存储在git中，因此咱们能够为CI和CD工具提供CI和CD。当咱们想要升级一个插件时，咱们发出一个pull请求，它会触发CI并构建一个预览Jenkins image，确保没有插件冲突，咱们甚至能够运行模拟做业做为自动化测试(尽管咱们尚未完成这一部分)。每一个人均可以采用彻底相同的方法，构建定制的Serverless Jenkins images，以相同的方式在管道中使用。

突出的一件事是,当你切换到Serverless Jenkins，进行构建是没有状态存储(这意味着为每一个Job构建的编号老是1)。在Jenkins X中，咱们为了PipelineActivity建立的CRD，因此这就容许咱们在单个Jenkins构建完成以后想象先前的构建管道能够生成下一个构建编号和存储信息。

当Prow收到webhook事件时，它将在Kubernetes中建立一个Knative构建资源。接下来，监视构建的Knative构建控制器将建立一个Kubernetes pod，并自动添加一个克隆PR或发布分支源代码的init容器。接下来，利用Jenkinsfile runner,在一个单独的步骤中启动Jenkins能够访问Knative克隆的源代码并处理应用程序的Jenkinsfile。

How to try this out?

今天，含有Prow的Jenkins X在使用terraform via在GKE上建立集群时开箱即用

jx create terraform

或者在其余建立集群或安装命令上使用功能标志时， 即：

jx create cluster gke --prow
jx install — prow

FAQs

• 若是没有运行中的Jenkins服务，如何访问UI 有一个很是重要的问题是Serveless Jenkins没有开源的Jenkins UI。下面咱们来解释一下，Jenkins X具备可使Jenkins X开发人员感到友好的IDE和CLI工具，但UI已经消失了。 Prow有一个名为Deck的开源UI，Jenkins X安装了OOTB。 CloudBees可能很快也将提供免费增值UI，但有关详细信息，请自行查找。

• 从哪里能够看到构建的日志 目前Jenkinsfile runner将构建日志发送到标准输出，可是一个容许咱们利用Kubernetes集群集中日志记录的更好的解决方案将被开发，如Stackdriver，CloudWatch。 咱们还提供jx logs -k（在构建运行时可用）和jx get build log（可用几个小时）

• 我是否须要更改依赖于特定Jenkins multibranch插件环境变量（如$ JOB_NAME）的Jenkinsfile？ 不，咱们已经尝试确保全部与MBP相关的环境变量仍然以相同的格式添加。 若是还有什么没有被添加的。请让咱们知道。

如何迁移我本身的Jenkinsfiles到Serveless Jenkins？

Jenkins X项目自己已经从使用静态（永远在线）Jenkins服务器迁移到Serveless Jenkins。 是的，咱们将Jenkins服务器缩小到0并将咱们全部的Git存储转移到Prow和Serverless Jenkins。 您能够在https://github.com/jenkins-x/组织上查看任何拉取请求，以查看它的实际运行状况。 咱们使用的是declarative style Jenkinsfile（这是咱们在将新项目导入Jenkins X时添加的），这意味着迁移到Serverless Jenkins只须要对Jenkins文件进行一些调整：

1. 将代理类型更改成“any”，以便在一个临时的单独的Jenkins上执行管道
2. 如今删除全部Jenkinsfile容器块，假设全部步骤都在一个单独的Jenkins管道引擎中执行。
3. 对于任何发布分支管道都应该有一个标记（它们都应该建立一个git标签！），而后咱们必须进行从checkout scm 到 git'github / foo.git'的切换，由于从新使用来自Knative和Jenkinsfile runner的克隆repo有问题，好像是由于将repo添加到Jenkins工做区时使用的是符号连接。 咱们但愿解决这个问题。

这里能够看到上述变化的一个例子。 要启用prow的ChatOps/approve注释，您还须要一个相似的OWNERS文件到该连接，该文件使用批准者GitHub ID。

Current restrictions:

• 目前只有GitHub，咱们将为多个git提供者提供支持
• Jenkins X使用了另外一个分支，可是在接下来的几周内它将被切换回使用上游的prow repo
• 默认状况下，Jenkins X会建立一个声明性管道Jenkinsfiles，这还没有在脚本和共享库Jenkinsfile管道上进行测试，但若是按预期工做，咱们很想收到反馈。
• Kubernetes Plugin PodTemplates尚不支持。 咱们不肯定这是不是一个好主意。 这意味着若是要迁移具备多个不一样容器{...}块的现有Jenkinsfiles，则须要将每一个容器的构建工具添加到上面由CWP建立的单个一次性Jenkins中。

还有工做要作，因此若是你想参与其中，请在Jenkins X Kubernetes slack rooms打个招呼来帮助解决问题，或先试试，让咱们知道你是怎么作到的。

如今和咱们一块儿参加 Jenkins World Nice并不会太晚，咱们将在现场演示中展现这个以及其余精彩的演讲！

结论

Jenkins X是使用Prow ChatOps编排静态，无服务器或Knative构建做业的团队的一站式服务，其中包括用于Kubernetes工做负载的自动化CI / CD以及更多自动化。