持续集成是云原生应用的支柱技术之一,因此在交付基于云原生的一些支撑产品的时候,CICD 是一个无法拒绝的需求。为了满足这种需要,自然而然会想到对 Jenkins(X) 或者 Gitlab 进行集成,然而这两个东西虽说功能强大,却也不是为了做螺丝钉而设计的,其中包含了大量的周边功能,并非我们产品的需要,并且其接口和 Pipeline 设计也不太容易复用和提供给用户进行定制,而 Tekton 这个东西就有趣多了:
- Kubernetes 原生
Tekton 的所有配置都是使用 CRD 方式进行编写存储的,非常易于检索和使用。 - 配置和流程分离
Tekton 的 Pipeline 和配置可以分开编写,使用名称进行引用。 - 轻量级
核心的 Pipeline 非常轻便,适合作为组件进行集成,另外也有周边的 Dashboard、Trigger、CLI 等工具,能够进一步挖掘其潜力。 - 可复用、组合的 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 稍稍复杂一点的小例子:
-
下载一个文件。
-
传递给下一个环节。
为什么不用官方例子呢?我想糊弄过 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
对我们定义的 download
和 display
两个 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 get
和 kubectl logs
来查看运行情况。
结果
这个项目还是很符合它的名字的描述的,真的只有 Pipeline 而已,它的最重要职责就是用 CRD 进行解耦,用 Step->Task->Pipeline 的三级形式对 CICD 中的动作进行抽象和分离;用 Task/TaskRun 以及 Pipeline/PipelineRun/Resource 的组合,把运行环节和输入输出内容进行分离。这样一来,就提供了一个稳定、可重构和组合的过程引擎,以及可定制的执行能力。
Tekton 还提供了一些其它周边项目,例如 Dashboard、Trigger 等,能给 Pipeline 项目提供一定的帮助。
文章来源于互联网:可能是最适合自定义的 Pipeline:Tekton