Tekton系列之實踐篇-如何用Jenkins來管理Tekton
在《??Tekton系列之實踐篇-由Jenkins改成Tekton??》中，我們可以將Jenkinsfile改成Tekton Pipeline，但是Tekton有一個很大的問題是不能很好的劃分權(quán)限，特別是在Dashboard上根本就做權(quán)限控制，那如果在實際中使用的話權(quán)限不明會帶來很多問題，比如誰刪了什么，誰執(zhí)行了什么都不知道。
如果你公司有自動化運維平臺，可以接入Tekton，如果沒有就需要在Github上找是否有相關(guān)的Dashboard或者平臺，可惜我什么都沒有.....
目前我使用的Kubesphere來管理K8s集群以及流水線，所以我就在想怎么使用kubesphere管理。不過截止目前版本，Kubesphere的流水線引擎還是Jenkins，除非二開，不然沒辦法直接繼承Tekton，期待Kubesphere把Tekton也加入(https://github.com/kubesphere/community/blob/master/sig-advocacy-and-outreach/summer-ospp/kubeSphere-tekton-integration_zh-CN.md)。
那應(yīng)該怎么做呢?我想到一個很牛逼(SB)的辦法，如下：
看懂了么?
其實就是繼續(xù)使用Jenkins做Kubesphere的流水線引擎，然后將Jenkins和Tekton進行打通，這樣是不是間接使用了Tekton?這是不是一個很牛逼(SB)的idea?
但是悲劇來了，Jenkins的Tekton插件要求Jenkins最低的版本是2.263，而Kubesphere的Jenkins版本是2.49，而且升級非常麻煩，麻煩到官方都不建議升級的地步。所以這里只能退而求其次，使用Jenkins來進行實驗了。
部署Jenkins
Jenkins的部署方式有很多，這里采用Helm的方式來部署，簡單快捷。
首先需要安裝Helm命令，見文檔(https://helm.sh/docs/intro/install/)。
接著安裝Jenkins，如下：
helm repo add jenkinsci https://charts.jenkins.io
helm repo update
# 我習慣把CHART下載到本地，方便管理
helm pull jenkinsci/jenkins
# 這里有一步解壓的過程，然后進入Jenkins目錄進行部署
# 部署
kubectl create ns devops
helm install jenkins -n devops .
部署完成后即可進行登錄了。
訪問地址要么使用NodePort，要么使用ingress，這里沒有展示配置過程。
安裝Jenkins插件
為了實現(xiàn)上面的需求，我找到一個Jenkins插件可以用來管理Tekton，插件名叫tekton-client-plugin tekton-client-plugin(https://github.com/jenkinsci/tekton-client-plugin)。
tekton-client-plugin用來打通Jenkins和Tekton，功能也不復(fù)雜，可以到文檔(https://plugins.jenkins.io/tekton-client/#documentation)進行學習。
如果Jenkins版本大于2.263，可以直接在插件中心下載，如下：
配置權(quán)限
這里是權(quán)限是Jenkins操作Tekton的權(quán)限，如下：
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: tekton-role
namespace: tekton-devops-pipeline
rules:
- apiGroups:
- ""
resources:
- pods
- pods/log
verbs:
- get
- list
- watch
- apiGroups:
- tekton.dev
resources:
- tasks
- taskruns
- pipelines
- pipelineruns
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tekton-role-binding
namespace: tekton-devops-pipeline
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: tekton-role
subjects:
- kind: ServiceAccount
name: jenkins
namespace: devops
注意授權(quán)的serviceaccount和namespace。
編寫Jenkinsfile
要使用的Jenkinsfile其實很簡單。但是由于我們是多分支發(fā)布，所以Jenkinsfile如下：
pipeline {
agent any
parameters {
choice(description: '選擇分支', name: 'BRANCH_NAME', choices: ['dev', 'test', 'uat', 'pre', 'prod'])
}
stages {
stage('deploy to dev'){
when{
expression {
return "$BRANCH_NAME".contains('dev')
}
}
steps{
tektonCreateRaw input: 'deploy/dev/pipeline.yaml', inputType: 'FILE', namespace: 'tekton-devops-pipeline'
}
}
stage('deploy to test'){
when{
expression {
return "$BRANCH_NAME".contains('test')
}
}
steps{
tektonCreateRaw input: 'deploy/test/pipeline.yaml', inputType: 'FILE', namespace: 'tekton-devops-pipeline'
}
}
stage('deploy to uat'){
when{
expression {
return "$BRANCH_NAME".contains('uat')
}
}
steps{
tektonCreateRaw input: 'deploy/uat/pipeline.yaml', inputType: 'FILE', namespace: 'tekton-devops-pipeline'
}
}
stage('deploy to pre'){
when{
expression {
return "$BRANCH_NAME".contains('pre')
}
}
steps{
tektonCreateRaw input: 'deploy/pre/pipeline.yaml', inputType: 'FILE', namespace: 'tekton-devops-pipeline'
}
}
stage('deploy to prod'){
when{
expression {
return "$BRANCH_NAME".contains('prod')
}
}
steps{
tektonCreateRaw input: 'deploy/prod/pipeline.yaml', inputType: 'FILE', namespace: 'tekton-devops-pipeline'
}
}
}
}
Tekton的PipelineRun按目錄分級，如下(這里只是為了方便，其實可以只用一個PipelineRun)：
弄完過后，就可以創(chuàng)建流水線了，如下創(chuàng)建一個hello-world-test的流水線。
然后選擇對應(yīng)的分支進行部署?？梢钥吹接|發(fā)了Tekton的PipelineRun，如下：
不過Jenkins這邊還有如下問題：
[Checks API] No suitable checks publisher found.
Failed: null
java.lang.NullPointerException
at org.waveywaves.jenkins.plugins.tekton.client.build.create.CreateRaw.createPipelineRun(CreateRaw.java:278)
at org.waveywaves.jenkins.plugins.tekton.client.build.create.CreateRaw.createWithResourceSpecificClient(CreateRaw.java:168)
at org.waveywaves.jenkins.plugins.tekton.client.build.create.CreateRaw.runCreate(CreateRaw.java:429)
at org.waveywaves.jenkins.plugins.tekton.client.build.create.CreateRaw.perform(CreateRaw.java:393)
at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:101)
at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:71)
at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
[Checks API] No suitable checks publisher found.
雖然報這個錯，但是Tekton PipelineRun觸發(fā)沒問題，具體原因還待排查，這就非常尷尬了?？吹较旅孢@一串串的紅色，心涼了一半(Tekton實際是可以允許成功)。
最后其實這篇實踐不算完成，Jenkins的問題還沒有解決，在網(wǎng)上查了半天資料也沒什么效果，很多說是Jenkins Check-API 插件的原因，但是沒有去測試。
不過，從理論上用Jenkins來管理Tekton是可行的，而且對于Jenkins重度用戶來說，也算是比較不錯的事情。當然我更想使用類似于Kubesphere這類來管理，期待Kubesphere把Tekton集成進去。
