[Kubernetes in Google Cloud] 쿠버네티스 스터디 잼 입문반: Kubernetes Engine에서 Jenkins로 지속적 배포

이 실습에서 배울 내용은 다음과 같다.

• Jenkins를 통한 지속적 배포 파이프라인 설정
• 코드의 지속적인 통합

공유 저장소에서 코드를 자주 통합하는 개발자를 위해 다음 아키텍쳐와 유사한 솔루션을 빌드하려고 한다.

Jenkins 아키텍쳐

Google Cloud Skills Boost는 실습에서 활용할 여러 기술에 대해서 다음과 같이 정의내리고 있다.

Kubernetes Engine란?

Kubernetes Engine은 컨테이너를 위한 강력한 클러스터 관리자 및 조정 시스템인 Kubernetes의 Google Cloud 호스팅 버전입니다. Kubernetes는 노트북에서 고가용성 다중 노드 클러스터, 가상 머신에서 베어 메탈까지 다양한 환경에서 실행할 수 있는 오픈소스 프로젝트입니다. 앞서 언급했듯이 Kubernetes 앱은 컨테이너로 빌드되었으며, 컨테이너는 실행을 위해 필요한 모든 종속 항목 및 라이브러리와 함께 번들로 제공되는 경량 애플리케이션입니다. 이러한 기본 구조 덕분에 Kubernetes 애플리케이션은 안전하고 가용성이 높으며 빠른 배포가 가능하여 클라우드 개발자에게 이상적인 프레임워크라고 할 수 있습니다.

Jenkins란?

Jenkins는 빌드, 테스트, 배포 파이프라인을 유연하게 조정할 수 있는 오픈소스 자동화 서버입니다. Jenkins를 사용하면 개발자는 지속적 배포로 인해 발생할 수 있는 오버헤드 문제에 대한 걱정 없이 프로젝트를 신속하게 변경 및 개선할 수 있습니다.

지속적 배포란?

지속적 배포(CD) 파이프라인을 설정해야 하는 경우 Jenkins를 Kubernetes Engine으로 배포하면 표준 VM 기반 배포 대비 상당한 이점을 얻을 수 있습니다.
빌드 프로세스에서 컨테이너를 사용하는 경우 하나의 가상 호스트로 여러 운영체제에서 작업이 가능합니다. Kubernetes Engine에서는 '일시적 빌드 실행자(ephemeral build executors)'를 제공하는데, 이 기능은 빌드가 활발하게 실행될 때만 사용되므로 일괄 처리 작업과 같은 다른 클러스터 작업에 사용할 여유 리소스를 확보할 수 있습니다. 일시적 빌드 실행자의 또 다른 이점은 바로 시작하는 데 몇 초밖에 걸리지 않는 속도입니다.
Kubernetes Engine에는 Google의 전역 부하 분산기도 사전 설치되어 있어 인스턴스로의 웹 트래픽 라우팅을 자동화하는 데 사용할 수 있습니다. 부하 분산기에서는 SSL 종료를 처리하고, 웹 프런트엔드와 함께 Google의 백본 네트워크로 구성되는 전역 IP 주소를 활용하며, 사용자가 항상 애플리케이션 인스턴스에 가장 빠른 경로로 액세스할 수 있도록 설정해 줍니다.

이렇게 각각의 설명만 나열한 글을 읽으면 감이 잘 잡히지 않을 것 같다. 쉽게 말해서 요즘의 개발 트랜드는 지속적인 통합(Continuous Integration)과 지속적인 배포(Continuous Delivery)가 이루어지는 CI/CD인데, 이는 Jenkins라는 오픈 소스를 통해서 구축 가능하다. Jenkins는 코드 푸시와 같은 특정한 이벤트가 발생할 때 새로운 소스 코드를 테스트하고 빌드 후 자동 배포할 수 있는 CI/CD를 담당한다. 이때 이렇게 빌드한 어플리케이션을 배포할 때 운영체제에 상관없이 배포하고 싶다면 컨테이너 환경으로 배포해야 하는데, 이런 컨테이너화된 서비스를 제공해주는 오픈소스가 바로 쿠버네티스이다.

따라서 위의 글을 요약하자면 Kubernetes+Jenkins 조합을 활용할 시 CI/CD와 컨테이너 환경 구축이 편리하다는 뜻이다. 이번 실습에서는 바로 이렇게 Jenkins를 쿠버네티스 안에 구축하는 법을 배운다.

참고로 이 실습은 굉장히 길고 내용도 많기 때문에, 시간을 들여서 실습해 보는 것을 추천한다.

작업 1. 소스 코드 다운로드하기

먼저 Cloud Shell에서 새로운 세션을 열고, 영역을 설정한 후 소스 코드를 다운로드 받는다.

gcloud config set compute/zone [lab에서 설정해준 영역] # 영역 설정
gsutil cp gs://spls/gsp051/continuous-deployment-on-kubernetes.zip . # 소스 코드 다운로드
unzip continuous-deployment-on-kubernetes.zip # zip 풀기
cd continuous-deployment-on-kubernetes # 디렉터리로 이동

작업 2. Jenkins 프로비저닝하기

그리고 나서 kubernetes 클러스터를 생성해 준다. 노드의 갯수는 2개, 인스턴스 타입은 n1-standard-2이다. 참고로 가장 저렴한 E2 계열이 아니라 N1 계열을 생성해주는 이유는 Jenkins를 구동시키려면 가장 낮은 스펙의 VM으로는 부족하기 때문이다.

gcloud container clusters create jenkins-cd \
--num-nodes 2 \
--machine-type n1-standard-2 \
--scopes "https://www.googleapis.com/auth/source.read_write,cloud-platform"

클러스터 생성까지는 5분 정도 소요된다. 클러스터가 만들어면 우선 클러스터가 실행 중인지를 확인하고, 사용자 인증 정보를 가져온다. 인증 정보를 가져온 후에는 kubectl cluster-info 명령어를 통해서 인증 정보가 올바르게 설정되었는지를 확인한다.

gcloud container clusters list # 클러스터 실행 중인지 확인
gcloud container clusters get-credentials jenkins-cd # 클러스터 인증 정보 가져오기
kubectl cluster-info # 클러스터 연결 가능한지 확인

인증 정보 확인

작업 3. Helm 설정하기

이 실습에서는 Helm을 사용하여 차트 저장소에서 Jenkins를 설치한다. Helm은 Kubernetes 애플리케이션을 쉽게 구성하고 배포할 수 있게 해주는 패키지 관리자이다. python에서는 pip, RedHat 계열에서는 yum, ubuntu에서는 apt라고 생각하면 된다.

helm repo add jenkins https://charts.jenkins.io # Helm 차트 저장소 추가
helm repo update # 저장소가 최신 상태인지 확인

*Happy Helming!*

작업 4. Jenkins 구성 및 설치하기

Jenkins 설치 시 values 파일을 템플릿으로 사용하여 설정에 필요한 값을 제공할 수 있다. 커스텀 values 파일을 사용하면 Kubernetes Cloud를 자동으로 구성하고 다음 필수 플러그인을 추가할 수 있다.

• Kubernetes:latest
• Workflow-multibranch:latest
• Git:latest
• Configuration-as-code:latest
• Google-oauth-plugin:latest
• Google-source-plugin:latest
• Google-storage-plugin:latest

이 필수 플러그인들이 있어야 Jenkins가 쿠버네티스 클러스터 및 GCP 프로젝트에 연결할 수 있게 된다.

실습에서는 이렇게 values 파일을 설명만 해주고 직접 보여주지는 않아서 무슨 말인지 헷갈릴 수 있다. 다음과 같이 values 파일을 직접 보면 그냥 yaml 파일 내에 Jenkins 설치 시 필요한 installPlugins를 정의해 놓은 구성 파일이라는 점을 알 수 있다. 만약 이를 정의해 놓지 않으면 젠킨스를 설치할 때마다 콘솔에 들어가서 플러그인을 하나하나 다시 설치해주어야 한다.

controller:
  installPlugins:
    - kubernetes:latest
    - workflow-job:latest
    - workflow-aggregator:latest
    - credentials-binding:latest
    - git:latest
    - google-oauth-plugin:latest
    - google-source-plugin:latest
    - google-kubernetes-engine:latest
    - google-storage-plugin:latest
  resources:
    requests:
      cpu: "50m"
      memory: "1024Mi"
    limits:
      cpu: "1"
      memory: "3500Mi"
  javaOpts: "-Xms3500m -Xmx3500m"
  serviceType: ClusterIP
agent:
  resources:
    requests:
      cpu: "500m"
      memory: "256Mi"
    limits:
      cpu: "1"
      memory: "512Mi"
persistence:
  size: 100Gi
serviceAccount:
  name: cd-jenkins

values.yaml 구성 파일도 확인했으니 이제 Helm CLI를 사용해서 해당 구성 설정으로 젠킨스를 설치하고 확인해보자. 그리고 clusterrolebinding을 통해서 클러스터 롤 바인딩을 해보자. 클러스터 롤 바인딩은 특정 서비스 계정에 특정 클러스터 역할(cluster role)을 할당하는 것을 말한다.

helm install cd jenkins/jenkins -f jenkins/values.yaml --wait # 젠킨스 설치
kubectl get pods # 설치 확인
# 젠킨스 서비스 계정 구성
kubectl create clusterrolebinding jenkins-deploy --clusterrole=cluster-admin --serviceaccount=default:cd-jenkins

참고로 helm 명령어의 설정은 다음과 같다.

• helm install: Helm을 사용하여 차트를 설치하는 명령어
• cd jenkins/jenkins: Jenkins 차트의 위치를 지정하는 명령어
• -f jenkins/values.yaml: Jenkins 차트에 대한 값 파일인 values.yaml을 사용하여 구성을 지정하는 명령어
• --wait: 설치가 완료될 때까지 명령어를 대기시키고 설치가 완료되면 제어를 반환하는 명령어.

다음 명령어를 실행하여 Cloud Shell에서 Jenkins로의 포트 전달을 설정하고 젠킨스 서비스가 만들어졌는지 확인한다.

export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/component=jenkins-master" -l "app.kubernetes.io/instance=cd" -o jsonpath="{.items[0].metadata.name}")
kubectl port-forward $POD_NAME 8080:8080 >> /dev/null &
# 젠킨스 서비스 만들어졌는지 확인
kubectl get svc

젠킨스 서비스가 생성된 모습

작업 5. Jenkins에 연결하기

Jenkins는 처음 생성할 때 자동으로 관리자 비밀번호를 만들어 준다. 이를 확인하려면 다음을 명령어를 입력한다.

printf $(kubectl get secret cd-jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo

비밀번호 확인

그리고 나서 Could Shell의 웹 미리보기 버튼을 클릭한 다음 포드 8080에서 미리보기를 클릭한다. 그 후 사용자 이름은 admin으로, 비밀번호는 위에서 확인한 대로 로그인하면 된다.

Jenkins에 들어가게 되면 다음과 같은 화면이 뜬다.

(그런데 나는 로그인 과정 없이 바로 Jenkins 콘솔에 바로 들어갈 수 있었다. 정확한 원인은 잘 모르겠다.)

아무튼 이제 쿠버네티스 클러스터에 Jenkins가 설치되었으니, 자동화된 CI/CD 파이프라인을 만들면 된다.

작업 6. 애플리케이션 이해하기

지속적 배포 파이프라인에 샘플 애플리케이션 gceme를 배포해본다. 이 애플리케이션은 Go 언어로 작성되었으며 저장소의 sample-app 디렉터리에 있다. Compute Engine 인스턴스에서 gceme 바이너리를 실행하면 인스턴스의 메타데이터를 보여주는 애플리케이션이다. 이 애플리케이션은 마이크로서비스를 모방해 두 가지 작동 모드를 지원한다.

• 백엔드 모드에서 gceme는 포트 8080을 수신 대기하고 Compute Engine 인스턴스 메타데이터를 JSON 형식으로 반환한다.
• 프론트엔드 모드에서 gceme는 백엔드 gceme 서비스를 쿼리하고 결과 JSON을 사용자 인터페이스에서 렌더링한다.

즉 다음과 같은 아키텍쳐라고 할 수 있겠다.

작업 7. 애플리케이션 배포하기

애플리케이션을 2개의 다른 환경에 배포해보자.

• 프로덕션: 사용자가 액세스하는 라이브 사이트
• 카나리아: 사용자 트래픽 중 일부만 수용하는 소규모 사이트. 이 환경을 사용하여 실제 트래픽으로 소프트웨어의 이상 유무를 확인한 후 이상이 없을 시 모든 사용자에게 배포한다.

샘플 애플리케이션 디렉터리로 이동한 후, 쿠버네티스 네임스페이스를 만들어 배포를 논리적으로 격리하고자 한다.

cd sample-app
kubectl create ns production # 네임스페이스 생성
# 프로덕션 및 카나리아 배포 생성
kubectl apply -f k8s/production -n production
kubectl apply -f k8s/canary -n production
kubectl apply -f k8s/services -n production

배포 생성 결과.

기본적으로 하나의 프론트엔드 복제본만 배포되었으므로, kubectl scale 명령어를 사용해서 최소 4개의 복제본이 항상 실행되도록 한다.

# 복제본 생성
kubectl scale deployment gceme-frontend-production -n production --replicas 4
# 프론트엔드 포드 실행 중 확인
kubectl get pods -n production -l app=gceme -l role=frontend
# 벡엔드 포드 실행 중 확인
kubectl get pods -n production -l app=gceme -l role=backend

프론트엔드에는 프로덕션 트래픽에 4개, 카나리아 릴리스에 1개의 포드가 실행중이고, 백엔드에서는 프로덕션에 1개, 카나리아에 1개의 포드가 실행 중이어야 한다.

이제 프로덕션 서비스의 외부 IP를 검색한다.

kubectl get service gceme-frontend -n production

이 외부 IP를 브라우저의 URL 창에 검색해 넣으면 다음과 같은 VM의 메타데이터 내용을 확인할 수 있다. 

이제 나중에 사용할 수 있도록 프런트엔드 서비스 부하 분산기 IP를 환경 변수에 저장하고, curl 명령어를 통해서 서비스의 버전을 확인한다(1.0.0 버전으로 표시되어야 한다).

샘플 애플리케이션을 배포했으니 이제 파이프라인을 설정해 지속적이고 안정적으로 변경사항을 배포할 수 있도록 설정해보자.

작업 8. Jenkins 파이프라인 만들기

샘플 앱 소스 코드를 호스팅하는 저장소 만들기

다음과 같이 gceme 샘플 앱의 복사본을 만들고 이를 Cloud Source Repository로 푸시하자.

gcloud source repos create default # GCP의 Source Repository 생성
git init
git config credential.helper gcloud.sh # 인증
# 생성된 원격 저장소를 Git 프로젝트에 추가
git remote add origin https://source.developers.google.com/p/$DEVSHELL_PROJECT_ID/r/default

Git 커밋을 위한 사용자 이름 및 이메일 주소를 설정한다. 아래에서 [EMAIL_ADDRESS]를 Git 이메일 주소로, [USERNAME]을 Git 사용자 이름으로 바꾸어 입력해야 한다. 나는 실습을 시작하면 자동으로 생성되는 구글 계정의 이메일 주소와 사용자 이름을 입력했지만, 사실 이미 GCP 레포지토리에 대한 인증을 완료했으므로 아무 이메일/사용자 이름이나 입력하면 될 것 같다.

git config --global user.email "[EMAIL_ADDRESS]"
git config --global user.name "[USERNAME]"

그 후에는 파일을 추가, 커밋, 푸시한다.

git add .
git commit -m "Initial commit"
git push origin master

Git push 성공한 모습

서비스 계정 사용자 인증 정보 추가

사용자 인증 정보를 구성하여 Jenkins에서 코드 저장소에 액세스할 수 있도록 허용해야 한다. Jenkins는 Cloud Source Repositories에서 코드를 다운로드하기 위해 클러스터의 서비스 계정 사용자 인증 정보를 사용한다.

젠킨스 콘솔에서 Jenkins 관리 > Manage Credentials > System > Global credentials > Add Credentials을 클릭하면 인증 정보를 만들 수 있다.

Manage Credentials에 들어가서 인증 정보 만들기

참고로 Credential 추가하기까지의 들어가야 하는 UI의 Depth가 굉장히 깊다. 하나하나 클릭해서 들어가야 한다.

Kind 드롭다운에서 Google Service Account from metadata(메타데이터의 Google 서비스 계정)를 선택하고 Create(만들기)를 클릭하여 전역 사용자 인증 정보를 추가한다.

인증 정보가 추가되면 다음과 같이 보인다.

Credential 추가된 모습

Kubernetes용 Jenkins Cloud 구성

아까 들어갔었던 Jenkins 관리에서 이제는 Manage Cloud(노드 및 클라우드 관리)로 들어간다. 그 다음 Clouds Add a new cloud(새 클라우드 추가)을 클릭하고 Kubernetes를 선택한다. Kubernetes Cloud Details(Kubernetes 클라우드 세부정보)를 클릭하고, Jenkins URL 필드에는 http://cd-jenkins:8080를, Jenkins tunnel(Jenkins 터널) 필드에 cd-jenkins-agent:50000를 입력한다.

Kubernetes 선택

Kubernetes Cloud Details 설정

Jenkins 작업 만들기

인증 정보 입력이 완료되었으면 이제 Jenkins 콘솔로 이동해서 Jenkins 작업을 만들어야 한다. 작업이란 젠킨스에서 실행되는 개별적인 단위를 뜻하는 말로, 소스 코드 체크아웃, 환경 설정, 인증 정보 구성, 빌드, 테스트, 베포 등 원하는 일련의 과정들을 하나로 묶은 것을 의미한다.

젠킨스 작업은 다음과 같이 설정해야 한다.

1. Dashboard(대시보드) > New Item(새 항목) 클릭
2. 프로젝트 이름은 sample-app으로 지정, Multibranch Pipeline(다중 브랜치 파이프라인) 옵션 선택 후 OK 클릭
3. Branch Sources(브랜치 소스) 섹션에 있는 Add Source(소스 추가) 드롭다운에서 Git 선택
4. Cloud Source Repositories에 있는 sample-app 저장소에 다음 HTTPS clone URL(HTTPS 클론 URL)을 Project Repository(프로젝트 저장소) 필드에 붙여 넣기, [PROJECT_ID]를 현재 프로젝트 ID로 변경 https://source.developers.google.com/p/[PROJECT_ID]/r/default
5. 이전 단계에서 서비스 계정을 추가할 때 만든 사용자 인증 정보의 이름을 사용자 인증 정보드롭다운에서 선택
6. Scan Multibranch Pipeline Triggers(다중 브랜치 파이프라인 트리거 검색)섹션에서 Periodically if not otherwise run(별도로 실행하지 않는 경우 주기적으로 실행)상자를 선택하고 Interval(간격) 값을 1분으로 설정

사진으로 자세히 설명하자면 다음과 같다.

Multibranch Pipeline 선택

브랜치 소스 설정, 인증 정보 추가

다중 브랜치 파이프라인 트리거 검색 설정

이 상태로 저장하고 나면 Branch Indexing이라는 작업이 자동으로 실행된다. 이 작업에서는 저장소에서 브랜치를 식별하고 기존 브랜치에 변경된 사항이 없는지를 확인한다. 다음과 같이 로그의 맨 마지막에 Finished: SUCCESS 메세지가 떠야지 성공이다. 만약 Finished: FAILED라고 뜬다면 위 단계 설정 중에서 무언가를 잘못한 것이므로 다시 Configuration에 들어가서 설정을 수정해야 한다.

이렇게 복잡한 인증 정보 구성과 작업 구성이 끝났다. 복잡해 보여도 한번만 만들어 놓으면 자동화가 가능하다.

작업 9. 개발 환경 만들기

개발 브랜치는 개발자가 코드 변경사항을 제출하여 라이브 사이트에 통합하기 전에 테스트하는 데 사용하는 일련의 환경이다. 이러한 환경은 애플리케이션의 축소 버전이지만 실제 환경과 동일한 메커니즘으로 배포되어야 한다.

개발 브랜치 만들기

기능 브랜치로부터 개발 환경을 만들려면 브랜치를 Git 서버에 푸시하고 Jenkins를 통해 환경을 배포해야 한다. 다음과 같이 개발 브랜치를 만들고 Git 서버에 푸시하자.

git checkout -b new-feature

• -b: 새로운 브랜치를 생성하는 옵션
• new-feature: 새로 생성할 브랜치의 이름

파이프라인 정의 수정하기

파이프라인을 정의하는 Jenkinsfile은 Jenkins 파이프라인 Groovy 구문을 사용하여 작성된다. Jenkinsfile을 사용하면 전체 빌드 파이프라인을 소스 코드가 포함된 단일 파일로 표현할 수 있다. 쉽게 말해서, 빌드할 때 필요한 모든 일련의 프로세스(git에서 소스 코드를 다운받는다든지, cmd창에 go build를 입력한다든지 등등)을 Jenkinsfile 안에 모두 명시해 놓으면 젠킨스가 알아서 전부 실행한다. 따라서 자동화된 빌드 파이프라인 구축이 가능하다.

파이프라인이 정상적으로 작동하도록 하려면 Jenkinsfile을 수정하여 프로젝트 ID를 설정해야 한다. 다음과 같이 수정해주면 된다.

vi Jenkinsfile
i # 편집기 실행

PROJECT = "REPLACE_WITH_YOUR_PROJECT_ID" # 실습에서 할당받은 프로젝트 ID로 수정
APP_NAME = "gceme"
FE_SVC_NAME = "${APP_NAME}-frontend"
CLUSTER = "jenkins-cd"
CLUSTER_ZONE = "" # 실습에서 할당받은 컴퓨팅 영역으로 수정, gcloud config get compute/zone로 확인 가능
IMAGE_TAG = "gcr.io/${PROJECT}/${APP_NAME}:${env.BRANCH_NAME}.${env.BUILD_NUMBER}"
JENKINS_CRED = "${PROJECT}"

Jenkinsfile 수정

사이트 수정하기

애플리케이션이 변경되었음을 보여주기 위해 gceme 카드를 파란색에서 주황색으로 변경해준다. <div class="card blue"> 부분을 다음과 같이 수정해주면 된다.

vi html.go
i # 편집기 실행

<div class="card orange">

또한 main.go에 정의된 const version string = "1.0.0" 버전 정보도 같이 수정해준다.

vi main.go
i # 편집기 시작

const version string = "2.0.0"

main.go 수정

작업 10. 배포 시작하기

이제 위에서 저장한 파일들의 변경사항을 커밋하고 푸시한다.

git add Jenkinsfile html.go main.go
git commit -m "Version 2.0.0"
git push origin new-feature

변경사항 푸시

그러면 개발 환경 빌드가 자동으로 시작된다. 변경사항이 Git 저장소에 푸시되고 나면 Jenkins 콘솔로 이동해 new-feature 브랜치의 빌드가 시작되었는지 확인한다. 빌드의 Console output을 클릭하면 아래처럼 자동으로 빌드되는 과정의 로그를 확인할 수 있다. 

Jenkinsfile의 파이프라인을 따라 빌드되는 모습

로그를 따라 가면서 kubectl --namespace=new-feature apply... 메시지가 시작되는지 확인한다.해당 메세지가 뜨면 이제 new-feature 브랜치가 클러스터에 배포된다.

모두 처리되었다면 이제 백그라운드에서 프록시를 시작한다. 그 후에 curl 명령어로 localhost에 요청을 보내서 kubectl 프록시가 정상적으로 요청을 서비스에 전달하여 애플리케이션에 엑세스할 수 있는지 확인한다. 2.0.0 이라는 출력이 표시되어야 한다.

kubectl proxy & # 프록시 실행

curl \
http://localhost:8001/api/v1/namespaces/new-feature/services/gceme-frontend:80/proxy/version

참고로 다음과 같은 에러 메시지가 뜬다면 아직 프론트엔드 엔드포인트가 전파되지 않았다는 뜻이므로, 잠시 기다렸다가 다시 시도해보면 된다.

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
  },
  "status": "Failure",
  "message": "no endpoints available for service \"gceme-frontend:80\"",
  "reason": "ServiceUnavailable",
  "code": 503
}

작업 11. 카나리아 릴리스 배포하기

앱이 개발 환경에서 최신 코드를 실행 중임을 확인했으므로 이제 해당 코드를 카나리아 환경에 배포해본다.

먼저 카나리아 브랜치를 만들고 Git 서버에 푸시한다.

git checkout -b canary
git push origin canary

이제 젠킨스에서 카나리아 파이프라인이 자동으로 실행된다.

일부 트래픽에 새 버전을 제공하고 있는지를 다음과 같이 while문을 사용한 curl 명령어를 통해서 확인해보자. 1초 간격으로 버전 확인을 하며, 약 5개 중 1개의 비율로 버전 2.0.0이 반환되어야 한다.

export FRONTEND_SERVICE_IP=$(kubectl get -o \
jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend)

# 1초마다 버전 확인
while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done

일부분만 2.0.0 버전으로 출력된 모습

작업 12. 프로덕션에 배포하기

카나리아 릴리스가 성공적으로 이루어지고 사용자에게 테스트해 본 결과 결함이 없었다면 이를 이제 나머지 프로덕션 환경에 배포하면 된다. master 브랜치로 이동한 후 카나리아 브랜치를 master에 통합한다.

git checkout master
git merge canary
git push origin master

그럼 Jenkins에서 마스터 파이프라인이 시작된다. 파이프라인 빌드가 완료되면 서비스 URL을 확인하여 모든 트래픽에 새 버전인 2.0.0이 제공되고 있는지 파악할 수 있다.

export FRONTEND_SERVICE_IP=$(kubectl get -o \
jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend)

# 1초마다 확인
while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done

마지막으로 gceme 애플리케이션이 정보 카드를 표시하는 사이트로 이동해서 카드 색상이 파란색에서 주황색으로 변경되었는지 확인한다. 다음 명령어를 입력해 외부 IP 주소를 확인하고, 해당 IP 주소로 이동한다.

kubectl get service gceme-frontend -n production

그럼 다음과 같이 카드 색이 주황색으로 변경된 것을 확인할 수 있다.

여기까지 완료했으면 이제 쿠버네티스 입문반 실습이 모두 끝났다!🥳