3.5. 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 タスク。

3.5.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 リポジトリーのクローンを作成している。

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

手順

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

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

    $ oc new-project pipelines-tutorial
    注記

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

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

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

    $ oc get serviceaccount pipeline

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

手順

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

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.9/01_pipeline/01_apply_manifest_task.yaml
    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.9/01_pipeline/02_update_deployment_task.yaml
  2. tkn task list コマンドを使用して、作成したタスクを一覧表示します。

    $ tkn task list

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

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

    注記

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

    $ tkn clustertasks list

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

    NAME                       DESCRIPTION   AGE
    buildah                                  1 day ago
    git-clone                                1 day ago
    s2i-python                               1 day ago
    tkn                                      1 day ago
重要

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

3.5.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.9"
      - 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

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

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

    $ oc create -f <pipeline-yaml-file-name.yaml>

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

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

    $ tkn pipeline list

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

    NAME               AGE            LAST RUN   STARTED   DURATION   STATUS
    build-and-deploy   1 minute ago   ---        ---       ---        ---

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

      出力例

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

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

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

      $ oc tag <mirror-registry>:<port>/ubi8/python-38 python:latest --scheduled -n openshift

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

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

      $ oc describe imagestream python -n openshift

      出力例

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

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

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

      $ oc describe imagestream golang -n openshift

      出力例

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

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

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

      $ oc tag <mirror-registry>:<port>/ubi8/go-toolset golang:latest --scheduled -n openshift

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

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

      $ oc describe imagestream golang -n openshift

      出力例

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

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

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

      $ oc describe imagestream cli -n openshift

      出力例

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

    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
    3. イメージをインポートします。

      $ oc tag <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev cli:latest --scheduled -n openshift

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

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

      $ oc describe imagestream cli -n openshift

      出力例

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

3.5.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.9/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/$(context.pipelineRun.namespace)/pipelines-vote-api' \
        --use-param-defaults

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

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

    $ tkn pipelinerun logs <pipelinerun_id> -f

    上記のコマンドの <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.9/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/$(context.pipelineRun.namespace)/pipelines-vote-ui' \
        --use-param-defaults
  4. パイプライン実行の進捗を追跡するには、以下のコマンドを入力します。

    $ tkn pipelinerun logs <pipelinerun_id> -f

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

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

    $ tkn pipelinerun list

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

     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
  6. アプリケーションルートを取得します。

    $ oc get route pipelines-vote-ui --template='http://{{.spec.host}}'

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

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

    $ tkn pipeline start build-and-deploy --last

3.5.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)
  2. TriggerBinding リソースを作成します。

    $ oc create -f <triggerbinding-yaml-file-name.yaml>

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

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.9/03_triggers/01_binding.yaml
  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.9
      - 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/$(context.pipelineRun.namespace)/$(tt.params.git-repo-name)
          workspaces:
          - name: shared-workspace
            volumeClaimTemplate:
              spec:
                accessModes:
                  - ReadWriteOnce
                resources:
                  requests:
                    storage: 500Mi

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

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

    $ oc create -f <triggertemplate-yaml-file-name.yaml>

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

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.9/03_triggers/02_template.yaml
  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
  6. Trigger リソースを作成します。

    $ oc create -f <trigger-yaml-file-name.yaml>

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

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

    apiVersion: triggers.tekton.dev/v1beta1
    kind: EventListener
    metadata:
      name: vote-app
    spec:
      serviceAccountName: pipeline
      triggers:
        - triggerRef: vote-trigger

    または、トリガーカスタムリソースを定義していない場合は、トリガーの名前を参照する代わりに、バインディングおよびテンプレート仕様を 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
  8. 以下のコマンドを実行して EventListener リソースを作成します。

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

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

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

        $ oc create -f <eventlistener-yaml-file-name.yaml>

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

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

        $ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>

        または、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-----

        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

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

注記

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

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

手順

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

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

      ServiceAccount.yaml の例

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: el-sa
      ---

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

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

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

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

    ServiceAccount.yaml の例

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: foo-trigger-sa
      namespace: foo
    ...

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

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

3.5.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}}')"
    • HTTP (非セキュアな) 接続の場合:

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

      出力で取得した 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 を繰り返します。

3.5.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.9
  2. 空のコミットをプッシュします。

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

    $ tkn pipelinerun list

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

3.5.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
    ...
  2. リクエストをイベントリスナーに送信して、サービスモニターをテストします。たとえば、空のコミットをプッシュします。

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

3.5.12. GitHub Interceptor でのプルリクエスト機能の設定

GitHub Interceptor を使用すると、GitHub Webhook を検証およびフィルタリングするロジックを作成できます。たとえば、Webhook の発信元を検証し、指定された基準に基づいて着信イベントをフィルター処理できます。GitHub Interceptor を使用してイベントデータをフィルタリングする場合、Interceptor がフィールドで受け入れることができるイベントタイプを指定できます。Red Hat OpenShift Pipelines では、GitHub Interceptor の以下の機能を使用できます。

  • 変更されたファイルに基づいてプルリクエストイベントをフィルタリングする
  • 設定された GitHub 所有者に基づいてプルリクエストを検証する

3.5.12.1. GitHub Interceptor を使用したプルリクエストのフィルタリング

プッシュおよびプルイベント用に変更されたファイルに基づいて、GitHub イベントをフィルター処理できます。これは、Git リポジトリー内の関連する変更のみに対してパイプラインを実行するのに役立ちます。GitHub Interceptor は、変更されたすべてのファイルのコンマ区切りリストを追加し、CEL Interceptor を使用して、変更されたファイルに基づいて着信イベントをフィルタリングします。変更されたファイルのリストは、最上位の extensions フィールドのイベントペイロードの changed_files がプロパティーに追加されます。

前提条件

  • Red Hat OpenShift Pipelines Operator がインストールされている。

手順

  1. 以下のいずれかの手順を実行します。

    • パブリック GitHub リポジトリーの場合、以下に示す YAML 設定ファイルで addChangedFiles パラメーターの値を true に設定します。

      apiVersion: triggers.tekton.dev/v1beta1
      kind: EventListener
      metadata:
        name: github-add-changed-files-pr-listener
      spec:
        triggers:
          - name: github-listener
            interceptors:
              - ref:
                  name: "github"
                  kind: ClusterInterceptor
                  apiVersion: triggers.tekton.dev
                params:
                - name: "secretRef"
                  value:
                    secretName: github-secret
                    secretKey: secretToken
                - name: "eventTypes"
                  value: ["pull_request", "push"]
                - name: "addChangedFiles"
                  value:
                    enabled: true
              - ref:
                  name: cel
                params:
                - name: filter
                  value: extensions.changed_files.matches('controllers/')
      ...
    • プライベート GitHub リポジトリーの場合、addChangedFiles パラメーターの値を true に設定し、以下に示す YAML 設定ファイルでアクセストークンの詳細、secretName、および secretKey を指定します。

      apiVersion: triggers.tekton.dev/v1beta1
      kind: EventListener
      metadata:
        name: github-add-changed-files-pr-listener
      spec:
        triggers:
          - name: github-listener
            interceptors:
              - ref:
                  name: "github"
                  kind: ClusterInterceptor
                  apiVersion: triggers.tekton.dev
                params:
                - name: "secretRef"
                  value:
                    secretName: github-secret
                    secretKey: secretToken
                - name: "eventTypes"
                  value: ["pull_request", "push"]
                - name: "addChangedFiles"
                  value:
                    enabled: true
                    personalAccessToken:
                      secretName: github-pat
                      secretKey: token
              - ref:
                  name: cel
                params:
                - name: filter
                  value: extensions.changed_files.matches('controllers/')
      ...
  2. 設定ファイルを作成します。

3.5.12.2. GitHub Interceptors を使用したプルリクエストの検証

GitHub Interceptor を使用して、リポジトリー用に設定された GitHub 所有者に基づいてプルリクエストの処理を検証できます。この検証は、PipelineRun または TaskRun オブジェクトの不要な実行を防ぐのに役立ちます。GitHub Interceptor は、ユーザー名が所有者としてリストされている場合、または設定可能なコメントがリポジトリーの所有者によって発行された場合にのみ、プルリクエストを処理します。たとえば、所有者としてプルリクエストで /ok-to-test にコメントすると、PipelineRun または TaskRun がトリガーされます。

注記

所有者は、リポジトリーのルートにある OWNERS ファイルで設定されます。

前提条件

  • Red Hat OpenShift Pipelines Operator がインストールされている。

手順

  1. シークレットの文字列値を作成します。
  2. その値で GitHub webhook を設定します。
  3. シークレット値を含む secretRef という名前の Kubernetes シークレットを作成します。
  4. Kubernetes シークレットを GitHub Interceptor への参照として渡します。
  5. owners ファイルを作成し、承認者のリストを approvers セクションに追加します。
  6. 以下のいずれかの手順を実行します。

    • パブリック GitHub リポジトリーの場合、以下に示す YAML 設定ファイルで githubOwners パラメーターの値を true に設定します。

      apiVersion: triggers.tekton.dev/v1beta1
      kind: EventListener
      metadata:
        name: github-owners-listener
      spec:
        triggers:
          - name: github-listener
            interceptors:
              - ref:
                  name: "github"
                  kind: ClusterInterceptor
                  apiVersion: triggers.tekton.dev
                params:
                  - name: "secretRef"
                    value:
                      secretName: github-secret
                      secretKey: secretToken
                  - name: "eventTypes"
                    value: ["pull_request", "issue_comment"]
                  - name: "githubOwners"
                    value:
                      enabled: true
                      checkType: none
      ...
    • プライベート GitHub リポジトリーの場合、githubOwners パラメーターの値を true に設定し、以下に示す YAML 設定ファイルでアクセストークンの詳細、secretName、および secretKey を指定します。

      apiVersion: triggers.tekton.dev/v1beta1
      kind: EventListener
      metadata:
        name: github-owners-listener
      spec:
        triggers:
          - name: github-listener
            interceptors:
              - ref:
                  name: "github"
                  kind: ClusterInterceptor
                  apiVersion: triggers.tekton.dev
                params:
                  - name: "secretRef"
                    value:
                      secretName: github-secret
                      secretKey: secretToken
                  - name: "eventTypes"
                    value: ["pull_request", "issue_comment"]
                  - name: "githubOwners"
                    value:
                      enabled: true
                      personalAccessToken:
                        secretName: github-token
                        secretKey: secretToken
                      checkType: all
      ...
      注記

      checkType パラメーターは、認証が必要な GitHub 所有者を指定するために使用されます。その値を orgMembersrepoMembers、または all に設定できます。

  7. 設定ファイルを作成します。

3.5.13. 関連情報

  • Pipelines as Code とアプリケーションソースコードを同一レポジトリーに格納するには、Pipelines as Code の使用 を参照してください。
  • Developer パースペクティブのパイプラインについての詳細は、working with pipelines in the Developer perspective セクションを参照してください。
  • SCC (Security Context Constraints) の詳細は、Managing Security Context Constraints セクションを参照してください。
  • 再利用可能なタスクの追加の例については、OpenShift Catalog リポジトリーを参照してください。さらに、Tekton プロジェクトで Tekton Catalog を参照することもできます。
  • 再利用可能なタスクとパイプライン用に Tekton Hub のカスタムインスタンスをインストールしてデプロイするには、Red Hat OpenShift Pipeline での Tekton Hub の使用 を参照してください。
  • re-encrypt TLS 終端の詳細は、再暗号化終端 を参照してください。
  • セキュリティー保護されたルートについての詳細は、Secured routes セクションを参照してください。