pipline总览
PipelineRun允许您实例化并执行集群上的。A 以所需的执行顺序Pipeline指定一个或多个Tasks。一个PipelineRun 执行Tasks中Pipeline,直到所有的顺序,他们被指定Tasks已成功执行或出现故障。
注意: A会PipelineRun自动TaskRuns为中的每个 创建对应Task的内容Pipeline。
该Status字段跟踪的当前状态PipelineRun,并可用于监视进度。此字段包含每个的状态TaskRun,以及PipelineSpec用于实例化此状态的完整状态,以实现PipelineRun完全可审核性。
配置 PipelineRun
一个Pipeline定义支持以下领域:
- 需要:
- apiVersion-指定API版本,例如 tekton.dev/v1beta1。
- kind-将此资源对象标识为Pipeline对象。
- metadata-指定唯一标识Pipeline对象的元数据 。例如,一个name。
- spec-指定此Pipeline对象的配置信息。必须包括:
- tasks-指定Tasks组成的Pipeline 以及其执行的详细信息。
- 可选的:
- resources- 仅alpha,指定 PipelineResources由Tasks组成的需要或创建Pipeline。
- tasks:
- resources.inputs/resource.outputs
- from-表示a的数据PipelineResource 来自previous的输出Task。
- runAfter-表示a Task 应该在其他一个或多个之后执行,Tasks而不进行输出链接。
- retries-指定Task失败后重试执行的次数。不适用于执行取消。
- conditions-指定Conditions仅Task 在成功评估后才允许执行。
- timeout-指定Task失败之前的超时。
- results-指定Pipeline发出执行结果的位置。
- description-包含Pipeline对象的详细说明。
指定 Resources
pipline需要piplineresources为tasks提供输入存储输出,您可以在Pipeline定义的spec部分的resources字段中声明它们。每个条目都需要唯一的名称和类型。例如:
spec:
resources:
- name: my-repo
type: git
- name: my-image
type: image
指定 Workspaces
Workspaces允许指定一个或多个pipline中task运行时所需的volme
spec:
workspaces:
- name: pipeline-ws1 # The name of the workspace in the Pipeline
tasks:
- name: use-ws-from-pipeline
taskRef:
name: gen-code # gen-code expects a workspace with name "output"
workspaces:
- name: output
workspace: pipeline-ws1
- name: use-ws-again
taskRef:
name: commit # commit expects a workspace with name "src"
runAfter:
- use-ws-from-pipeline # important: use-ws-from-pipeline writes to the workspace first
workspaces:
- name: src
workspace: pipeline-ws1
指定Parameters
您可以指定要在执行时提供给pipline的全局参数,例如编译flags或artifact名称。参数从其对应的PipelineRun传递到Pipeline,并且可以替换管道中每个Task中指定的模板值。
参数名称:
- 必须仅包含字母数字字符,连字符(-)和下划线(-)
- 必须以字母或下划线(-)开头。
例如,fooIs-Bar_是有效的参数名称,而barIsBa$或0banana不是。
每个声明的参数都有一个类型字段,可以将其设置为数组或字符串。如果在整个执行过程中提供给管道的编译标志的数量不同,则array很有用。如果未指定任何值,则类型字段默认为字符串。提供实际参数值时,将根据类型字段验证其解析的类型。参数的说明和默认字段是可选的。
以下示例说明了Pipeline中Parameters的用法。
以下Pipeline声明了一个名为context的输入参数,并将其值传递给Task以在Task中设置pathToContext参数的值。如果您为默认字段指定一个值,并在PipelineRun中调用此Pipeline而不为上下文指定值,则将使用该值。
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: pipeline-with-parameters
spec:
params:
- name: context
type: string
description: Path to context
default: /some/where/or/other
tasks:
- name: build-skaffold-web
taskRef:
name: build-push
params:
- name: pathToDockerFile
value: Dockerfile
- name: pathToContext
value: "$(params.context)"
以下PipelineRun为上下文提供值
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
name: pipelinerun-with-parameters
spec:
pipelineRef:
name: pipeline-with-parameters
params:
- name: "context"
value: "/workspace/examples/microservices/leeroy-web"
为Pipeline添加tasks
您的Pipeline定义必须至少引用一个Task。每个Task内Pipeline必须有一个有效的 name和一个taskRef。例如:
tasks:
- name: build-the-image
taskRef:
name: build-push
您可以使用PipelineResources作为Tasks中Pipeline的输入和输出。例如:
spec:
tasks:
- name: build-the-image
taskRef:
name: build-push
resources:
inputs:
- name: workspace
resource: my-repo
outputs:
- name: image
resource: my-image
您还可以提供Parameters:
spec:
tasks:
- name: build-skaffold-web
taskRef:
name: build-push
params:
- name: pathToDockerFile
value: Dockerfile
- name: pathToContext
value: /workspace/examples/microservices/leeroy-web
使用from参数
如果管道中的任务需要使用先前任务的输出作为其输入,请使用可选的from参数来指定必须在将其输出作为其输入的任务之前执行的任务列表。 当目标任务执行时,仅使用此列表中最后一个任务生成的所需PipelineResource的版本。 此输出PipelineReource输出的名称必须与在提取它的Task中指定的输入PipelineResource的名称匹配。
在下面的示例中,deploy-app任务提取名为my-image的build-app任务的输出作为其输入。 因此,无论在管道中声明这些任务的顺序如何,build-app Task都将在deploy-app Task之前执行。
- name: build-app
taskRef:
name: build-push
resources:
outputs:
- name: image
resource: my-image
- name: deploy-app
taskRef:
name: deploy-kubectl
resources:
inputs:
- name: image
resource: my-image
from:
- build-app
使用runAfter参数
如果您需要任务在管道中按特定顺序执行,但是它们没有需要from参数的资源依赖关系,请使用runAfter参数指示任务必须在其他一个或多个任务之后执行。
在下面的示例中,我们要在构建代码之前对其进行测试。 由于test-app Task没有输出,因此build-app Task使用runAfter来指示test-app必须在其之前运行,而不管它们在管道定义中的引用顺序如何。
- name: test-app
taskRef:
name: make-test
resources:
inputs:
- name: workspace
resource: my-repo
- name: build-app
taskRef:
name: kaniko-build
runAfter:
- test-app
resources:
inputs:
- name: workspace
resource: my-repo
使用重试参数
对于管道中的每个任务,您可以指定Tekton失败时应重试其执行的次数。 当任务失败时,相应的TaskRun将其成功条件设置为False。 retries参数指示Tekton在发生这种情况时重试执行任务。
如果您希望Task在执行过程中遇到问题(例如,您知道网络连接性或缺少依赖项会出现问题),请将其retries参数设置为大于0的合适值。如果您未明确指定值 ,Tekton不会尝试再次执行失败的任务。
在下面的示例中,构建映像任务的执行将在失败后重试一次。 如果重试的执行也失败,则任务执行整体会失败。
tasks:
- name: build-the-image
retries: 1
taskRef:
name: build-push
使用Conditions保护task执行
要仅在满足某些条件时运行任务,可以使用条件字段来保护任务执行。 条件字段使您可以列出对条件资源的一系列引用。 声明的条件在任务运行之前运行。 如果所有条件都成功评估,则运行任务。 如果任何条件失败,则不运行任务,并且TaskRun状态字段ConditionSucceeded设置为False,其原因设置为ConditionCheckFailed。
如下示例,is-master-branch依赖于Conditions资源,deploy task将仅在is-master-branch条件校验成功时执行
apiVersion: tekton.dev/v1alpha1
kind: Condition
metadata:
name: is-master-branch
spec:
params:
- name: branch-name
default: master
check:
image: alpine
git rev-parse --verify $(params.branch)
---
tasks:
- name: deploy-if-branch-is-master
conditions:
- conditionRef: is-master-branch
params:
- name: branch-name
value: master
taskRef:
name: deploy
与常规任务失败不同,条件失败不会自动使整个PipelineRun失败
- 仍然运行不依赖于Task(通过from或runAfter)的其他任务。
配置故障超时
您可以使用管道内“Task”规范中的“Timeout”字段来设置执行该管道的“TaskRun”中执行该任务的TaskRun的超时。 超时值是符合Go的ParseDuration格式的持续时间。 例如,有效值为1h30m,1h,1m和60s。
spec:
tasks:
- name: build-the-image
taskRef:
name: build-push
Timeout: "0h1m30s"
在Task级别配置执行结果
任务在执行时可以发出结果.您可以通过变量替换将这些结果值用作管道中后续任务中的参数值。 Tekton推断任务顺序,以便发出引用结果结果的任务在消耗它们的任务之前执行。
在下面的示例中,先前任务名称Task的结果声明为bar-result:
params:
- name: foo
value: "$(tasks.previous-task-name.results.bar-result)"
在Pipeline级别配置执行结果
您可以将管道配置为在执行期间发出结果,以引用其中每个任务发出的结果。
在下面的示例中,管道使用名称sum指定一个结果条目,该名称引用第二个添加Task发出的结果
results:
- name: sum
description: the sum of all three operands
value: $(tasks.second-add.results.sum)
配置task执行顺序
您可以在管道中连接任务,以便它们在有向非循环图(DAG)中执行。 流水线中的每个任务都成为图上的一个节点,可以与一条边相连,这样一个任务将先于另一个边运行,并且流水线的执行进度到完成而不会陷入无限循环。
使用以下命令完成此操作:
- 每个任务使用的PipelineResources上的from子句
- 相应任务上的runAfter子句
- 通过将一个任务的结果链接到另一个任务的参数
例如,管道定义如下
- name: lint-repo
taskRef:
name: pylint
resources:
inputs:
- name: workspace
resource: my-repo
- name: test-app
taskRef:
name: make-test
resources:
inputs:
- name: workspace
resource: my-repo
- name: build-app
taskRef:
name: kaniko-build-app
runAfter:
- test-app
resources:
inputs:
- name: workspace
resource: my-repo
outputs:
- name: image
resource: my-app-image
- name: build-frontend
taskRef:
name: kaniko-build-frontend
runAfter:
- test-app
resources:
inputs:
- name: workspace
resource: my-repo
outputs:
- name: image
resource: my-frontend-image
- name: deploy-all
taskRef:
name: deploy-kubectl
resources:
inputs:
- name: my-app-image
resource: my-app-image
from:
- build-app
- name: my-frontend-image
resource: my-frontend-image
from:
- build-frontend
根据下图执行:
| |
v v
test-app lint-repo
/ \
v v
build-app build-frontend
\ /
v v
deploy-all
- lint-repo和test-app Task没有from和runafter子句并开始同时执行。
- 一旦测试应用程序完成,由于build-app和build-frontend都运行在test-app Task之后,因此它们同时开始执行。
- 全部部署任务在build-app和build-frontend都完成后执行,因为它会从这两者中提取PipelineResources。
- 一旦lint-repo和deploy-all全部完成执行,整个管道就完成了执行。
添加Finally
您可以在finally部分下指定一个或多个最终任务的列表。 无论任务是成功还是错误,都保证在任务下的所有PipelineTasks完成之后并行执行最终任务。 最终任务与tasks部分下的PipelineTasks非常相似,并且遵循相同的语法。 每个最终任务必须具有有效的名称和taskRef或taskSpec。 例如:
spec:
tasks:
- name: tests
taskRef:
Name: integration-test
finally:
- name: cleanup-test
taskRef:
Name: cleanup
在最终任务中指定工作区
finally任务可以指定PipelineTasks可能已经利用的工作空间,例如Secrets中保存的凭据的挂载点。为了支持该要求,您可以在Workspaces字段中为与任务相似的Final tasks指定一个或多个workspaces。
spec:
resources:
- name: app-git
type: git
workspaces:
- name: shared-workspace
tasks:
- name: clone-app-source
taskRef:
name: clone-app-repo-to-workspace
workspaces:
- name: shared-workspace
workspace: shared-workspace
resources:
inputs:
- name: app-git
resource: app-git
finally:
- name: cleanup-workspace
taskRef:
name: cleanup-workspace
workspaces:
- name: shared-workspace
workspace: shared-workspace
为final tasks指定参数
spec:
tasks:
- name: tests
taskRef:
Name: integration-test
finally:
- name: report-results
taskRef:
Name: report-results
params:
- name: url
value: "someURL"
使用finally的PipelineRun状态
不设置 finally
:
PipelineTasks under tasks | PipelineRun status | Reason |
---|---|---|
all PipelineTasks successful | true | Succeeded |
one or more PipelineTasks skipped and rest successful | true | Completed |
single failure of PipelineTask | false | failed |
设置 finally
:
PipelineTasks under tasks | Final Tasks | PipelineRun status | Reason |
---|---|---|---|
all PipelineTask successful | all final tasks successful | true | Succeeded |
all PipelineTask successful | one or more failure of final tasks | false | Failed |
one or more PipelineTask skipped and rest successful | all final tasks successful | true | Completed |
one or more PipelineTask skipped and rest successful | one or more failure of final tasks | false | Failed |
single failure of PipelineTask | all final tasks successful | false | failed |
single failure of PipelineTask | one or more failure of final tasks | false | failed |
扫描关注我: