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

手順

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

手順

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

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/01_pipeline/01_apply_manifest_task.yaml
   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/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

手順

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.11"
     - 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.11/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   ---        ---       ---        ---

手順

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

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

      $ oc describe imagestream python -n openshift

      出力例

      Name:			python
      Namespace:		openshift
      [...]
      
      3.8-ubi9 (latest)
        tagged from registry.redhat.io/ubi9/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/ubi9/python-39:latest <mirror-registry>:<port>/ubi9/python-39

   3. イメージをインポートします。

      $ oc tag <mirror-registry>:<port>/ubi9/python-39 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>/ubi9/python-39
      
        *  <mirror-registry>:<port>/ubi9/python-39@sha256:3ee...
      
      [...]

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/ubi9/go-toolset:latest <mirror-registry>:<port>/ubi9/go-toolset

   3. イメージをインポートします。

      $ oc tag <mirror-registry>:<port>/ubi9/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>/ubi9/go-toolset
      
        * <mirror-registry>:<port>/ubi9/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
      
      [...]

手順

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

   $ tkn pipeline start build-and-deploy \
       -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/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.11/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

手順

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

手順

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

手順

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. Settings → Webhooks → Add 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. ターミナルから、フォークした Git リポジトリー pipelines-vote-ui のクローンを作成します。

   $ git clone git@github.com:<your GitHub ID>/pipelines-vote-ui.git -b pipelines-1.11

2. 空のコミットをプッシュします。

   $ git commit -m "empty-commit" --allow-empty && git push origin pipelines-1.11

3. パイプライン実行がトリガーされたかどうかを確認します。

   $ tkn pipelinerun list

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

手順

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 コンソールで、Administrator → Observe → Metrics の順に移動します。
4. メトリクスを表示するには、名前で検索します。たとえば、github-listener イベントリスナーの eventlistener_http_resources メトリクスの詳細を表示するには、eventlistener_http_resources のキーワードを使用して検索します。