1. 작업 디렉터리가 구성되고 모든 입력 콘텐츠가 작업 디렉터리에 배치됩니다. 예를 들어 입력 Git 리포지토리가 작업 디렉터리에 복제되고 입력 이미지에서 지정된 파일이 타겟 경로를 사용하여 작업 디렉터리에 복사됩니다.
2. 빌드 프로세스에서는 contextDir이 정의된 경우 디렉터리를 해당 디렉터리로 변경합니다.
3. 인라인 Dockerfile(있는 경우)은 현재 디렉터리에 기록됩니다.
4. 현재 디렉터리의 콘텐츠는 Dockerfile, 사용자 지정 빌더 논리 또는 assemble 스크립트에서 참조할 수 있도록 빌드 프로세스에 제공됩니다. 즉 contextDir 외부에 있는 모든 입력 콘텐츠는 빌드에서 무시합니다.

1. 미러의 URL 및 연결 설정으로 구성된 settings.xml 파일
2. 설정 파일에서 참조하는 개인 키(예: ~/.ssh/id_rsa)

프로세스

1. 로컬 .docker/config.json 파일에서 보안을 생성합니다.

   $ oc create secret generic dockerhub \
       --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
       --type=kubernetes.io/dockerconfigjson

   이 명령은 dockerhub라는 보안의 JSON 사양을 생성한 후 오브젝트를 생성합니다.

2. BuildConfig의 output 섹션에 pushSecret 필드를 추가하고 생성한 secret 이름(위 예의 경우 dockerhub)으로 설정합니다.

   spec:
     output:
       to:
         kind: "DockerImage"
         name: "private.registry.com/org/private-image:latest"
       pushSecret:
         name: "dockerhub"

   oc set build-secret 명령을 사용하여 빌드 구성에 내보내기 보안을 설정할 수 있습니다.

   $ oc set build-secret --push bc/sample-build dockerhub

   pushSecret 필드를 지정하는 대신 빌드에서 사용하는 서비스 계정에 내보내기 보안을 연결할 수도 있습니다. 기본적으로 빌드에서는 builder 서비스 계정을 사용합니다. 보안에 빌드의 출력 이미지를 호스팅하는 리포지토리와 일치하는 자격 증명이 포함된 경우 내보내기 보안이 빌드에 자동으로 추가됩니다.

   $ oc secrets link builder dockerhub

3. 빌드 전략 정의의 일부인 pullSecret 필드를 지정하여 개인 컨테이너 이미지 레지스트리에서 빌더 컨테이너 이미지를 가져옵니다.

   strategy:
     sourceStrategy:
       from:
         kind: "DockerImage"
         name: "docker.io/user/private_repository"
       pullSecret:
         name: "dockerhub"

   oc set build-secret 명령을 사용하여 빌드 구성에 가져오기 보안을 설정할 수 있습니다.

   $ oc set build-secret --pull bc/sample-build dockerhub

   참고

   이 예제에서는 소스 빌드에 pullSecret을 사용하지만 Docker 및 Custom 빌드에도 적용할 수 있습니다.

   pullSecret 필드를 지정하는 대신 빌드에서 사용하는 서비스 계정에 가져오기 보안을 연결할 수도 있습니다. 기본적으로 빌드에서는 builder 서비스 계정을 사용합니다. 보안에 빌드의 입력 이미지를 호스팅하는 리포지토리와 일치하는 자격 증명이 포함된 경우 가져오기 보안이 빌드에 자동으로 추가됩니다. pullSecret 필드를 지정하는 대신 빌드에서 사용하는 서비스 계정에 가져오기 보안을 연결하려면 다음을 실행합니다.

   $ oc secrets link builder dockerhub

   참고

   이 기능을 사용하려면 BuildConfig 사양에 from 이미지를 지정해야 합니다. oc new-build 또는 oc new-app으로 생성한 Docker 전략 빌드는 특정 상황에서 이러한 작업을 수행하지 못할 수 있습니다.

1. 새 OpenShift Container Platform 프로젝트를 생성합니다.
2. 개인 소스 코드 리포지토리에 액세스하는 데 필요한 자격 증명이 포함된 보안을 생성합니다.
3. 빌드 구성을 생성합니다.
4. 빌드 구성 편집기 페이지 또는 웹 콘솔의 빌더 이미지에서 앱 생성 페이지에서 소스 보안을 설정합니다.
5. 저장을 클릭합니다.

프로세스

1. 빈 디렉터리에서부터 다음 콘텐츠를 사용하여 Dockerfile이라는 파일을 생성합니다.

   FROM registry.redhat.io/rhel8/buildah
   # In this example, `/tmp/build` contains the inputs that build when this
   # custom builder image is run. Normally the custom builder image fetches
   # this content from some location at build time, by using git clone as an example.
   ADD dockerfile.sample /tmp/input/Dockerfile
   ADD build.sh /usr/bin
   RUN chmod a+x /usr/bin/build.sh
   # /usr/bin/build.sh contains the actual custom build logic that will be run when
   # this custom builder image is run.
   ENTRYPOINT ["/usr/bin/build.sh"]

2. 동일한 디렉터리에서 dockerfile.sample이라는 파일을 생성합니다. 이 파일은 사용자 정의 빌드 이미지에 포함되어 있으며 사용자 정의 빌드에서 생성하는 이미지를 정의합니다.

   FROM registry.access.redhat.com/ubi8/ubi
   RUN touch /tmp/build

3. 동일한 디렉터리에 build.sh라는 파일을 생성합니다. 이 파일에는 사용자 정의 빌드가 실행될 때 실행되는 논리가 포함되어 있습니다.

   #!/bin/sh
   # Note that in this case the build inputs are part of the custom builder image, but normally this
   # is retrieved from an external source.
   cd /tmp/input
   # OUTPUT_REGISTRY and OUTPUT_IMAGE are env variables provided by the custom
   # build framework
   TAG="${OUTPUT_REGISTRY}/${OUTPUT_IMAGE}"
   
   
   # performs the build of the new image defined by dockerfile.sample
   buildah --storage-driver vfs bud --isolation chroot -t ${TAG} .
   
   
   # buildah requires a slight modification to the push secret provided by the service
   # account to use it for pushing the image
   cp /var/run/secrets/openshift.io/push/.dockercfg /tmp
   (echo "{ \"auths\": " ; cat /var/run/secrets/openshift.io/push/.dockercfg ; echo "}") > /tmp/.dockercfg
   
   
   # push the new image to the target for the build
   buildah --storage-driver vfs push --tls-verify=false --authfile /tmp/.dockercfg ${TAG}

프로세스

1. 사용자 정의 빌더 이미지를 빌드할 BuildConfig 오브젝트를 정의합니다.

   $ oc new-build --binary --strategy=docker --name custom-builder-image

2. 사용자 정의 빌드 이미지를 생성한 디렉터리에서 빌드를 실행합니다.

   $ oc start-build custom-builder-image --from-dir . -F

   빌드가 완료되면 custom-builder-image:latest라는 이미지 스트림 태그의 프로젝트에서 새 사용자 정의 빌더 이미지를 사용할 수 있습니다.

프로세스

1. buildconfig.yaml이라는 파일을 생성합니다. 이 파일은 프로젝트에서 생성되어 실행되는 BuildConfig 오브젝트를 정의합니다.

   kind: BuildConfig
   apiVersion: build.openshift.io/v1
   metadata:
     name: sample-custom-build
     labels:
       name: sample-custom-build
     annotations:
       template.alpha.openshift.io/wait-for-ready: 'true'
   spec:
     strategy:
       type: Custom
       customStrategy:
         forcePull: true
         from:
           kind: ImageStreamTag
           name: custom-builder-image:latest
           namespace: <yourproject> 1
     output:
       to:
         kind: ImageStreamTag
         name: sample-custom:latest

   1

   프로젝트 이름을 지정합니다.

2. BuildConfig를 생성합니다.

   $ oc create -f buildconfig.yaml

3. imagestream.yaml이라는 파일을 생성합니다. 이 파일은 빌드에서 이미지를 내보낼 이미지 스트림을 정의합니다.

   kind: ImageStream
   apiVersion: image.openshift.io/v1
   metadata:
     name: sample-custom
   spec: {}

4. 이미지 스트림을 생성합니다.

   $ oc create -f imagestream.yaml

5. 사용자 정의 빌드를 실행합니다.

   $ oc start-build sample-custom-build -F

   빌드를 실행하면 빌드에서 이전에 빌드한 사용자 정의 빌더 이미지를 실행하는 Pod를 시작합니다. Pod는 사용자 정의 빌더 이미지의 진입점으로 정의된 build.sh 논리를 실행합니다. build.sh 논리는 Buildah를 호출하여 사용자 정의 빌더 이미지에 포함된 dockerfile.sample을 빌드한 다음 Buildah를 사용하여 새 이미지를 sample-custom image stream으로 내보냅니다.

프로세스

1. BuildConfig의 successfulBuildsHistoryLimit 또는 failedBuildsHistoryLimit에 양의 정수 값을 제공하여 유지되는 이전 빌드의 수를 제한합니다. 예를 들면 다음과 같습니다.

   apiVersion: "v1"
   kind: "BuildConfig"
   metadata:
     name: "sample-build"
   spec:
     successfulBuildsHistoryLimit: 2 1
     failedBuildsHistoryLimit: 2 2

   1

   successfulBuildsHistoryLimit은 completed 상태의 빌드를 두 개까지 유지합니다.

   2

   failedBuildsHistoryLimit은 failed, canceled 또는 error 상태의 빌드를 두 개까지 유지합니다.

2. 다음 작업 중 하나로 빌드 정리를 트리거합니다.

   • 빌드 구성 업데이트
   • 빌드가 라이프사이클을 완료할 때까지 대기

프로세스

1. 자격이 포함된 보안을 생성하여 공개 및 개인 키가 포함된 별도의 파일이 있는지 확인합니다.

   $  oc create secret generic etc-pki-entitlement --from-file /path/to/entitlement/{ID}.pem \
   > --from-file /path/to/entitlement/{ID}-key.pem ...

2. 빌드 구성에 빌드 입력으로 보안을 추가합니다.

   source:
     secrets:
     - secret:
         name: etc-pki-entitlement
       destinationDir: etc-pki-entitlement

프로세스

1. rbac.authorization.kubernetes.io/autoupdate 주석을 적용합니다.

   $ oc edit clusterrolebinding system:build-strategy-docker-binding

   출력 예

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     annotations:
       rbac.authorization.kubernetes.io/autoupdate: "false" 1
     creationTimestamp: 2018-08-10T01:24:14Z
     name: system:build-strategy-docker-binding
     resourceVersion: "225"
     selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding
     uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bf
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: system:build-strategy-docker
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated

   1

   rbac.authorization.kubernetes.io/autoupdate 주석 값을 "false"로 변경합니다.

2. 역할을 제거합니다.

   $ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated

3. 빌드 전략 하위 소스도 이러한 역할에서 제거되었는지 확인합니다.

   $ oc edit clusterrole admin

   $ oc edit clusterrole edit

4. 각 역할에 대해 비활성화할 전략 리소스에 해당하는 하위 리소스를 지정합니다.

   1. admin에 대한 Docker 빌드 전략을 비활성화합니다.

      kind: ClusterRole
      metadata:
        name: admin
      ...
      - apiGroups:
        - ""
        - build.openshift.io
        resources:
        - buildconfigs
        - buildconfigs/webhooks
        - builds/custom 1
        - builds/source
        verbs:
        - create
        - delete
        - deletecollection
        - get
        - list
        - patch
        - update
        - watch
      ...

      1

      빌드/사용자 지정 및 빌드/소스 를 추가하여 admin 역할이 있는 사용자에 대해 Docker 빌드를 전역적으로 비활성화합니다.

절차

1. 자체 서명 인증서를 사용하는 레지스트리의 경우 신뢰할 수 있는 인증서가 있는 openshift-config 네임스페이스에 ConfigMap을 생성합니다. 각 CA 파일에 대해 ConfigMap의 키가 hostname[..port] 형식의 레지스트리 호스트 이름인지 확인하십시오.

   $ oc create configmap registry-cas -n openshift-config \
   --from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \
   --from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt

2. 클러스터 이미지 구성을 업데이트합니다.

   $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge

절차

1. 웹 콘솔의 관리자 화면에서 Operator → OperatorHub로 이동합니다.
2. 키워드로 필터링 박스를 사용하여 카탈로그에서 Red Hat OpenShift Pipelines Operator를 검색합니다. Red Hat OpenShift Pipelines Operator 타일을 클릭합니다.
3. Red Hat OpenShift Pipelines Operator 페이지에서 Operator에 대한 간략한 설명을 확인합니다. 설치를 클릭합니다.

4. Operator 설치 페이지에서 다음을 수행합니다.

   1. Installation Mode로 All namespaces on the cluste(default)를 선택합니다. 이 모드에서는 기본 openshift-operators 네임스페이스에 Operator가 설치되므로 Operator가 클러스터의 모든 네임스페이스를 감시하고 사용 가능하게 만들 수 있습니다.
   2. Approval Strategy으로 Automatic을 선택합니다. 그러면 Operator에 향후 지원되는 업그레이드가 OLM(Operator Lifecycle Manager)에 의해 자동으로 처리됩니다. Manual 승인 전략을 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.

   3. Update Channel을 선택합니다.

      • stable 채널을 사용하면 Red Hat OpenShift Pipelines Operator의 안정적인 최신 릴리스를 설치할 수 있습니다.
      • preview 채널을 사용하면 Red Hat OpenShift Pipelines Operator의 최신 프리뷰 버전을 설치할 수 있습니다. 이 버전에는 stable 채널에서 아직 지원되지 않는 기능이 포함될 수 있습니다.

5. 설치를 클릭합니다. Installed Operators 페이지의 목록에 해당 Operator가 나타납니다.

   참고

   Operator는 openshift-operators 네임스페이스에 자동으로 설치됩니다.

6. Red Hat OpenShift Pipelines Operator가 성공적으로 설치되었는지 확인하려면 상태가 최신 업데이트 완료로 설정되어 있는지 확인합니다.

프로세스

1. 서브스크립션 오브젝트 YAML 파일을 생성하여 Red Hat OpenShift Pipelines Operator에 네임스페이스를 서브스크립션합니다(예: sub.yaml).

   Subscription의 예

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-pipelines-operator
     namespace: openshift-operators
   spec:
     channel:  <channel name> 1
     name: openshift-pipelines-operator-rh 2
     source: redhat-operators 3
     sourceNamespace: openshift-marketplace 4

   1

   Operator를 서브스크립션할 채널 이름을 지정합니다.

   2

   서브스크립션할 Operator의 이름입니다.

   3

   Operator를 제공하는 CatalogSource의 이름입니다.

   4

   CatalogSource의 네임스페이스입니다. 기본 OperatorHub CatalogSources에는 openshift-marketplace를 사용합니다.

2. 서브스크립션 오브젝트를 생성합니다.

   $ oc apply -f sub.yaml

   이제 Red Hat OpenShift Pipelines Operator가 기본 타겟 네임스페이스인 openshift-operators에 설치되었습니다.

프로세스

1. 웹 콘솔의 관리자 화면에서 Administration → Custom Resource Definition로 이동합니다.
2. 이름으로 필터링 박스에 config.operator.tekton.dev를 입력하여 Red Hat OpenShift Pipelines Operator CR을 검색합니다.
3. CRD Config을 클릭하여 Custom Resource Definition Details 페이지를 엽니다.

4. Actions 드롭다운 메뉴를 클릭하고 Delete Custom Resource Definition를 선택합니다.

   참고

   CR을 삭제하면 Red Hat OpenShift Pipelines 구성 요소가 삭제되고 클러스터의 모든 작업과 파이프라인이 사라집니다.

5. Delete를 클릭하여 CR 삭제를 확인합니다.

프로세스

1. Operators → OperatorHub 페이지에서 키워드로 필터링 박스를 사용하여 Red Hat OpenShift Pipelines Operator를 검색합니다.
2. OpenShift Pipelines Operator 타일을 클릭합니다. Operator 타일은 Operator가 설치되었음을 타나냅니다.
3. OpenShift Pipelines Operator 설명자 페이지에서 Uninstall를 클릭합니다.

프로세스

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

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

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

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/v1alpha1
   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.4/03_triggers/01_binding.yaml

3. 다음 샘플 TriggerTemplate YAML 파일의 내용을 복사하여 저장합니다.

   apiVersion: triggers.tekton.dev/v1alpha1
   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.4
     - 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

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

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.4/03_triggers/02_template.yaml

5. 다음 샘플 Trigger YAML 파일의 콘텐츠를 복사하여 저장합니다.

   apiVersion: triggers.tekton.dev/v1alpha1
   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.4/03_triggers/03_trigger.yaml

7. 다음 샘플 EventListener YAML 파일의 내용을 복사하여 저장합니다.

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

   또는 트리거 사용자 정의 리소스를 정의하지 않은 경우 트리거 이름을 참조하는 대신 바인딩 및 템플릿 사양을 EventListener YAML 파일에 추가합니다.

   apiVersion: triggers.tekton.dev/v1alpha1
   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.4/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 는 엔드포인트 인증서의 유효성을 검사하고 라우터에서 대상 포드로의 연결을 보호하는 CA 인증서를 지정합니다. 서비스에서 서비스 서명 인증서를 사용 중이거나 관리자가 라우터의 기본 CA 인증서를 지정하고 서비스에 해당 CA에서 서명한 인증서가 있는 경우 이 필드를 생략할 수 있습니다.

        자세한 옵션은 oc create route reencrypt --help를 참조하십시오.

   • 비보안 HTTP 연결을 사용하여 EventListener 리소스를 생성하려면 다음을 수행합니다.

     1. EventListener 리소스를 생성합니다.

     2. EventListener 서비스에 공개 액세스가 가능하도록 이 서비스를 OpenShift Container Platform 경로로 노출합니다.

        $ oc expose svc el-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.4

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

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

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

   $ tkn pipelinerun list

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

프로세스

1. 개발자 화면의 +추가 보기에서 파이프라인 타일을 클릭하여 파이프라인 빌더 페이지를 표시합니다.

2. 파이프라인 빌더 보기 또는 YAML 보기를 사용하여 파이프라인을 구성합니다.

   참고

   파이프라인 빌더 보기에서는 제한된 수의 필드를 지원하는 반면 YAML 보기는 사용 가능한 모든 필드를 지원합니다. 필요한 경우 Operator에서 설치한 재사용 가능 조각과 샘플을 사용하여 세부 파이프라인을 생성할 수 있습니다.

   그림 3.1. YAML보기

   

   파이프라인 빌더를 사용하여 파이프라인을 구성하려면 다음을 수행합니다.

   1. 파이프라인의 고유 이름을 입력합니다.

   2. 작업 선택 목록에서 작업을 선택하여 파이프라인에 작업을 추가합니다. 이 예제에서는 s2i-nodejs 작업을 사용합니다.

      • 파이프라인에 순차 작업을 추가하려면 작업 오른쪽 또는 왼쪽에 있는 더하기 아이콘을 클릭하고 작업 선택 목록에서 파이프라인에 추가할 작업을 선택합니다. 예를 들어 openshift-client 작업을 추가하려면 s2i-nodejs 작업 오른쪽에 있는 더하기 아이콘을 사용합니다.

      • 기존 작업에 병렬 작업을 추가하려면 작업 옆에 표시된 더하기 아이콘을 클릭하고 작업 선택 목록에서 파이프라인에 추가할 병렬 작업을 선택합니다.

        그림 3.2. Pipeline 빌더

        

   3. 리소스 추가를 클릭하여 파이프라인 실행에 사용할 리소스의 이름 및 유형을 지정합니다. 그러면 파이프라인의 작업에서 이러한 리소스를 입력 및 출력으로 사용합니다. 예시의 경우:

      1. 입력 리소스를 추가합니다. 이름 필드에 Source를 입력하고 리소스 유형 드롭다운 목록에서 Git을 선택합니다.
      2. 출력 리소스를 추가합니다. 이름 필드에 Img를 입력하고 리소스 유형 드롭다운 목록에서 이미지를 선택합니다.
   4. 선택 사항: 작업의 매개 변수는 작업 사양에 따라 미리 채워집니다. 필요하면 Add Parameters 링크를 사용하여 매개변수를 더 추가합니다.

   5. 작업의 리소스가 지정되지 않은 경우 작업에 리소스 없음 경고가 표시됩니다. s2i-nodejs 작업을 클릭하여 작업 세부 정보가 있는 측면 패널을 확인합니다.

      그림 3.3. Pipeline 빌더의 Task 세부 사항

      

   6. 작업 측면 패널에서 s2i-nodejs 작업에 대한 리소스 및 매개변수를 지정합니다.

      1. 입력 리소스 → 소스 섹션의 리소스 선택 드롭다운 목록에 사용자가 파이프라인에 추가한 리소스가 표시됩니다. 예에서는 Source 선택합니다.
      2. Output Resources → Image 섹션에서 Select Resources 목록을 클릭하고 Img를 선택합니다.
      3. 필요하면 Parameters 섹션에서 $(params.<param-name>) 구문을 사용하여 기본 매개변수에 매개변수를 더 추가합니다.
      4. 마찬가지로 openshift-client 작업의 입력 리소스를 추가합니다.
3. 생성을 클릭하여 파이프라인 세부 정보 페이지에서 파이프라인을 생성하고 봅니다.
4. 작업 드롭다운 메뉴를 클릭한 다음 시작을 클릭하여 파이프라인을 시작합니다.

프로세스

1. 개발자 화면의 파이프라인 보기에서 프로젝트 드롭다운 목록에 있는 프로젝트를 선택하여 해당 프로젝트의 파이프라인을 확인합니다.

2. 필요한 파이프라인을 클릭하여 파이프라인 세부 정보 페이지를 확인합니다. 기본적으로 세부 정보 탭이 열리고 파이프라인의 모든 직렬 및 병렬 작업이 시각적으로 표시됩니다. 페이지 오른쪽 아래에 작업 목록도 표시됩니다. 목록의 작업을 클릭하면 해당 작업의 세부 정보를 확인할 수 있습니다.

   그림 3.4. 파이프 라인 세부 정보

   

3. 필요한 경우 파이프라인 세부 정보 페이지에서 다음을 수행합니다.

   • 지표 탭을 클릭하여 파이프라인에 대한 다음 정보를 확인합니다.

     • 파이프 라인 성공률
     • 파이프 라인 실행 수
     • 파이프 라인 실행 기간

     • 작업 실행 기간

       이 정보를 사용하여 파이프라인 라이프사이클 초기에 파이프라인 워크플로를 개선하고 문제를 제거할 수 있습니다.

   • YAML 탭을 클릭하여 파이프라인의 YAML 파일을 편집합니다.

   • 파이프라인 실행 탭을 클릭하여 파이프라인 실행 상태가 완료, 실행 중 또는 실패인지 확인합니다.

     참고

     파이프라인 실행 세부 정보 페이지의 세부 정보 섹션에는 실패한 파이프라인 실행에 대한 로그 조각이 표시됩니다. 로그 조각에는 일반적인 오류 메시지와 해당 로그의 조각이 있습니다. 로그 섹션 링크를 사용하면 실패한 실행에 대한 세부 정보에 빠르게 액세스할 수 있습니다. 로그 조각은 작업 실행 세부 정보 페이지의 세부 정보 섹션에도 표시됩니다.

     옵션 메뉴 에서는 실행 중인 파이프라인 중지, 이전 파이프라인 실행과 동일한 매개변수 및 리소스를 사용하여 파이프라인 재실행 또는 파이프라인 실행 삭제 작업을 수행할 수 있습니다.

   • 매개변수 탭을 클릭하여 파이프라인에 정의된 매개변수를 확인합니다. 필요에 따라 매개변수를 추가하거나 편집할 수도 있습니다.
   • 리소스 탭을 클릭하여 파이프라인에 정의된 리소스를 확인합니다. 필요에 따라 리소스를 추가하거나 편집할 수도 있습니다.

1. 개발자 화면의 파이프라인 보기에서 파이프라인 옆에 있는 옵션 메뉴를 클릭하고 시작을 선택합니다.

2. 파이프라인 정의에 따라 파이프라인 시작 대화 상자에 Git 리소스 및 이미지 리소스가 표시됩니다.

   참고

   Git에서 옵션을 사용하여 생성한 파이프라인의 경우 파이프라인 시작 대화 상자의 매개변수 섹션에 APP_NAME 필드도 표시되며, 대화 상자의 모든 필드가 파이프라인 템플릿에 의해 미리 채워집니다.

   1. 네임스페이스에 리소스가 있는 경우 Git Resources 및 Image Resources 필드에 해당 리소스가 미리 채워집니다. 필요한 경우 드롭다운 목록을 사용하여 필요한 리소스를 선택하거나 생성한 다음 파이프라인 실행 인스턴스를 사용자 정의합니다.

3. 선택 사항: Advanced Options(고급 옵션 )를 수정하여 지정된 개인 Git 서버 또는 이미지 레지스트리를 인증하는 자격 증명을 추가합니다.

   1. Advanced Options에서 Show Credentials Options를 클릭하고 Add Secret을 선택합니다.

   2. Create Source Secre 섹션에서 다음 사항을 지정합니다.

      1. 보안에 대한 고유한 보안 이름입니다.
      2. Designated provider to be authenticated 섹션에서 Access to 필드에 인증할 공급자를 지정하고 기본 Server URL을 지정합니다.

      3. Authentication Type을 선택하고 자격 증명을 제공합니다.

         • 인증 유형 Image Registry Crendentials의 경우 인증할 레지스트리 서버 주소를 지정하고 사용자 이름, 암호, 이메일 필드에 자격 증명을 제공합니다.

           추가 Registry Server Address를 지정하려면 Add Credentials를 선택하십시오.

         • Authentication Type Basic Authentication의 경우 UserName 및 Password or Token 필드 값을 지정합니다.
         • 인증 유형 SSH Keys의 경우 SSH 개인 키 필드 값을 지정합니다.
      4. 확인 표시를 선택하여 보안을 추가합니다.

   파이프라인의 리소스 수에 따라 여러 개의 보안을 추가할 수 있습니다.

4. 시작을 클릭하여 파이프라인을 시작합니다.

5. 파이프라인 실행 세부 정보 페이지에 실행 중인 파이프라인이 표시됩니다. 파이프라인이 시작된 후 작업과 각 작업 내 단계가 실행됩니다. 다음을 수행할 수 있습니다.

   • 작업 위로 커서를 이동하여 각 단계를 실행하는 데 걸리는 시간을 확인합니다.
   • 작업을 클릭하여 각 작업 단계에 대한 로그를 확인합니다.
   • 로그 탭을 클릭하여 작업 실행 순서와 관련된 로그를 확인합니다. 관련 버튼을 사용하여 창을 확장하고 로그를 개별적 또는 일괄적으로 다운로드할 수도 있습니다.

   • 이벤트 탭을 클릭하여 파이프라인 실행으로 생성된 이벤트 스트림을 확인합니다.

     작업 실행, 로그, 이벤트 탭을 사용하면 실패한 파이프라인 실행 또는 실패한 작업 실행을 디버깅하는 데 도움이 될 수 있습니다.

     그림 3.5. ‘파이프 라인 실행' 세부 정보

     

6. Git에서 옵션을 사용하여 생성한 파이프라인의 경우 토폴로지 보기를 사용하여 파이프라인을 시작한 후 상호 작용할 수 있습니다.

   참고

   토폴로지 보기에서 파이프라인 빌더를 사용하여 생성한 파이프라인을 보려면 파이프라인 라벨을 사용자 정의하여 파이프라인을 애플리케이션 워크로드에 연결합니다.

   1. 왼쪽 탐색 패널에서 토폴로지를 클릭하고 애플리케이션을 클릭하여 사이드 패널에서 파이프라인 실행 목록을 확인합니다.

   2. 파이프라인 실행 섹션에서 마지막 실행 시작을 클릭하여 이전 파이프라인과 동일한 매개변수 및 리소스로 새 파이프라인 실행을 시작합니다. 파이프라인 실행이 시작되지 않은 경우 이 옵션이 비활성화되어 있습니다.

      그림 3.6. 토폴로지 보기의 파이프라인

      

   3. 토폴로지 페이지에서 애플리케이션 왼쪽으로 커서를 이동하여 애플리케이션의 파이프라인 실행 상태를 확인합니다.

      참고

      토폴로지 페이지의 애플리케이션 노드 사이드 패널에는 파이프라인 실행이 특정 작업 실행에서 실패할 때 로그 조각이 표시됩니다. 로그 조각은 리소스 탭의 파이프라인 실행 섹션에서 확인할 수 있습니다. 로그 조각에는 일반적인 오류 메시지와 해당 로그의 조각이 있습니다. 로그 섹션 링크를 사용하면 실패한 실행에 대한 세부 정보에 빠르게 액세스할 수 있습니다.