Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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 -----------------------------------
Copy to Clipboard Toggle word wrap
1
Task API バージョン v1beta1。
2
Kubernetes オブジェクトのタイプ Task。
3
この Task の一意の名前。
4
Task のパラメーターおよび Step と、Task によって使用される Workspace の一覧。

この 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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
1
Pipeline の一意の名前。
2
git リポジトリーのクローンが作成される共有ワークスペース。
3
アプリケーションリポジトリーを共有ワークスペースにクローンするタスク。
4
共有ワークスペースをクリーンアップするタスク。
5
TaskRun で実行されるタスクへの参照。
6
入力を受信し、出力を提供するために Pipeline の Task がランタイム時に必要とする共有ストレージボリュームを宣言します。
7
タスクに必要なパラメーターの一覧。パラメーターに暗黙的なデフォルト値がない場合は、その値を明示的に設定する必要があります。
8
埋め込まれたタスク定義。

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
Copy to Clipboard Toggle word wrap
1
TaskRun API バージョン v1beta1
2
Kubernetes オブジェクトのタイプを指定します。この例では、TaskRun です。
3
この TaskRun を識別する一意の名前。
4
TaskRun の定義。この TaskRun には、Task と必要な Workspace を指定します。
5
この TaskRun に使用される Task 参照の名前。この TaskRun は Task apply-manifests Task を実行します。
6
TaskRun によって使用される Workspace。

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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
1
Pipeline Run の API バージョン v1beta1。
2
Kubernetes オブジェクトのタイプ。この例では、PipelineRun です。
3
この Pipeline Run を識別する一意の名前。
4
実行する Pipeline の名前。この例では、build-and-deploy です。
5
Pipeline の実行に必要なパラメーターの一覧。
6
Pipeline Run で使用する Workspace。

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
...
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
1
PipelineRun にボリュームバインディングを提供する Pipeline Workspace の一覧を指定します。
2
ボリュームが提供されている Pipeline の Workspace の名前。
3
ワークスペースのストレージボリュームを定義するために永続ボリューム要求 (PVC) を作成するボリューム要求テンプレートを指定します。

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)
    Copy to Clipboard Toggle word wrap
    1
    TriggerBinding リソースの API バージョン。この例では、v1alpha1 です。
    2
    Kubernetes オブジェクトのタイプを指定します。この例では、TriggerBinding です。
    3
    この TriggerBinding を識別する一意の名前。
    4
    受信イベントペイロードから抽出され、 TriggerTemplate に渡されるパラメーターの一覧。この例では、Git リポジトリー URL、名前、およびリビジョンはイベントペイロードの本体から抽出されます。

  • 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
    Copy to Clipboard Toggle word wrap
    1
    TriggerTemplate リソースの API バージョン。この例では、v1alpha1 です。
    2
    Kubernetes オブジェクトのタイプを指定します。この例では、TriggerTemplate です。
    3
    TriggerTemplate リソースを識別するための一意の名前。
    4
    TriggerBinding リソースによって提供されるパラメーター。
    5
    TriggerBinding または EventListener リソースを使用して受信されるパラメーターを使用してリソースを作成する必要がある方法を指定するテンプレートの一覧。

  • 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"
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    1
    EventListener リソースの API バージョン。この例では、v1alpha1 です。
    2
    Kubernetes オブジェクトのタイプを指定します。この例では、EventListener です。
    3
    EventListener リソースを識別するための一意の名前。
    4
    使用されるサービスアカウント名。
    5
    EventListener リソースによって参照される Trigger リソースの名前。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat