第 3 章 从 Jenkins 迁移到 Tekton
3.1. 从 Jenkins 迁移到 Tekton
Jenkins 和 Tekton 广泛用于自动化构建、测试和部署应用和项目的过程。但是，Tekton 是一个云原生 CI/CD 解决方案，它可与 Kubernetes 和 OpenShift Container Platform 无缝配合工作。本文档可帮助您将 Jenkins CI/CD 工作流迁移到 Tekton。
3.1.1. Jenkins 和 Tekton 概念的比较
本节总结了 Jenkins 和 Tekton 中使用的基本术语，并比较了相同的术语。
3.1.1.1. Jenkins 术语
Jenkins 提供声明式和脚本化管道，它们可以使用共享库和插件扩展。Jenkins 中的一些基本术语如下：
- 管道（Pipeline）：利用 Groovy 语法自动化构建、测试和部署应用的整个流程。
- 节点（Node）：能够编配或执行脚本化管道的计算机。
- 阶段（Stage）：在管道中执行的概念上不同的任务子集。插件或用户界面通常使用此块来显示任务的状态或进度。
- 步骤（Step）：一项任务指定要执行的确切操作，可使用命令或脚本。
3.1.1.2. Tekton 术语
Tekton 使用 YAML 语法用于声明管道，由任务组成。Tekton 中的一些基本术语如下：
- 频道（Pipeline）：一组串行或并行（或两者）任务。
- 任务（Task） ：作为命令、二进制文件或脚本的步骤序列。
- 管道运行（PipelineRun）：执行包含一个或多个任务的管道。
任务运行（TaskRun）：通过一个或多个步骤执行任务。
注意您可以使用一组输入（如参数和工作区）启动 PipelineRun 或 TaskRun，执行会产生一组输出和工件。
工作区（Workspace）：在 Tekton 中，工作区是概念块，用于以下目的：
- 存储输入、输出和构建工件.
- 在任务间共享数据的通用空间.
- 在 secret 中保存的凭证挂载点、配置映射中保存的配置以及机构共享的通用工具。
注意在 Jenkins 中，没有 Tekton 工作区直接等效的工作区。您可以将控制节点视为工作区，因为它存储克隆的代码存储库、构建历史记录和工件。当作业分配到其他节点时，克隆的代码和生成的工件会存储在该节点中，但构建历史记录由控制节点维护。
3.1.1.3. 概念映射
Jenkins 和 Tekton 的构建块并不匹配，对它们的比较在技术上并不是准确的映射。Jenkins 和 Tekton 中的以下术语和概念一般相对应：
| Jenkins | Tekton |
|---|---|
| Pipeline | Pipeline 和 PipelineRun |
| Stage | 任务 |
| Step | 一个任务中的一个步骤 |
3.1.2. 将示例管道从 Jenkins 迁移到 Tekton
本节提供了 Jenkins 和 Tekton 中的等效管道示例，可帮助您将构建、测试和部署管道从 Jenkins 迁移到 Tekton。
3.1.2.1. Jenkins 管道
考虑在 Groovy 中编写的 Jenkins 管道，用于构建、测试和部署：
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'make'
}
}
stage('Test'){
steps {
sh 'make check'
junit 'reports/**/*.xml'
}
}
stage('Deploy') {
steps {
sh 'make publish'
}
}
}
}3.1.2.2. Tekton pipeline
在 Tekton 中，Jenkins 管道的等效示例由三个任务组成，每个任务都可以使用 YAML 语法来声明编写：
build 任务示例
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: myproject-build
spec:
workspaces:
- name: source
steps:
- image: my-ci-image
command: ["make"]
workingDir: $(workspaces.source.path)
test 任务示例：
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: myproject-test
spec:
workspaces:
- name: source
steps:
- image: my-ci-image
command: ["make check"]
workingDir: $(workspaces.source.path)
- image: junit-report-image
script: |
#!/usr/bin/env bash
junit-report reports/**/*.xml
workingDir: $(workspaces.source.path)
deploy 任务示例：
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: myprojectd-deploy
spec:
workspaces:
- name: source
steps:
- image: my-deploy-image
command: ["make deploy"]
workingDir: $(workspaces.source.path)
您可以按顺序组合三个任务组成 Tekton 管道：
示例：用于构建、测试和部署的 Tekton 管道
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: myproject-pipeline
spec:
workspaces:
- name: shared-dir
tasks:
- name: build
taskRef:
name: myproject-build
workspaces:
- name: source
workspace: shared-dir
- name: test
taskRef:
name: myproject-test
workspaces:
- name: source
workspace: shared-dir
- name: deploy
taskRef:
name: myproject-deploy
workspaces:
- name: source
workspace: shared-dir
3.1.3. 从 Jenkins 插件迁移到 Tekton Hub 任务
您可以使用插件（plugins）来扩展 Jenkins 的功能。要在 Tekton 中实现类似的可扩展性，请使用 Tekton Hub 中的任何可用任务。
例如，请考虑 Tekton Hub 中可用的 git-clone 任务，它对应于 Jenkins 的 git 插件。
示例：Tekton Hub 中的 git-clone 任务
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: demo-pipeline
spec:
params:
- name: repo_url
- name: revision
workspaces:
- name: source
tasks:
- name: fetch-from-git
taskRef:
name: git-clone
params:
- name: url
value: $(params.repo_url)
- name: revision
value: $(params.revision)
workspaces:
- name: output
workspace: source
3.1.4. 使用自定义任务和脚本扩展 Tekton 功能
在 Tekton 中，如果您在 Tekton Hub 中找不到正确的任务，或需要对任务进行更大的控制，您可以创建自定义任务和脚本来扩展 Tekton 的功能。
示例：运行 maven test 命令的自定义任务
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: maven-test
spec:
workspaces:
- name: source
steps:
- image: my-maven-image
command: ["mvn test"]
workingDir: $(workspaces.source.path)
示例：通过提供自定义 shell 脚本的路径
...
steps:
image: ubuntu
script: |
#!/usr/bin/env bash
/workspace/my-script.sh
...
示例：在 YAML 文件中写入一个自定义 Python 脚本
...
steps:
image: python
script: |
#!/usr/bin/env python3
print(“hello from python!”)
...
3.1.5. Jenkins 和 Tekton 执行模型的比较
Jenkins 和 Tekton 提供了类似的功能，但在架构和执行方面有所不同。本节概述了这两种执行模型的简要比较。
| Jenkins | Tekton |
|---|---|
| Jenkins 有一个控制节点。Jenkins 集中执行管道和步骤，或者编排其他节点上运行的作业。 | Tekton 是无服务器且分布式的，它的执行并不依赖于一个中心系统。 |
| 容器由控制节点通过管道启动。 | Tekton 采用"容器先行"方法，其中每一步骤都作为容器集中运行的容器执行（等同于 Jenkins 中的节点）。 |
| 使用插件可实现可扩展性。 | 使用 Tekton Hub 中的任务或创建自定义任务和脚本来实现可扩展性。 |
