搜索

第 3 章 从 Jenkins 迁移到 Tekton

download PDF

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 - 基本比较
JenkinsTekton

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 中的执行模型比较
JenkinsTekton

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.6.3. 在 Jenkins 和 Tekton 中共享可重复使用的代码

Jenkins 共享库 为 Jenkins 管道的各部分提供可重复使用的代码。该库在 Jenkinsfile 之间共享,以创建高度模块化的管道,而不重复代码。

虽然 Tekton 中没有 Jenkins 共享库直接对应的,但您可以使用 Tekton Hub 中的任务实现类似的工作流,从而结合使用自定义任务和脚本。

3.1.7. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.