K8s原生Jenkins-X和Tekton Pipeline

Jenkins X不是Jenkins，它是完全从头开始重写的。

Jenkins X比Jenkins更聚焦于特定领域。它提供了一种使用特定工具（Kubernetes Helm Tekton Skaffold Flagger…）来构建和部署应用程序的方式。如果您喜欢这样使用它，那将是一种享受，如果您不喜欢，那么另一种 工具 更适合。

本文将为您讲述Jenkins X架构。我们将首先描述k8s 原生和CRD，这将有助于我们了解Tekton的工作原理和作用。然后我们来看看Jenkins X，它如何在后台使用Tekton，以及为什么。

Jenkins

Jenkins很老，开发语言为Java，体积庞大，通常很难配置。尽管它非常灵活，可扩展，并且可能是使用最广泛的CI和CD工具。 Jenkins X能否青出于蓝而胜于蓝？

Kubernetes原生? CRD?

我们正处于软件程序和运行它们所需的基础结构融合在一起的时代。随着Kubernetes的兴起，一种通用语言得以创建，它可以描述现代基础设施。

Kubernetes为创建基础架构时的常见问题提供了解决方案，例如定期运行容器，让容器进行通信，收集日志/事件以及附加卷。

Custom Resource Definitions

Kubernetes中的CRD提供了一种扩展API的方法。在群集中安装CRD时，可以使用新的资源类型。随同新的资源类型一起提供了自定义控制器，该控制器在控制器管理器中运行并处理新资源类型的生命周期。

上图显示了k8s Deployment Controller管理部署，以及通过引入的CRD的MyShiny Controller管理MyShiny资源。将CRD安装在群集中后，用户可以像使用kubectl或API一样与其他资源正常交互。

Kubernetes原生

Kubernetes原生应用程序直接在Kubernetes之上开发。他们使用k8s API并为其工作流程定义CRD。就像您可以使用Windows API/SDK为Windows开发应用程序一样，您也可以对Kubernetes执行相同的操作。

Jenkins X是Kubernetes原生的一个例子，我们将在本文中进行探讨并说明原因。

Tekton Pipelines

“Tekton用于CI/CD，就像Kubernetes用于基础架构一样”。这意味着它为持续集成和持续部署/交付的常见问题提供了通用解决方案。它通过提供新资源（如通过CRD的task或pipeline）来实现：

Task

Task是您要在连续集成流程中运行的连续步骤的集合。Task将在集群中的pod内运行。

如果您查看上面的示例，将会发现与Pod的相似之处。每个步骤都使用特定的镜像执行。步骤可以像普通pod容器一样通过卷共享数据。

Pipeline

Pipeline定义了一组要执行的任务。

在此示例中，我们创建了一个新pipeline，执行一个名为build-push的task。可以将参数传递给pipeline和task。

Tekton概括

简短介绍了Tekton如何创建Kubernetes CRD来解决常见的CI/CD问题。这样，各种不同的CI/CD工具就可以利用这一共同点来构建其特定功能。

Tekton不能直接使用，而是可以通过其他工具（例如Jenkins X）直接使用。Tekton可以成为处理Kubernetes中CI/CD的事实上的标准低层。

Jenkins X

在最新版本（从2.0版开始）中，Jenkins X是Golang的完整版本，与经典Jenkins没有任何共同之处。除其他技术外，它还使用Tekton在Kubernetes上管理和执行pipeline和作业。现在，我们深入探讨其一些概念：

GitOps

Jenkins X首先是GitOps，这意味着它挂接到Git Webhooks中，并在提交或合并请求时被激活。 Jenkins X将要求每个应用程序/微服务都有自己的Git存储库。

而且，每个生产/预发布等环境都将拥有自己的Git存储库。到环境中的每个部署都将通过（自动创建）拉取请求完成。

Jenkins X安装及其所有配置（通过jx boot安装）也将驻留在其自己的Git存储库中。这样，将对应用程序，基础架构或配置进行所有更改，并将其存储在Git中。

架构

Serverless

关于Jenkins X，无服务器意味着没有一直在运行的Jenkins服务器。在Kubernetes控制平面中运行的Tekton CRD控制器正在等待Git事件，然后创建处理pipeline所需的Pod。在Jenkins X中运行的每个pipeline均由Tekton管理。无需手动处理。

但是，如果没有pipeline在运行，也不要指望集群完全是空的：

使用Kubernetes无限扩展

对于每个pipeline运行，都会创建一个新的Pod。因此，可伸缩性仅受Kubernetes集群资源或命名空间配额的限制。

通过YAML配置

是的，最后是pipeline的YAML配置:

https://github.com/jenkins-x/jx/blob/e7060d9d599f01465ca2d064a505e0e5e09a9e15/jenkins-x.yml

Buildpacks/自动配置

Jenkins X甚至可以完全不使用任何Jenkinsfile导入（jx导入）项目。它将创建默认pipeline，甚至创建默认的Dockerfile（如果不存在）。它包含适用于许多常见项目类型和语言（例如Python/JS/Go/Java）的构建包。

运行旧的pipeline/Jenkinsfile

在不重新考虑工作流程的情况下，您将无法轻松使用或转换旧的Jenkins pipeline。如果您想研究转换，可以检查一下Jenkinsfile转换示例。从经典Jenkins切换到Jenkins X可能意味着您必须调整CI/CD工作流程。

预览环境

Jenkins X允许为每个提交或合并请求自动创建预览环境。预览环境的URL作为对合并请求的注释发布。只要不合并Pull Request，预览环境就将存在，并在Kubernetes集群环境中作为单独的命名空间实现。

Jenkins vs Jenkins X

Jenkins X根本不是Jenkins。让我们给它起一个名字，我们称它为... Klaus。严格意义上说，Jenkins X和Jenkins并没有多大关系。

Classic Jenkins是可用于所有事物的多配置和可扩展工具。 Jenkins X专门用于特定目的：在Kubernetes上运行的微服务架构。

概述

当我开始使用Jenkins X时，我立即觉得它对我有太多帮助。我可以逐步进行配置。使用Jenkins X，您必须禁用很多而不是启用。但最后，您应该让步，接受工作流程并感到高兴。

因此，我深入研究了Jenkins X，我认为它非常简洁，确实提供了巨大的优势，并且消除了很多重复的工作。我将继续，并希望很快将其用于生产中。如果您是Kubernetes爱好者，那么绝对感觉像CI/CD的未来。

也许今天我们不再需要像经典Jenkins这样的大型多功能工具。我们能够比以往更快地开发专用应用程序。我们希望使用小型工具/微服务来解决使用。