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

OpenShift Pipelines について

Red Hat OpenShift Pipelines 1.18

OpenShift Pipelines の概要

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、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.18 など) することにより利用できます。

さらに、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. タスク

Task リソースは、パイプラインのビルディングブロックであり、順次実行されるステップで構成されます。これは基本的に入出力の機能です。Task は個別に実行することも、パイプラインの一部として実行することもできます。タスクは再利用可能で、複数のパイプラインで使用できます。

Step は、イメージのビルドなど、Task によって順次実行され、特定の目的を達成するための一連のコマンドです。各タスクは Pod として実行され、各ステップは同じ Pod 内のコンテナーとして実行されます。Step は同じ Pod 内で実行されるため、ファイル、設定マップ、およびシークレットをキャッシュするために同じボリュームにアクセスできます。

以下の例は、apply-manifests Task を示しています。 

apiVersion: tekton.dev/v1 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
1
タスク API バージョン v1。
2
Kubernetes オブジェクトのタイプ Task。
3
この Task の一意の名前。
4
Task のパラメーターおよび Step と、Task によって使用される Workspace のリスト。

この 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: false
Copy to clipboard

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

2.2.4. TaskRun

TaskRun は、クラスター上の特定の入出力、および実行パラメーターで実行するためにタスクをインスタンス化します。これは独自に起動することも、パイプラインの各タスクのパイプライン実行の一部として起動することもできます。

タスクはコンテナーイメージを実行する 1 つ以上のステップで構成され、各コンテナーイメージは特定のビルド作業を実行します。タスク実行では、すべてのステップが正常に実行されるか、失敗が発生するまで、指定された順序でタスクのステップが実行されます。TaskRun は､PipelineRun により、パイプライン内の各タスクに対して自動的に作成されます。

次の例は、関連する入力パラメーターを使用して apply-manifests タスクを実行するタスク実行を示しています。 

apiVersion: tekton.dev/v1 1
kind: TaskRun 2
metadata:
  name: apply-manifests-taskrun 3
spec: 4
  taskRunTemplate:
    serviceAccountName: pipeline
  taskRef: 5
    kind: Task
    name: apply-manifests
  workspaces: 6
  - name: source
    persistentVolumeClaim:
      claimName: source-pvc
Copy to clipboard
1
タスク実行 API バージョン v1。
2
Kubernetes オブジェクトのタイプを指定します。この例では、TaskRun です。
3
このタスク実行を識別する一意の名前。
4
タスク実行の定義。このタスクの実行では、タスクと必要なワークスペースが指定されています。
5
このタスクの実行に使用されるタスク参照の名前。このタスク実行は､apply-manifests タスクを実行します。
6
タスクの実行で使用されるワークスペース。

2.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 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.18"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks: 7
  - 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 8
    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 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
1
Pipeline API バージョン v1
2
Kubernetes オブジェクトのタイプを指定します。この例では、Pipeline です。
3
この Pipeline の一意の名前。
4
Pipeline の定義と構造を指定します。
5
Pipeline のすべてのタスクで使用される Workspace。
6
Pipeline のすべてのタスクで使用されるパラメーター。
7
Pipeline で使用されたタスクの一覧を指定します。
8
build-image タスク: openshift-pipelines namespace で提供される buildah タスクを使用して、指定された Git リポジトリーからアプリケーションイメージを構築します。
9
apply-manifests タスク: 同じ名前のユーザー定義のタスクを使用します。
10
タスクが Pipeline で実行されるシーケンスを指定します。この例では、apply-manifests タスクは build-image タスクが完了した後にのみ実行されます。
注記

Red Hat OpenShift Pipelines Operator は、openshift-pipelines namespaxw に Buildah タスクをインストールし、イメージをビルドしてプッシュするのに十分な権限を割り当てて pipeline サービスアカウントを作成します。権限が不十分な別のサービスアカウントに関連付けられていると、Buildah タスクが失敗する可能性があります。

2.2.6. PipelineRun

PipelineRun は、パイプライン、ワークスペース、認証情報、および CI/CD ワークフローを実行するシナリオ固有のパラメーター値のセットをバインドするリソースタイプです。

パイプライン実行は、パイプラインの実行中のインスタンスです。これは、クラスター上の特定の入力、出力、および実行パラメーターで実行されるパイプラインをインスタンス化します。また、パイプライン実行に、タスクごとのタスク実行も作成します。

パイプラインは、完了するか、タスクが失敗するまでタスクを順次実行します。status フィールドは、監視および監査のために、Task run ごとの進捗を追跡し、保存します。

以下の例は、関連するリソースおよびパラメーターで build-and-deploy Pipeline を実行しています。 

apiVersion: tekton.dev/v1 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
1
パイプライン実行 API バージョン v1。
2
Kubernetes オブジェクトのタイプ。この例では、PipelineRun です。
3
この Pipeline Run を識別する一意の名前。
4
実行する Pipeline の名前。この例では、build-and-deploy です。
5
Pipeline の実行に必要なパラメーターのリスト。
6
Pipeline Run で使用する Workspace。

関連情報

2.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
Copy to clipboard

注記

以前の 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: 1001
Copy to clipboard

関連情報

2.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: 1
  - name: shared-workspace
  params:
...
  tasks: 2
  - name: build-image
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: buildah
      - name: namespace
        value: openshift-pipelines
    workspaces: 3
    - name: source 4
      workspace: shared-workspace 5
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    runAfter:
    - fetch-repository
  - name: apply-manifests
    taskRef:
      name: apply-manifests
    workspaces: 6
    - name: source
      workspace: shared-workspace
    runAfter:
      - build-image
...
Copy to clipboard
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 つまたは複数のボリュームを指定できます。永続ボリューム要求を作成するか、永続ボリューム要求を作成するボリューム要求テンプレートを指定できます。

以下の 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: 1
  - name: shared-workspace 2
    volumeClaimTemplate: 3
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi
Copy to clipboard
1
Pipeline にボリュームバインディングを提供する Pipeline Workspace の一覧を指定します。
2
ボリュームが提供されている Pipeline の Workspace の名前。
3
ワークスペースのストレージボリュームを定義するために永続ボリューム要求を作成するボリューム要求テンプレートを指定します。

2.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 1
    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)
Copy to clipboard
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)'
Copy to clipboard

関連情報

2.2.10. トリガー

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

  • TriggerTemplate リソースは、リソースの作成方法の標準として機能します。これは、TriggerBinding リソースからのパラメーター化されたデータが使用される方法を指定します。トリガーテンプレートは、トリガーバインディングから入力を受け取り、新規パイプラインリソースの作成および新規パイプライン実行の開始につながる一連のアクションを実行します。

    以下の例は、TriggerTemplate リソースのコードスニペットを示しています。これは、作成した TriggerBinding リソースから受け取る Git リポジトリー情報を使用してパイプライン実行を作成します。 

    apiVersion: triggers.tekton.dev/v1beta1 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.18
  - 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: 500Mi
    Copy to clipboard
    1
    TriggerTemplate リソースの API バージョン。この例では、v1beta1 です。
    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/v1beta1 1
kind: Trigger 2
metadata:
  name: vote-trigger 3
spec:
  taskRunTemplate:
    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
    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/v1beta1 1
kind: EventListener 2
metadata:
  name: vote-app 3
spec:
  taskRunTemplate:
    serviceAccountName: pipeline 4
  triggers:
    - triggerRef: vote-trigger 5
    Copy to clipboard
    1
    EventListener リソースの API バージョン。この例では、v1beta1 です。
    2
    Kubernetes オブジェクトのタイプを指定します。この例では、EventListener です。
    3
    EventListener リソースを識別するための一意の名前。
    4
    使用されるサービスアカウント名。
    5
    EventListener リソースによって参照される Trigger リソースの名前。

2.3. 関連情報

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.