Tekton 사용해보기 (1) Tekton으로 쿠버네티스에서 CI/CD 파이프라인을 구성해보자

 

Tekton은 Linux Foundation과 CD Foundation 프로젝트의 일환으로 등장한 Cloud-native CI/CD Pipline 솔루션입니다.

 

Tekton은 Kubernetes의 Extension으로  실행되기 때문에 기존 Kuberntes의 에코시스템을 그대로 활용하면서 사용할 수 있습니다.

 

이러한 점은 사용자에게 친숙한 Kubernetes 환경을 그대로 사용하면서 Tekton 파이프라인을 구성할 수 있게 해준다는 장점이 됩니다.

 

앞으로 Tekton을 사용해보는 여러 포스팅을 작성하고자 계획하고 있으며, 이 포스팅은 그 중 첫번째 글입니다.

 

특히 이번 포스팅에서는 이러한 Tekton을 어떻게 사용할 수 있는지, 시연 Demo와 사용 사례를 알아보도록 하겠습니다.

 

 

 

 

1. Tekton 소개

Tekton은 Kubernetes의 Extension으로 이용할 수 있는 CI/CD Pipeline 도구입니다.

 

Kubernetes의 Extension이라는 말은 즉 Kubernetes 오브젝트로 CI/CD 파이프라인을 구축할 수 있다는 말이죠.

 

Tekton은 빌딩 블록을 쌓아 올리듯이 다양한 컴포넌트를 기반으로 단일한 파이프라인을 구현할 수 있습니다.

 

Tekton은 Pipeline을 구축하는 기능 외에도 웹 기반 UI를 제공하는 Dashboard, CLI 명령어 도구같은 CI/CD 파이프라인을 구성하는데 도움이 되는 다양한 컴포넌트를 가지고 있습니다.

 

먼저 Tekton이 어떤 컴포넌트 셋을 제공하는지 알아보도록 하겠습니다.

 

 

 

1-1. Tekton 컴포넌트

 

 

1. Tekton Pipeline

Tekton의 기초이자 핵심 컴포넌트입니다.

쿠버네티스의 Custom Resources로 이루어져 쿠버네티스 오브젝트로 CI/CD 파이프라인을 조립할 수 있는 빌딩 블록을 제공합니다.

 

2. Tekton Dashboard

Tekton Dashboard는 웹 기반 UI로 Tekton Pipeline 관련한 정보들을 그래피컬하게 확인하거나 버튼 클릭으로 Tekton 파이프라인을 조작할 수 있습니다.

 

3. Tekton Triggers

이벤트에 기반해 Tekton Pipline을 동작시킬 수 있는 컴포넌트입니다. Tekton Trigger를 이용하면 Github Repo에서 Push가 들어왔을시 이를 감지해 Tekton Pipeline을 자동으로 동작시켜 이미지를 빌드하는 CI/CD Pipline을 구성할 수 있습니다.

 

4,. Tekton CLI

Tekton CLI는 tkn이라고 하는 CLI 기반의 도구입니다. tkn을 이용하면 커맨드 라인 인터페이스를 통해 다양한 Tekton 리소스와 상호작용할 수 있습니다.

 

 

5. Tekton Hub

Tekton Hub는 Community에서 제공하는 빌딩 블록들(Task,Pipeline 등)을 저장하고 있는 Tekton Catalogue를 웹 기반으로 제공하는 사이트입니다. 일종의 커뮤니티 기반 Tekton 레포지토리라고 할 수 있으며 tkn CLI 도구를 통해 바로 받아서 사용할 수 있습니다.

 

 

 

1-2. Tekton Pipeline 구성

이제 Tekton의 핵심이라고 할 수 있는 Tekton Pipeline의 구성 요소, 즉 어떤 빌딩 블록들을 이용해 파이프라인을 조립할 수 있는지 알아보겠습니다.

 

1. Step

Step은 CI/CD 파이프라인의 가장 작은 단위이자, 파이프라인의 실제 작업을 담당하는 빌딩 블록입니다.

Tekton Pipeline의 Step은 Kubernetes 관점에서는 컨테이너 이미지 단위로 동작합니다.

 

2. Task

Task는 순서대로 나열한 Step의 모음입니다. 
Tekton Pipeline의 Task는 Kubernetes 관점에서는 pod 단위로 동작합니다.

이러한 디자인으로 인해 Task는 각 Step들이 실행되는 환경을 공유하게 할 수도 있다는 장점이 있습니다.

 

3. Pipeline

Pipeline은 순서대로 나열한 Task들의 모음입니다.

Pipeline은 각 Task들을 모아서 directed acyclic graph (DAG)형태로 구성해 실행합니다.

Kubernetes 관점에서는 Pipeline 실행에 필요한 pod를 생성하고 순서대로 실행되도록 보장하는 역할을 합니다.

 

4. TaskRun

TaskRun은 Task를 실행하는 역할을 합니다. Tekton의 Task 그 자체로는 아무것도 실행하지 않는 템플릿에 불과합니다.

이 템플릿에 변수 값을 지정하고 실행하는 것은 TaskRun의 역할입니다.

단순히 Task를 실행하는 것 뿐만이 아니라 하루에 Task를 몇 번 실행할지 지정하는 등의 스케쥴링도 가능합니다.

 

5. PIpelineRun

PipelineRun도 TaskRun과 동일하게 Pipeline을 실행하는 역할을 합니다.

Pipeline이라는 템플릿에 변수 값을 지정하고 실행하며 실행의 스케쥴링도 가능합니다.

 

 

 

 

2. DEMO  - Tekton Pipeline으로 CI/CD 파이프라인 구성하기

 

 

이제 본격적으로 Tekton을 활용한 CI/CD Pipeline 구성 DEMO를 시연해보겠습니다.

 

CI/CD Workflow는 위 다이어그램에서 볼 수 있듯이, Github에서 Push작업이 들어오면 이를 감지해서 이미지를 빌드하고, 빌드한 이미지를 Docker hub 이미지 레지스트리에 Push하는 순서로 되어 있습니다.

 

이 같은 CI/CD Pipeline을 구성하기 위해 Tekton에서 어떤 컴포넌트를 사용해야 하는지, Pipeline의 빌딩 블록을 어떻게 구성해야 하는지 같이 알아보도록 하겠습니다.

 

 

 

2-1. Tekton 컴포넌트 설치

 

Tekton을 설치하기 전에, Tekton은 Kubernetes의 Extension으로 등장한 솔루션이기 때문에 당연하게도 1개 이상의 Kubernetes 클러스터 및 Kubernetes와 상호작용할 수 있는 kubectl이 준비되어 있어야 합니다.

 

본 포스팅에서는 Minikube v1.27.0으로 Kubernetes 클러스터를 사용합니다. 

 

 

그리고 파이프라인을 구성할 새로운 네임스페이스인 "getting-started" 를 생성하겠습니다.

 

앞으로 생성할 Tekton 오브젝트들은 모두 이 네임스페이스에서 생성하겠습니다.

 

kubectl create ns getting-started

 

 

2-1-1. Tekton Pipeline 설치

Tekton의 핵심인 Tekton Pipeline을 설치하겠습니다.

 

아래 명령어로 Tekton Pipeline을 설치합니다.

 

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

 

tekton-pipelines 네임스페이스에 "tekton-pipelines-controller-"와 "tekton-pipelines-webhook-" pod가 RUNNING 상태가 되면 정상적으로 설치가 완료된 것입니다.

 

2-1-2. Tekton CLI 설치

다음으로 Tekton 컴포넌트와 CLI로 상호작용할 수 있는 Tekton CLI를 설치합니다. 

 

설치 방법은 OS마다 다르기 때문에 자세한 설치 방법은 아래 링크를 참고해주시기 바랍니다.

 

https://tekton.dev/docs/cli/

CLI

 

본 포스팅은 MacOS에서 진행하기 때문에 아래 명령어로 Tekton CLI를 설치하도록 하겠습니다.

 

brew install tektoncd-cli

 

2-1-3. Tekton Dashboard 설치

다음으로 Tekton 컴포넌트를 확인 및 관리할 수 있는 웹 UI인 Tekton Dashboard를 설치하겠습니다.

 

아래 명령어로 Tekton Dashboard를 설치합니다.

 

kubectl apply --filename https://storage.googleapis.com/tekton-releases/dashboard/latest/tekton-dashboard-release.yaml

 

tekton-pipelines 네임스페이스의 "tekton-dashboard-" pod가 RUNNING 상태이면 설치가 정상적으로 완료된 것입니다.

 

 

웹 인터페이스에 접속하기 위해 kubectl port-forward 명령어를 이용해서 localhost로 접근해보겠습니다. 아래 명령어를 실행해 port-forwarding을 시행합니다.

 

kubectl port-forward -n tekton-pipelines svc/tekton-dashboard 9097:9097

 

localhost:9097로 접속하면 아래와 같은 인터페이스를 확인할 수 있습니다. 대쉬보드는 이번 파이프라인을 실행하면서 주기적으로 확인할 예정입니다.

 

 

2-1-3. Tekton Triggers 설치

마지막으로 Tekton의 이벤트 감지를 담당하는 Tekton Trigger를 설치하겠습니다.

 

아래 명령어로 Tekton Trigger를 설치합니다.

 

kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/triggers/latest/interceptors.yaml

 

"tekton-triggers-controller-", "tekton-triggers-core-interceptors-", "tekton-triggers-webhook-" pod가 RUNNING 상태가 되면 정상적으로 설치된 것입니다.

 

 

 

2-2. Tekton Pipeline 구성

이제 본격적으로 Tekton으로 CI/CD 파이프라인을 구성할 수 있는 빌딩 블록을 조립해보도록 하겠습니다.

 

Tekton의 모든 오브젝트들은 Kubernetes의 Extension이기 때문에 Kubernetes CR이라고 할 수 있습니다.

 

따라서 Kubernetes와 같이 yaml 매니페스트로 Tekton의 구성 요소들을 정의할 수 있습니다.

 

2-2-1. Task 구성

먼저 Tekton에서 yaml로 정의할 수 있는 가장 작은 단위인 Task부터 정의해보도록 하겠습니다.

 

이번 CI/CD 파이프라인에서 필요한 Step은 git repository의 코드를 기반으로 컨테이너 이미지를 빌드 및 이미지 레지스트리로 푸시하는 것입니다.

 

이러한 Step을 Kubernetes 환경에서 컨테이너 이미지 빌드 및 푸시를 수행할 수 있는 Kaniko로 수행하는 Task로 구성해보겠습니다.

 

Kaniko에 대한 자세한 내용은 아래 링크를 참고하세요.

 

https://github.com/GoogleContainerTools/kaniko

GitHub - GoogleContainerTools/kaniko: Build Container Images In Kubernetes

 

Task의 전체 yaml 매니페스트는 아래와 같습니다.

 

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-docker-image
  namespace: getting-started
spec:
  params:
  - name: pathToContext
    description:
      The build directory used by img
    default: /workspace/source-repo
  - name: pathToDockerFile
    type: string
    description: The path to the dockerfile to build
    default: $(resources.inputs.source-repo.path)/Dockerfile
  resources:
    inputs:
      - name: source-repo
        type: git
    outputs:
      - name: builtImage
        type: image
  steps:
    - name: build-and-push
      image: gcr.io/kaniko-project/executor:v0.16.0
      volumeMounts:
        - name: docker-credentials
          mountPath: /tekton/home/.docker/
      env:
        - name: "DOCKER_CONFIG"
          value: "/tekton/home/.docker/"
      command:
        - /kaniko/executor
      args:
        - --dockerfile=$(params.pathToDockerFile)
        - --destination=$(resources.outputs.builtImage.url)
        - --context=$(params.pathToContext)
        - --force
  volumes:
    - name: docker-credentials
      secret: 
        secretName: docker-credentials

 

위 매니페스트에서 주의해야 할 값만 몇 가지 보도록 하겠습니다.

 

1. spec.steps.image

이 어트리뷰트를 통해 해당 스텝이 실행할 컨테이너 이미지를 지정할 수 있습니다. 

위 Task는 gcr.io/kaniko-project/executor:v0.16.0로 지정해 Kaniko를 사용하다는 것을 알 수 있습니다.

 

2. spec.steps.env.name

해당 어트리뷰트를 보면 "DOCKER_CONFIG"라는 이름으로 환경 변수를 지정해 놓은 것을 볼 수 있습니다.

이 환경 변수에는 docker hub에 이미지를 푸시하기 위해 필요한 Credential 경로를 지정해야 합니다.

그렇지 않으면 권한 Issue로 docker hub 이미지 레지스트리에 푸시할 수 없습니다.

 

3. spec.steps.volumeMounts

위 Credential 경로에 넣을 config.json 파일을 kubernetes secret 형태로 Mount한 어트리뷰트입니다.

config.json파일의 매니페스트는 아래와 같습니다.

 

{
    "auths": {
        "https://index.docker.io/v1/": {
            "auth": "cmVlMzY5OnMwMTExNzc3MA=="
        }
    }
}

 

"auth"란에 들어간 값은 docker hub 인증 정보 "USERNAME:PASSWORD" 을 base64로 인코딩한 값입니다.

위 매니페스트를 base64 인코딩하여 Kubernetes Secret으로 생성한 뒤 Mount합니다.

 

 

kubectl apply 명령어로 위 매니페스트를 적용하도록 합니다.

 

매니페스트를 적용한 뒤 아래와 같이 "tkn task ls -n getting-started" 명령어로 task의 생성을 확인할 수 있습니다.

 

 

2-2-2. Pipeline 구성

Task를 구성했으니 이제 Task를 모아서 일련의 파이프라인으로 구성하는 Pipeline 리소스를 구성해보도록 하겠습니다.

 

이번 포스팅에서 사용하는 Pipeline은 Task가 1개 뿐이라 순서를 지정할 필요는 없겠지만, Pipeline은 Task를 실행하는데 꼭 필요한 리소스이기 때문에 정의해보도록 하겠습니다. 

 

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: getting-started-pipeline
  namespace: getting-started
spec:
  resources:
    - name: source-repo
      type: git
    - name: image-source
      type: image
  tasks:
    - name: build-docker-image
      taskRef:
        name: build-docker-image
      params:
        - name: pathToContext
          value: /workspace/source-repo
      resources:
        inputs:
          - name: source-repo
            resource: source-repo
        outputs:
          - name: builtImage
            resource: image-source

 

마찬가지로 중요한 항목만 짚어보도록 하겠습니다.

 

1. spec.tasks.taskRef

이 어트리뷰트를 통해 Pipeline이 실행할 Task를 지정할 수 있습니다.

이번 Pipeline이 실행할 Task는 1개지만, Task가 여러 개일 경우에는 배치에 따라서 Task가 실행될 순서를 정할 수도 있습니다.

 

 

kubectl apply 명령어로 위 매니페스트를 적용하도록 합니다.

 

매니페스트를 적용한 뒤 아래와 같이 "tkn pipeline ls -n getting-started" 명령어로 Pipeline의 생성을 확인할 수 있습니다.

 

 

 

2-2-3. Service account 구성

Pipeline까지 구성했으니 Pipeline을 실행할 PipelineRun을 생성해야 겠지만, 그 전에 PipelineRun은 작업을 실행하는 오브젝트이기 때문에 작업 실행의 권한이 필요합니다.

 

이럴 때 필요한 것이 적절한 권한을 가진 Service account의 존재인데요, 그렇기 때문에 PipelineRun에 필요한 Service Account를 먼저 생성하도록 하겠습니다.

 

아래 매니페스트를 적용하도록 합니다.

 

apiVersion: v1
kind: ServiceAccount
namespace: getting-started
metadata:
  name: tekton-triggers-example-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
namespace: getting-started
metadata:
  name: triggers-example-eventlistener-binding
subjects:
- kind: ServiceAccount
  name: tekton-triggers-example-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-triggers-eventlistener-roles

 

"kubectl get sa -n getting-started" 명령어로 Service account가 정상적으로 생성되었는지 확인하도록 합니다.

 

 

 

2-2-4. PipelineRun 구성

Pipeline을 생성했으니 Pipeline을 실행할 수 있는 PipelineRun 리소스를 생성하겠습니다.

 

PipelineRun은 단순히 Pipeline을 실행하는 것 뿐만이 아니라 Pipeline이 가진 변수에 값을 할당하거나 작업을 실행할 Service account를 지정하는 등의 작업도 할 수 있습니다.

 

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
generateName: getting-started-pipeline-run-
namespace: getting-startd
spec:
  : tekton-triggers-example-sa
    pipelineRef:
      name: getting-started-pipeline
      resources:
          - name: source-repo
            resourceSpec:
              type: git
              params:
              - name: revision
                value: master
              - name: url
                value: https://github.com/nangmans/docsy-example
          - name: image-source
            resourceSpec:
              type: image
              params:
                - name: url
                 value: ree369/example:v1 #Use your URL

 

1. spec.pipelineRef.name

이 어트리뷰트를 통해 PipelineRun이 실행할 Pipeline 오브젝트를 지정할 수 있습니다.

 

2. spec.pipelineRef.resources.resourceSpec.params

Pipeline에서 설정한 변수의 값을 PipelineRun에서 할당할 수 있습니다.

이번 포스팅에서 사용할 PipelineRun은 github Repository 푸쉬가 들어올 Revision과 URL, 그리고 빌드한 컨테이너 이미지를 푸쉬할 이미지 레지스트리 주소 값을 할당했습니다.

 

이미지 레지스트리 주소는 자신의 Docker Registry 주소로 수정해서 사용해 줍시다.

 

 

Tekton PipelineRun은 위 2개 오브젝트(Task, Pipeline)과 다르게 적용 후 등록하는 리소스가 아닌, 적용하면 바로 해당 파이프라인이 실행되는 Job의 성격을 띄고 있습니다.

 

그렇기 때문에 위 매니페스트를 아직 적용하지 않고 다음 단계로 넘어가겠습니다.

 

2-2-5.  Tekton Dashboard 확인

위에서 만든 Tekton 오브젝트들을 Tekton Dashboard에서 확인할 수 있습니다.

 

Tasks 탭에서 생성한 "build-docker-image" Task를 확인할 수 있습니다.

 

 

Pipelines 탭에서 생성한 "getting-started-pipeline" Pipeline을 확인할 수 있습니다.

 

 

 

 

 

2-3. Tekton Trigger 구성

지금까지 CI/CD Pipeline을 조립하기 위한 Tekton Pipeline을 구성해봤습니다.

 

하지만 이번 CI/CD Workflow에서는 Github Repository에서 오는 Push 작업을 감지하고 Pipeline을 발동해야 하기 때문에,

 

Tekton Trigger를 이용해서 이 같은 로직을 구현해보겠습니다.

 

 

2-3-1. Tekton Trigger 개요

Tekton Trigger는 여러 Kubernetes CR로 이루어진 컴포넌트이기 때문에 Trigger를 생성하기 전, 먼저 Tekton Trigger가 어떻게 구성되어 있는지 살펴보겠습니다.

 

 

1. EventListener 

다양한 소스에서 이벤트를 감지하는 오브젝트입니다. 

Kubernetes 관점에서는 Ingress로 노출된 Pod로 띄워져 있어 이벤트 발생을 대기하고 있습니다.

TriggerBindging과 TriggerTemplate을 묶어주는 역할도 합니다.

 

2. Trigger

EventListener가 이벤트를 감지했을시 어떤 행위를 할지 지정하는 오브젝트입니다.

TriggerTemplate과 TriggerBinding을 지정해 사용합니다.

 

3. TriggerTemplate

EventListener가 이벤트를 감지했을시 Trigger할 PipelineRun이나 TaskRun 오브젝트를 지정합니다.

리소스의 템플릿으로써 기능하며 여러 파라미터를 노출시켜 사용할 수 있습니다.

 

4. TriggerBinding

EventListener가 감지한 이벤트에서 필요한 정보를 추출하는 오브젝트입니다.

 

 

2-3-2. Tekton TriggerTemplate 구성

먼저 Tekton Trigger에서 실행할 PipelineRun을 지정할 수 있는 TriggerTemplate을 생성하겠습니다.

 

PipelineRun 오브젝트는 위에서 미리 만들어놨기 때문에, 이 매니페스트를 활용하도록 합니다.

 

apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: getting-started-triggertemplate
  namespace: getting-started
spec:
  params:
    - name: gitrevision
      description: The git revision
      default: master
    - name: gitrepositoryurl
      description: The git repository url
    - name: namespace
      description: The namespace to create the resources
  resourcetemplates:
    - apiVersion: tekton.dev/v1beta1
      kind: PipelineRun
      metadata:
        generateName: getting-started-pipeline-run-
       namespace: getting-started
      spec:
        : tekton-triggers-example-sa
        pipelineRef:
          name: getting-started-pipeline
        resources:
          - name: source-repo
            resourceSpec:
              type: git
              params:
              - name: revision
                value: $(tt.params.gitrevision)
              - name: url
                value: $(tt.params.gitrepositoryurl)
          - name: image-source
            resourceSpec:
              type: image
              params:
                - name: url
                 value: ree369/example:v1 # Use your URL

위와 마찬가지로 중요한 몇 가지 부분만 짚도록 하겠습니다.

 

1. spec.resourcestemplates

이 어트리뷰트의 값에 이전에 생성해놨던 PipelineRun 매니페스트를 넣습니다.

주의해야 할 점은 PipelineRun 내의 "revision"과 "url" Param 값을 고정된 값에서 TriggerTemplate의 Param값을 받아오도록 변경했다는 점입니다. 
TriggerTemplate의 param값은 이벤트에서 정보를 추출할 수 있는 TriggerBinding에서 지정할 수 있으므로, 이렇게 하면 Webhook 정보에서 값을 유기적으로 받아올 수 있다는 장점이 있습니다.

 

 

 

"tkn triggertemplate ls -n getting-started" 명령어로 triggerTemplate이 정상적으로 생성되었는지 확인하도록 합니다.

 

 

2-3-3. TriggerBinding 구성

다음으로는 이벤트에서 필요한 정보를 추출할 수 있는 TriggerBinding을 생성하겠습니다.

 

apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerBinding
metadata:
  name: getting-started-pipelinebinding
  namespace: getting-started
spec:
  params:
    - name: gitrevision
      value: $(body.repository.master_branch)
    - name: namespace
      value: getting-started
    - name: gitrepositoryurl
      value: $(body.repository.url)

 

1. spec.params.value

해당 어트리뷰트의 값을 보면 변수로써 값이 할당되어 있는 것을 볼 수 있습니다.

이 값들은 Github webhook에 포함되어 있는 데이터에서 추출한 값입니다. 

Github webhook이 가지고 있는 payload의 자세한 내용은 아래 링크에서 참고할 수 있습니다.

 

https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#webhook-payload-example-41

Webhook events and payloads - GitHub Docs

 

예를 들어 파이프라인에 필요한 url 정보는 repository.url에 존재하는 것을 알 수 있습니다. 

 

Revision은 현재 Master로 고정해놨지만 원하는 경우 이와 같이 Payload를 찾아 변수로 값을 할당할 수 있습니다.

 

 

 

"tkn triggerbinding ls -n getting-started" 명령어로 triggerBinding이 정상적으로 생성되었는지 확인하도록 합니다.

 

 

2-3-4. Trigger EventListener 구성

마지막으로 Tekton TriggerTemplate과 TriggerBinding을 묶어주고 이벤트를 감지하는 EventListener를 생성하겠습니다.

 

apiVersion: triggers.tekton.dev/v1alpha1
kind: EventListener
metadata:
  name: getting-started-listener
  namespace: getting-started
spec:
  serviceAccountName: tekton-triggers-example-sa
  triggers:
    - bindings:
      - ref: getting-started-pipelinebinding
      template:
        ref: getting-started-triggertemplate

 

1. spec.triggers.bindings.ref

EventListener가 사용할 TriggerBinding을 지정합니다.

 

2. spec.triggers.template.ref

EventListener가 사용할 TriggerTemplate을 지정합니다. 

EventListener는 위 2개 오브젝트를 묶어줍니다. 

 

 

 

"tkn eventlistener ls -n getting-started" 명령어로 eventListener가 정상적으로 생성되었는지 확인하도록 합니다.

 

 

eventListener는 실제 Pod로 동작하기 때문에 아래 명령어로 pod가 RUNNGING 상태로 돌아가는 것을 확인할 수도 있습니다.

 

 

 

2-3-5.  Tekton Dashboard 확인

 

EventListeners 탭에서 생성한 "getting-started-listener" eventListener 오브젝트를 확인할 수 있습니다.

 

TriggerBindings 탭에서 생성한 "getting-started-pipeinebinding" 오브젝트를 확인할 수 있습니다.

 

 

TriggerTemplates 탭에서 생성한 "getting-started-triggertemplate" 오브젝트를 확인할 수 있습니다.

 

 

 

2-4. Tekton CI/CD 파이프라인 동작 확인

 

이제 본격적으로 구성한 CI/CD 파이프라인의 동작을 확인해보도록 하겠습니다.

 

주의할 점은, 이번 포스팅에서 생성한 파이프라인은 Minikube라는 로컬 클러스터에서 구성한 것이기 때문에 실제 Push webhook을 받아 파이프라인을 동작시키지는 못한다는 것입니다.

 

대신 Webhook을 가장한 API call을 EventListener에게 보내 파이프라인이 동작하는지 확인하는 절차를 가져볼 것입니다.

 

우선 아래  port-forwarding 명령어를 통해 EventListener를 Localhost로 접근할 수 있도록 하겠습니다. 

 

kubectl port-forward -n getting-started svc/el-getting-started-listener 8080:8080 

 

다음으로 아래 curl 명령어를 통해 EventListener에게 Github webhook을 가장한 API call을 보내보도록 하겠습니다.

 

 curl -X POST \
    -d '{"head_commit": {"id": "23a3kjhheq9m3a3hx1a3k4uog2ufr4qfj19ej3bzk"}, "repository": {"url": "https://github.com/nangmans/docsy-example", "name": "nangmans/docsy-example"}}' \
    -H "Content-Type: application/json" \
    http://localhost:8080

 

데이터 값의 repositoy와 name값은 이 글을 읽는 분들이 접근 가능한 Github repository 값으로 바꿔서 넣으셔야 합니다.

 

넣을 만한 repository 주소가 없다면 아래 레포를 포크해서 사용하는 것을 권장합니다.

 

https://github.com/google/docsy-example

GitHub - google/docsy-example: An example documentation site using the Docsy Hugo theme

API콜을 실행했다면 Tekton Dashboard의 PipelineRun에서 작업이 실행되는 것을 볼 수 있습니다.

 

 

PiplineRun 작업이 Succeeded 상태로 완료되었다면 Docker Hub 이미지 레지스트리에 컨테이너 이미지가 푸시된 것을 확인할 수 있습니다.

 

 

PipelineRun 작업이 실패했다면 Dashboard에서 작업 실패 로그를 확인할 수 있습니다.

 

이 로그는 해당 Step이 실행하는 Container에서 출력되는 로그와 동일합니다. 

 

 

 

3. 마무리

 

지금까지 Kubernetes 환경에서 파이프라인을 구성할 수 있는 Tekton에 대해서 알아봤습니다.

 

Tekton은 Kubernetes CR 기반의 빌딩 블록으로 쉽게 파이프라인을 구성할 수 있다는 장점이 있으며, 기존 Kubernetes 환경을 그대로 이용할 수 있다는 활용성도 가지고 있습니다.

 

이번 포스팅에서는 DEMO를 통해 Github에서 들어온 Push를 기반으로 Docker hub에 컨테이너 이미지를 빌드 및 푸시하는 CI/CD 파이프라인을 구성해 봤는데요.

 

이번 포스팅을 보시는 분들이 Tekton을 이용하는데 많은 도움을 받으셨으면 합니다.