专栏首页伪架构师可能是最适合自定义的 Pipeline:Tekton

可能是最适合自定义的 Pipeline:Tekton

持续集成是云原生应用的支柱技术之一,因此在交付基于云原生的一些支撑产品的时候,CICD 是一个无法拒绝的需求。为了满足这种需要,自然而然会想到对 Jenkins(X) 或者 Gitlab 进行集成,然而这两个东西虽说功能强大,却也不是为了做螺丝钉而设计的,其中包含了大量的周边功能,并非我们产品的需要,并且其接口和 Pipeline 设计也不太容易复用和提供给用户进行定制,而 Tekton 这个东西就有趣多了:

  1. Kubernetes 原生 Tekton 的所有配置都是使用 CRD 方式进行编写存储的,非常易于检索和使用。
  2. 配置和流程分离 Tekton 的 Pipeline 和配置可以分开编写,使用名称进行引用。
  3. 轻量级 核心的 Pipeline 非常轻便,适合作为组件进行集成,另外也有周边的 Dashboard、Trigger、CLI 等工具,能够进一步挖掘其潜力。
  4. 可复用、组合的 Pipeline 构建方式 非常适合在集成过程中对 Pipeline 进行定制。

安装

安装过程非常轻松:

$ kubectl apply -f \
https://storage.googleapis.com/tekton-releases/latest/release.yaml
namespace/tekton-pipelines created
podsecuritypolicy.policy/tekton-pipelines created
clusterrole.rbac.authorization.k8s.io/tekton-pipelines-admin created
...
$ kubectl get pods -n tekton-pipelines
NAME                                           READY   STATUS    RESTARTS   AGE
tekton-pipelines-controller-5888756f5c-t5kgx   1/1     Running   0          2m10s
tekton-pipelines-webhook-7494f6f84b-gm92g      1/1     Running   0          2m10s

概念

今天的内容主要涉及几个 CRD:

  • Task:任务环节。
  • TaskRun:Task 对象的运行参数。
  • Pipeline:Task 的组合。
  • PipelineRun:Pipeline 的运行参数。

Hello world

这里有个比 Hello world 稍稍复杂一点的小例子:

  1. 下载一个文件。
  2. 传递给下一个环节。

为什么不用官方例子呢?我想糊弄过 CI/CD/DevOps 的同学们应该都清楚,能使用容器、能执行 Shell、能获得输出、能传递文件,这几个能力加起来,足够冒充工具链小能手了。循序渐进并不适合心急的朋友们。

下载文件并显示内容

首先引入的是 Task 对象:

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
name: get-http-file
spec:
steps:
- name: show
image: dustise/sleep
command:
- curl
args:
- "-s"
- "https://httpbin.org/ip"

这里定义了一个 Task CRD,使用 kubectl apply -f 提交到集群,会看到 task.tekton.dev/get-http-file created 的反馈信息。

要运行这个环节,可以创建一个 TaskRun 对象:

apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
name: get-http-file-run
spec:
taskRef:
name: get-http-file

提交之后,可以使用 kubectl get taskrun get-http-file-run -o yaml 来查看任务执行状况:

apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
...
status:
...
conditions:
- message: All Steps have completed executing
reason: Succeeded
status: "True"
type: Succeeded
podName: get-http-file-run-pod-51fddd
...

这里能看到很多任务执行信息,还能看到执行这个步骤的 Pod 名称,看看它的日志:

$ kubectl logs -f get-http-file-run-pod-51fddd
{
"origin": "165.22.223.124, 165.22.223.124"
}

看来 CICD 过程中的日志输出和命令执行基本是有保障的,那么如何完成工件的传递呢?

文件传递

通常我们都会想到使用 PVC 来进行文件存储和共享,例如:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: trans
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi

首先把上面的步骤命令行改为:

command:
- curl
args:
- "-s"
- "-o"
- "/share/share.json"
- "https://httpbin.org/ip"
volumeMounts:
- name: trans
mountPath: /share

第二个步骤就更加简单,只要显示文件内容即可:

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
name: display
spec:
steps:
- name: showcontent
image: alpine
command: ["cat"]
args: ["/share/share.json"]
volumeMounts:
- name: trans
mountPath: /share

这里需要使用 Pipeline 对象把步骤连接起来。

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: pipeline1
spec:
tasks:
- name: step1
taskRef:
name: download
- name: step2
runAfter: [step1]
taskRef:
name: display

这里的定义,使用 Pipeline 对象把两个步骤串联起来,其中使用 taskRef 对我们定义的 downloaddisplay 两个 Task 对象进行引用,并且使用 runAfter 数组定义先后顺序。

TaskRun 类似,Pipeline 定义之后,还需要用 PipelineRun 对象来执行一次,上面的 Task 中只定义了 volumeMounts,具体的 Volume 就要在 PipelineRun 中定义:

apiVersion: tekton.dev/v1alpha1
kind: PipelineRun
metadata:
name: pprun1
spec:
pipelineRef:
name: pipeline1
podTemplate:
volumes:
- name: trans
persistentVolumeClaim:
claimName: trans

把 PipelineRun 提交到集群之后,就可以看到,Pipeline 开始运行,可以使用 kubectl getkubectl logs 来查看运行情况。

结果

这个项目还是很符合它的名字的描述的,真的只有 Pipeline 而已,它的最重要职责就是用 CRD 进行解耦,用 Step->Task->Pipeline 的三级形式对 CICD 中的动作进行抽象和分离;用 Task/TaskRun 以及 Pipeline/PipelineRun/Resource 的组合,把运行环节和输入输出内容进行分离。这样一来,就提供了一个稳定、可重构和组合的过程引擎,以及可定制的执行能力。

Tekton 还提供了一些其它周边项目,例如 Dashboard、Trigger 等,能给 Pipeline 项目提供一定的帮助。

本文分享自微信公众号 - 伪架构师(fake-architect),作者:崔秀龙

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 全面易用的镜像漏洞检测工具:Trivy

    相对于其它同类工具,Trivy 非常适合自动化操作,从 CircleCI 之类的公有服务,到企业内部使用的 Jenkins、Gitlab 等私有工具,或者作为开...

    崔秀龙
  • (译)在 Kubernetes 和 Istio 环境下进行蓝绿部署

    作为一个服务网格系统,Istio 为服务间通信提供稳定性、透明性和安全性方面的保障。不论集群内外的服务,只要其访问目标是网格内的服务,就都会被 Istio 所拦...

    崔秀龙
  • Helm 和 Kustomize:不只是含谷量的区别

    Kustomize 问世的时候,我是比较鄙视的——非要造个谷歌的轮子么?不过最近抽出时间熟悉了一下 Kustomize,发现我还是带了有色眼镜。二者功能虽然有所...

    崔秀龙
  • 可能是最适合自定义的 Pipeline:Tekton

    ? 本文作者 / 龙少 开源软件、自动化爱好者。资深马拉松酱油选手。 持续集成是云原生应用的支柱技术之一,因此在交付基于云原生的一些支撑产品的时候,CICD ...

    腾讯云TStack
  • cuDNN 5对RNN模型的性能优化

    用户1737318
  • IP代理池之验证是否有效

    把proxy pool项目跑起来,但也不知道这些ip怎么用,爬虫的时候是否用代理去爬取,下面通过一个例子来看看。

    py3study
  • Yarn 的日志聚集功能配置使用

    需要 hadoop 的安装目录/etc/hadoop/yarn-site.xml 中进行配置

    梅花
  • 原 Spark On Yarn完全分布式搭

    云飞扬
  • 手把手教你在腾讯云上搭建hadoop3.x伪集群的方法

    /home/centos/software/hadoop-3.1.3.tar.gz

    砸漏
  • YARN之label调度在EMR中的应用

    在腾讯云EMR的用户场景使用当中,有部分用户要求希望他们能在任务高峰期,对集群进行扩容,利用云端的弹性计算资源,为集群扩展计算能力,并且在集群相对空闲的情况下,...

    shangwen_

扫码关注云+社区

领取腾讯云代金券