3.2. OpenShift Pipeline の概念

このガイドでは、パイプラインの各種概念を詳述します。

3.2.1. タスク
リンクのコピー

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 -----------------------------------

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 -----------------------------------

Copy to Clipboard

Toggle word wrap

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

spec:
  pipeline:
    disable-working-directory-overwrite: false
    disable-home-env-overwrite: false

Copy to Clipboard

Toggle word wrap

3.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

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

Copy to Clipboard

Toggle word wrap

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 式の記号が赤で表示されます。

3.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
              fi

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
              fi

Copy to Clipboard

Toggle word wrap

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

3.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-pvc

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-pvc

Copy to Clipboard

Toggle word wrap

1: タスク実行 API バージョン v1。
2: Kubernetes オブジェクトのタイプを指定します。この例では、TaskRun です。
3: このタスク実行を識別する一意の名前。
4: タスク実行の定義。このタスクの実行では、タスクと必要なワークスペースが指定されています。
5: このタスクの実行に使用されるタスク参照の名前。このタスク実行は､apply-manifests タスクを実行します。
6: タスクの実行で使用されるワークスペース。

3.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.15"
  - 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

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.15"
  - 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

Copy to Clipboard

Toggle word wrap

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 タスクが失敗する可能性があります。

3.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: 500Mi

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: 500Mi

Copy to Clipboard

Toggle word wrap

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

3.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

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: mypipelinerun
spec:
  pipelineRef:
    name: mypipeline
  taskRunTemplate:
    podTemplate:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1001

Copy to Clipboard

Toggle word wrap

注記

以前の 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

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

Toggle word wrap

3.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
...

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
...

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 つまたは複数のボリュームを指定できます。永続ボリューム要求を作成するか、永続ボリューム要求を作成するボリューム要求テンプレートを指定できます。

以下の 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: 500Mi

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: 500Mi

Copy to Clipboard

Toggle word wrap

1: Pipeline にボリュームバインディングを提供する Pipeline Workspace の一覧を指定します。
2: ボリュームが提供されている Pipeline の Workspace の名前。
3: ワークスペースのストレージボリュームを定義するために永続ボリューム要求を作成するボリューム要求テンプレートを指定します。

3.2.9. トリガー
リンクのコピー

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 
kind: TriggerBinding 
metadata:
  name: vote-app 
spec:
  params: 
  - name: git-repo-url
    value: $(body.repository.url)
  - name: git-repo-name
    value: $(body.repository.name)
  - name: git-revision
    value: $(body.head_commit.id)
```
```
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 Toggle word wrap
1
TriggerBinding リソースの API バージョン。この例では、v1beta1 です。
2
Kubernetes オブジェクトのタイプを指定します。この例では、TriggerBinding です。
3
この TriggerBinding を識別する一意の名前。
4
受信イベントペイロードから抽出され、TriggerTemplate に渡されるパラメーターのリスト。この例では、Git リポジトリー URL、名前、およびリビジョンはイベントペイロードの本体から抽出されます。

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

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

apiVersion: triggers.tekton.dev/v1beta1 
kind: TriggerTemplate 
metadata:
  name: vote-app 
spec:
  params: 
  - name: git-repo-url
    description: The git repository url
  - name: git-revision
    description: The git revision
    default: pipelines-1.15
  - name: git-repo-name
    description: The name of the deployment to be created / patched

  resourcetemplates: 
  - 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

apiVersion: triggers.tekton.dev/v1beta1


kind: TriggerTemplate


metadata:
  name: vote-app


spec:
  params:


  - name: git-repo-url
    description: The git repository url
  - name: git-revision
    description: The git revision
    default: pipelines-1.15
  - name: git-repo-name
    description: The name of the deployment to be created / patched

  resourcetemplates:


  - 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

Toggle word wrap

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 
kind: Trigger 
metadata:
  name: vote-trigger 
spec:
  taskRunTemplate:
    serviceAccountName: pipeline 
  interceptors:
    - ref:
        name: "github" 
      params: 
        - name: "secretRef"
          value:
            secretName: github-secret
            secretKey: secretToken
        - name: "eventTypes"
          value: ["push"]
  bindings:
    - ref: vote-app 
  template: 
     ref: vote-app
---
apiVersion: v1
kind: Secret 
metadata:
  name: github-secret
type: Opaque
stringData:
  secretToken: "1234567"
```
```
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 Toggle word wrap
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 
kind: EventListener 
metadata:
  name: vote-app 
spec:
  taskRunTemplate:
    serviceAccountName: pipeline 
  triggers:
    - triggerRef: vote-trigger 
```
```
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 Toggle word wrap
1
EventListener リソースの API バージョン。この例では、v1beta1 です。
2
Kubernetes オブジェクトのタイプを指定します。この例では、EventListener です。
3
EventListener リソースを識別するための一意の名前。
4
使用されるサービスアカウント名。
5
EventListener リソースによって参照される Trigger リソースの名前。

トップに戻る

3.2. OpenShift Pipeline の概念

3.2.1. タスク
リンクのコピー

3.2.2. when 式
リンクのコピー

3.2.3. 最後のタスク
リンクのコピー

3.2.4. TaskRun
リンクのコピー

3.2.5. Pipelines
リンクのコピー

3.2.6. PipelineRun
リンクのコピー

3.2.7. Pod テンプレート
リンクのコピー

3.2.8. ワークスペース
リンクのコピー

3.2.9. トリガー
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

3.2. OpenShift Pipeline の概念

3.2.1. タスクリンクのコピーリンクがクリップボードにコピーされました!

3.2.2. when 式リンクのコピーリンクがクリップボードにコピーされました!

3.2.3. 最後のタスクリンクのコピーリンクがクリップボードにコピーされました!

3.2.4. TaskRunリンクのコピーリンクがクリップボードにコピーされました!

3.2.5. Pipelinesリンクのコピーリンクがクリップボードにコピーされました!

3.2.6. PipelineRunリンクのコピーリンクがクリップボードにコピーされました!

3.2.7. Pod テンプレートリンクのコピーリンクがクリップボードにコピーされました!

3.2.8. ワークスペースリンクのコピーリンクがクリップボードにコピーされました!

3.2.9. トリガーリンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

3.2.1. タスク
リンクのコピー

3.2.2. when 式
リンクのコピー

3.2.3. 最後のタスク
リンクのコピー

3.2.4. TaskRun
リンクのコピー

3.2.5. Pipelines
リンクのコピー

3.2.6. PipelineRun
リンクのコピー

3.2.7. Pod テンプレート
リンクのコピー

3.2.8. ワークスペース
リンクのコピー

3.2.9. トリガー
リンクのコピー