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 오브젝트들은 모두 이 네임스페이스에서 생성하겠습니다.
|
1
|
kubectl create ns getting-started
|
cs |
2-1-1. Tekton Pipeline 설치
Tekton의 핵심인 Tekton Pipeline을 설치하겠습니다.
아래 명령어로 Tekton Pipeline을 설치합니다.
|
1
2
|
kubectl apply --filename \
https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
|
cs |
tekton-pipelines 네임스페이스에 "tekton-pipelines-controller-"와 "tekton-pipelines-webhook-" pod가 RUNNING 상태가 되면 정상적으로 설치가 완료된 것입니다.
2-1-2. Tekton CLI 설치
다음으로 Tekton 컴포넌트와 CLI로 상호작용할 수 있는 Tekton CLI를 설치합니다.
설치 방법은 OS마다 다르기 때문에 자세한 설치 방법은 아래 링크를 참고해주시기 바랍니다.
CLI
Command-Line Interface
tekton.dev
본 포스팅은 MacOS에서 진행하기 때문에 아래 명령어로 Tekton CLI를 설치하도록 하겠습니다.
2-1-3. Tekton Dashboard 설치
다음으로 Tekton 컴포넌트를 확인 및 관리할 수 있는 웹 UI인 Tekton Dashboard를 설치하겠습니다.
아래 명령어로 Tekton Dashboard를 설치합니다.
|
1
|
kubectl apply --filename https://storage.googleapis.com/tekton-releases/dashboard/latest/tekton-dashboard-release.yaml
|
cs |
tekton-pipelines 네임스페이스의 "tekton-dashboard-" pod가 RUNNING 상태이면 설치가 정상적으로 완료된 것입니다.
웹 인터페이스에 접속하기 위해 kubectl port-forward 명령어를 이용해서 localhost로 접근해보겠습니다. 아래 명령어를 실행해 port-forwarding을 시행합니다.
|
1
|
kubectl port-forward -n tekton-pipelines svc/tekton-dashboard 9097:9097
|
cs |
localhost:9097로 접속하면 아래와 같은 인터페이스를 확인할 수 있습니다. 대쉬보드는 이번 파이프라인을 실행하면서 주기적으로 확인할 예정입니다.
2-1-3. Tekton Triggers 설치
마지막으로 Tekton의 이벤트 감지를 담당하는 Tekton Trigger를 설치하겠습니다.
아래 명령어로 Tekton Trigger를 설치합니다.
|
1
2
3
4
|
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
|
cs |
"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
Build Container Images In Kubernetes. Contribute to GoogleContainerTools/kaniko development by creating an account on GitHub.
github.com
Task의 전체 yaml 매니페스트는 아래와 같습니다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
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
|
cs |
위 매니페스트에서 주의해야 할 값만 몇 가지 보도록 하겠습니다.
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파일의 매니페스트는 아래와 같습니다.
|
1
2
3
4
5
6
7
|
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "cmVlMzY5OnMwMTExNzc3MA=="
}
}
}
|
cs |
"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를 실행하는데 꼭 필요한 리소스이기 때문에 정의해보도록 하겠습니다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
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
|
cs |
마찬가지로 중요한 항목만 짚어보도록 하겠습니다.
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를 먼저 생성하도록 하겠습니다.
아래 매니페스트를 적용하도록 합니다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
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
|
cs |
"kubectl get sa -n getting-started" 명령어로 Service account가 정상적으로 생성되었는지 확인하도록 합니다.
2-2-4. PipelineRun 구성
Pipeline을 생성했으니 Pipeline을 실행할 수 있는 PipelineRun 리소스를 생성하겠습니다.
PipelineRun은 단순히 Pipeline을 실행하는 것 뿐만이 아니라 Pipeline이 가진 변수에 값을 할당하거나 작업을 실행할 Service account를 지정하는 등의 작업도 할 수 있습니다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
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
|
cs |
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 오브젝트는 위에서 미리 만들어놨기 때문에, 이 매니페스트를 활용하도록 합니다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
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
|
cs |
위와 마찬가지로 중요한 몇 가지 부분만 짚도록 하겠습니다.
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을 생성하겠습니다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
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)
|
cs |
1. spec.params.value
해당 어트리뷰트의 값을 보면 변수로써 값이 할당되어 있는 것을 볼 수 있습니다.
이 값들은 Github webhook에 포함되어 있는 데이터에서 추출한 값입니다.
Github webhook이 가지고 있는 payload의 자세한 내용은 아래 링크에서 참고할 수 있습니다.
Webhook events and payloads - GitHub Docs
When configuring a webhook, you can use the UI or API to choose which events will send you payloads. Only subscribing to the specific events you plan on handling limits the number of HTTP requests to your server. You can also subscribe to all current and f
docs.github.com
예를 들어 파이프라인에 필요한 url 정보는 repository.url에 존재하는 것을 알 수 있습니다.
Revision은 현재 Master로 고정해놨지만 원하는 경우 이와 같이 Payload를 찾아 변수로 값을 할당할 수 있습니다.
"tkn triggerbinding ls -n getting-started" 명령어로 triggerBinding이 정상적으로 생성되었는지 확인하도록 합니다.
2-3-4. Trigger EventListener 구성
마지막으로 Tekton TriggerTemplate과 TriggerBinding을 묶어주고 이벤트를 감지하는 EventListener를 생성하겠습니다.
|
1
2
3
4
5
6
7
8
9
10
11
12
|
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
|
cs |
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로 접근할 수 있도록 하겠습니다.
|
1
|
kubectl port-forward -n getting-started svc/el-getting-started-listener 8080:8080
|
cs |
다음으로 아래 curl 명령어를 통해 EventListener에게 Github webhook을 가장한 API call을 보내보도록 하겠습니다.
|
1
2
3
4
|
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
|
cs |
데이터 값의 repositoy와 name값은 이 글을 읽는 분들이 접근 가능한 Github repository 값으로 바꿔서 넣으셔야 합니다.
넣을 만한 repository 주소가 없다면 아래 레포를 포크해서 사용하는 것을 권장합니다.
https://github.com/google/docsy-example
GitHub - google/docsy-example: An example documentation site using the Docsy Hugo theme
An example documentation site using the Docsy Hugo theme - GitHub - google/docsy-example: An example documentation site using the Docsy Hugo theme
github.com
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을 이용하는데 많은 도움을 받으셨으면 합니다.