Red Hat Summit4.2. OpenShift Pipelines について
Red Hat OpenShift Pipelines は、Kubernetes リソースをベースとしたクラウドネイティブの継続的インテグレーションおよび継続的デリバリー (CI/CD) ソリューションです。これは Tekton ビルディングブロックを使用し、基礎となる実装の詳細を抽象化することで、複数のプラットフォームでのデプロイメントを自動化します。Tekton では、Kubernetes ディストリビューション間で移植可能な CI/CD パイプラインを定義するための標準のカスタムリソース定義 (CRD) が多数導入されています。
4.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 でのパイプラインの管理を実行できます。
4.2.2. OpenShift Pipelines の概念
本書では、パイプラインの各種概念を詳述します。
4.2.2.1. タスク
Task は Pipeline のビルディングブロックであり、順次実行されるステップで設定されます。これは基本的に入出力の機能です。Task は個別に実行することも、パイプラインの一部として実行することもできます。これらは再利用可能であり、複数の Pipeline で使用することができます。
Step は、イメージのビルドなど、Task によって順次実行され、特定の目的を達成するための一連のコマンドです。各タスクは Pod として実行され、各ステップは同じ Pod 内のコンテナーとして実行されます。Step は同じ Pod 内で実行されるため、ファイル、設定マップ、およびシークレットをキャッシュするために同じボリュームにアクセスできます。
以下の例は、apply-manifests Task を示しています。
apiVersion: tekton.dev/v1beta1
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 内のコンテナーを実行されます。
Pipelines 1.6 以降、この手順の YAML ファイルから、以下のデフォルト設定が削除されます。
-
HOME環境変数が/tekton/homeディレクトリーにデフォルト設定されない -
workingDirフィールドがデフォルトで/workspaceディレクトリーにない
代わりに、この手順のコンテナーは HOME 環境変数と workingDir フィールドを定義します。ただし、この手順の YAML ファイルにカスタム値を指定すると、デフォルト値を上書きできます。
一時的な措置として、古い Pipelines バージョンとの後方互換性を維持するために、TektonConfig カスタムリソース定義の以下のフィールドを false に設定できます。
spec:
pipeline:
disable-working-directory-overwrite: false
disable-home-env-overwrite: false4.2.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/v1beta1
kind: PipelineRun
metadata:
generateName: guarded-pr-
spec:
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タスクが Pipeline で使用されます。- 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 式の記号が赤で表示されます。
4.2.2.3. 最後のタスク
finally のタスクは、パイプライン YAML ファイルの finally フィールドを使用して指定される最終タスクのセットです。finally タスクは、パイプライン実行が正常に実行されるかどうかに関係なく、パイプライン内でタスクを常に実行します。finally のタスクは、対応するパイプラインが終了する前に、すべてのパイプラインの実行後に並行して実行されます。
同じパイプライン内のタスクの結果を使用するように、finally タスクを設定できます。このアプローチでは、この最終タスクが実行される順序は変更されません。これは、最終以外のタスクすべての実行後に他の最終タスクと並行して実行されます。
以下の例は、clone-cleanup-workspace パイプラインのコードスニペットを示しています。このコードは、リポジトリーを共有ワークスペースにクローンし、ワークスペースをクリーンアップします。パイプラインタスクの実行後に、パイプライン YAML ファイルの finally セクションで指定される cleanup タスクがワークスペースをクリーンアップします。
apiVersion: tekton.dev/v1beta1
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
fi4.2.2.4. TaskRun
TaskRun は、クラスター上の特定の入出力、および実行パラメーターで実行するために Task をインスタンス化します。これは独自に起動することも、パイプラインの各 Task の PipelineRun の一部として起動すこともできます。
Task はコンテナーイメージを実行する 1 つ以上の Step で設定され、各コンテナーイメージは特定のビルド作業を実行します。TaskRun は、すべての Step が正常に実行されるか、または失敗が発生するまで、指定された順序で Task の Step を実行します。TaskRun は、Pipeline の各 Task について PipelineRun によって自動的に作成されます。
以下の例は、関連する入力パラメーターで apply-manifests Task を実行する TaskRun を示しています。
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
name: apply-manifests-taskrun
spec:
serviceAccountName: pipeline
taskRef:
kind: Task
name: apply-manifests
workspaces:
- name: source
persistentVolumeClaim:
claimName: source-pvc4.2.2.5. パイプライン
Pipeline は、特定の実行順序で編成される Task リソースのコレクションです。これらは、アプリケーションのビルド、デプロイメント、およびデリバリーを自動化する複雑なワークフローを構築するために実行されます。1 つ以上のタスクを含むパイプラインを使用して、アプリケーションの CI/CD ワークフローを定義できます。
Pipeline 定義は、多くのフィールドまたは属性で設定され、Pipeline が特定の目的を達成することを可能にします。各 Pipeline リソース定義には、特定の入力を取り込み、特定の出力を生成する Task が少なくとも 1 つ含まれる必要があります。パイプライン定義には、アプリケーション要件に応じて Conditions、Workspaces、 Parameters、または Resources をオプションで含めることもできます。
以下の例は、buildah ClusterTask を使用して Git リポジトリーからアプリケーションイメージをビルドする build-and-deploy パイプラインを示しています。
apiVersion: tekton.dev/v1beta1
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.7"
- name: IMAGE
type: string
description: image to be built from the code
tasks:
- name: fetch-repository
taskRef:
name: git-clone
kind: ClusterTask
workspaces:
- name: output
workspace: shared-workspace
params:
- name: url
value: $(params.git-url)
- name: subdirectory
value: ""
- name: deleteExisting
value: "true"
- name: revision
value: $(params.git-revision)
- name: build-image
taskRef:
name: buildah
kind: ClusterTask
params:
- name: TLSVERIFY
value: "false"
- name: IMAGE
value: $(params.IMAGE)
workspaces:
- name: source
workspace: shared-workspace
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 バージョン
v1beta1。 - 2
- Kubernetes オブジェクトのタイプを指定します。この例では、
Pipelineです。 - 3
- この Pipeline の一意の名前。
- 4
- Pipeline の定義および構造を指定します。
- 5
- Pipeline のすべての Task で使用される Workspace。
- 6
- Pipeline のすべての Task で使用されるパラメーター。
- 7
- Pipeline で使用される Task の一覧を指定します。
- 8
- Task
build-image:buildahClusterTask を使用して、所定の Git リポジトリーからアプリケーションイメージをビルドします。 - 9
- Task
apply-manifests: 同じ名前のユーザー定義 Task を使用します。 - 10
- Task が Pipeline で実行されるシーケンスを指定します。この例では、
apply-manifestsTask はbuild-imageTask の完了後にのみ実行されます。
Red Hat OpenShift Pipelines Operator は Buildah クラスタータスクをインストールし、イメージのビルドおよびプッシュを実行するのに十分なパーミッションを割り当てて、パイプライン サービスアカウントを作成します。Buildah クラスタータスクは、パーミッションが不十分な別のサービスアカウントに関連付けられていると失敗する可能性があります。
4.2.2.6. PipelineRun
PipelineRun は、パイプライン、ワークスペース、認証情報、および CI/CD ワークフローを実行するシナリオ固有のパラメーター値のセットをバインドするリソースタイプです。
pipeline run は、Pipeline の実行中のインスタンスです。これは、クラスター上の特定の入力、出力、および実行パラメーターで実行される Pipeline をインスタンス化します。また、パイプライン実行に、タスクごとのタスク実行も作成します。
パイプラインは、完了するか、タスクが失敗するまでタスクを順次実行します。status フィールドは、監視および監査のために、Task run ごとの進捗を追跡し、保存します。
以下の例は、関連するリソースおよびパラメーターで build-and-deploy Pipeline を実行しています。
apiVersion: tekton.dev/v1beta1
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: 500Mi4.2.2.7. Workspaces
PipelineResource はデバッグが容易ではなく、スコープの制限があり、Task を再利用可能にしないため、OpenShift Pipelines では PipelineResource の代わりに Workspace を使用することが推奨されます。
Workspace は、入力を受信し、出力を提供するために Pipeline の Task がランタイム時に必要とする共有ストレージボリュームを宣言します。Workspace では、ボリュームの実際の場所を指定する代わりに、ランタイム時に必要となるファイルシステムまたはファイルシステムの一部を宣言できます。Task または Pipeline は Workspace を宣言し、ボリュームの特定の場所の詳細を指定する必要があります。その後、これは TaskRun または PipelineRun の Workspace にマウントされます。ランタイムストレージボリュームからボリューム宣言を分離することで、Task を再利用可能かつ柔軟にし、ユーザー環境から切り離すことができます。
Workspace を使用すると、以下が可能になります。
- Task の入力および出力の保存
- Task 間でのデータの共有
- Secret に保持される認証情報のマウントポイントとして使用
- ConfigMap に保持される設定のマウントポイントとして使用
- 組織が共有する共通ツールのマウントポイントとして使用
- ジョブを高速化するビルドアーティファクトのキャッシュの作成
以下を使用して、TaskRun または PipelineRun で Workspace を指定できます。
- 読み取り専用 ConfigMap または Secret
- 他の Task と共有される既存の PersistentVolumeClaim
- 指定された VolumeClaimTemplate からの PersistentVolumeClaim
- TaskRun の完了時に破棄される emptyDir
以下の例は、Pipeline で定義される、build-image および apply-manifests Task の shared-workspace Workspace を宣言する build-and-deploy Pipeline のコードスニペットを示しています。
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: build-and-deploy
spec:
workspaces:
- name: shared-workspace
params:
...
tasks:
- name: build-image
taskRef:
name: buildah
kind: ClusterTask
params:
- name: TLSVERIFY
value: "false"
- name: IMAGE
value: $(params.IMAGE)
workspaces:
- name: source
workspace: shared-workspace
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 つまたは複数のボリュームを指定することができます。永続ボリューム要求 (PVC) を作成するか、または永続ボリューム要求 (PVC) を作成するボリューム要求テンプレートを指定できます。
以下の build-deploy-api-pipelinerun PipelineRun のコードスニペットは、build-and-deploy Pipeline で使用される shared-workspace Workspace のストレージボリュームを定義するための永続ボリューム要求 (PVC) を作成するために永続ボリュームテンプレートを使用します。
apiVersion: tekton.dev/v1beta1
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: 500Mi4.2.2.8. トリガー
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.7 - name: git-repo-name description: The name of the deployment to be created / patched resourcetemplates:5 - apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: name: build-deploy-$(tt.params.git-repo-name)-$(uid) spec: 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: 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: 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}