首页 > 其他分享 >Tekton Tasks 基础

Tekton Tasks 基础

时间:2023-12-12 15:31:45浏览次数:31  
标签:Task workspaces name image 基础 Tekton Tasks path description

Tasks 概述

Task是一系列Step的组合,每个Step主要负责运行特定的构建或交付工具从而完成相关的一次特定事项;Task以Kubernetes集群上Pod运行。Task是名称空间级别的资源。

Tasks 组成

Parameters:是使得Task及Pipeline资源定义出的“模板”更加具有通用性的关键要素之一
Steps:具体执行的任务
Workspaces:由Task声明的,且需要由TaskRun在运行时提供的文件系统
Results:它将Task中Step生成的结果保存于临时文件中

Results

Results 概述

在Pipeline的Task之间使用同一个共享的Workspace可以完成数据共享,但对于简单的字符串数据的传递,则可以使用Results API完成;
Results用于让Task及其Step保存执行结果,并可在同一Pipeline中的后续Task中调用该结果;

Results 保存路径

Task将会为每个results条目自动创建一个文件以进行保存,这些文件统一放置于/tektons/results目录中;
每个results条目的相关值(value)需要在Step中进行生成并保存,且Task不会对相关数据进行任何多余的操作;

Results 变量

在Task中引用Results时使用的变量

results.<resultName>.path
results['<resultName>'].path 或 results["<resultName>"].path

在Pipeline中引用Results时使用的变量

tasks.<taskName>.results.<resultName>
tasks.<taskName>.results['<resultName>'] 或 tasks.<taskName>.results["<resultName>"]

Workspace

Workspace 概述

Workspace用于为Task中的各Step提供工作目录,基于该Task运行的TaskRun需要在运行时提供该目录

Workspace 运行方式

TaskRun的实际运行形式为Pod,因而Workspace对应的实际组件为Pod上的Volume
由Task声明的,且需要由TaskRun在运行时提供的文件系统;通常对应于Kubernetes上的ConfigMap、Secret、emptyDir、静态PVC类型的卷,或者是VolumeClaimTemplate动态请求的PVC;emptyDir的生命周期与Pod相同,因此仅能在一个TaskRun的各Step间共享数据;若要跨Task共享数据,则需要使用PVC;
ConfigMap和Secret:只读式的Workspace
PersistentVolumeClaim:支持跨Task共享数据的Workspace
   静态预配
   动态预配:基于VolumeClaimTemplate动态创建
emptyDir:临时工作目录,用后即弃

Workspace 作用

1. 跨Task共享数据
2. 借助于Secrets加载机密凭据
3. 借助于ConfigMap加载配置数据
4. 持久化存储数据
5. 为Task提供缓存以加速构建过程

Workspace 变量

$(workspaces.<name>.path):由<name>指定的Workspace挂载的路径,对于可选且TaskRun未声明时,其值为空;
$(workspaces.<name>.bound):其值为true或false,用于标识指定的Workspace是已经绑定;对于optional为false的Workspace,该变量的值将始终为true;
$(workspaces.<name>.claim):由<name>标示的Workspace所使用的PVC的名称;对于非PVC类型的存储卷,该变量值为空;
$(workspaces.<name>.volume):由<name>标示的Workspace所使用的存储卷的名称;

Task 资源清单

apiVersion: tekton.dev/v1   # 指定 API 版本。
kind: Task                  # 将此资源对象标识为一个Task对象。
metadata:                   # 指定唯一标识 Task资源对象的元数据。例如,一个name.
  name: hello
spec:                       # 指定该资源对象Task的配置信息
  workspaces:
    - name: signals         # 必选字段,该Workspace的唯一标识符
      description:          # 描述信息,通常标明其使用目的
      mountPath:            # 在各Step中的挂载路径,默认为“/workspace/<name>”,其中<name>是当前Workspace的名称
      readOnly:             # 是否为只读,默认为false
      optional:             # 是否为可选,默认为false
 
  results:
    - name: current-date-unix-timestamp   # 唯一名称
      description:                        # 描述信息
                
  params:                   # 定义变量信息
    - name:                 # 变量名称
      type: string          # 参数类型,有string、array (beta feature)、object (beta feature),默认值 string
      description:          # 描述信息
      default:              # 默认值
      enum: ["v1", "v2"]    # 枚举
      value:                # 静态赋值
    - name: gitrepo
      type: object
      properties:
        url:
          type: string
        commit:
          type: string
    - name: flags
      type: array
  
  steps:
    - name:                                           # task名称                      
      image:                                          # 执行task的镜像
      command: ["echo"]                               # 执行的命令
      args: ["push", "$(params.gitrepo)"]             # 执行命令的参数
      script: |                                       # 指定运行的脚本,多行脚本,可以使用“|”启用,script同command互斥
        #!/usr/bin/env bash
        echo "Hello from Bash!" 
        date +%s | tee $(results.current-date-unix-timestamp.path)  # 调用results结果
        
      securityContext:                                # 设置允许容器用户id
        runAsUser: 2000 
      env:                                            # 设置环境变量
        - name: 
          value: 
      computeResources:                               # 资源限制
        requests:
          memory: 1Gi
          cpu: 500m
        limits:
          memory: 2Gi
          cpu: 800m
      timeout: 60s                                    # 超时时间,例如 1s 或 1ms
      one rror: continue                               # 本次step执行失败则跳过本次任务,继续向下执行其它step
      stdoutConfig:                                   # 标准输出
        path: ...
      stderrConfig:                                   # 标准错误输出
        path: ...
      
  sidecars:
    - image: alpine
      # Note: must explicitly include volumeMount for the workspace to be accessible in the Sidecar
      volumeMounts:
        - name: $(workspaces.signals.volume)       # 调用workspace
          mountPath: $(workspaces.signals.path)

Task 示例

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: git-clone
spec:
  description: Clone the code repository to the workspace. 
  params:
    - name: git-repo-url
      type: string
      description: git repository url to clone
    - name: git-revision
      type: string
      description: git revision to checkout (branch, tag, sha, ref)
  workspaces:
    - name: source
      description: The git repo will be cloned onto the volume backing this workspace
  steps:
    - name: git-clone
      image: alpine/git:v2.36.1
      script: | 
        git clone -v $(params.git-repo-url) $(workspaces.source.path)/source
        cd $(workspaces.source.path)/source && git reset --hard $(params.git-revision)
---
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-to-package
spec:
  description: build application and package the files to image
  workspaces:
    - name: source
      description: The git repo that cloned onto the volume backing this workspace
  steps:
    - name: build
      image: maven:3.8-openjdk-11-slim
      workingDir: $(workspaces.source.path)/source
      volumeMounts:
        - name: m2
          mountPath: /root/.m2
      script: mvn clean install
  volumes:
    - name: m2
      persistentVolumeClaim:
        claimName: maven-cache
---
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: generate-build-id
spec:
  params:
    - name: version
      description: The version of the application
      type: string
  results:
    - name: datetime
      description: The current date and time
    - name: buildId
      description: The build ID
  steps:
    - name: generate-datetime
      image: ikubernetes/admin-box:v1.2
      script: |
        #!/usr/bin/env bash
        datetime=`date +%Y%m%d-%H%M%S`
        echo -n ${datetime} | tee $(results.datetime.path)
    - name: generate-buildid
      image: ikubernetes/admin-box:v1.2
      script: |
        #!/usr/bin/env bash
        buildDatetime=`cat $(results.datetime.path)`
        buildId=$(params.version)-${buildDatetime}
        echo -n ${buildId} | tee $(results.buildId.path)
---
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: image-build-and-push
spec:
  description: package the application files to image
  params:
    - name: dockerfile
      description: The path to the dockerfile to build (relative to the context)
      default: Dockerfile
    - name: image-url
      description: Url of image repository
    - name: image-tag
      description: Tag to apply to the built image
  workspaces:
    - name: source
    - name: dockerconfig
      mountPath: /kaniko/.docker
  steps:
    - name: image-build-and-push
      image: gcr.dockerproxy.com/kaniko-project/executor:latest
      securityContext:
        runAsUser: 0
      env:
        - name: DOCKER_CONFIG
          value: /kaniko/.docker
      command:
        - /kaniko/executor
      args:
        - --dockerfile=$(params.dockerfile)
        - --context=$(workspaces.source.path)/source
        - --destination=$(params.image-url):$(params.image-tag)
        - --cache=true
        - --cache-dir=$(workspaces.source.path)/cache
---
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: deploy-using-kubectl
spec:
  workspaces:
    - name: source
      description: The git repo
  params:
    - name: deploy-config-file
      description: The path to the yaml file to deploy within the git source
    - name: image-url
      description: Image name including repository
    - name: image-tag
      description: Image tag
  steps:
    - name: update-yaml
      image: alpine:3.16
      command: ["sed"]
      args:
        - "-i"
        - "-e"
        - "s@__IMAGE__@$(params.image-url):$(params.image-tag)@g"
        - "$(workspaces.source.path)/source/deploy/$(params.deploy-config-file)"
    - name: run-kubectl
      image: lachlanevenson/k8s-kubectl
      command: ["kubectl"]
      args:
        - "apply"
        - "-f"
        - "$(workspaces.source.path)/source/deploy/$(params.deploy-config-file)"
---

参考文档

https://tekton.dev/docs/pipelines/tasks/



标签:Task,workspaces,name,image,基础,Tekton,Tasks,path,description
From: https://blog.51cto.com/wangguishe/8788278

相关文章

  • Tekton Trigger Interceptors 基础
    Interceptors概述Interceptor是针对特定平台的的事件处理器,在TriggerBinding之前运行。它允许您执行有效负载过滤、验证(使用秘密)、转换、定义和测试触发条件,以及实现其他有用的处理。一旦事件数据通过Interceptor,它就会在将有效负载数据传递到TriggerBinding之前转到Trigger。......
  • 【python基础之装饰器】---装饰器
    title:【python基础之装饰器】---装饰器date:2023-12-1118:54:06updated:2023-12-1214:30:00description:cover:https://home.cnblogs.com/u/dream-ze/【一】什么是装饰器装饰代指为被装饰对象添加新的功能,器代指器具/工具,装饰器与被装饰的对象均可......
  • 【python基础之函数对象和闭包】 --- 函数对象与闭包
    title:【python基础之函数对象和闭包】---函数对象与闭包date:2023-12-1119:20:00updated:2023-12-1119:20:00description:cover:https://home.cnblogs.com/u/dream-ze/【一】函数对象函数对象指的是函数可以被当做数据来处理具体可以分为四......
  • 系统架构设计系列之基础:初探软件架构设计
    前言欢迎来到软件架构设计的世界,这是一次面向有志成为架构师的研发工程师的学习和分享交流的机会。本系列内容将结合理论和实践经验,探讨软件架构的基本知识、设计原则和最佳实践,旨在和大家一起更好地理解软件架构设计的重要性和成为架构师的路径。一、架构的基础我们都知道编......
  • 图的基础概念和深搜广搜序
    有关图的定义图是由若干给定的顶点及连接两顶点的边所构成的图形,这种图形通常用来描述某些事物之间的某种特定关系。顶点用于代表事物,连接两顶点的边则用于表示两个事物间具有这种关系。图论起源于著名的柯尼斯堡七桥问题(下图所示),该问题于1736年被欧拉解决,因此普遍认为欧拉是图......
  • 面试基础复盘
    px、rpx、em、rem、vw、vhpx:px就是pixel的缩写,意味像素。px就是一张图片最小的一个点,一张位图就是无数个这样的点构成的,是web开发中最常用的像素单位。rpx:由微信小程序官方推出的新单位,适用于移动端的uni-app或者微信小程序的开发。可以根据屏幕宽度进行自适应,1rpx实际上等......
  • shell脚本基础学习
    shell脚本基础学习一.shell的解释:shell具备编程的能力shell是一种解释型语言(不需要提前编译,一边执行一边解释,每种解释性语言都有解释器)shell语言支持大部分编程语言都具备的功能(if判断,for循环,变量,数组,函数,加减乘除,逻辑运算)二.shell脚本的规范模板tips:shell脚本的本......
  • cesium.js入门基础教程
    运行环境搭建下载cesium.js从https://cesium.com/downloads/下载cesium.js:在vsCode中建立index.html和index.js,并在index.html中引入index.js:index.html:<!DOCTYPEhtml><htmllang="en"><head><!--Usecorrectcharacterset.-->&......
  • C++基础 -4- C/C++混合编程
    ———————C/C++混合编程———————......
  • 锁-基础篇(3)
    乐观锁和悲观锁乐观锁与悲观锁不是指具体的什么类型的锁,而是指看待并发同步的角度。悲观锁认为对于同一个数据的并发操作,一定是会发生修改的,哪怕没有修改,也会认为修改。因此对于同一个数据的并发操作,悲观锁采取加锁的形式。悲观的认为,不加锁的并发操作一定会出问题。乐观锁则......