티스토리 뷰

<출처>

https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4



이 시리즈 중 마지막 파트에서는,  Kr8sswordz Puzzle 앱을 위한 CI/CD hooks 을 설정할 것이다.


시리즈 중 Part 3에서, Kr8sswordz Puzzle 앱를 동작하도록 했고, 부하 테스틀를 위해 여러 개의 인스턴스를 구동하도록 하고 K8S가 클러스터를 걸쳐서 방대한 요청을 우아하게 조정하는 것을 지켜보았다.


Part 2에서 Hello-Kenzan 앱과 함께 사용할 Jenkins 를 설치하기는 했지만, Kr8sswordz Puzzle 앱에 대한 CI/CD hooks를 설치하지는 않았다. 이번 마지막 글에서 이 설치를 검토해 나갈 것이다. Kr8sswordz Puzzle 앱을 위해 Jenkins 2.0 파이프라인 스크립트를 이용하게 될 것이다. 이번에는 중대한 차이점을 갖는데, fork한 Git repo에 대한 업데이트를 근거로 빌드가 유발 된다. 검토해 볼 내용은 Git 에 코드를 푸쉬하여 애플리케이션에 변경 기능을 업데이트 하는 것을 시뮬레이션 하는 것이다. 이 푸쉬는 Jenkins 빌드 프로세스를 유발 시킬 것이다. 현실 상황의 lifecycle 에서, 이 자동화는 개발자가 간단하게 특정 브랜치에 코드를 푸쉬하고, 특정 환경에 앱을 빌드, 푸쉬 그리고 배포할 수 있도록 해준다.


일단 이 모든 인프라가 설치되면, 이후부터는 반복적인 배포는 엄청나게 간단해지고, 기능들을 구식으로 만들어 lifecycle을 단축시킨다는 게 묘미다. 


시리즈의 모든 글을 읽어보자.

Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview
Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)
Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)
Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)



중요: 이 실습을 완성시키기 위해, 최신 버전의 리눅스, macOS가 동작하는 컴퓨터가 필요하다. 최적의 성능을 내기위해, 컴퓨터는 16GB의 RAM을 보유해야만 하며, 컴퓨터를 리부팅하고 현재 동작 중인 앱의 갯수를 최소로 유지한다. (그만큼 부하를 유발시킬 거라는 이야기지만 필자는 나름 사양이 빵빵?해서 리부팅과 앱 최소 유지는 생략했다^. 진행해 보고 버벅거리면 그때 조치하는 것으로 해도 무방할 듯...)


Exercise 1: Creating a Kr8sswordz Pipeline in Jenkins

시작하기 전에, K8S에서 이전에 빌드했던 모든 컴포넌트들이 갖춰질 수 있도록 Part 1,2, 그리고 3 단계를 거치면서 수행했던 것을 확인하고 싶을 것이다. Minikube를 중지시켰다면, 다시 구동시켜야 한다. 다음 터미널 명령을 입력하고 클러스터가 구동되기를 기다린다.

1
2
3
4
5
6
7
8
9
10
11
root@zerobig-vm-u:~# minikube start --memory 8000 --cpus 2 --kubernetes-version v1.10.0
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.
Loading cached images from config file.
cs


클러스터 상태를 확인하고 모든 파드를 확인해 보고 싶으면, 다음명령을 수행해본다.

1
2
3
4
5
root@zerobig-vm-u:/home/study/k8s/kubernetes-ci-cd# kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443
KubeDNS is running at https://192.168.99.100:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
 
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
cs


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
root@zerobig-vm-u:/home/study/k8s/kubernetes-ci-cd# kubectl get pods --all-namespaces
NAMESPACE     NAME                                        READY     STATUS      RESTARTS   AGE
default       etcd-job-fxb55                              0/1       Completed   0          19h
default       etcd-operator-69b559656f-zw4hq              1/1       Running     0          19h
default       example-etcd-cluster-2stvm2j6d9             1/1       Running     0          19h
default       example-etcd-cluster-kkf67n5tvj             1/1       Running     0          19h
default       example-etcd-cluster-xvj82zxrhf             1/1       Running     0          19h
default       hello-kenzan-55bcf94b6b-rdr7f               1/1       Running     0          23h
default       jenkins-c5d9b4944-mb6pk                     1/1       Running     0          1d
default       kr8sswordz-85b9fd8fb4-tmm8n                 1/1       Running     0          18h
default       mongo-79fbd6bc6-q4pqn                       1/1       Running     0          18h
default       monitor-scale-6bb95b75b7-lf72x              2/2       Running     0          19h
default       nginx-768979984b-p6hl2                      1/1       Running     1          2d
default       puzzle-686c87976d-dl7sj                     1/1       Running     0          13h
default       registry-95c457bdb-hcvsd                    2/2       Running     2          2d
kube-system   default-http-backend-59868b7dd6-b9rqt       1/1       Running     1          2d
kube-system   etcd-minikube                               1/1       Running     0          1d
kube-system   heapster-vpztx                              1/1       Running     1          2d
kube-system   influxdb-grafana-84vm6                      2/2       Running     2          2d
kube-system   kube-addon-manager-minikube                 1/1       Running     1          2d
kube-system   kube-apiserver-minikube                     1/1       Running     0          1d
kube-system   kube-controller-manager-minikube            1/1       Running     0          1d
kube-system   kube-dns-86f4d74b45-cqpr4                   3/3       Running     4          2d
kube-system   kube-proxy-66nvj                            1/1       Running     0          1d
kube-system   kube-scheduler-minikube                     1/1       Running     0          1d
kube-system   kubernetes-dashboard-5498ccf677-dcbwc       1/1       Running     3          2d
kube-system   nginx-ingress-controller-5984b97644-n8lmr   1/1       Running     2          2d
kube-system   storage-provisioner                         1/1       Running     3          2d
cs

다음 두 개의 실습을 위해, Jenkins와 퍼즐 앱에서 대부분의 작업을 수행하려 한다. 그래서 튜토리얼 스크립트를 이용하는 대신 수동으로 이 단계들을 검토해 나갈 것이다. (여전히 스크립트가 존재하고 있으니 이를 이용하길 원한다면 -- 프로젝트 루트에서 "npm run part4" 을 입력한다)

1. 브라우져에서 Jenkins UI를 오픈하기 위해 다음 명령을 입력한다. 이전에 설정했던 사용자이름과 패스워드를 이용하여 Jenkins에 로그인 한다.

1
2
root@zerobig-vm-u:/home/study/k8s/kubernetes-ci-cd# minikube service jenkins
Opening kubernetes service default/jenkins in default browser...
cs


2. 이전에 배포했던 puzzle 서비스에 대한 새로운 파이프라인 생성이 필요할 것이다. Jenkins 촤측에 새로운 Item을 클릭한다.



3. Puzzle-Service 라고 아이템 이름을 입력하고, Pipeline 을 클릭하고 나서 OK를 클릭한다.


4. 아래 Build Triggers 섹션에서, Poll SCM을 선택한다. 스케쥴을 위해, H/5 * * * *  문자열을 입력한다. 이는 매 5분마다 Git repo의 변경사항을 poll 할 것이다.


5. Pipeline 섹션에서, 다음을 변경한다.

  a. Definition: Pipeline script from SCM

  b. SCM: Git

  c. Repository URL: fork한 Git 레파지토리 URL

  d. Script Path: applications/puzzle/Jenkinsfile


6. (설정이) 끝나면, Save를 클릭하고, 새로운 파이프라인을 동작시키기 위해 Build Now 를 클릭한다. 수분 내 빌드, 푸쉬, 그리고 배포 단계를 성공적으로 통과해 나가는 것을 볼 수 있을 것이다.


Puzzle-Service 파이프라인은 이제 매 5분마다 Git repo 변경사항을 poll 하도록 설정되었고 변경사항이 검출되면 빌드를 개시한다.


Exercise 2: Pushing a Feature Update Through the Pipeline

이제 간단한 변경을 일으켜 보자. 파이프라인이 유발되고 퍼즐 서비스가 재빌드 될 것이다.

현재 Kr8sswordz Puzzle 앱에서, Reload를 누르거나 Load Test를 수행하면 puzzle 서비스에 대한 hit가 UI 내 녹색 빛으로 나타난다.


그러나, Submit 버튼을 클릭하면 동일한 녹색 hit가 빛나지 않는 것을 보았을 수도 있을 것이다.


7. 터미널에서, Kr8sswordz Puzzle 앱을 오픈한다. (퍼즐이 보이지 않는다면, 브라우져를 새로고침 해야할 수도 있다.)

1
2
root@zerobig-vm-u:/home/study/k8s/kubernetes-ci-cd# minikube service kr8sswordz
Opening kubernetes service default/kr8sswordz in default browser...
cs


8. 슬라이더를 오른쪽으로 이동시키고 Scale 을 클릭하여 puzzle 서비스 인스턴스 몇개를 구동한다. 참고용으로, Submit 클릭하고 녹색 빛이 퍼즐 서비스 상에 나타나지 않는 것을 주목한다.


9. nano 편집기로 applications/puzzle/common/models/crossword.js 파일을 편집한다.

1
root@zerobig-vm-u:/home/study/k8s/kubernetes-ci-cd# nano applications/puzzle/common/models/crossword.js
cs


42-43라인에 다음 주석 부분을 볼 수 있을 것이다.

1
2
// Part 4: Uncomment the next line to enable puzzle pod highlighting when clicking the Submit button
//fireHit();
cs


포워드 슬래쉬를 삭제하여 43라인의 주석을 해제하고, 종료를 위해 Ctrl+X 를 누르고, 파일이름 확인을 위해 Y를 클릭한다. 그리고 파일의 변경을 저장하기 위해 Enter를 누른다.

// Part 4: Uncomment the next line to enable puzzle pod highlighting when clicking the Submit button
fireHit();


10 . fork한 Git repo에 변경사항을 커밋하고 푸쉬한다. (GitHub credentials 입력이 필요할 것이다.)

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
root@zerobig-vm-u:/home/study/k8s/kubernetes-ci-cd# git commit -am "Enabled hit highlighting on Submit"
[master ee8dba2] Enabled hit highlighting on Submit
 1 file changed, 1 insertion(+), 1 deletion(-)
root@zerobig-vm-u:/home/study/k8s/kubernetes-ci-cd# git push
warning: push.default를 설정하지 않았습니다. 묵시적 값은 깃 2.0에서
'matching'에서 'simple'로 바뀌었습니다. 이 메시지를 표시하지
않고 과거의 동작을 유지하려면 다음과 같이 하십시오:
 
  git config --global push.default matching
 
이 메시지를 표시하지 않고 새 동작을 받아들이려면 다음과 같이
하십시오:
 
  git config --global push.default simple
 
push.default가 'matching'으로 설정되면, 로컬 브랜치를 이미 같은 이름이
있는 리모트 브랜치로 푸시합니다.
 
깃 2.0부터 더 보수적인 'simple' 동작이 기본값입니다. 여기서는 현재
브랜치를 'git pull'에서 현재 브랜치를 업데이트할 때 사용하는 해당
리모트 브랜치로 푸시합니다.
 
더 자세한 정보는 'git help config'에서 'push.default' 설명을 보십시오.
('simple' 모드는 깃 1.7.11에 추가되었습니다. 과거 버전의 깃을 사용하게
되면 비슷한 'current' 모드를 사용하십시오.)
 
Username for 'https://github.com': zer0big
Password for 'https://zer0big@github.com':
오브젝트 개수 세는 중: 7, 완료.
Delta compression using up to 4 threads.
오브젝트 압축하는 중: 100% (6/6), 완료.
오브젝트 쓰는 중: 100% (7/7), 551 bytes | 0 bytes/s, 완료.
Total 7 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
To https://github.com/zer0big/kubernetes-ci-cd.git
   fca8c7e..ee8dba2  master -> master
cs


11. Jenkins에서, Puzzle-Service 파이프라인을 열고 빌드가 유발되기를 기다린다. 매 5분마다 유발되어야만 한다. (바로 유발되지 않으면, 시간을 갖고 기다린다.)


12. 유발되고 나서, Kr8sswordz Puzzle 앱에서 퍼즐 서비스가 어떻게 사라지는지, 그리고 어떻게 새로운 것으로 교체되는지 관찰해본다.


13. 이제 hit가 녹색 빛을 표시하는지 테스트 하기 위해 Submit 을 클릭해 본다.

퍼즐 인스턴스 중 하나가 빛나는 것을 보게 된다면, K8S 내 파드의 코드 변경사항을 자동으로 빌드, 푸쉬 그리고 배포해주는 CI/CD 파이프라인이 성공적으로 설치되었음을 의미하는 것이다. 좋다 – 계속 진행하여 잠시동안 영광을 누려보자.


Part 4를 완성시켰고 K8S와 함께 CI/CD에 관한 Kenzan의 블로그 시리즈를 끝마쳤다. 

DevOps 관점에서 볼 때, 이 파이프라인은 실제 상황의 시나리오에서 달리 처리해야 할 몇 가지 것들이 있음을 언급할만 하다.

  • 마이크로서비스 개발/빌드/배포에 대한 분리를 시행하기 위해 Kr8sswordz Puzzle을 구성하는 각 서비스들에 대한 레파지토리를 분리하고 싶을 것이다. 여기서는 튜토리얼과 함께 이용이 용이하도록 하나의 repo 에 모든 서비스들을 결합시켰다. 

  • 또한 monitor-scale과 kr8sswordz 서비스에 대한 개별 파이프라인을 설정하고 싶을 것이다. 실습의 목적을 위해 CI/CD를 시연하기 위해 단일 파이프라인으로 유지되도록 하기는 했지만, 실제로 이 서비스들에 대한 Jenkins 파일은 레파지토리 내에 포함되어 있다. 

  • Dev, QA, Stage, 그리고 Prod 환경과 같은, 각 개발 환경에 대한 분리된 파이프라인을 설정하고 싶을 것이다. 이러한 환경에 대한 빌드 유발을 위해, 코드를 푸쉬 할 환경을 나타내는 다른 Git 브랜치를 사용할 수 있다. (예를 들어, dev branch > deploy to Dev, master branch > deploy to QA 등등)

  • 설정이 쉽기는 하지만, SCM Polling 오퍼레이션은 Jenkins가 변경사항 확인을 위해 전체 repo를 스캔하도록 해야 하므로 다소 리소스 집중적이다. 대안으로는 Jenkins Github plugin on your Jenkins server을 이용하는 것이다.

Going Deeper

Kr8sswordz Puzzle 앱 빌드하기는 우리에게 꽤 멋진 지속적인 통합 그리고 다음의 컨테이너 관리 패턴들에 대해 보여주었다. 

  • 어떻게 Jenkins 또는 이미지 레파지토리와 같은 인프라가 K8S에서 파드로 동작할 수 있는지

  • 어떻게 K8S가 스케일링, 로드밸런싱, 그리고 파드의 자동힐링을 처리하는지

  • 어떻게 Jenkin’s 2.0 파이프라인 스크립트가 컨테이너 이미지를 빌드하고, 레파지토리에 푸쉬하여 K8S 내 파드로 배포하기 위해 자동으로 Git 커밋을 동작시키도록 이용되어지는지


Spinnaker와 같은 배포 툴과 함께 CI/CD 파이프라인 프로세스에 대해 보다 깊숙히 알아보는데 관심이 있다면, Kenzan의 페이퍼 Image is Everything: Continuous Delivery with Kubernetes and Spinnaker을 참고한다.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2024/05   »
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
글 보관함