CI/CD パイプラインの作成


Red Hat OpenShift Pipelines 1.10

OpenShift Pipelines でのタスクとパイプラインの作成と実行の開始

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Pipelines でのタスクとパイプラインの作成と実行に関する情報を提供します。

第1章 OpenShift Pipelines を使用したアプリケーションの CI/CD ソリューションの作成

Red Hat OpenShift Pipelines を使用すると、カスタマイズされた CI/CD ソリューションを作成して、アプリケーションをビルドし、テストし、デプロイできます。

アプリケーション向けの本格的なセルフサービス型の CI/CD パイプラインを作成するには、以下のタスクを実行する必要があります。

  • カスタムタスクを作成するか、既存の再利用可能なタスクをインストールします。
  • アプリケーションの配信パイプラインを作成し、定義します。
  • 以下の方法のいずれかを使用して、パイプライン実行のためにワークスペースに接続されているストレージボリュームまたはファイルシステムを提供します。

    • 永続ボリューム要求 (PVC) を作成するボリューム要求テンプレートを指定します。
    • 永続ボリューム要求 (PVC) を指定します。
  • PipelineRun オブジェクトを作成し、Pipeline をインスタンス化し、これを起動します。
  • トリガーを追加し、ソースリポジトリーのイベントを取得します。

このセクションでは、pipelines-tutorial の例を使用して前述のタスクについて説明します。この例では、以下で設定される単純なアプリケーションを使用します。

  • pipelines-vote-ui Git リポジトリーにソースコードがあるフロントエンドインターフェイス (pipelines-vote-ui)。
  • pipelines-vote-api Git リポジトリーにソースコードがあるバックエンドインターフェイス (pipelines-vote-api)。
  • pipelines-tutorial Git リポジトリーにある apply-manifests および update-deployment タスク。

1.1. 前提条件

  • OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift OperatorHub にリストされている Red Hat OpenShift Pipelines Operator を使用して OpenShift Pipelines をインストールしている。インストールの完了後にクラスター全体に適用できる。
  • OpenShift Pipelines CLI がインストールされている。
  • GitHub ID を使用してフロントエンドの pipelines-vote-ui およびバックエンドの pipelines-vote-api Git リポジトリーをフォークしており、これらのリポジトリーに管理者権限でアクセスできる。
  • オプション: pipelines-tutorial Git リポジトリーのクローンを作成している。

1.2. プロジェクトの作成およびパイプラインのサービスアカウントの確認

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ oc login -u <login> -p <password> https://openshift.example.com:6443
    Copy to Clipboard Toggle word wrap
  2. サンプルアプリケーションのプロジェクトを作成します。このサンプルワークフローでは、pipelines-tutorial プロジェクトを作成します。

    $ oc new-project pipelines-tutorial
    Copy to Clipboard Toggle word wrap
    注記

    別の名前でプロジェクトを作成する場合は、サンプルで使用されているリソース URL をプロジェクト名で更新してください。

  3. pipeline サービスアカウントを表示します。

    Red Hat OpenShift Pipelines Operator は、イメージのビルドおよびプッシュを実行するのに十分なパーミッションを持つ pipeline という名前のサービスアカウントを追加し、設定します。このサービスアカウントは PipelineRun オブジェクトによって使用されます。

    $ oc get serviceaccount pipeline
    Copy to Clipboard Toggle word wrap

1.3. パイプラインタスクの作成

手順

  1. pipelines-tutorial リポジトリーから apply-manifests および update-deployment タスクリソースをインストールします。これには、パイプラインの再利用可能なタスクのリストが含まれます。

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/01_apply_manifest_task.yaml
    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/02_update_deployment_task.yaml
    Copy to Clipboard Toggle word wrap
  2. tkn task list コマンドを使用して、作成したタスクをリスト表示します。

    $ tkn task list
    Copy to Clipboard Toggle word wrap

    出力では、apply-manifests および update-deployment タスクリソースが作成されていることを検証します。

    NAME                DESCRIPTION   AGE
    apply-manifests                   1 minute ago
    update-deployment                 48 seconds ago
    Copy to Clipboard Toggle word wrap
  3. tkn clustertasks list コマンドを使用して、buildah および s2i-python-3 などの Operator でインストールされた追加のクラスタータスクをリスト表示します。

    注記

    制限された環境で buildah クラスタータスクを使用するには、Dockerfile が内部イメージストリームをベースイメージとして使用していることを確認する必要があります。

    $ tkn clustertasks list
    Copy to Clipboard Toggle word wrap

    出力には、Operator でインストールされた ClusterTask リソースが一覧表示されます。

    NAME                       DESCRIPTION   AGE
    buildah                                  1 day ago
    git-clone                                1 day ago
    s2i-python                               1 day ago
    tkn                                      1 day ago
    Copy to Clipboard Toggle word wrap
重要

Red Hat OpenShift Pipelines 1.10 では、クラスタータスク機能は非推奨であり、将来のリリースで削除される予定です。

1.4. パイプラインのアセンブル

パイプラインは CI/CD フローを表し、実行するタスクによって定義されます。これは、複数のアプリケーションや環境で汎用的かつ再利用可能になるように設計されています。

パイプラインは、from および runAfter パラメーターを使用してタスクが相互に対話する方法および実行順序を指定します。これは workspaces フィールドを使用して、パイプラインの各タスクの実行中に必要な 1 つ以上のボリュームを指定します。

このセクションでは、GitHub からアプリケーションのソースコードを取り、これを OpenShift Container Platform にビルドし、デプロイするパイプラインを作成します。

パイプラインは、バックエンドアプリケーションの vote-api およびフロントエンドアプリケーション vote-ui について以下のタスクを実行します。

  • git-url および git-revision パラメーターを参照して、Git リポジトリーからアプリケーションのソースコードのクローンを作成します。
  • buildah クラスタータスクを使用してコンテナーイメージをビルドします。
  • image パラメーターを参照して、イメージを OpenShift イメージレジストリーにプッシュします。
  • apply-manifests および update-deployment タスクを使用して新規イメージを OpenShift Container Platform にデプロイします。

手順

  1. 以下のサンプルのパイプライン YAML ファイルの内容をコピーし、保存します。

    apiVersion: tekton.dev/v1beta1
    kind: Pipeline
    metadata:
      name: build-and-deploy
    spec:
      workspaces:
      - name: shared-workspace
      params:
      - name: deployment-name
        type: string
        description: name of the deployment to be patched
      - name: git-url
        type: string
        description: url of the git repo for the code of deployment
      - name: git-revision
        type: string
        description: revision to be used from repo of the code for deployment
        default: "pipelines-1.10"
      - name: IMAGE
        type: string
        description: image to be built from the code
      tasks:
      - name: fetch-repository
        taskRef:
          name: git-clone
          kind: ClusterTask
        workspaces:
        - name: output
          workspace: shared-workspace
        params:
        - name: url
          value: $(params.git-url)
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
        - name: revision
          value: $(params.git-revision)
      - name: build-image
        taskRef:
          name: buildah
          kind: ClusterTask
        params:
        - name: IMAGE
          value: $(params.IMAGE)
        workspaces:
        - name: source
          workspace: shared-workspace
        runAfter:
        - fetch-repository
      - name: apply-manifests
        taskRef:
          name: apply-manifests
        workspaces:
        - name: source
          workspace: shared-workspace
        runAfter:
        - build-image
      - name: update-deployment
        taskRef:
          name: update-deployment
        params:
        - name: deployment
          value: $(params.deployment-name)
        - name: IMAGE
          value: $(params.IMAGE)
        runAfter:
        - apply-manifests
    Copy to Clipboard Toggle word wrap

    パイプライン定義は、Git ソースリポジトリーおよびイメージレジストリーの詳細を抽象化します。これらの詳細は、パイプラインのトリガーおよび実行時に params として追加されます。

  2. パイプラインを作成します。

    $ oc create -f <pipeline-yaml-file-name.yaml>
    Copy to Clipboard Toggle word wrap

    または、Git リポジトリーから YAML ファイルを直接実行することもできます。

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/04_pipeline.yaml
    Copy to Clipboard Toggle word wrap
  3. tkn pipeline list コマンドを使用して、パイプラインがアプリケーションに追加されていることを確認します。

    $ tkn pipeline list
    Copy to Clipboard Toggle word wrap

    この出力では、build-and-deploy パイプラインが作成されていることを検証します。

    NAME               AGE            LAST RUN   STARTED   DURATION   STATUS
    build-and-deploy   1 minute ago   ---        ---       ---        ---
    Copy to Clipboard Toggle word wrap

1.5. 制限された環境でパイプラインを実行するためのイメージのミラーリング

OpenShift Pipelines を非接続のクラスターまたは制限された環境でプロビジョニングされたクラスターで実行するには、制限されたネットワークに Samples Operator が設定されているか、クラスター管理者がミラーリングされたレジストリーでクラスターを作成しているか確認する必要があります。

以下の手順では、pipelines-tutorial の例を使用して、ミラーリングされたレジストリーを持つクラスターを使用して、制限された環境でアプリケーションのパイプラインを作成します。pipelines-tutorial の例が制限された環境で機能することを確認するには、フロントエンドインターフェイス (pipelines-vote-ui)、バックエンドインターフェイス (pipelines-vote-api) および cli のミラーレジストリーからそれぞれのビルダーイメージをミラーリングする必要があります。

手順

  1. フロントエンドインターフェイス (pipelines-vote-ui) のミラーレジストリーからビルダーイメージをミラーリングします。

    1. 必要なイメージタグがインポートされていないことを確認します。

      $ oc describe imagestream python -n openshift
      Copy to Clipboard Toggle word wrap

      出力例

      Name:			python
      Namespace:		openshift
      [...]
      
      3.8-ubi8 (latest)
        tagged from registry.redhat.io/ubi8/python-38:latest
          prefer registry pullthrough when referencing this tag
      
        Build and run Python 3.8 applications on UBI 8. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/s2i-python-container/blob/master/3.8/README.md.
        Tags: builder, python
        Supports: python:3.8, python
        Example Repo: https://github.com/sclorg/django-ex.git
      
      [...]
      Copy to Clipboard Toggle word wrap

    2. サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。

      $ oc image mirror registry.redhat.io/ubi8/python-38:latest <mirror-registry>:<port>/ubi8/python-38
      Copy to Clipboard Toggle word wrap
    3. イメージをインポートします。

      $ oc tag <mirror-registry>:<port>/ubi8/python-38 python:latest --scheduled -n openshift
      Copy to Clipboard Toggle word wrap

      イメージを定期的に再インポートする必要があります。--scheduled フラグは、イメージの自動再インポートを有効にします。

    4. 指定されたタグを持つイメージがインポートされていることを確認します。

      $ oc describe imagestream python -n openshift
      Copy to Clipboard Toggle word wrap

      出力例

      Name:			python
      Namespace:		openshift
      [...]
      
      latest
        updates automatically from registry <mirror-registry>:<port>/ubi8/python-38
      
        * <mirror-registry>:<port>/ubi8/python-38@sha256:3ee3c2e70251e75bfeac25c0c33356add9cc4abcbc9c51d858f39e4dc29c5f58
      
      [...]
      Copy to Clipboard Toggle word wrap

  2. バックエンドインターフェイス (pipelines-vote-api) のミラーレジストリーからビルダーイメージをミラーリングします。

    1. 必要なイメージタグがインポートされていないことを確認します。

      $ oc describe imagestream golang -n openshift
      Copy to Clipboard Toggle word wrap

      出力例

      Name:			golang
      Namespace:		openshift
      [...]
      
      1.14.7-ubi8 (latest)
        tagged from registry.redhat.io/ubi8/go-toolset:1.14.7
          prefer registry pullthrough when referencing this tag
      
        Build and run Go applications on UBI 8. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/golang-container/blob/master/README.md.
        Tags: builder, golang, go
        Supports: golang
        Example Repo: https://github.com/sclorg/golang-ex.git
      
      [...]
      Copy to Clipboard Toggle word wrap

    2. サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。

      $ oc image mirror registry.redhat.io/ubi8/go-toolset:1.14.7 <mirror-registry>:<port>/ubi8/go-toolset
      Copy to Clipboard Toggle word wrap
    3. イメージをインポートします。

      $ oc tag <mirror-registry>:<port>/ubi8/go-toolset golang:latest --scheduled -n openshift
      Copy to Clipboard Toggle word wrap

      イメージを定期的に再インポートする必要があります。--scheduled フラグは、イメージの自動再インポートを有効にします。

    4. 指定されたタグを持つイメージがインポートされていることを確認します。

      $ oc describe imagestream golang -n openshift
      Copy to Clipboard Toggle word wrap

      出力例

      Name:			golang
      Namespace:		openshift
      [...]
      
      latest
        updates automatically from registry <mirror-registry>:<port>/ubi8/go-toolset
      
        * <mirror-registry>:<port>/ubi8/go-toolset@sha256:59a74d581df3a2bd63ab55f7ac106677694bf612a1fe9e7e3e1487f55c421b37
      
      [...]
      Copy to Clipboard Toggle word wrap

  3. cli のミラーレジストリーからビルダーイメージをミラーリングします。

    1. 必要なイメージタグがインポートされていないことを確認します。

      $ oc describe imagestream cli -n openshift
      Copy to Clipboard Toggle word wrap

      出力例

      Name:                   cli
      Namespace:              openshift
      [...]
      
      latest
        updates automatically from registry quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551
      
        * quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551
      
      [...]
      Copy to Clipboard Toggle word wrap

    2. サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。

      $ oc image mirror quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551 <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev:latest
      Copy to Clipboard Toggle word wrap
    3. イメージをインポートします。

      $ oc tag <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev cli:latest --scheduled -n openshift
      Copy to Clipboard Toggle word wrap

      イメージを定期的に再インポートする必要があります。--scheduled フラグは、イメージの自動再インポートを有効にします。

    4. 指定されたタグを持つイメージがインポートされていることを確認します。

      $ oc describe imagestream cli -n openshift
      Copy to Clipboard Toggle word wrap

      出力例

      Name:                   cli
      Namespace:              openshift
      [...]
      
      latest
        updates automatically from registry <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev
      
        * <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551
      
      [...]
      Copy to Clipboard Toggle word wrap

1.6. パイプラインの実行

PipelineRun リソースはパイプラインを開始し、これを特定の呼び出しに使用する必要のある Git およびイメージリソースに関連付けます。これは、パイプラインの各タスクについて TaskRun を自動的に作成し、開始します。

手順

  1. バックエンドアプリケーションのパイプラインを起動します。

    $ tkn pipeline start build-and-deploy \
        -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/03_persistent_volume_claim.yaml \
        -p deployment-name=pipelines-vote-api \
        -p git-url=https://github.com/openshift/pipelines-vote-api.git \
        -p IMAGE='image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-api' \
        --use-param-defaults
    Copy to Clipboard Toggle word wrap

    直前のコマンドは、パイプライン実行の永続ボリューム要求 (PVC) を作成するボリューム要求テンプレートを使用します。

  2. パイプライン実行の進捗を追跡するには、以下のコマンドを入力します。

    $ tkn pipelinerun logs <pipelinerun_id> -f
    Copy to Clipboard Toggle word wrap

    上記のコマンドの <pipelinerun_id> は、直前のコマンドの出力で返された PipelineRun の ID です。

  3. フロントエンドアプリケーションのパイプラインを起動します。

    $ tkn pipeline start build-and-deploy \
        -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/03_persistent_volume_claim.yaml \
        -p deployment-name=pipelines-vote-ui \
        -p git-url=https://github.com/openshift/pipelines-vote-ui.git \
        -p IMAGE='image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-ui' \
        --use-param-defaults
    Copy to Clipboard Toggle word wrap
  4. パイプライン実行の進捗を追跡するには、以下のコマンドを入力します。

    $ tkn pipelinerun logs <pipelinerun_id> -f
    Copy to Clipboard Toggle word wrap

    上記のコマンドの <pipelinerun_id> は、直前のコマンドの出力で返された PipelineRun の ID です。

  5. 数分後に、tkn pipelinerun list コマンドを使用して、すべてのパイプライン実行をリスト表示してパイプラインが正常に実行されたことを確認します。

    $ tkn pipelinerun list
    Copy to Clipboard Toggle word wrap

    出力には、パイプライン実行がリスト表示されます。

     NAME                         STARTED      DURATION     STATUS
     build-and-deploy-run-xy7rw   1 hour ago   2 minutes    Succeeded
     build-and-deploy-run-z2rz8   1 hour ago   19 minutes   Succeeded
    Copy to Clipboard Toggle word wrap
  6. アプリケーションルートを取得します。

    $ oc get route pipelines-vote-ui --template='http://{{.spec.host}}'
    Copy to Clipboard Toggle word wrap

    上記のコマンドの出力に留意してください。このルートを使用してアプリケーションにアクセスできます。

  7. 直前のパイプラインのパイプラインリソースおよびサービスアカウントを使用して最後のパイプライン実行を再実行するには、以下を実行します。

    $ tkn pipeline start build-and-deploy --last
    Copy to Clipboard Toggle word wrap

1.7. トリガーのパイプラインへの追加

トリガーは、パイプラインがプッシュイベントやプル要求などの外部の GitHub イベントに応答できるようにします。アプリケーションのパイプラインをアセンブルし、起動した後に、TriggerBindingTriggerTemplateTrigger、および EventListener リソースを追加して GitHub イベントを取得します。

手順

  1. 以下のサンプル TriggerBinding YAML ファイルの内容をコピーし、これを保存します。

    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)
    Copy to Clipboard Toggle word wrap
  2. TriggerBinding リソースを作成します。

    $ oc create -f <triggerbinding-yaml-file-name.yaml>
    Copy to Clipboard Toggle word wrap

    または、TriggerBinding リソースを pipelines-tutorial Git リポジトリーから直接作成できます。

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/03_triggers/01_binding.yaml
    Copy to Clipboard Toggle word wrap
  3. 以下のサンプル TriggerTemplate YAML ファイルの内容をコピーし、これを保存します。

    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.10
      - name: git-repo-name
        description: The name of the deployment to be created / patched
    
      resourcetemplates:
      - apiVersion: tekton.dev/v1beta1
        kind: PipelineRun
        metadata:
          generateName: build-deploy-$(tt.params.git-repo-name)-
        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

    テンプレートは、ワークスペースのストレージボリュームを定義するための永続ボリューム要求 (PVC) を作成するためのボリューム要求テンプレートを指定します。そのため、データストレージを提供するために永続ボリューム要求 (PVC) を作成する必要はありません。

  4. TriggerTemplate リソースを作成します。

    $ oc create -f <triggertemplate-yaml-file-name.yaml>
    Copy to Clipboard Toggle word wrap

    または、TriggerTemplate リソースを pipelines-tutorial Git リポジトリーから直接作成できます。

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/03_triggers/02_template.yaml
    Copy to Clipboard Toggle word wrap
  5. 以下のサンプルの Trigger YAML ファイルの内容をコピーし、保存します。

    apiVersion: triggers.tekton.dev/v1beta1
    kind: Trigger
    metadata:
      name: vote-trigger
    spec:
      serviceAccountName: pipeline
      bindings:
        - ref: vote-app
      template:
        ref: vote-app
    Copy to Clipboard Toggle word wrap
  6. Trigger リソースを作成します。

    $ oc create -f <trigger-yaml-file-name.yaml>
    Copy to Clipboard Toggle word wrap

    または、Trigger リソースを pipelines-tutorial Git リポジトリーから直接作成できます。

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/03_triggers/03_trigger.yaml
    Copy to Clipboard Toggle word wrap
  7. 以下のサンプル EventListener YAML ファイルの内容をコピーし、これを保存します。

    apiVersion: triggers.tekton.dev/v1beta1
    kind: EventListener
    metadata:
      name: vote-app
    spec:
      serviceAccountName: pipeline
      triggers:
        - triggerRef: vote-trigger
    Copy to Clipboard Toggle word wrap

    または、トリガーカスタムリソースを定義していない場合は、トリガーの名前を参照する代わりに、バインディングおよびテンプレート仕様を EventListener YAML ファイルに追加します。

    apiVersion: triggers.tekton.dev/v1beta1
    kind: EventListener
    metadata:
      name: vote-app
    spec:
      serviceAccountName: pipeline
      triggers:
      - bindings:
        - ref: vote-app
        template:
          ref: vote-app
    Copy to Clipboard Toggle word wrap
  8. 以下のコマンドを実行して EventListener リソースを作成します。

    • セキュアな HTTPS 接続を使用して EventListener リソースを作成するには、以下を実行します。

      1. ラベルを追加して、Eventlistener リソースへのセキュアな HTTPS 接続を有効にします。

        $ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled
        Copy to Clipboard Toggle word wrap
      2. EventListener リソースを作成します。

        $ oc create -f <eventlistener-yaml-file-name.yaml>
        Copy to Clipboard Toggle word wrap

        または、EvenListener リソースを pipelines-tutorial Git リポジトリーから直接作成できます。

        $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/03_triggers/04_event_listener.yaml
        Copy to Clipboard Toggle word wrap
      3. re-encrypt TLS 終端でルートを作成します。

        $ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
        Copy to Clipboard Toggle word wrap

        または、re-encrypt TLS 終端 YAML ファイルを作成して、セキュアなルートを作成できます。

        セキュアなルートの re-encrypt TLS 終端 YAML の例

        apiVersion: route.openshift.io/v1
        kind: Route
        metadata:
          name: route-passthrough-secured 
        1
        
        spec:
          host: <hostname>
          to:
            kind: Service
            name: frontend 
        2
        
          tls:
            termination: reencrypt         
        3
        
            key: [as in edge termination]
            certificate: [as in edge termination]
            caCertificate: [as in edge termination]
            destinationCACertificate: |-   
        4
        
              -----BEGIN CERTIFICATE-----
              [...]
              -----END CERTIFICATE-----
        Copy to Clipboard Toggle word wrap

        1 2
        オブジェクトの名前で、63 文字に制限されます。
        3
        termination フィールドは reencrypt に設定されます。これは、必要な唯一の tls フィールドです。
        4
        再暗号化に必要です。destinationCACertificate は CA 証明書を指定してエンドポイントの証明書を検証し、ルーターから宛先 Pod への接続のセキュリティーを保護します。サービスがサービス署名証明書を使用する場合または、管理者がデフォルトの CA 証明書をルーターに指定し、サービスにその CA により署名された証明書がある場合には、このフィールドは省略可能です。

        他のオプションについては、oc create route reencrypt --help を参照してください。

    • 非セキュアな HTTP 接続を使用して EventListener リソースを作成するには、以下を実行します。

      1. EventListener リソースを作成します。
      2. EventListener サービスを OpenShift Container Platform ルートとして公開し、これをアクセス可能にします。

        $ oc expose svc el-vote-app
        Copy to Clipboard Toggle word wrap

1.8. 複数の namespace を提供するようにイベントリスナーを設定する

注記

基本的な CI/CD パイプラインを作成する必要がある場合は、このセクションをスキップできます。ただし、デプロイメント戦略に複数の namespace が含まれる場合は、複数の namespace を提供するようにイベントリスナーを設定できます。

EvenListener オブジェクトの再利用性を高めるために、クラスター管理者は、複数の namespace にサービスを提供するマルチテナントイベントリスナーとして、これらのオブジェクトを設定およびデプロイできます。

手順

  1. イベントリスナーのクラスター全体のフェッチ権限を設定します。

    1. ClusterRoleBinding オブジェクトおよびEventListener オブジェクトで使用するサービスアカウント名を設定します。たとえば、el-sa

      ServiceAccount.yaml の例

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: el-sa
      ---
      Copy to Clipboard Toggle word wrap

    2. ClusterRole.yaml ファイルの rules セクションで、クラスター全体で機能するように、すべてのイベントリスナーデプロイメントに適切な権限を設定します。

      ClusterRole.yaml の例

      kind: ClusterRole
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
        name: el-sel-clusterrole
      rules:
      - apiGroups: ["triggers.tekton.dev"]
        resources: ["eventlisteners", "clustertriggerbindings", "clusterinterceptors", "triggerbindings", "triggertemplates", "triggers"]
        verbs: ["get", "list", "watch"]
      - apiGroups: [""]
        resources: ["configmaps", "secrets"]
        verbs: ["get", "list", "watch"]
      - apiGroups: [""]
        resources: ["serviceaccounts"]
        verbs: ["impersonate"]
      ...
      Copy to Clipboard Toggle word wrap

    3. 適切なサービスアカウント名とクラスターロール名を使用して、クラスターロールバインディングを設定します。

      ClusterRoleBinding.yaml の例

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: el-mul-clusterrolebinding
      subjects:
      - kind: ServiceAccount
        name: el-sa
        namespace: default
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: el-sel-clusterrole
      ...
      Copy to Clipboard Toggle word wrap

  2. イベントリスナーのspecパラメーターに、サービスアカウント名 (el-sa など) を追加します。namespaceSelectorパラメーターに、イベントリスナーがサービスを提供する namespace の名前を入力します。

    EventListener.yaml の例

    apiVersion: triggers.tekton.dev/v1beta1
    kind: EventListener
    metadata:
      name: namespace-selector-listener
    spec:
      serviceAccountName: el-sa
      namespaceSelector:
        matchNames:
        - default
        - foo
    ...
    Copy to Clipboard Toggle word wrap

  3. 必要な権限を持つサービスアカウントを作成します (例: foo-trigger-sa)。トリガーをロールバインドするために使用します。

    ServiceAccount.yaml の例

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: foo-trigger-sa
      namespace: foo
    ...
    Copy to Clipboard Toggle word wrap

    RoleBinding.yaml の例

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: triggercr-rolebinding
      namespace: foo
    subjects:
    - kind: ServiceAccount
      name: foo-trigger-sa
      namespace: foo
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: tekton-triggers-eventlistener-roles
    ...
    Copy to Clipboard Toggle word wrap

  4. 適切なトリガーテンプレート、トリガーバインディング、およびサービスアカウント名を使用してトリガーを作成します。

    Trigger.yaml の例

    apiVersion: triggers.tekton.dev/v1beta1
    kind: Trigger
    metadata:
      name: trigger
      namespace: foo
    spec:
      serviceAccountName: foo-trigger-sa
      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
    ...
    Copy to Clipboard Toggle word wrap

1.9. Webhook の作成

Webhook は、設定されたイベントがリポジトリーで発生するたびにイベントリスナーよって受信される HTTP POST メッセージです。その後、イベントペイロードはトリガーバインディングにマップされ、トリガーテンプレートによって処理されます。トリガーテンプレートは最終的に 1 つ以上のパイプライン実行を開始し、Kubernetes リソースの作成およびデプロイメントを実行します。

このセクションでは、フォークされた Git リポジトリー pipelines-vote-ui および pipelines-vote-api で Webhook URL を設定します。この URL は、一般に公開されている EventListener サービスルートを参照します。

注記

Webhook を追加するには、リポジトリーへの管理者権限が必要です。リポジトリーへの管理者アクセスがない場合は、Webhook を追加できるようにシステム管理者に問い合わせてください。

手順

  1. Webhook URL を取得します。

    • セキュアな HTTPS 接続の場合:

      $ echo "URL: $(oc  get route el-vote-app --template='https://{{.spec.host}}')"
      Copy to Clipboard Toggle word wrap
    • HTTP (非セキュアな) 接続の場合:

      $ echo "URL: $(oc  get route el-vote-app --template='http://{{.spec.host}}')"
      Copy to Clipboard Toggle word wrap

      出力で取得した URL をメモします。

  2. フロントエンドリポジトリーで Webhook を手動で設定します。

    1. フロントエンド Git リポジトリー pipelines-vote-ui をブラウザーで開きます。
    2. SettingsWebhooksAdd Webhook をクリックします。
    3. Webhooks/Add Webhook ページで以下を実行します。

      1. 手順 1 の Webhook URL を Payload URL フィールドに入力します。
      2. Content type について application/json を選択します。
      3. シークレットを Secret フィールドに指定します。
      4. Just the push event が選択されていることを確認します。
      5. Active を選択します。
      6. Add Webhook をクリックします。
  3. バックエンドリポジトリー pipelines-vote-api について手順 2 を繰り返します。

1.10. パイプライン実行のトリガー

push イベントが Git リポジトリーで実行されるたびに、設定された Webhook はイベントペイロードを公開される EventListener サービスルートに送信します。アプリケーションの EventListener サービスはペイロードを処理し、これを関連する TriggerBinding および TriggerTemplate リソースのペアに渡します。TriggerBinding リソースはパラメーターを抽出し、TriggerTemplate リソースはこれらのパラメーターを使用して、リソースの作成方法を指定します。これにより、アプリケーションが再ビルドされ、再デプロイされる可能性があります。

このセクションでは、空のコミットをフロントエンドの pipelines-vote-ui リポジトリーにプッシュし、パイプライン実行をトリガーします。

手順

  1. ターミナルから、フォークした Git リポジトリー pipelines-vote-ui のクローンを作成します。

    $ git clone git@github.com:<your GitHub ID>/pipelines-vote-ui.git -b pipelines-1.10
    Copy to Clipboard Toggle word wrap
  2. 空のコミットをプッシュします。

    $ git commit -m "empty-commit" --allow-empty && git push origin pipelines-1.10
    Copy to Clipboard Toggle word wrap
  3. パイプライン実行がトリガーされたかどうかを確認します。

    $ tkn pipelinerun list
    Copy to Clipboard Toggle word wrap

    新規のパイプライン実行が開始されたことに注意してください。

1.11. ユーザー定義プロジェクトでの Triggers のイベントリスナーのモニタリングの有効化

クラスター管理者は、イベントリスナーごとにサービスモニターを作成し、ユーザー定義のプロジェクトで Triggers サービスのイベントリスナーメトリックを収集し、OpenShift Container Platform Web コンソールでそれらを表示することができます。HTTP リクエストを受信すると、Triggers サービスのイベントリスナーは 3 つのメトリック (eventlistener_http_duration_secondseventlistener_event_count、および eventlistener_triggered_resources) を返します。

前提条件

  • OpenShift Container Platform Web コンソールにログインしている。
  • Red Hat OpenShift Pipelines Operator がインストールされている。
  • ユーザー定義プロジェクトのモニタリングを有効にしている。

手順

  1. イベントリスナーごとに、サービスモニターを作成します。たとえば、test namespace の github-listener イベントリスナーのメトリックを表示するには、以下のサービスモニターを作成します。

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      labels:
        app.kubernetes.io/managed-by: EventListener
        app.kubernetes.io/part-of: Triggers
        eventlistener: github-listener
      annotations:
        networkoperator.openshift.io/ignore-errors: ""
      name: el-monitor
      namespace: test
    spec:
      endpoints:
        - interval: 10s
          port: http-metrics
      jobLabel: name
      namespaceSelector:
        matchNames:
          - test
      selector:
        matchLabels:
          app.kubernetes.io/managed-by: EventListener
          app.kubernetes.io/part-of: Triggers
          eventlistener: github-listener
    ...
    Copy to Clipboard Toggle word wrap
  2. リクエストをイベントリスナーに送信して、サービスモニターをテストします。たとえば、空のコミットをプッシュします。

    $ git commit -m "empty-commit" --allow-empty && git push origin main
    Copy to Clipboard Toggle word wrap
  3. OpenShift Container Platform Web コンソールで、AdministratorObserveMetrics の順に移動します。
  4. メトリックを表示するには、名前で検索します。たとえば、github-listener イベントリスナーの eventlistener_http_resources メトリックの詳細を表示するには、eventlistener_http_resources のキーワードを使用して検索します。

第2章 Web コンソールでの Red Hat OpenShift Pipelines の使用

Administrator または Developer パースペクティブを使用して、OpenShift Container Platform Web コンソールの Pipelines ページから PipelinePipelineRunRepository オブジェクトを作成および変更できます。Web コンソールの Developer パースペクティブの +Add ページを使用して、ソフトウェアデリバリープロセスの CI/CD パイプラインを作成することもできます。

2.1. Developer パースペクティブで Red Hat OpenShift Pipelines を使用する

Developer パースペクティブでは、+Add ページからパイプラインを作成するための以下のオプションにアクセスできます。

  • AddPipelinePipeline Builder オプションを使用して、アプリケーションのカスタマイズされたパイプラインを作成します。
  • +AddFrom Git オプションを使用して、アプリケーション作成時にパイプラインテンプレートおよびリソースを使用してパイプラインを作成します。

アプリケーションのパイプラインの作成後に、Pipelines ビューでデプロイされたパイプラインを表示し、これらと視覚的に対話できます。Topology ビューを使用して、From Git オプションを使用して作成されたパイプラインと対話することもできます。パイプライン ビルダーを使用して作成されたパイプラインを トポロジー ビューで表示するには、カスタムラベルを適用する必要があります。

前提条件

2.1.1. Pipeline Builder を使用した Pipeline の構築

コンソールの Developer パースペクティブで、+AddPipelinePipeline Builder オプションを使用して以下を実行できます。

  • Pipeline ビルダー または YAML ビュー のいずれかを使用してパイプラインを設定します。
  • 既存のタスクおよびクラスタータスクを使用して、パイプラインフローを構築します。OpenShift Pipelines Operator をインストールする際に、再利用可能なパイプラインクラスタータスクをクラスターに追加します。
重要

Red Hat OpenShift Pipelines 1.10 では、クラスタータスク機能は非推奨であり、将来のリリースで削除される予定です。

  • パイプライン実行に必要なリソースタイプを指定し、必要な場合は追加のパラメーターをパイプラインに追加します。
  • パイプラインの各タスクのこれらのパイプラインリソースを入力および出力リソースとして参照します。
  • 必要な場合は、タスクのパイプラインに追加されるパラメーターを参照します。タスクのパラメーターは、Task の仕様に基づいて事前に設定されます。
  • Operator によってインストールされた、再利用可能なスニペットおよびサンプルを使用して、詳細なパイプラインを作成します。

手順

  1. Developer パースペクティブの +Add ビューで、Pipeline タイルをクリックし、Pipeline Builder ページを表示します。
  2. Pipeline ビルダー ビューまたは YAML ビュー のいずれかを使用して、パイプラインを設定します。

    注記

    Pipeline ビルダー ビューは、限られた数のフィールドをサポートしますが、YAML ビュー は利用可能なすべてのフィールドをサポートします。オプションで、Operator によってインストールされた、再利用可能なスニペットおよびサンプルを使用して、詳細な Pipeline を作成することもできます。

    図2.1 YAML ビュー

    op pipeline yaml
  3. Pipeline builder を使用してパイプラインを設定します。

    1. Name フィールドにパイプラインの一意の名前を入力します。
    2. Tasks セクションで、以下を実行します。

      1. Add task をクリックします。
      2. クイック検索フィールドを使用してタスクを検索し、表示されたリストから必要なタスクを選択します。
      3. Add または Install and add をクリックします。この例では、s2i-nodejs タスクを使用します。

        注記

        検索のリストには、Tekton Hub タスクおよび、クラスターで利用可能なタスクがすべて含まれます。また、タスクがすでにインストールされている場合は、タスク追加用の Add が表示され、それ以外の場合は、タスクのインストールおよび追加用の Install and add が表示されます。更新されたバージョンで同じタスクを追加する場合は、Update and add が表示されます。

        • 連続するタスクをパイプラインに追加するには、以下を実行します。

          • タスクの右側にあるプラスアイコンをクリックし、Add task をクリックします。
          • クイック検索フィールドを使用してタスクを検索し、表示されたリストから必要なタスクを選択します。
          • Add または Install and add をクリックします。

            図2.2 Pipeline Builder

            op pipeline builder
        • 最終タスクを追加するには、以下を実行します。

          • Add finally taskAdd task の順にクリックします。
          • クイック検索フィールドを使用してタスクを検索し、表示されたリストから必要なタスクを選択します。
          • Add または Install and add をクリックします。
    3. Resources セクションで、Add Resources をクリックし、パイプライン実行用のリソースの名前およびタイプを指定します。これらのリソースは、パイプラインのタスクによって入力および出力として使用されます。この例では、以下のようになります。

      1. 入力リソースを追加します。Name フィールドに Source を入力してから、Resource Type ドロップダウンリストから Git を選択します。
      2. 出力リソースを追加します。Name フィールドに Img を入力してから、Resource Type ドロップダウンリストから イメージ を選択します。

        注記

        リソースが見つからない場合には、タスクの横に赤のアイコンが表示されます。

    4. オプション: タスクの Parameters は、タスクの仕様に基づいて事前に設定されます。必要な場合は、Parameters セクションの Add Parameters リンクを使用して、パラメーターを追加します。
    5. Workspaces セクションで、Add workspace をクリックし、Name フィールドに一意のワークスペース名を入力します。複数のワークスペースをパイプラインに追加できます。
    6. Tasks セクションで、s2i-nodejs タスクをクリックし、タスクの詳細情報が含まれるサイドパネルを表示します。タスクのサイドパネルで、s2i-nodejs タスクのリソースおよびパラメーターを指定します。

      1. 必要な場合は、Parameters セクションで、$(params.<param-name>) 構文を使用して、デフォルトのパラメーターにパラメーターをさらに追加します。
      2. Image セクションで、Resources セクションで指定されているように Img を入力します。
      3. Workspace セクションの source ドロップダウンからワークスペースを選択します。
    7. リソース、パラメーター、およびワークスペースを openshift-client タスクに追加します。
  4. Create をクリックし、Pipeline Details ページでパイプラインを作成し、表示します。
  5. Actions ドロップダウンメニューをクリックしてから Start をクリックし、Start Pipeline ページを表示します。
  6. Workspace セクションは、以前に作成したワークスペースをリスト表示します。それぞれのドロップダウンを使用して、ワークスペースのボリュームソースを指定します。Empty DirectoryConfig MapSecretPersistentVolumeClaim、または VolumeClaimTemplate のオプションを使用できます。

2.1.2. アプリケーションと共に OpenShift Pipelines を作成する

アプリケーションと共にパイプラインを作成するには、Developer パースペクティブの Add+ ビューで、From Git オプションを使用します。使用可能なすべてのパイプラインを表示し、コードのインポートまたはイメージのデプロイ中に、アプリケーションの作成に使用するパイプラインを選択できます。

Tekton Hub 統合はデフォルトで有効になっており、クラスターでサポートされている Tekton Hub からのタスクを確認できます。管理者は Tekton Hub 統合をオプトアウトでき、Tekton Hub タスクは表示されなくなります。生成されたパイプラインに Webhook URL が存在するかどうかを確認することもできます。+Addフローを使用して作成されたパイプラインにデフォルトの Webhook が追加され、Topology ビューで選択したリソースのサイドパネルに URL が表示されます。

2.1.3. Developer パースペクティブを使用したパイプラインの使用

Developer パースペクティブの Pipelines ビューは、以下の詳細と共にプロジェクトのすべてのパイプラインをリスト表示します。

  • パイプラインが作成された namespace
  • 最後のパイプライン実行
  • パイプライン実行のタスクのステータス
  • パイプライン実行のステータス
  • 最後のパイプライン実行の作成時間

手順

  1. Developer パースペクティブの Pipelines ビューで、Project ドロップダウンリストからプロジェクトを選択し、そのプロジェクトのパイプラインを表示します。
  2. 必要なパイプラインをクリックし、Pipeline Details ページを表示します。

    デフォルトでは、Details タブには、すべてのシリアルタスク、並列タスク、finally タスク、およびパイプラインの式がすべて視覚的に表示されます。タスクと finally タスクは、ページの右下にリスト表示されます。リスト表示されている Tasks および Finally タスクをクリックして、タスクの詳細を表示します。

    図2.3 Pipeline の詳細

    Pipeline の詳細
  3. オプション: Pipeline details ページで、Metrics タブをクリックして、パイプラインに関する以下の情報を表示します。

    • Pipeline 成功比率
    • Pipeline Run の数
    • Pipeline Run の期間
    • Task Run Balancing

      この情報を使用して、パイプラインのワークフローを改善し、パイプラインのライフサイクルの初期段階で問題をなくすことができます。

  4. オプション: YAML タブをクリックし、パイプラインの YAML ファイルを編集します。
  5. オプション: Pipeline Runs タブをクリックして、パイプラインの完了済み、実行中、または失敗した実行を確認します。

    Pipeline Runs タブでは、パイプライン実行、タスクのステータス、および失敗したパイプライン実行のデバッグ用のリンクの詳細が表示されます。Options メニュー kebab を使用して、実行中のパイプラインを停止するか、以前のパイプライン実行と同じパラメーターとリソースを使用してパイプラインを再実行するか、パイプライン実行を削除します。

    • 必要なパイプラインをクリックし、Pipeline Run details ページを表示します。デフォルトでは、Details タブには、すべてのシリアルタスク、並列タスク、finally タスク、およびパイプライン実行の式がすべて視覚的に表示されます。実行に成功すると、ページ下部の Pipeline Run results ペインに表示されます。さらに、クラスターでサポートされている Tekton Hub からのタスクのみを表示できます。タスクを見ながら、その横にあるリンクをクリックして、タスクのドキュメントにジャンプできます。

      注記

      Pipeline Run Details ページの Details セクションには、失敗したパイプライン実行の Log Snippet (ログスニペット) が表示されます。Log Snippet (ログスニペット) は、一般的なエラーメッセージとログのスニペットを提供します。Logs セクションへのリンクでは、失敗した実行に関する詳細へのクイックアクセスを提供します。

    • Pipeline Run details ページで、Task Runs タブをクリックして、タスクの完了、実行、および失敗した実行を確認します。

      Task Runs タブは、タスク実行に関する情報と、そのタスクおよび Pod へのリンクと、タスク実行のステータスおよび期間を提供します。Options メニュー kebab を使用してタスク実行を削除します。

    • 必要なタスク実行をクリックして、Task Run details ページを表示します。実行に成功すると、ページ下部の Task Run results ペインに表示されます。

      注記

      Task Run details ページの Details セクションには、失敗したパイプライン実行の Log Snippet (ログスニペット) が表示されます。Log Snippet (ログスニペット) は、一般的なエラーメッセージとログのスニペットを提供します。Logs セクションへのリンクでは、失敗した実行に関する詳細へのクイックアクセスを提供します。

  6. Parameters タブをクリックして、パイプラインに定義されるパラメーターを表示します。必要に応じて追加のパラメーターを追加するか、編集することもできます。
  7. Resources タブをクリックして、パイプラインで定義されたリソースを表示します。必要に応じて関連情報を追加するか、編集することもできます。

2.1.4. Pipelines ビューからパイプラインを開始する

パイプラインの作成後に、これを開始し、これに含まれるタスクを定義されたシーケンスで実行できるようにする必要があります。パイプラインを Pipelines ビュー、Pipeline Details ページ、または Topology ビューから開始できます。

手順

Pipelines ビューを使用してパイプラインを開始するには、以下を実行します。

  1. Developer パースペクティブの Pipelines ビューで、パイプラインに隣接する Options kebab メニューで、Start を選択します。
  2. Start Pipeline ダイアログボックスは、パイプライン定義に基づいて Git Resources および Image Resources を表示します。

    注記

    From Git オプションを使用して作成されるパイプラインの場合、Start Pipeline ダイアログボックスでは Parameters セクションに APP_NAME フィールドも表示され、ダイアログボックスのすべてのフィールドがパイプラインテンプレートによって事前に入力されます。

    1. namespace にリソースがある場合、Git Resources および Image Resources フィールドがそれらのリソースで事前に設定されます。必要な場合は、ドロップダウンを使用して必要なリソースを選択または作成し、Pipeline Run インスタンスをカスタマイズします。
  3. オプション: Advanced Options を変更し、認証情報を追加して、指定されたプライベート Git サーバーまたはイメージレジストリーを認証します。

    1. Advanced OptionsShow Credentials Options をクリックし、Add Secret を選択します。
    2. Create Source Secret セクションで、以下を指定します。

      1. シークレットの一意の シークレット名
      2. Designated provider to be authenticated セクションで、Access to フィールドで認証されるプロバイダー、およびベース Server URL を指定します。
      3. Authentication Type を選択し、認証情報を指定します。

        • Authentication Type Image Registry Credentials については、認証する Registry Server Address を指定し、UsernamePassword、および Email フィールドに認証情報を指定します。

          追加の Registry Server Address を指定する必要がある場合は、Add Credentials を選択します。

        • Authentication Type Basic Authentication については、UserName および Password or Token フィールドの値を指定します。
        • Authentication Type SSH Keys については、SSH Private Key フィールドの値を指定します。

          注記

          Basic 認証および SSH 認証には、以下のようなアノテーションを使用できます。

      4. シークレットを追加するためにチェックマークを選択します。

    パイプラインのリソースの数に基づいて、複数のシークレットを追加できます。

  4. Start をクリックしてパイプラインを開始します。
  5. Pipeline Run Details ページには、実行されるパイプラインが表示されます。パイプラインが開始すると、タスクおよび各タスク内のステップが実行されます。以下を実行することができます。

    • 各ステップの実行にかかった時間を表示するには、タスクにカーソルを合わせます。
    • タスクをクリックし、タスクの各ステップのログを表示します。
    • Logs タブをクリックして、タスクの実行シーケンスに関連するログを表示します。該当するボタンを使用して、ペインをデプロイメントし、ログを個別に、または一括してダウンロードすることもできます。
    • Events タブをクリックして、パイプライン実行で生成されるイベントのストリームを表示します。

      Task RunsLogs、および Events タブを使用すると、失敗したパイプラインの実行またはタスクの実行のデバッグに役立ちます。

      図2.4 パイプライン実行の詳細

      パイプライン実行の詳細

2.1.5. Topology ビューからパイプラインを開始する

From Git オプションを使用して作成されるパイプラインの場合、Topology ビューを使用して、開始後のパイプラインと対話することができます。

注記

Topology ビューで Pipeline Builder を使用して作成されるパイプラインを表示するには、パイプラインのラベルをカスタマイズし、パイプラインをアプリケーションのワークロードにリンクします。

手順

  1. 左側のナビゲーションパネルで Topology をクリックします。
  2. アプリケーションをクリックして、サイドパネルに Pipeline Runs を表示します。
  3. Pipeline Runs で、Start Last Run をクリックして、前のパイプラインと同じパラメーターとリソースを使用して新しいパイプラインの実行を開始します。このオプションは、パイプライン実行が開始されていない場合は無効になります。パイプラインの作成時にパイプラインの実行を開始することもできます。

    図2.5 Topology ビューのパイプライン

    Topology ビューのパイプライン

Topology ページで、アプリケーションの左側にカーソルを合わせると、パイプライン実行のステータスが表示されます。パイプラインが追加された後、左下のアイコンは、関連付けられたパイプラインがあることを示します。

2.1.6. Topology ビューからのパイプラインとの対話

Topology ページのアプリケーションノードのサイドパネルには、パイプライン実行のステータスが表示され、対話することができます。

  • パイプラインの実行が自動的に開始されない場合、サイドパネルにパイプラインを自動的に開始できないというメッセージが表示されるため、手動で開始する必要があります。
  • パイプラインが作成されたが、ユーザーがパイプラインを開始していない場合、そのステータスは Not started になります。ユーザーが、Not started ステータスアイコンをクリックすると、Topology ビューに start ダイアログボックスが開きます。
  • パイプラインにビルドまたはビルド設定がない場合、Buildsセクションは表示されません。パイプラインとビルド設定がある場合は、Builds セクション が表示されます。
  • 特定のタスク実行でパイプライン実行が失敗すると、サイドパネルに Log Snippet が表示されます。Resources タブの Pipeline Runs セクションに Log Snippet を表示できます。これは、一般的なエラーメッセージとログのスニペットを提供します。Logs セクションへのリンクでは、失敗した実行に関する詳細へのクイックアクセスを提供します。

2.1.7. Pipeline の編集

Web コンソールの Developer パースペクティブを使用して、クラスター内のパイプラインを編集できます。

手順

  1. Developer パースペクティブの Pipelines ビューで、編集する必要のある Pipeline を選択し、Pipeline の詳細を表示します。Pipeline Details ページで Actions をクリックし、Edit Pipeline を選択します。
  2. パイプラインビルダー ページでは、次のタスクを実行できます。

    • 追加のタスク、パラメーター、またはリソースをパイプラインに追加します。
    • 変更するタスクをクリックして、サイドパネルにタスクの詳細を表示し、表示名、パラメーター、リソースなどの必要なタスクの詳細を変更します。
    • または、Task を削除するには、Task をクリックし、サイドパネルで Actions をクリックし、Remove Task を選択します。
  3. Save をクリックして変更された Pipeline を保存します。

2.1.8. Pipeline の削除

Web コンソールの Developer パースペクティブを使用して、クラスターの Pipeline を削除できます。

手順

  1. Developer パースペクティブの Pipelines ビューで、Pipeline に隣接する Options kebab メニューをクリックし、Delete Pipeline を選択します。
  2. Delete Pipeline 確認プロンプトで、Delete をクリックし、削除を確認します。

2.3. Administrator パースペクティブでパイプラインテンプレートを作成する

クラスター管理者は、開発者がクラスターでパイプラインを作成するときに再利用できるパイプラインテンプレートを作成できます。

前提条件

  • クラスター管理者権限で OpenShift Container Platform クラスターにアクセスでき、Administrator パースペクティブに切り替えている。
  • OpenShift Pipelines Operator がクラスターにインストールされている。

手順

  1. Pipelines ページに移動し、既存のパイプラインテンプレートを表示します。
  2. import icon アイコンをクリックして Import YAML ページに移動します。
  3. パイプラインテンプレートの YAML を追加します。テンプレートには、以下の情報が含まれている必要があります。

    apiVersion: tekton.dev/v1beta1
    kind: Pipeline
    metadata:
    # ...
      namespace: openshift 
    1
    
      labels:
        pipeline.openshift.io/runtime: <runtime> 
    2
    
        pipeline.openshift.io/type: <pipeline-type> 
    3
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    テンプレートは openshift namespace に作成する必要があります。
    2
    テンプレートには pipeline.openshift.io/runtime ラベルが含まれている必要があります。このラベルで許可されるランタイム値は、nodejsgolangdotnetjavaphprubyperlpythonnginx、および httpd です。
    3
    テンプレートには、pipeline.openshift.io/type: ラベルが含まれている必要があります。このラベルで許可されるタイプ値は、openshiftknative、および kubernetes です。
  4. Create をクリックします。パイプラインを作成すると、Pipeline details ページが表示されます。ここでは、Pipeline 情報の表示や編集が可能です。

クラスター管理者は、Red Hat OpenShift Pipelines Operator をインストールすると、バージョン付けされたクラスタータスク(VCT) およびバージョン付けされていないクラスタータスク (NVCT) として知られるそれぞれのデフォルトクラスタータスクのバリアントが作成されます。たとえば、Red Hat OpenShift Pipelines Operator v1.7 をインストールすると、buildah-1-7-0 VCT および buildah NVCT が作成されます。

NVCT と VCT の両方は、paramsworkspaces、および steps など、同じメタデータ、動作、仕様を持ちます。ただし、それらを無効にするか、Operator をアップグレードすると、動作が異なります。

重要

Red Hat OpenShift Pipelines 1.10 では、クラスタータスク機能は非推奨であり、将来のリリースで削除される予定です。

バージョン付けされていないクラスタータスクとバージョン付けされたクラスタータスクでは、命名規則が異なります。また、Red Hat OpenShift Pipelines Operator はそれらを異なる方法でアップグレードします。

Expand
表3.1 バージョン付けされていないクラスタータスクとバージョン付けされたクラスタータスクの違い
 バージョン付けされていないクラスタータスクバージョン付けされたクラスタータスク

命名法

NVCT には、クラスタータスクの名前のみが含まれます。たとえば、Operator v1.7 でインストールされた Buildah の NVCT の名前は buildah です。

VCT には、クラスタータスクの名前の後にバージョンが接尾辞として含まれます。たとえば、Operator v1.7 でインストールされた Buildah の VCT の名前は buildah-1-7-0 です。

アップグレード

Operator をアップグレードすると、最新の変更でバージョン付けされていないクラスタータスクを更新します。NVCT の名前は変更されません。

Operator をアップグレードすると、最新バージョンの VCT をインストールし、以前のバージョンを保持します。VCT の最新バージョンは、アップグレードされた Operator に対応します。たとえば、Operator 1.7 をインストールすると buildah-1-7-0 がインストールされ、buildah-1-6-0 は保持されます。

バージョン付けされていないクラスタータスクまたはバージョン付けされたクラスタータスクを実稼働環境で標準として導入する前に、クラスター管理者はその長所と短所を検討する場合があります。

Expand
表3.2 バージョン付けされていないクラスタータスクとバージョン付けされたクラスタータスクの長所と短所
クラスタータスクメリットデメリット

バージョン付けされていないクラスタータスク (NVCT)

  • 最新の更新およびバグ修正でパイプラインをデプロイする場合は、NVCT を使用します。
  • Operator をアップグレードすると、バージョン付けされていないクラスタータスクがアップグレードされます。これは、複数のバージョン付けされたクラスタータスクよりも少ないリソースを消費します。

NVCT を使用するパイプラインをデプロイする場合、自動的にアップグレードされたクラスタータスクが後方互換性を持たない場合、Operator のアップグレード後にそれらが破損する可能性があります。

バージョン付けされたクラスタータスク (VCT)

  • 実稼働で安定したパイプラインが重要視される場合は、VCT を使用します。
  • 新しいバージョンのクラスタータスクがインストールされた後でも、以前のバージョンはクラスターで保持されます。以前のクラスタータスクを引き続き使用できます。
  • 以前のバージョンのクラスタータスクを引き続き使用する場合は、最新の機能と重要なセキュリティー更新が欠落している可能性があります。
  • 動作していない以前のバージョンのクラスタータスクがクラスターリソースを消費します。
  • * アップグレード後に、Operator は以前の VCT を管理できません。oc delete clustertask コマンドを使用して、以前の VCT を手動で削除できますが、復元することはできません。

クラスター管理者は、OpenShift Pipeline Operator がインストールしたクラスタータスクを無効にできます。

手順

  1. バージョン付けされていないクラスタータスクおよび最新のバージョン付けされたクラスタータスクをすべて削除するには、TektonConfig カスタムリソース定義 (CRD) を編集し、spec.addon.paramsclusterTasks パラメーターを false に設定します。

    TektonConfig CR の例

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonConfig
    metadata:
      name: config
    spec:
      params:
      - name: createRbacResource
        value: "false"
      profile: all
      targetNamespace: openshift-pipelines
      addon:
        params:
        - name: clusterTasks
          value: "false"
    ...
    Copy to Clipboard Toggle word wrap

    クラスタータスクを無効にすると、Operator はすべてのバージョン付けされていないクラスタータスクおよび最新バージョンのバージョン付けされたクラスタータスクだけをクラスターから削除します。

    注記

    クラスタータスクを再度有効にすると、バージョン付けされていないクラスタータスクがインストールされます。

  2. オプション: バージョン付けされたクラスタータスクの以前のバージョンを削除するには、以下のいずれかの方法を使用します。

    1. 以前のバージョン付けされたクラスタータスクを個別に削除するには、oc delete clustertask コマンドの後にバージョン付けされたクラスタータスクの名前を使用します。以下に例を示します。

      $ oc delete clustertask buildah-1-6-0
      Copy to Clipboard Toggle word wrap
    2. 以前のバージョンの Operator によって作成されたバージョン付けされたクラスタータスクをすべて削除するには、対応するインストーラーセットを削除できます。以下に例を示します。

      $ oc delete tektoninstallerset versioned-clustertask-1-6-k98as
      Copy to Clipboard Toggle word wrap
      Important

      古いバージョン付けされたクラスタータスクを削除する場合は、これを復元できません。Operator の現行バージョンが作成したバージョン付けされたクラスタータスクおよびバージョン付けされていないクラスタータスクのみを復元できます。

法律上の通知

Copyright © 2023 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

© 2026 Red Hat
トップに戻る