Red Hat SummitOpenShift Pipelines について
OpenShift Pipelines の概要
概要
第1章 Red Hat OpenShift Pipeline について
Red Hat OpenShift Pipelines は、Kubernetes リソースをベースとしたクラウドネイティブの継続的インテグレーションおよび継続的デリバリー (CI/CD) ソリューションです。これは Tekton ビルディングブロックを使用し、基礎となる実装の詳細を抽象化して、複数のプラットフォームでのデプロイメントを自動化します。Tekton では、Kubernetes ディストリビューション間で移植可能な CI/CD パイプラインを定義するための標準のカスタムリソース定義 (CRD) が多数導入されています。
Red Hat OpenShift Pipelines は OpenShift Container Platform とは異なる頻度でリリースされるため、Red Hat OpenShift Pipelines ドキュメントは製品のマイナーバージョンごとに個別のドキュメントセットとして利用できるようになりました。
Red Hat OpenShift Pipelines ドキュメントは https://docs.openshift.com/pipelines/ で利用できます。
特定のバージョンのドキュメントは、バージョンセレクターのドロップダウンリストを使用するか、URL にバージョンを直接追加 (https://docs.openshift.com/pipelines/1.20 など) することにより利用できます。
さらに、Red Hat OpenShift Pipelines のドキュメントは、Red Hat カスタマーポータルの https://access.redhat.com/documentation/ja-jp/red_hat_openshift_pipelines/ でも入手できます。
Red Hat OpenShift Pipelines のライフサイクルとサポートされるプラットフォームに関する追加情報は、プラットフォームのライフサイクルポリシー を参照してください。
第2章 OpenShift Pipelines について
Red Hat OpenShift Pipelines は、Kubernetes リソースをベースとしたクラウドネイティブの継続的インテグレーションおよび継続的デリバリー (CI/CD) ソリューションです。これは Tekton ビルディングブロックを使用し、基礎となる実装の詳細を抽象化して、複数のプラットフォームでのデプロイメントを自動化します。Tekton では、Kubernetes ディストリビューション間で移植可能な CI/CD パイプラインを定義するための標準のカスタムリソース定義 (CRD) が多数導入されています。
2.1. 主な特長
- Red Hat OpenShift Pipelines は、分離されたコンテナーで必要なすべての依存関係と共にパイプラインを実行するサーバーレスの CI/CD システムです。
- Red Hat OpenShift Pipelines は、マイクロサービスベースのアーキテクチャーで機能する分散型チーム向けに設計されています。
- Red Hat OpenShift Pipelines は、拡張および既存の Kubernetes ツールとの統合を容易にする標準の CI/CD パイプライン定義を使用し、オンデマンドのスケーリングを可能にします。
- Red Hat OpenShift Pipelines を使用して、Kubernetes プラットフォーム全体で移植可能な S2I (Source-to-Image)、Buildah、Buildpacks、および Kaniko などの Kubernetes ツールを使用してイメージをビルドできます。
- OpenShift Container Platform Developer Console を使用して、Tekton リソースの作成、パイプライン実行のログの表示、OpenShift Container Platform namespace でのパイプラインの管理を実行できます。
2.2. OpenShift Pipeline の概念
このガイドでは、パイプラインの各種概念を詳述します。
2.2.1. Tasks
Task リソースは、パイプラインのビルディングブロックであり、順次実行されるステップで構成されます。これは基本的に入出力の機能です。Task は個別に実行することも、パイプラインの一部として実行することもできます。タスクは再利用可能で、複数のパイプラインで使用できます。
Step は、イメージのビルドなど、Task によって順次実行され、特定の目的を達成するための一連のコマンドです。各タスクは Pod として実行され、各ステップは同じ Pod 内のコンテナーとして実行されます。Step は同じ Pod 内で実行されるため、ファイル、設定マップ、およびシークレットをキャッシュするために同じボリュームにアクセスできます。
以下の例は、apply-manifests Task を示しています。
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: apply-manifests
spec:
workspaces:
- name: source
params:
- name: manifest_dir
description: The directory in source that contains yaml manifests
type: string
default: "k8s"
steps:
- name: apply
image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
workingDir: /workspace/source
command: ["/bin/bash", "-c"]
args:
- |-
echo Applying manifests in $(params.manifest_dir) directory
oc apply -f $(params.manifest_dir)
echo -----------------------------------この Task は Pod を起動し、指定されたコマンドを実行するために指定されたイメージを使用して Pod 内のコンテナーを実行されます。
OpenShift Pipelines 1.6 以降、ステップ YAML ファイルから以下のデフォルトが削除されます。
-
HOME環境変数が/tekton/homeディレクトリーにデフォルト設定されない -
workingDirフィールドがデフォルトで/workspaceディレクトリーにない
代わりに、この手順のコンテナーは HOME 環境変数と workingDir フィールドを定義します。ただし、この手順の YAML ファイルにカスタム値を指定すると、デフォルト値をオーバーライドできます。
一時的な手段として、以前の OpenShift Pipelines バージョンとの下位互換性を維持するために、TektonConfig カスタムリソース定義の以下のフィールドを false に設定できます。
spec:
pipeline:
disable-working-directory-overwrite: false
disable-home-env-overwrite: false2.2.2. when 式
when 式で、パイプライン内のタスクの実行の条件を設定して、タスク実行を保護します。これには、特定の条件が満たされる場合にのみタスクを実行できるようにします。when 式は、パイプライン YAML ファイルの finally フィールドを使用して指定される最終タスクセットでもサポートされます。
when 式の主要なコンポーネントは、以下のとおりです。
-
input: パラメーター、タスクの結果、実行ステータスなどの静的入力または変数を指定します。有効な入力を入力する必要があります。有効な入力を入力しない場合は、デフォルトで空の文字列に設定されます。 -
operator:valuesセットへの入力の関係を指定します。operator の値としてinまたはnotinを入力します。 -
values: 文字列値の配列を指定します。ワークスペースに、パラメーター、結果、バインドされたステータスなどの静的値や変数の空でない配列を入力します。
宣言された when 式が、タスクの実行前に評価されます。when 式の値が True の場合は、タスクが実行します。when 式の値が False の場合、タスクはスキップします。
さまざまなユースケースで when 式を使用できます。たとえば、次のいずれかです。
- 以前のタスクの結果が期待どおりに実行される。
- Git リポジトリーのファイルが以前のコミットで変更になる。
- イメージがレジストリーに存在する。
- 任意のワークスペースが利用可能である。
以下の例は、パイプライン実行の when 式を示しています。パイプライン実行は、次の基準が満たされた場合にのみ create-file タスクを実行します。path パラメーターは README.md です。また、check-file タスクから生じる exists が yes の場合に限り、echo-file-exists タスクが実行します。
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
generateName: guarded-pr-
spec:
taskRunTemplate:
serviceAccountName: pipeline
pipelineSpec:
params:
- name: path
type: string
description: The path of the file to be created
workspaces:
- name: source
description: |
This workspace is shared among all the pipeline tasks to read/write common resources
tasks:
- name: create-file
when:
- input: "$(params.path)"
operator: in
values: ["README.md"]
workspaces:
- name: source
workspace: source
taskSpec:
workspaces:
- name: source
description: The workspace to create the readme file in
steps:
- name: write-new-stuff
image: ubuntu
script: 'touch $(workspaces.source.path)/README.md'
- name: check-file
params:
- name: path
value: "$(params.path)"
workspaces:
- name: source
workspace: source
runAfter:
- create-file
taskSpec:
params:
- name: path
workspaces:
- name: source
description: The workspace to check for the file
results:
- name: exists
description: indicates whether the file exists or is missing
steps:
- name: check-file
image: alpine
script: |
if test -f $(workspaces.source.path)/$(params.path); then
printf yes | tee /tekton/results/exists
else
printf no | tee /tekton/results/exists
fi
- name: echo-file-exists
when:
- input: "$(tasks.check-file.results.exists)"
operator: in
values: ["yes"]
taskSpec:
steps:
- name: echo
image: ubuntu
script: 'echo file exists'
...
- name: task-should-be-skipped-1
when:
- input: "$(params.path)"
operator: notin
values: ["README.md"]
taskSpec:
steps:
- name: echo
image: ubuntu
script: exit 1
...
finally:
- name: finally-task-should-be-executed
when:
- input: "$(tasks.echo-file-exists.status)"
operator: in
values: ["Succeeded"]
- input: "$(tasks.status)"
operator: in
values: ["Succeeded"]
- input: "$(tasks.check-file.results.exists)"
operator: in
values: ["yes"]
- input: "$(params.path)"
operator: in
values: ["README.md"]
taskSpec:
steps:
- name: echo
image: ubuntu
script: 'echo finally done'
params:
- name: path
value: README.md
workspaces:
- name: source
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 16Mi- 1
- Kubernetes オブジェクトのタイプを指定します。この例では、
PipelineRunです。 - 2
- パイプラインで使用されるタスク
create-file。 - 3
check-fileタスクから生じたexistsがyesになった場合に限り、echo-file-existsタスクを実行するのに指定するwhen式。- 4
pathパラメーターがREADME.mdの場合に限り、task-should-be-skipped-1タスクをスキップすることを指定するwhen式。- 5
echo-file-existsタスクの実行ステータス、およびタスクステータスがSucceededで、check-fileタスクから生じるexistsがyesになり、pathパラメーターがREADME.mdとなる場合に限り、finally-task-should-be-executedタスクを実行するのに指定するwhen式。
OpenShift Container Platform Web コンソールの Pipeline Run details ページには、以下のようにタスクと when 式が表示されます。
- すべての基準が満たされています。タスクと、ひし形で表される when 式の記号は緑色です。
- いずれかの基準が満たされていません。タスクはスキップされます。スキップされたタスクと when 式記号は灰色になります。
- 満たされていない基準はありません。タスクはスキップされます。スキップされたタスクと when 式記号は灰色になります。
- タスクの実行が失敗する: 失敗したタスクと when 式の記号が赤で表示されます。
2.2.3. 最後のタスク
finally のタスクは、パイプライン YAML ファイルの finally フィールドを使用して指定される最終タスクのセットです。finally タスクは、パイプライン実行が正常に実行されるかどうかに関係なく、パイプライン内でタスクを常に実行します。finally のタスクは、対応するパイプラインが終了する前に、すべてのパイプラインの実行後に並行して実行されます。
同じパイプライン内のタスクの結果を使用するように、finally タスクを設定できます。このアプローチでは、この最終タスクが実行される順序は変更されません。これは、最終以外のすべてのタスク実行後に他の最終タスクと並行して実行します。
以下の例は、clone-cleanup-workspace パイプラインのコードスニペットを示しています。このコードは、リポジトリーを共有ワークスペースにクローンし、ワークスペースをクリーンアップします。パイプラインタスクの実行後に、パイプライン YAML ファイルの finally セクションで指定される cleanup タスクがワークスペースをクリーンアップします。
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: clone-cleanup-workspace
spec:
workspaces:
- name: git-source
tasks:
- name: clone-app-repo
taskRef:
name: git-clone-from-catalog
params:
- name: url
value: https://github.com/tektoncd/community.git
- name: subdirectory
value: application
workspaces:
- name: output
workspace: git-source
finally:
- name: cleanup
taskRef:
name: cleanup-workspace
workspaces:
- name: source
workspace: git-source
- name: check-git-commit
params:
- name: commit
value: $(tasks.clone-app-repo.results.commit)
taskSpec:
params:
- name: commit
steps:
- name: check-commit-initialized
image: alpine
script: |
if [[ ! $(params.commit) ]]; then
exit 1
fi2.2.4. TaskRun
TaskRun は、クラスター上の特定の入出力、および実行パラメーターで実行するためにタスクをインスタンス化します。これは独自に起動することも、パイプラインの各タスクのパイプライン実行の一部として起動することもできます。
タスクはコンテナーイメージを実行する 1 つ以上のステップで構成され、各コンテナーイメージは特定のビルド作業を実行します。タスク実行では、すべてのステップが正常に実行されるか、失敗が発生するまで、指定された順序でタスクのステップが実行されます。TaskRun は、PipelineRun により、パイプライン内の各タスクに対して自動的に作成されます。
次の例は、関連する入力パラメーターを使用して apply-manifests タスクを実行するタスク実行を示しています。
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
name: apply-manifests-taskrun
spec:
taskRunTemplate:
serviceAccountName: pipeline
taskRef:
kind: Task
name: apply-manifests
workspaces:
- name: source
persistentVolumeClaim:
claimName: source-pvc2.2.5. Pipelines
Pipeline は､特定の実行順序で配置された Task リソースのコレクションです。これらは、アプリケーションのビルド、デプロイメント、およびデリバリーを自動化する複雑なワークフローを構築するために実行されます。1 つ以上のタスクを含むパイプラインを使用して、アプリケーションの CI/CD ワークフローを定義できます。
Pipeline 定義は、多くのフィールドまたは属性で構成され、Pipeline が特定の目的を達成することを可能にします。各 Pipeline リソース定義には、特定の入力を取り込み、特定の出力を生成する Task が少なくとも 1 つ含まれる必要があります。パイプライン定義には、アプリケーション要件に応じて Conditions、Workspaces、Parameters、または Resources をオプションで含めることもできます。
次の例は、openshift-pipelines 名前空間で提供される buildah タスクを使用して Git リポジトリーからアプリケーションイメージを構築する build-and-deploy パイプラインを示しています。
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: build-and-deploy
spec:
workspaces:
- name: shared-workspace
params:
- name: deployment-name
type: string
description: name of the deployment to be patched
- name: git-url
type: string
description: url of the git repo for the code of deployment
- name: git-revision
type: string
description: revision to be used from repo of the code for deployment
default: "pipelines-1.20"
- name: IMAGE
type: string
description: image to be built from the code
tasks:
- name: fetch-repository
taskRef:
resolver: cluster
params:
- name: kind
value: task
- name: name
value: git-clone
- name: namespace
value: openshift-pipelines
workspaces:
- name: output
workspace: shared-workspace
params:
- name: URL
value: $(params.git-url)
- name: SUBDIRECTORY
value: ""
- name: DELETE_EXISTING
value: "true"
- name: REVISION
value: $(params.git-revision)
- name: build-image
taskRef:
resolver: cluster
params:
- name: kind
value: task
- name: name
value: buildah
- name: namespace
value: openshift-pipelines
workspaces:
- name: source
workspace: shared-workspace
params:
- name: TLSVERIFY
value: "false"
- name: IMAGE
value: $(params.IMAGE)
runAfter:
- fetch-repository
- name: apply-manifests
taskRef:
name: apply-manifests
workspaces:
- name: source
workspace: shared-workspace
runAfter:
- build-image
- name: update-deployment
taskRef:
name: update-deployment
workspaces:
- name: source
workspace: shared-workspace
params:
- name: deployment
value: $(params.deployment-name)
- name: IMAGE
value: $(params.IMAGE)
runAfter:
- apply-manifests- 1
- Pipeline API バージョン
v1 - 2
- Kubernetes オブジェクトのタイプを指定します。この例では、
Pipelineです。 - 3
- この Pipeline の一意の名前。
- 4
- Pipeline の定義と構造を指定します。
- 5
- Pipeline のすべてのタスクで使用される Workspace。
- 6
- Pipeline のすべてのタスクで使用されるパラメーター。
- 7
- Pipeline で使用されたタスクの一覧を指定します。
- 8
build-imageタスク:openshift-pipelinesnamespace で提供されるbuildahタスクを使用して、指定された Git リポジトリーからアプリケーションイメージを構築します。- 9
apply-manifestsタスク: 同じ名前のユーザー定義のタスクを使用します。- 10
- タスクが Pipeline で実行されるシーケンスを指定します。この例では、
apply-manifestsタスクはbuild-imageタスクが完了した後にのみ実行されます。
Red Hat OpenShift Pipelines Operator は、openshift-pipelines namespace に Buildah タスクをインストールし、イメージをビルドしてプッシュするのに十分な権限を割り当てて pipeline サービスアカウントを作成します。権限が不十分な別のサービスアカウントに関連付けられていると、Buildah タスクが失敗する可能性があります。
2.2.6. PipelineRun
PipelineRun は、パイプライン、ワークスペース、認証情報、および CI/CD ワークフローを実行するシナリオ固有のパラメーター値のセットをバインドするリソースタイプです。
パイプライン実行は、パイプラインの実行中のインスタンスです。これは、クラスター上の特定の入力、出力、および実行パラメーターで実行されるパイプラインをインスタンス化します。また、パイプライン実行に、タスクごとのタスク実行も作成します。
パイプラインは、完了するか、タスクが失敗するまでタスクを順次実行します。status フィールドは、監視および監査のために、Task Run ごとの進捗を追跡し、保存します。
以下の例は、関連するリソースおよびパラメーターで build-and-deploy Pipeline を実行しています。
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
name: build-deploy-api-pipelinerun
spec:
pipelineRef:
name: build-and-deploy
params:
- name: deployment-name
value: vote-api
- name: git-url
value: https://github.com/openshift-pipelines/vote-api.git
- name: IMAGE
value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/vote-api
workspaces:
- name: shared-workspace
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Mi2.2.7. Pod テンプレート
オプションで、PipelineRun または TaskRun カスタムリソース (CR) で Pod テンプレート を定義できます。Pod テンプレートでは、Pod CR に使用可能な任意のパラメーターを使用できます。パイプラインまたはタスクを実行する Pod を作成するときに、OpenShift Pipelines はすべての Pod に対してこれらのパラメーターを設定します。
たとえば、Pod テンプレートを使用して、Pod を root ではなくユーザーとして実行できます。
パイプライン実行の場合、次の例のように、pipelineRunTemplate.podTemplate 仕様で Pod テンプレートを定義できます。
Pod テンプレートを使用した PipelineRun CR の例
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
name: mypipelinerun
spec:
pipelineRef:
name: mypipeline
taskRunTemplate:
podTemplate:
securityContext:
runAsNonRoot: true
runAsUser: 1001
以前の API バージョン v1beta1 では、PipelineRun CR の Pod テンプレートは、spec: セクションで直接 podTemplate として指定されていました。この形式は v1 API ではサポートされていません。
タスク実行の場合、次の例のように、podTemplate 仕様で Pod テンプレートを定義できます。
Pod テンプレートを使用した TaskRun CR の例
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
kind: TaskRun
metadata:
name: mytaskrun
namespace: default
spec:
taskRef:
name: mytask
podTemplate:
schedulerName: volcano
securityContext:
runAsNonRoot: true
runAsUser: 10012.2.8. ワークスペース
Red Hat OpenShift Pipelines の PipelineResource CR の代わりにワークスペースを使用することを推奨します。これは、PipelineResource CR はデバッグが難しく、範囲が限定されており、タスクの再利用性が低下するためです。
Workspace は、入力を受信し、出力を提供するために Pipeline の Task がランタイム時に必要とする共有ストレージボリュームを宣言します。Workspace では、ボリュームの実際の場所を指定する代わりに、ランタイム時に必要となるファイルシステムまたはファイルシステムの一部を宣言できます。Task または Pipeline は Workspace を宣言し、ボリュームの特定の場所の詳細を指定する必要があります。その後、これはタスク実行またはパイプライン実行の Workspace にマウントされます。ランタイムストレージボリュームからボリューム宣言を分離することで、Task を再利用可能かつ柔軟にし、ユーザー環境から切り離すことができます。
Workspace を使用すると、以下が可能になります。
- Task の入力および出力の保存
- Task 間でのデータの共有
- Secret に保持される認証情報のマウントポイントとして使用
- config maps に保持される設定のマウントポイントとして使用
- 組織が共有する共通ツールのマウントポイントとして使用
- ジョブを高速化するビルドアーティファクトのキャッシュの作成
以下を使用して、TaskRun または PipelineRun で Workspace を指定できます。
- 読み取り専用の config map またはシークレット
- 他のタスクと共有されている既存の永続ボリューム要求
- 提供されたボリュームクレームテンプレートからの永続的なボリュームクレーム
-
タスクの実行が完了すると破棄される
emptyDir
以下の例は、Pipeline で定義される、build-image および apply-manifests Task の shared-workspace Workspace を宣言する build-and-deploy Pipeline のコードスニペットを示しています。
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: build-and-deploy
spec:
workspaces:
- name: shared-workspace
params:
...
tasks:
- name: build-image
taskRef:
resolver: cluster
params:
- name: kind
value: task
- name: name
value: buildah
- name: namespace
value: openshift-pipelines
workspaces:
- name: source
workspace: shared-workspace
params:
- name: TLSVERIFY
value: "false"
- name: IMAGE
value: $(params.IMAGE)
runAfter:
- fetch-repository
- name: apply-manifests
taskRef:
name: apply-manifests
workspaces:
- name: source
workspace: shared-workspace
runAfter:
- build-image
...- 1
- Pipeline で定義される Task 間で共有される Workspace の一覧。Pipeline は、必要な数の Workspace を定義できます。この例では、
shared-workspaceという名前の 1 つの Workspace のみが宣言されます。 - 2
- Pipeline で使用される Task の定義。このスニペットは、共通の Workspace を共有する
build-imageおよびapply-manifestsの 2 つの Task を定義します。 - 3
build-imageTask で使用される Workspace の一覧。Task 定義には、必要な数の Workspace を含めることができます。ただし、Task が最大 1 つの書き込み可能な Workspace を使用することが推奨されます。- 4
- Task で使用される Workspace を一意に識別する名前。この Task は、
sourceという名前の 1 つの Workspace を使用します。 - 5
- Task によって使用される Pipeline Workspace の名前。Workspace
sourceは Pipeline Workspace のshared-workspaceを使用することに注意してください。 - 6
apply-manifestsTask で使用される Workspace の一覧。この Task は、build-imageTask とsourceWorkspace を共有することに注意してください。
Workspace はタスクがデータを共有する際に使用でき、これにより、パイプラインの各タスクが実行時に必要となる 1 つまたは複数のボリュームを指定できます。永続ボリューム要求を作成するか、永続ボリューム要求を作成するボリューム要求テンプレートを指定できます。
以下の build-deploy-api-pipelinerun パイプライン実行のコードスニペットは、build-and-deploy Pipeline で使用される shared-workspace Workspace のストレージボリュームを定義するための永続ボリューム要求を作成するために永続ボリュームテンプレートを使用します。
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
name: build-deploy-api-pipelinerun
spec:
pipelineRef:
name: build-and-deploy
params:
...
workspaces:
- name: shared-workspace
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Mi2.2.9. ステップアクション
ステップはタスクの一部です。タスク内でステップを定義した場合は、別のタスクからこのステップを参照できません。
ただし、オプションで、StepAction カスタムリソース (CR) で ステップアクション を定義することもできます。この CR には、ステップが実行するアクションが含まれます。ステップから StepAction オブジェクトを参照して、アクションを実行するステップを作成できます。リゾルバーを使用して、外部ソースから利用可能な StepAction 定義を参照することもできます。
次の例は、apply-manifests-action という名前の StepAction CR を示しています。このステップアクションは、ソースツリーからのマニフェストを OpenShift Container Platform 環境に適用します。
apiVersion: tekton.dev/v1
kind: StepAction
metadata:
name: apply-manifests-action
spec:
params:
- name: working_dir
description: The working directory where the source is located
type: string
default: "/workspace/source"
- name: manifest_dir
description: The directory in source that contains yaml manifests
default: "k8s"
results:
- name: output
description: The output of the oc apply command
image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
env:
- name: MANIFEST_DIR
value: $(params.manifest_dir)
workingDir: $(params.working_dir)
script: |
#!/usr/bin/env bash
oc apply -f "$MANIFEST_DIR" | tee $(results.output)- 1
- パラメーターの
type指定はオプションです。
StepAction CR にはワークスペースの定義が含まれていません。代わりに、ステップアクションでは、アクションを含むタスクが、通常はワークスペースを使用して、マウントされたソースツリーも提供することを想定しています。
StepAction オブジェクトは、パラメーターと結果を定義できます。このオブジェクトを参照する場合は、ステップの定義で StepAction オブジェクトのパラメーターの値を指定する必要があります。StepAction オブジェクトの結果は、自動的にステップの結果になります。
シェルを使用した悪意のある攻撃を回避するために、StepAction CR は script 値にパラメーター値を使用するサポートは提供していません。代わりに、env: セクションを使用して、パラメーター値を含む環境変数を定義する必要があります。
次のタスク例には apply-manifests-action ステップアクションを参照し、必要なパラメーターを指定して、結果を使用するステップが含まれています。
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: apply-manifests-with-action
spec:
workspaces:
- name: source
params:
- name: manifest_dir
description: The directory in source that contains yaml manifests
type: string
default: "k8s"
steps:
- name: apply
ref:
name: apply-manifests-action
params:
- name: working_dir
value: "/workspace/source"
- name: manifest_dir
value: $(params.manifest_dir)
- name: display_result
script: 'echo $(step.apply.results.output)'2.2.10. Triggers
Trigger をパイプラインと併用して、Kubernetes リソースで CI/CD 実行全体を定義する本格的な CI/CD システムを作成します。Trigger は、Git プルリクエストなどの外部イベントをキャプチャーし、それらのイベントを処理して情報の主要な部分を抽出します。このイベントデータを事前に定義されたパラメーターのセットにマップすると、Kubernetes リソースを作成およびデプロイし、パイプラインをインスタンス化できる一連のタスクがトリガーされます。
たとえば、アプリケーションの Red Hat OpenShift Pipelines を使用して CI/CD ワークフローを定義します。アプリケーションリポジトリーで新たな変更を有効にするには、パイプラインを開始する必要があります。トリガーは変更イベントをキャプチャーし、処理することにより、また新規イメージを最新の変更でデプロイするパイプライン実行をトリガーして、このプロセスを自動化します。
Trigger は、再利用可能で分離した自律型 CI/CD システムを設定するように連携する以下の主なリソースで構成されています。
TriggerBindingリソースは、イベントペイロードからフィールドを抽出し、それらをパラメーターとして保存します。以下の例は、
TriggerBindingリソースのコードスニペットを示しています。これは、受信イベントペイロードから Git リポジトリー情報を抽出します。apiVersion: triggers.tekton.dev/v1beta11 kind: TriggerBinding2 metadata: name: vote-app3 spec: params:4 - name: git-repo-url value: $(body.repository.url) - name: git-repo-name value: $(body.repository.name) - name: git-revision value: $(body.head_commit.id)TriggerTemplateリソースは、リソースの作成方法の標準として機能します。これは、TriggerBindingリソースからのパラメーター化されたデータが使用される方法を指定します。トリガーテンプレートは、トリガーバインディングから入力を受け取り、新規パイプラインリソースの作成および新規パイプライン実行の開始につながる一連のアクションを実行します。以下の例は、
TriggerTemplateリソースのコードスニペットを示しています。これは、作成したTriggerBindingリソースから受け取る Git リポジトリー情報を使用してパイプライン実行を作成します。apiVersion: triggers.tekton.dev/v1beta11 kind: TriggerTemplate2 metadata: name: vote-app3 spec: params:4 - name: git-repo-url description: The git repository url - name: git-revision description: The git revision default: pipelines-1.20 - name: git-repo-name description: The name of the deployment to be created / patched resourcetemplates:5 - apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: build-deploy-$(tt.params.git-repo-name)-$(uid) spec: taskRunTemplate: serviceAccountName: pipeline pipelineRef: name: build-and-deploy params: - name: deployment-name value: $(tt.params.git-repo-name) - name: git-url value: $(tt.params.git-repo-url) - name: git-revision value: $(tt.params.git-revision) - name: IMAGE value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/$(tt.params.git-repo-name) workspaces: - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 500MiTriggerリソースは、TriggerBindingリソースおよびTriggerTemplateリソースと、オプションでinterceptorsイベントプロセッサーを組み合わせます。インターセプターは、
TriggerBindingリソースの前に実行される特定プラットフォームのすべてのイベントを処理します。インターセプターを使用して、ペイロードのフィルタリング、イベントの検証、トリガー条件の定義およびテスト、および他の有用な処理を実装できます。インターセプターは、イベント検証にシークレットを使用します。イベントデータがインターセプターを通過したら、ペイロードデータをトリガーバインディングに渡す前にトリガーに移動します。インターセプターを使用して、EventListener仕様で参照される関連付けられたトリガーの動作を変更することもできます。以下の例は、
TriggerBindingおよびTriggerTemplateリソースを接続するvote-triggerという名前のTriggerリソースのコードスニペットと、interceptorsイベントプロセッサーを示しています。apiVersion: triggers.tekton.dev/v1beta11 kind: Trigger2 metadata: name: vote-trigger3 spec: taskRunTemplate: serviceAccountName: pipeline4 interceptors: - ref: name: "github"5 params:6 - name: "secretRef" value: secretName: github-secret secretKey: secretToken - name: "eventTypes" value: ["push"] bindings: - ref: vote-app7 template:8 ref: vote-app --- apiVersion: v1 kind: Secret9 metadata: name: github-secret type: Opaque stringData: secretToken: "1234567"- 1
Triggerリソースの API バージョン。この例では、v1beta1です。- 2
- Kubernetes オブジェクトのタイプを指定します。この例では、
Triggerです。 - 3
- この
Triggerリソースを識別するための一意の名前。 - 4
- 使用されるサービスアカウント名。
- 5
- 参照されるインターセプター名。この例では、
githubです。 - 6
- 指定する必要のあるパラメーター。
- 7
TriggerTemplateリソースに接続するTriggerBindingリソースの名前。- 8
TriggerBindingリソースに接続するためのTriggerTemplateリソースの名前。- 9
- イベントの検証に使用されるシークレット。
EventListenerは、JSON ペイロードを含む受信 HTTP ベースイベントをリッスンするエンドポイントまたはイベントシンクを提供します。これは各TriggerBindingリソースからイベントパラメーターを抽出し、次にこのデータを処理し、対応するTriggerTemplateリソースによって指定される Kubernetes リソースを作成します。EventListenerリソースは、イベントのinterceptorsを使用してペイロードで軽量イベント処理または基本的なフィルターを実行します。これはペイロードのタイプを特定し、オプションでこれを変更します。現時点で、パイプライントリガーは Webhook インターセプター、GitHub インターセプター、GitLab インターセプター、Bitbucket インターセプター、および Common Expression Language (CEL) インターセプター の 4 種類のインターセプターをサポートします。以下の例は、
vote-triggerという名前のTriggerリソースを参照するEventListenerリソースを示しています。apiVersion: triggers.tekton.dev/v1beta11 kind: EventListener2 metadata: name: vote-app3 spec: taskRunTemplate: serviceAccountName: pipeline4 triggers: - triggerRef: vote-trigger5
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}