第 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 中的以下术语和概念一般相对应：

表 3.1. 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 任务

您可以使用插件来扩展 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 提供了类似的功能，但在架构和执行方面有所不同。本节概述了这两种执行模型的简要比较。

表 3.2. Jenkins 和 Tekton 中的执行模型比较
Jenkins	Tekton
Jenkins 有一个控制节点。Jenkins 集中执行管道和步骤，或者编排其他节点上运行的作业。	Tekton 是无服务器且分布式的，它的执行并不依赖于一个中心系统。
容器由控制节点通过管道启动。	Tekton 采用"容器先行"方法，其中每一步骤都作为容器集中运行的容器执行（等同于 Jenkins 中的节点）。
使用插件可实现可扩展性。	使用 Tekton Hub 中的任务或创建自定义任务和脚本来实现可扩展性。

3.1.6. 常见使用案例示例

Jenkins 和 Tekton 都提供通用 CI/CD 用例的功能，例如：

使用 maven 编译、构建和部署镜像
使用插件扩展核心功能
重新使用可共享库和自定义脚本

3.1.6.1. 在 Jenkins 和 Tekton 中运行 maven 管道

您可以在 Jenkins 和 Tekton 工作流中使用 maven 来编译、构建和部署镜像。要将现有 Jenkins 工作流映射到 Tekton，请考虑以下示例：

示例：编译并构建镜像，并使用 Jenkins 中的 maven 将它部署到 OpenShift

#!/usr/bin/groovy
node('maven') {
    stage 'Checkout'
    checkout scm

    stage 'Build'
    sh 'cd helloworld && mvn clean'
    sh 'cd helloworld && mvn compile'

    stage 'Run Unit Tests'
    sh 'cd helloworld && mvn test'

    stage 'Package'
    sh 'cd helloworld && mvn package'

    stage 'Archive artifact'
    sh 'mkdir -p artifacts/deployments && cp helloworld/target/*.war artifacts/deployments'
    archive 'helloworld/target/*.war'

    stage 'Create Image'
    sh 'oc login https://kubernetes.default -u admin -p admin --insecure-skip-tls-verify=true'
    sh 'oc new-project helloworldproject'
    sh 'oc project helloworldproject'
    sh 'oc process -f helloworld/jboss-eap70-binary-build.json | oc create -f -'
    sh 'oc start-build eap-helloworld-app --from-dir=artifacts/'

    stage 'Deploy'
    sh 'oc new-app helloworld/jboss-eap70-deploy.json' }

示例：编译并构建镜像，并使用 Tekton 中的 maven 将它部署到 OpenShift。

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: maven-pipeline
spec:
  workspaces:
    - name: shared-workspace
    - name: maven-settings
    - name: kubeconfig-dir
      optional: true
  params:
    - name: repo-url
    - name: revision
    - name: context-path
  tasks:
    - name: fetch-repo
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: shared-workspace
      params:
        - name: url
          value: "$(params.repo-url)"
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
        - name: revision
          value: $(params.revision)
    - name: mvn-build
      taskRef:
        name: maven
      runAfter:
        - fetch-repo
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["-DskipTests", "clean", "compile"]
    - name: mvn-tests
      taskRef:
        name: maven
      runAfter:
        - mvn-build
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["test"]
    - name: mvn-package
      taskRef:
        name: maven
      runAfter:
        - mvn-tests
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["package"]
    - name: create-image-and-deploy
      taskRef:
        name: openshift-client
      runAfter:
        - mvn-package
      workspaces:
        - name: manifest-dir
          workspace: shared-workspace
        - name: kubeconfig-dir
          workspace: kubeconfig-dir
      params:
        - name: SCRIPT
          value: |
            cd "$(params.context-path)"
            mkdir -p ./artifacts/deployments && cp ./target/*.war ./artifacts/deployments
            oc new-project helloworldproject
            oc project helloworldproject
            oc process -f jboss-eap70-binary-build.json | oc create -f -
            oc start-build eap-helloworld-app --from-dir=artifacts/
            oc new-app jboss-eap70-deploy.json

3.1.6.2. 使用插件扩展 Jenkins 和 Tekton 的核心功能

Jenkins 利用了其广泛的用户群来多年开发的大量插件生态系统。您可以在 Jenkins 插件索引中搜索和浏览插件。

Tekton 还有许多任务由社区和企业用户开发并贡献。Tekton Hub 中提供了可重复使用 Tekton 任务的公开可用目录。

另外，Tekton 在其核心功能中纳入了 Jenkins 生态系统的许多插件。例如，授权是 Jenkins 和 Tekton 中的关键功能。虽然 Jenkins 使用基于角色的访问控制插件来确保授权，Tekton 使用 OpenShift 的内置基于角色的访问控制系统。

3.1.7. 其他资源

基于角色的访问控制

第 3 章从 Jenkins 迁移到 Tekton

3.1. 从 Jenkins 迁移到 Tekton

3.1.1. Jenkins 和 Tekton 概念的比较

3.1.1.1. Jenkins 术语

3.1.1.2. Tekton 术语

3.1.1.3. 概念映射

3.1.2. 将示例管道从 Jenkins 迁移到 Tekton

3.1.2.1. Jenkins 管道

3.1.2.2. Tekton pipeline

3.1.3. 从 Jenkins 插件迁移到 Tekton Hub 任务

3.1.4. 使用自定义任务和脚本扩展 Tekton 功能

3.1.5. Jenkins 和 Tekton 执行模型的比较

3.1.6. 常见使用案例示例

3.1.6.1. 在 Jenkins 和 Tekton 中运行 maven 管道

3.1.6.2. 使用插件扩展 Jenkins 和 Tekton 的核心功能

3.1.7. 其他资源

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links

第 3 章 从 Jenkins 迁移到 Tekton

3.1. 从 Jenkins 迁移到 Tekton

3.1.1. Jenkins 和 Tekton 概念的比较

3.1.1.1. Jenkins 术语

3.1.1.2. Tekton 术语

3.1.1.3. 概念映射

3.1.2. 将示例管道从 Jenkins 迁移到 Tekton

3.1.2.1. Jenkins 管道

3.1.2.2. Tekton pipeline

3.1.3. 从 Jenkins 插件迁移到 Tekton Hub 任务

3.1.4. 使用自定义任务和脚本扩展 Tekton 功能

3.1.5. Jenkins 和 Tekton 执行模型的比较

3.1.6. 常见使用案例示例

3.1.6.1. 在 Jenkins 和 Tekton 中运行 maven 管道

3.1.6.2. 使用插件扩展 Jenkins 和 Tekton 的核心功能

3.1.6.3. 在 Jenkins 和 Tekton 中共享可重复使用的代码

3.1.7. 其他资源

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links

第 3 章从 Jenkins 迁移到 Tekton