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这样的大型多功能工具。咱们可以比以往更快地开发专用应用程序。咱们但愿使用小型工具/微服务来解决使用。