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.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-manifest 및 update-deployment 작업 리소스가 생성된 것이 출력에서 확인됩니다.

   NAME                DESCRIPTION   AGE
   apply-manifests                   1 minute ago
   update-deployment                 48 seconds ago

3. tkn clustertasks list 명령을 사용하여 Operator에서 설치한 추가 클러스터 작업 목록을 표시합니다(예: buildah 및 s2i-python-3).

   참고

   제한된 환경에서 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.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   ---        ---       ---        ---

프로세스

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

프로세스

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

   위 명령은 파이프라인 실행을 위한 영구 볼륨 클레임을 생성하는 볼륨 클레임 템플릿을 사용합니다.

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

프로세스

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>

   또는 pipelines-tutorial Git 리포지토리에서 직접 TriggerBinding 리소스를 생성할 수 있습니다.

   $ 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

   템플릿은 작업 영역의 스토리지 볼륨을 정의하기 위해 영구 볼륨 클레임을 생성하는 볼륨 클레임 템플릿을 지정합니다. 따라서 데이터 스토리지를 제공하기 위해 영구 볼륨 클레임을 생성할 필요가 없습니다.

4. TriggerTemplate 리소스를 생성합니다.

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

   또는 pipelines-tutorial Git 리포지토리에서 직접 TriggerTemplate 리소스를 생성할 수도 있습니다.

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

   또는 pipelines-tutorial Git 리포지토리에서 직접 Trigger 리소스를 생성할 수도 있습니다.

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

        또는 pipelines-tutorial Git 리포지토리에서 직접 EvenListener 리소스를 생성할 수도 있습니다.

        $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.9/03_triggers/04_event_listener.yaml

     3. 재암호화 TLS 종료로 경로를 생성합니다.

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

        또는 재암호화 TLS 종료 YAML 파일을 만들어 보안 경로를 만들 수도 있습니다.

        보안 경로의 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는 엔드포인트 인증서의 유효성을 검사하고 라우터에서 대상 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 매개변수를 채웁니다.

   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 Webhook Webhook 추가를 클릭합니다.

   3. Webhooks/Add Webhook 페이지에서:

      1. Payload URL 필드에 1단계의 Webhook 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.9

2. 비어 있는 커밋을 푸시합니다.

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

3. 파이프라인 실행이 트리거되었는지 확인합니다.

   $ tkn pipelinerun list

   새로운 파이프라인 실행이 시작되었습니다.

절차

1. 각 이벤트 리스너에 대해 서비스 모니터를 생성합니다. 예를 들어 테스트 네임스페이스에서 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 웹 콘솔에서 Administrator Observe Metrics 로 이동합니다.
4. 지표를 보려면 이름으로 검색합니다. 예를 들어 github-listener 이벤트 리스너에 대한 eventlistener_http_resources 지표의 세부 정보를 보려면 eventlistener_http_resources 키워드를 사용하여 검색합니다.