4.2. OpenShift Pipelines 이해

Tasks는 Pipeline 구성 블록이며, 순차적으로 실행되는 단계들로 구성됩니다. 기본적으로 입력 및 출력의 기능입니다. 개별적으로 또는 파이프라인의 일부로 작업을 실행할 수 있습니다. 작업은 재사용이 가능하며 여러 파이프라인에서 사용할 수 있습니다.

Steps는 작업에 의해 순차적으로 실행되어 이미지 작성과 같은 특정 목표를 달성하는 일련의 명령입니다. 모든 작업은 Pod로 실행되고 각 단계는 해당 Pod 내에서 컨테이너로 실행됩니다. 여러 단계가 동일한 Pod 내에서 실행되기 때문에 이러한 단계에서 파일, 구성 맵, 보안을 캐싱하기 위해 동일한 볼륨에 액세스할 수 있습니다.

다음 예는 apply-manifests Task를 보여줍니다.

apiVersion: tekton.dev/v1beta1 1
kind: Task 2
metadata:
  name: apply-manifests 3
spec: 4
  workspaces:
  - name: source
  params:
    - name: manifest_dir
      description: The directory in source that contains yaml manifests
      type: string
      default: "k8s"
  steps:
    - name: apply
      image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
      workingDir: /workspace/source
      command: ["/bin/bash", "-c"]
      args:
        - |-
          echo Applying manifests in $(params.manifest_dir) directory
          oc apply -f $(params.manifest_dir)
          echo -----------------------------------

이 작업은 Pod를 시작하고 해당 Pod 내에서 지정된 이미지를 사용하는 컨테이너를 실행하여 지정된 명령을 실행합니다.

When 표현식은 파이프라인 내에서 작업 실행 기준을 설정하여 작업 실행을 보호합니다. 여기에는 특정 기준이 충족될 때만 작업을 실행할 수 있는 구성 요소 목록이 포함되어 있습니다. when 표현식은 파이프라인 YAML 파일의 finally 필드를 사용하여 지정된 최종 작업 세트에서도 지원됩니다.

when 표현식의 주요 구성 요소는 다음과 같습니다.

선언된 when 표현식은 작업이 실행되기 전에 평가됩니다. when 표현식 값이 True이면 작업이 실행됩니다. when 표현식 값이 False이면 작업을 건너뜁니다.

다양한 사용 사례에서 when 표현식을 사용할 수 있습니다. 예를 들면 다음과 같은 경우입니다.

다음 예제에서는 파이프라인 실행에 대한 when 표현식을 보여줍니다. 파이프라인 실행은 다음 기준이 충족되는 경우에만 create-file 작업을 실행합니다. path 매개 변수는 README.md이고, check-file 작업의 exists결과가 yes인 경우에만 echo-file-exists 작업이 실행됩니다.

apiVersion: tekton.dev/v1beta1
kind: PipelineRun 1
metadata:
  generateName: guarded-pr-
spec:
  serviceAccountName: 'pipeline'
  pipelineSpec:
    params:
      - name: path
        type: string
        description: The path of the file to be created
    workspaces:
      - name: source
        description: |
          This workspace is shared among all the pipeline tasks to read/write common resources
    tasks:
      - name: create-file 2
        when:
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        workspaces:
          - name: source
            workspace: source
        taskSpec:
          workspaces:
            - name: source
              description: The workspace to create the readme file in
          steps:
            - name: write-new-stuff
              image: ubuntu
              script: 'touch $(workspaces.source.path)/README.md'
      - name: check-file
        params:
          - name: path
            value: "$(params.path)"
        workspaces:
          - name: source
            workspace: source
        runAfter:
          - create-file
        taskSpec:
          params:
            - name: path
          workspaces:
            - name: source
              description: The workspace to check for the file
          results:
            - name: exists
              description: indicates whether the file exists or is missing
          steps:
            - name: check-file
              image: alpine
              script: |
                if test -f $(workspaces.source.path)/$(params.path); then
                  printf yes | tee /tekton/results/exists
                else
                  printf no | tee /tekton/results/exists
                fi
      - name: echo-file-exists
        when: 3
          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo file exists'
...
      - name: task-should-be-skipped-1
        when: 4
          - input: "$(params.path)"
            operator: notin
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: exit 1
...
    finally:
      - name: finally-task-should-be-executed
        when: 5
          - input: "$(tasks.echo-file-exists.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo finally done'
  params:
    - name: path
      value: README.md
  workspaces:
    - name: source
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 16Mi

OpenShift Container Platform 웹 콘솔의 Pipeline Run 세부 정보 페이지에 다음과 같이 작업의 상태와 when 표현식이 표시됩니다.

finally 작업은 파이프라인 YAML 파일의 finally 필드를 사용하여 지정된 최종 작업 집합입니다. finally 작업은 파이프라인 실행이 성공적으로 실행되는지 여부에 관계없이 항상 파이프라인 내의 작업을 실행합니다. finally 작업은 해당 파이프라인이 종료되기 전에 모든 파이프라인 작업이 실행된 후 병렬로 실행됩니다.

finally 작업은 동일한 파이프라인 내의 모든 작업 결과를 사용하도록 구성할 수 있습니다. 이 접근 방식은 이 최종 작업이 실행되는 순서를 변경하지 않습니다. 모든 최종 작업이 실행된 후 다른 최종 작업과 동시에 실행됩니다.

다음 예제에서는 clone-cleanup-workspace 파이프라인의 코드 스니펫을 보여줍니다. 이 코드는 리포지토리를 공유 작업 공간으로 복제하고 작업 영역을 정리합니다. 파이프라인 작업을 실행한 후 파이프라인 YAML 파일의 finally 섹션에 지정된 cleanup 작업이 작업 영역을 정리합니다.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: clone-cleanup-workspace 1
spec:
  workspaces:
    - name: git-source 2
  tasks:
    - name: clone-app-repo 3
      taskRef:
        name: git-clone-from-catalog
      params:
        - name: url
          value: https://github.com/tektoncd/community.git
        - name: subdirectory
          value: application
      workspaces:
        - name: output
          workspace: git-source
  finally:
    - name: cleanup 4
      taskRef: 5
        name: cleanup-workspace
      workspaces: 6
        - name: source
          workspace: git-source
    - name: check-git-commit
      params: 7
        - name: commit
          value: $(tasks.clone-app-repo.results.commit)
      taskSpec: 8
        params:
          - name: commit
        steps:
          - name: check-commit-initialized
            image: alpine
            script: |
              if [[ ! $(params.commit) ]]; then
                exit 1
              fi

TaskRun은 클러스터에서 특정 입력, 출력 및 실행 매개변수를 사용하여 실행할 Task를 인스턴스화합니다. 자체 또는 파이프라인의 각 작업에 대해 파이프라인 실행의 일부로 호출할 수 있습니다.

Task는 컨테이너 이미지를 실행하는 하나 이상의 단계(Step)로 구성되며, 각 컨테이너 이미지의 특정 빌드 작업을 수행합니다. TaskRun은 Task의 모든 단계(Step)를 지정된 순서로 실행하며, 모든 단계(Step)가 성공적으로 실행되거나 실패하는 단계가 발생하면 실행을 멈춥니다. TaskRun은 Pipeline의 각 Task에 대한 PipelineRun에 의해 자동으로 생성되며,

다음 예는 관련 입력 매개변수를 사용하여 apply-manifests Task를 실행하는 TaskRun을 보여줍니다.

apiVersion: tekton.dev/v1beta1 1
kind: TaskRun 2
metadata:
  name: apply-manifests-taskrun 3
spec: 4
  serviceAccountName: pipeline
  taskRef: 5
    kind: Task
    name: apply-manifests
  workspaces: 6
  - name: source
    persistentVolumeClaim:
      claimName: source-pvc

파이프라인은 특정 실행 순서대로 정렬된 Task 리소스 컬렉션입니다. 애플리케이션 빌드, 배포 및 제공 작업을 자동화하는 복잡한 워크플로를 구성하기 위해 실행됩니다. 하나 이상의 작업이 포함된 파이프라인을 사용하여 애플리케이션에 대한 CI/CD 워크플로를 정의할 수 있습니다.

Pipeline 리소스 정의는 함께 사용하면 파이프라인에서 특정 목표를 달성할 수 있는 여러 필드 또는 특성으로 구성됩니다. 각 Pipeline 리소스 정의에는 특정 입력을 수집하고 특정 출력을 생성하는 Task가 하나 이상 포함되어야 합니다. 또한 파이프라인 정의에는 애플리케이션 요구 사항에 따라 Conditions, Workspaces, Parameters 또는 Resources가 선택적으로 포함될 수 있습니다.

다음 예제에서는 buildah ClusterTask 리소스를 사용하여 Git 리포지토리에서 애플리케이션 이미지를 빌드하는 build-and-deploy 파이프라인을 보여줍니다.

apiVersion: tekton.dev/v1beta1 1
kind: Pipeline 2
metadata:
  name: build-and-deploy 3
spec: 4
  workspaces: 5
  - name: shared-workspace
  params: 6
  - 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.5"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks: 7
  - 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 8
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
    - fetch-repository
  - name: apply-manifests 9
    taskRef:
      name: apply-manifests
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter: 10
    - build-image
  - name: update-deployment
    taskRef:
      name: update-deployment
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: deployment
      value: $(params.deployment-name)
    - name: IMAGE
      value: $(params.IMAGE)
    runAfter:
    - apply-manifests

PipelineRun 은 CI/CD 워크플로를 실행하는 시나리오에 고유한 파이프라인, 작업 공간, 인증 정보 및 일련의 매개변수 값을 바인딩하는 리소스 유형입니다.

파이프라인 실행 은 파이프라인의 실행 중인 인스턴스입니다. 클러스터에서 특정 입력, 출력 및 실행 매개변수를 사용하여 실행할 파이프라인을 인스턴스화합니다. 또한 파이프라인 실행의 각 작업에 대한 작업 실행을 생성합니다.

파이프라인은 완료되거나 작업이 실패할 때까지 작업을 순차적으로 실행합니다. status 필드는 각 작업 실행의 진행 상황 및 모니터링 및 감사 목적으로 저장합니다.

다음 예는 관련 리소스 및 매개변수를 사용하여 build-and-deploy Pipeline을 실행하는 PipelineRun을 보여줍니다.

apiVersion: tekton.dev/v1beta1 1
kind: PipelineRun 2
metadata:
  name: build-deploy-api-pipelinerun 3
spec:
  pipelineRef:
    name: build-and-deploy 4
  params: 5
  - name: deployment-name
    value: vote-api
  - name: git-url
    value: https://github.com/openshift-pipelines/vote-api.git
  - name: IMAGE
    value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/vote-api
  workspaces: 6
  - name: shared-workspace
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi

작업 공간은 입력 또는 출력을 제공하기 위해 런타임 시 파이프라인의 작업에 필요한 공유 스토리지 볼륨을 선언합니다. 볼륨의 실제 위치를 지정하는 대신 Workspace를 사용하여 런타임 시 필요한 파일 시스템 전체 또는 파일 시스템의 일부를 선언할 수 있습니다. 작업 또는 파이프라인은 작업 공간을 선언하고 볼륨의 특정 위치 세부 정보를 제공해야 합니다. 그런 다음 작업 실행 또는 파이프라인 실행에서 해당 작업 공간에 마운트됩니다. 이러한 방식으로 런타임 스토리지 볼륨에서 볼륨 선언을 분리하면 사용자 환경에 종속되지 않으며 유연성 높고 재사용 가능한 Task로 만들 수 있습니다.

다음과 같은 용도로 Workspace를 활용할 수 있습니다.

다음을 사용하여 TaskRun 또는 PipelineRun에서 Workspace를 지정할 수 있습니다.

다음은 Pipeline에 정의된 대로 build-image 및 apply-manifests Task에 대한 shared-workspace Workspace를 선언하는 build-and-deploy Pipeline의 코드 스니펫 예입니다.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
  workspaces: 1
  - name: shared-workspace
  params:
...
  tasks: 2
  - name: build-image
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces: 3
    - name: source 4
      workspace: shared-workspace 5
    runAfter:
    - fetch-repository
  - name: apply-manifests
    taskRef:
      name: apply-manifests
    workspaces: 6
    - name: source
      workspace: shared-workspace
    runAfter:
      - build-image
...

작업 공간을 사용하면 여러 작업에서 데이터를 공유하고 파이프라인의 각 작업을 실행하는 동안 필요한 하나 이상의 볼륨을 지정할 수 있습니다. 영구 볼륨 클레임을 생성하거나 사용자를 대신하여 영구 볼륨 클레임을 생성하는 볼륨 클레임 템플릿을 제공할 수 있습니다.

다음의 build-deploy-api-pipelinerun PipelineRun 코드 조각에서는 볼륨 클레임 템플릿을 사용하여 build-and-deploy 파이프라인에 사용된 shared-workspace 작업 공간의 스토리지 볼륨을 정의하는 영구 볼륨 클레임을 생성합니다.

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: build-deploy-api-pipelinerun
spec:
  pipelineRef:
    name: build-and-deploy
  params:
...

  workspaces: 1
  - name: shared-workspace 2
    volumeClaimTemplate: 3
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi

Kubernetes 리소스에서 전체 CI/CD 실행을 정의하는 완전한 CI/CD 시스템을 생성하려면 파이프라인과 함께 트리거를 사용합니다. 트리거는 Git 풀 요청과 같은 외부 이벤트를 캡처하고 처리하여 주요 정보를 추출합니다. 이 이벤트 데이터를 미리 정의된 매개변수 집합에 매핑하면 Kubernetes 리소스를 생성 및 배포하고 파이프라인을 인스턴스화할 수 있는 일련의 작업이 트리거됩니다.

애플리케이션에 Red Hat OpenShift Pipeline을 사용하여 CI/CD 워크플로를 정의하는 경우를 예로 들 수 있습니다. 새로운 변경 사항을 애플리케이션 리포지토리에 적용하려면 파이프라인을 시작해야 합니다. 트리거는 모든 변경 이벤트를 캡처하여 처리하고 최신 변경 사항이 적용된 새 이미지를 배포하는 파이프라인 실행을 트리거하는 방식으로 이 프로세스를 자동화합니다.

트리거는 함께 작동하여 재사용 가능하고 분리되고 자체 유지되는 CI/CD 시스템을 형성하는 다음과 같은 주요 리소스로 구성됩니다.