雲原生CI/CD：Tektoncd/pipeline之pipelineRun
簡介
上一節我們講過了pipeline，以及pipeline中如何進行與其他資源進行交互。但是pipeline就像個函數，它自己不會運行，要有個調用函數的觸發，才能讓pipeline開始運行。這個調用就是pipelineRun（同樣taskRun也是調用task）。本節着重介紹pipelineRun.
pipelineRun概覽
PipelineRun可以實例化並執行pipeline，一個pipeline可以指定1個或者多個tasks以指定順序執行，而一個pipelineRun則可以執行Pipeline中的task直到所有的Task都執行結束或者執行某個task失敗。
注意：pipelineRun會自動的創建taskrun執行執行Pipeline中task,有幾個task就有自動創建幾個taskRun.
pipelineRun與其他資源的交互
指定目標pipeline
您必須通過引用現有的Pipeline定義，或直接在PipelineRun中嵌入Pipeline定義來指定希望PipelineRun執行的目標Pipeline。
使用pipelineSpec字段來指定已有的pipeline：
spec:
pipelineRef:
name: mypipeline
直接在pipelineRun中內嵌一個pipeline定義：
spec:
pipelineSpec:
tasks:
- name: task1
taskRef:
name: mytask
也可在內嵌pipeline定義時定義task:
spec:
pipelineSpec:
tasks:
- name: task1
taskSpec:
steps:
...
指定resource
pipeline需要pipelineResources來提供輸入和task的輸出。用戶必須在PipelineRun的spec部分的resources字段中配置這些資源。resource的配置可以對接tekton的trigger組件用於拉取倉庫代碼，也可以用於定於github上的倉庫代碼，還可以用於定義docker 倉庫。
用戶可以使用resourceRef字段引用PipelineResources：
spec:
resources:
- name: source-repo
resourceRef:
name: skaffold-git
- name: web-image
resourceRef:
name: skaffold-image-leeroy-web
- name: app-image
resourceRef:
name: skaffold-image-leeroy-app
用戶也可以使用resourceSpec字段將PipelineResource定義嵌入PipelineRun中：
spec:
resources:
- name: source-repo
resourceSpec:
type: git
params:
- name: revision
value: v0.32.0
- name: url
value: https://github.com/GoogleContainerTools/skaffold
- name: web-image
resourceSpec:
type: image
params:
- name: url
value: gcr.io/christiewilson-catfactory/leeroy-web
- name: app-image
resourceSpec:
type: image
params:
- name: url
value: gcr.io/christiewilson-catfactory/leeroy-app
指定參數
用戶可以指定要在執行期間傳遞給pipeline的參數，包括pipeline中不同task的同一參數的不同值。舉例：
spec:
params:
- name: pl-param-x
value: "100"
- name: pl-param-y
value: "500"
指定自定義的ServiceAccount憑據
通過在PipelineRun定義的serviceAccountName字段中指定ServiceAccount對象名稱，可以使用一組特定的憑據在PipelineRun中執行Pipeline。如果未明確指定，則PipelineRun創建的TaskRun將使用configmap-defaults ConfigMap中指定的憑據執行。如果未指定此默認值，則TaskRun將使用爲目標名稱空間設置的默認服務帳戶執行。
將ServiceAccount憑據映射到task
如果在指定執行憑據時需要更多粒度，請使用serviceAccounNames字段將特定serviceAccountName值映射到管道中的特定Task。這將覆蓋您可能爲管道設置的全局serviceAccountName，如上一節所述。
例如，用戶指定以下映射：
spec:
serviceAccountName: sa-1
serviceAccountNames:
- taskName: build-task
serviceAccountName: sa-for-build # 每個Task都指定一個serviceAccount
對於此pipeline:
kind: Pipeline
spec:
tasks:
- name: build-task
taskRef:
name: build-push
- name: test-task
taskRef:
name: test
那麼test-task將使用sa-1帳戶執行， 而build-task將使用sa-for-build執行。
指定workspace
如果管道指定一個或多個工作區，則必須將這些工作區映射到PipelineRun定義中的相應物理卷。例如，可以將PersistentVolumeClaim卷映射到工作區，如下所示：
workspaces:
- name: myworkspace # must match workspace name in Task
persistentVolumeClaim:
claimName: mypvc # this PVC must already exist
subPath: my-subdir
配置故障超時
用戶可以使用超時字段以分鐘爲單位設置PipelineRun的所需超時值。如果未在PipelineRun中指定此值，則將應用全局默認超時值。如果將超時設置爲0，則在遇到錯誤時PipelineRun將立即失敗。首次安裝Tekton時，全局默認超時設置爲60分鐘。您可以使用tekton-pipeline命名空間下的config-defaults configmao中的default-timeout-minutes字段設置其他全局默認超時值。
超時值是符合Go的ParseDuration格式的持續時間。例如，有效值爲1h30m，1h，1m和60s。如果將全局超時設置爲0，則在遇到錯誤時所有未設置常規超時的PipelineRun將立即失敗
指定task運行規範
指定PipelineRunTaskSpec的列表，其中包含TaskServiceAccountName，TaskPodTemplate和TaskName。根據TaskName將規範映射到相應的Task，PipelineTask將與配置的TaskServiceAccountName和TaskPodTemplate一起運行，覆蓋pipeline範圍的ServiceAccountName和podTemplate配置，例如：
spec:
podTemplate:
securityContext:
runAsUser: 1000
runAsGroup: 2000
fsGroup: 3000
taskRunSpecs:
- taskName: build-task #指定task的名稱
taskServiceAccountName: sa-for-build
taskPodTemplate:
nodeSelector:
disktype: ssd
如果與此pipeline一起使用，則build-task將使用任務特定的Pod模板（其中nodeSelector的磁盤類型等於ssd）。
總結要點
- pipelineRun與pipeline的關係是調用與被調用關係。pipeline就像定義好的函數，而pipelineRun就像是對函數的調用，還可以在函數中傳參數；
- 一直有個疑惑，task和pipeline感覺差不太多，task有多個step作爲執行步驟，pipeline分多個Task來執行任務。爲什麼不同意task和pipeline呢？可能是因爲pipeline能提供比task更復雜的功能，比如task的輸出作爲task的輸入這種。所以複雜的設計使用pipeline，簡單的使用task和taskRun就可以了。