4.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 によって順次実行され、特定の目的を達成するための一連のコマンドです。各 Task は Pod として実行され、各 Step は同じ Pod 内のコンテナーとして実行されます。Step は同じ Pod 内で実行されるため、ファイル、設定マップ、およびシークレットをキャッシュするために同じボリュームにアクセスできます。
以下の例は、apply-manifests
Task を示しています。
apiVersion: tekton.dev/v1beta1 1 kind: Task 2 metadata: name: apply-manifests 3 spec: 4 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 内のコンテナーを実行されます。
4.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 1 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 2 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: 3 - 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: 4 - 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: 5 - 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 1 spec: workspaces: - name: git-source 2 tasks: - name: clone-app-repo 3 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 4 taskRef: 5 name: cleanup-workspace workspaces: 6 - name: source workspace: git-source - name: check-git-commit params: 7 - name: commit value: $(tasks.clone-app-repo.results.commit) taskSpec: 8 params: - name: commit steps: - name: check-commit-initialized image: alpine script: | if [[ ! $(params.commit) ]]; then exit 1 fi
4.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 1 kind: TaskRun 2 metadata: name: apply-manifests-taskrun 3 spec: 4 serviceAccountName: pipeline taskRef: 5 kind: Task name: apply-manifests workspaces: 6 - name: source persistentVolumeClaim: claimName: source-pvc
4.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 1 kind: Pipeline 2 metadata: name: build-and-deploy 3 spec: 4 workspaces: 5 - name: shared-workspace params: 6 - 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.5" - name: IMAGE type: string description: image to be built from the code tasks: 7 - 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 8 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 9 taskRef: name: apply-manifests workspaces: - name: source workspace: shared-workspace runAfter: 10 - 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
:buildah
ClusterTask を使用して、所定の Git リポジトリーからアプリケーションイメージをビルドします。 - 9
- Task
apply-manifests
: 同じ名前のユーザー定義 Task を使用します。 - 10
- Task が Pipeline で実行されるシーケンスを指定します。この例では、
apply-manifests
Task はbuild-image
Task の完了後にのみ実行されます。
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 を実行する PipelineRun を示しています。
apiVersion: tekton.dev/v1beta1 1 kind: PipelineRun 2 metadata: name: build-deploy-api-pipelinerun 3 spec: pipelineRef: name: build-and-deploy 4 params: 5 - 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: 6 - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi
4.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: 1 - name: shared-workspace params: ... tasks: 2 - name: build-image taskRef: name: buildah kind: ClusterTask params: - name: TLSVERIFY value: "false" - name: IMAGE value: $(params.IMAGE) workspaces: 3 - name: source 4 workspace: shared-workspace 5 runAfter: - fetch-repository - name: apply-manifests taskRef: name: apply-manifests workspaces: 6 - 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-image
Task で使用される 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-manifests
Task で使用される Workspace の一覧。この Task は、build-image
Task とsource
Workspace を共有することに注意してください。
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: 1 - name: shared-workspace 2 volumeClaimTemplate: 3 spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi
4.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/v1alpha1 1 kind: TriggerBinding 2 metadata: name: vote-app 3 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/v1alpha1 1 kind: TriggerTemplate 2 metadata: name: vote-app 3 spec: params: 4 - name: git-repo-url description: The git repository url - name: git-revision description: The git revision default: pipelines-1.5 - 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: 500Mi
Trigger
リソースは、TriggerBinding
リソースおよびTriggerTemplate
リソースと、オプションでinterceptors
イベントプロセッサーを組み合わせます。インターセプターは、
TriggerBinding
リソースの前に実行される特定プラットフォームのすべてのイベントを処理します。インターセプターを使用して、ペイロードのフィルターリング、イベントの検証、トリガー条件の定義およびテスト、および他の有用な処理を実装できます。インターセプターは、イベント検証にシークレットを使用します。イベントデータがインターセプターを通過したら、ペイロードデータをトリガーバインディングに渡す前にトリガーに移動します。インターセプターを使用して、EventListener
仕様で参照される関連付けられたトリガーの動作を変更することもできます。以下の例は、
TriggerBinding
およびTriggerTemplate
リソースを接続するvote-trigger
という名前のTrigger
リソースのコードスニペットと、interceptors
イベントプロセッサーを示しています。apiVersion: triggers.tekton.dev/v1alpha1 1 kind: Trigger 2 metadata: name: vote-trigger 3 spec: serviceAccountName: pipeline 4 interceptors: - ref: name: "github" 5 params: 6 - name: "secretRef" value: secretName: github-secret secretKey: secretToken - name: "eventTypes" value: ["push"] bindings: - ref: vote-app 7 template: 8 ref: vote-app --- apiVersion: v1 kind: Secret 9 metadata: name: github-secret type: Opaque stringData: secretToken: "1234567"
- 1
Trigger
リソースの API バージョン。この例では、v1alpha1
です。- 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/v1alpha1 1 kind: EventListener 2 metadata: name: vote-app 3 spec: serviceAccountName: pipeline 4 triggers: - triggerRef: vote-trigger 5
4.2.3. 関連情報
- パイプラインのインストールについての詳細は、OpenShift Pipelines のインストール を参照してください。
- カスタムの CI/CD ソリューションの作成についての詳細は、CI/CD パイプラインを使用したアプリケーションの作成 を参照してください。
- re-encrypt TLS 終端についての詳細は、 再暗号化終端 について参照してください。
- セキュリティー保護されたルートについての詳細は、セキュリティー保護されたルート についてのセクションを参照してください。