[클라우드 스터디잼] Continuous Delivery with Jenkins in Kubernetes Engine

* 클라우드 스터디잼 쿠버네티스 입문반 과정을 수강하면서 정리한 내용입니다.

Overview

이 실습에서는 Kubernetes 엔진에서 Jenkins를 사용하여 continuous delivery 파이프라인을 설정하는 방법을 배우게 됩니다. Jenkins는 코드를 자주 공유 저장소에서 통합하는 개발자가 가장 많이 사용하는 자동화 서버입니다. 이 실습에서 빌드할 솔루션은 다음 다이어그램과 유사합니다.

여기에서 Kubernetes에서의 Jenkins 실행에 관한 자세한 내용을 확인할 수 있습니다.

What you'll do

이 실습에서는 다음 작업을 완료합니다.

• Jenkins 애플리케이션을 Kubernetes Engine 클러스터에 프로비저닝하기
• Helm Package Manager를 사용하여 Jenkins 애플리케이션 설정하기
• Jenkins 애플리케이션의 기능 살펴보기
• Jenkins 파이프라인 생성 및 실습

Prerequisites

이것은 advanced 레벨 랩입니다. 시작하기 전에 적어도 셸 프로그래밍, Kubernetes 및 Jenkins의 기본 사항에 익숙해져야 합니다. 실습 진도를 따라잡는 데 도움이 될 만한 몇 가지 Qwiklabs 실습은 다음과 같습니다.

• Docker 소개
• Hello Node Kubernetes
• Kubernetes Engine을 사용한 관리
• Kubernetes Engine에서 Jenkins 설정하기

준비가 되면 아래로 스크롤하여 Kubernetes와 Jenkins, Continuous Delivery에 관해 자세히 알아보세요.

What is Kubernetes Engine?

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

What is Jenkins?

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

What is Continuous Delivery / Continuous Deployment?

지속적 배포(continuous delivery, CD) 파이프라인을 설정해야 하는 경우 Jenkins를 Kubernetes Engine으로 배포하면 표준 VM 기반 배포 대비 상당한 이점을 얻을 수 있습니다.

빌드 프로세스에서 컨테이너를 사용하는 경우 하나의 가상 호스트로 여러 운영 체제에서 작업이 가능합니다. Kubernetes Engine은 일시적 빌드 실행자(ephemeral build executors)를 제공하는데 이 기능은 빌드가 활발하게 실행될 때만 사용되므로, 일괄 처리 작업과 같은 다른 클러스터 작업에 사용할 여유 리소스를 확보할 수 있습니다. 일시적 빌드 실행자의 또 다른 이점은 속도로, 시작하는 데 몇 초밖에 걸리지 않습니다.

Kubernetes Engine에는 Google의 전역 부하 분산기가 사전 설치되어 있어 인스턴스로의 웹 트래픽 라우팅을 자동화하는 데 사용할 수 있습니다. load balancer는 SSL 종료를 처리하고, 웹 프런트와 결합되어 Google 백본 네트워크로 구성된 전역 IP 주소를 활용합니다. 이 load balancer는 사용자가 항상 애플리케이션 인스턴스에 이르는 가장 빠른 경로로 액세스할 수 있도록 설정해 줍니다.

이제 어느 정도 Kubernetes와 Jenkins, 그리고 이들이 CD 파이프라인에서 어떻게 상호작용하는지 배웠으니 파이프라인을 빌드해보겠습니다.

Download the source code

설정하려면 Cloud Shell에서 새 세션을 열고 다음 명령을 실행하여 영역 us-west1-b를 설정하십시오.

▼ 명령어

gcloud config set compute/zone us-west1-b

▼ 아웃풋

그리고 다음 실습의 샘플 코드를 복제하십시오.

▼ 명령어

gsutil cp gs://spls/gsp051/continuous-deployment-on-kubernetes.zip .

▼ 아웃풋

▼ 명령어

unzip continuous-deployment-on-kubernetes.zip

▼ 아웃풋

이제 올바른 디렉토리로 변경하십시오.

▼ 명령어

cd continuous-deployment-on-kubernetes

▼ 아웃풋

Provisioning Jenkins

Creating a Kubernetes cluster

이제 다음 명령어를 실행하여 Kubernetes 클러스터를 프로비저닝합니다.

▼ 명령어

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"

이 단계를 완료하는 데 최대 몇 분이 걸릴 수 있습니다. 추가된 scopes 매개변수는 Jenkins가 Cloud Source Repositories 및 Google Container Registry에 액세스할 수 있도록 합니다.

▼ 아웃풋

 

계속하기 전에 다음 명령어를 실행하여 클러스터가 실행 중인지 확인합니다.

▼ 명령어

gcloud container clusters list

▼ 아웃풋

이제 내 클러스터의 사용자 인증 정보를 가져오세요.

▼ 명령어

gcloud container clusters get-credentials jenkins-cd

 

▼ 아웃풋

 

Kubernetes Engine은 이 사용자 인증 정보를 사용하여 새로 프로비저닝된 클러스터에 액세스합니다. 다음 명령어를 실행하여 연결할 수 있는지 확인합니다.

▼ 명령어

kubectl cluster-info

▼ 아웃풋

Setup Helm

이 실습에서는 Helm을 사용하여 Charts repository에서 Jenkins를 설치합니다. Helm은 Kubernetes 애플리케이션을 쉽게 구성하고 배포할 수 있는 패키지 관리자입니다. Jenkins를 설치하면 CI/CD 파이프라인을 설정할 수 있습니다.

1. Helm의 안정적인 차트 저장소 추가 :

▼ 명령어

helm repo add jenkins https://charts.jenkins.io

▼ 아웃풋

2. 저장소가 최신 상태인지 확인하십시오.

▼ 명령어

helm repo update

▼ 아웃풋

Configure and Install Jenkins

Jenkins를 설치할 때 값 파일을 템플릿으로 사용하여 설정에 필요한 값을 제공할 수 있습니다.

사용자 지정 값 파일을 사용하여 Kubernetes 클라우드를 자동으로 구성하고 다음 필수 플러그인을 추가합니다.

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

이렇게 하면 Jenkins가 클러스터와 GCP 프로젝트에 연결할 수 있습니다.

1. 사용자 정의 값 파일 다운로드:

▼ 명령어

gsutil cp gs://spls/gsp330/values.yaml jenkins/values.yaml

▼ 아웃풋

2. Helm CLI를 사용하여 configuration settings으로 chart 를 배포합니다.

▼ 명령어

helm install cd jenkins/jenkins -f jenkins/values.yaml --wait

이 명령을 완료하는 데 몇 분이 걸릴 수 있습니다.

▼ 아웃풋

3. 명령어가 완료되면 Jenkins 포드가 Running 상태이고 컨테이너가 READY 상태인지 확인합니다.

▼ 명령어

kubectl get pods

▼ 아웃풋

NAME                          READY     STATUS    RESTARTS   AGE
cd-jenkins-7c786475dd-vbhg4   1/1       Running   0          1m

4. 클러스터에 배포할 수 있도록 Jenkins 서비스 계정을 구성하십시오.

▼ 명령어

kubectl create clusterrolebinding jenkins-deploy --clusterrole=cluster-admin --serviceaccount=default:cd-jenkins

▼ 아웃풋

clusterrolebinding.rbac.authorization.k8s.io/jenkins-deploy created

5. 다음 명령어를 실행하여 Cloud Shell에서 Jenkins UI로 port forwarding을 설정합니다.

▼ 명령어

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 &

 

6. 이제 Jenkins 서비스가 올바르게 생성되었는지 확인합니다.

▼ 명령어

kubectl get svc

▼ 아웃풋

NAME               CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
cd-jenkins         10.35.249.67   <none>        8080/TCP    3h
cd-jenkins-agent   10.35.248.1    <none>        50000/TCP   3h
kubernetes         10.35.240.1    <none>        443/TCP     9h

Jenkins 마스터가 요청할 때 필요에 따라 빌더 노드가 자동으로 시작되도록 Kubernetes 플러그인을 사용하고 있습니다. 관련 작업이 완료되면 자동으로 해제되고 리소스가 클러스터 리소스 풀에 다시 추가됩니다.

이 서비스는 selector와 일치하는 모든 포드에 관해 포트 8080 및 50000을 노출합니다. 그러면 Kubernetes 클러스터 내의 빌더/에이전트 등록 포트와 Jenkins 웹 UI가 노출됩니다. 또한 jenkins-ui 서비스는 클러스터 외부에서 액세스할 수 없도록 ClusterIP를 사용하여 노출됩니다.

Connect to Jenkins

1. Jenkins 차트는 자동으로 관리자 비밀번호를 만듭니다. 이를 검색하려면 다음을 실행합니다.

▼ 명령어

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

▼ 아웃풋

2. Jenkins 사용자 인터페이스를 가져오려면 Cloud Shell에서 웹 미리보기를 클릭하고 포트 8080에서 미리보기를 클릭합니다.

3. 이제 사용자 이름 admin과 자동으로 생성된 비밀번호를 사용하여 로그인할 수 있습니다.

이제 Kubernetes 클러스터에 Jenkins가 설정되었습니다. 이제 다음 섹션에서 Jenkins를 활용해 자동화된 CI/CD 파이프라인을 운용합니다.

Understanding the Application

continuous deployment pipeline에 샘플 애플리케이션 gceme를 배포하려고 합니다. 이 애플리케이션은 Go 언어로 작성되었으며 저장소의 sample-app 디렉토리에 있습니다. Compute Engine 인스턴스에서 gceme 바이너리를 실행하면 앱에서 정보 카드에 인스턴스의 메타데이터를 표시합니다.

이 애플리케이션은 마이크로 서비스를 모방하여 두 가지 작동 모드를 지원합니다.

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

Deploying the Application

애플리케이션을 2개의 다른 환경에 배포합니다.

• Production: 사용자가 액세스하는 실제 사이트입니다.
• Canary: 사용자 트래픽 중 일정 비율을 수용하는 소규모 사이트입니다. 이 환경을 사용하여 실제 트래픽으로 소프트웨어의 이상 유무를 확인한 후 사용자에게 배포합니다.

Google Cloud Shell에서 샘플 애플리케이션 디렉토리로 이동합니다.

▼ 명령어

cd sample-app

▼ 아웃풋

 

Kubernetes 네임스페이스를 만들어 deployment를 논리적으로 분리합니다.

▼ 명령어

kubectl create ns production

▼ 아웃풋

production 및 canary 배포를 생성하고 kubectl apply 명령어를 사용하여 서비스를 생성합니다.

▼ 명령어

kubectl apply -f k8s/production -n production

kubectl apply -f k8s/canary -n production

kubectl apply -f k8s/services -n production

▼ 아웃풋

기본적으로 하나의 frontend replica만 배포됩니다. kubectl scale 명령어를 사용하여 최소 4개의 replica가 항상 실행되도록 합니다.

다음 명령어를 실행하여 프로덕션 환경 frontends를 확장합니다.

▼ 명령어

kubectl scale deployment gceme-frontend-production -n production --replicas 4

▼ 아웃풋

이제 frontend에 5개의 pods, production 트래픽에 4개의 pods, canary 릴리스에 1개의 pod가 실행 중인지 확인합니다(canary 릴리스에 변경이 생기면 사용자 5명 중 1명(20%)에만 영향을 줍니다).

▼ 명령어

kubectl get pods -n production -l app=gceme -l role=frontend

▼ 아웃풋

또한 백엔드에 2개의 pods, production에 1개의 pod, canary에 1개의 pod가 있는지 확인합니다.

 

▼ 명령어

kubectl get pods -n production -l app=gceme -l role=backend

▼ 아웃풋

 

프로덕션 서비스의 외부 IP를 검색합니다.

▼ 명령어

kubectl get service gceme-frontend -n production

 

참고: load balancer 외부 IP 주소가 확인될 때까지 몇 분 정도 걸릴 수 있습니다.

▼ 아웃풋

NAME            TYPE          CLUSTER-IP     EXTERNAL-IP     PORT(S)  AGE
gceme-frontend  LoadBalancer  10.79.241.131  104.196.110.46  80/TCP   5h

외부 IP를 브라우저에 붙여넣어 카드에 표시된 info 카드를 확인합니다. 다음과 유사한 페이지가 나타납니다.

이제 나중에 사용할 수 있도록 프런트엔드 서비스 load balancer IP를 환경 변수에 저장합니다.

▼ 명령어

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

▼ 아웃풋

브라우저에서 프런트엔드 외부 IP 주소를 열어 두 서비스가 정상 작동하는지 확인합니다. 다음 명령어를 실행하여 서비스의 버전을 확인합니다(1.0.0으로 표시되어야 함).

▼ 명령어

curl http://$FRONTEND_SERVICE_IP/version

▼ 아웃풋

 

샘플 애플리케이션을 배포했습니다. 이제 지속적, 안정적으로 변경 사항을 배포할 수 있는 파이프라인을 설정합니다.

Creating the Jenkins Pipeline

Creating a repository to host the sample app source code

gceme 샘플 앱의 복사본을 만들고 Cloud Source Repository에 푸시해보겠습니다.

▼ 명령어

gcloud source repos create default

경고를 무시할 수 있으며 이 저장소에 관한 비용은 청구되지 않습니다.

자체 Git 저장소로 sample-app 디렉토리를 초기화합니다.

▼ 명령어

git init

▼ 아웃풋

▼ 명령어

git config credential.helper gcloud.sh

▼ 아웃풋

 

다음 명령어를 실행합니다.

▼ 명령어

git remote add origin https://source.developers.google.com/p/$DEVSHELL_PROJECT_ID/r/default

▼ 아웃풋

Git 커밋에 사용할 내 사용자 이름과 이메일 주소를 설정합니다. [EMAIL_ADDRESS]를 Git 이메일 주소로, [USERNAME]을 Git 사용자 이름으로 바꿉니다.

▼ 명령어

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

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

파일을 애드, 커밋, 푸시합니다.

▼ 명령어

git add .

git commit -m "Initial commit"

git push origin master

▼ 아웃풋

Adding your service account credentials

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

1단계

Jenkins 사용자 인터페이스의 왼쪽 탐색 창에서 Manage Jenkins를 클릭 한 다음 Manage Credentials를 클릭합니다.

2단계

Jenkins 를 클릭합니다.

3단계

Global credentials (unrestricted)를 클릭합니다.

4단계

왼쪽 탐색 메뉴에서 Add Credentials(사용자 인증 정보 추가)를 클릭합니다.

5단계

Kind(종류) 드롭다운에서 메타데이터의 Google 서비스 계정을 선택하고 OK(확인)을 클릭합니다.

전역 사용자 인증 정보가 추가되었습니다. 사용자 인증 정보의 이름은 Project ID이며 실습의 연결 세부정보 섹션에 있습니다.

Creating the Jenkins job

Jenkins 사용자 인터페이스로 이동하고 다음 단계에 따라 파이프라인 작업을 구성합니다.

1단계

왼쪽 탐색 메뉴에서 New Item을 클릭합니다.

2단계

프로젝트 이름을 sample-app으로 지정하고 Multibranch Pipeline 옵션을 선택한 후 확인을 클릭합니다.

3단계

다음 페이지의 Branch Sources 섹션에서 Add Source를 클릭하고 git를 선택합니다.

4단계

Cloud Source Repositories에 있는 sample-app 저장소의 HTTPS clone URL을 Project Repository 필드에 붙여넣습니다. [PROJECT_ID]를 Project ID로 바꿉니다.

▼ 명령어

https://source.developers.google.com/p/[PROJECT_ID]/r/default

 

5단계

Credentials드롭다운에서 이전 단계에서 서비스 계정을 추가할 때 생성한 사용자 인증 정보의 이름을 선택합니다.

6단계

Scan Multibranch Pipeline Triggers 섹션에서 Periodically if not otherwise run 상자를 선택하고 Interval값을 1분으로 설정합니다.

7단계

작업 구성은 다음과 같이 표시됩니다.

8단계

Save을 클릭하여 기본값을 사용하여 다른 모든 옵션을 그대로 둡니다.

이 단계를 완료하면 Branch indexing이라는 작업이 실행됩니다. 이 메타 작업은 저장소의 브랜치를 식별하고 기존 브랜치에 변경사항이 발생하지 않았는지 확인합니다. 왼쪽 상단에서 sample-app을 클릭하면 마스터 작업이 표시됩니다.

참고: 다음 단계에서 몇 가지 코드를 변경하기 전에는 master job의 첫번째 실행이 실패할 수 있습니다.

Jenkins 파이프라인을 만들었습니다. 다음으로 continuous integration을 위한 개발 환경을 만듭니다.

Creating the Development Environment

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

Creating a development branch

feature branch로부터 개발 환경을 만들려면 브랜치를 Git 서버에 푸시하고 Jenkins를 통해 환경을 배포합니다.

개발 브랜치를 만들고 Git 서버에 푸시합니다.

▼ 명령어

git checkout -b new-feature

Modifying the pipeline definition

이 파이프라인을 정의하는 Jenkinsfile은 Jenkins Pipeline Groovy syntax으로 작성됩니다. Jenkinsfile을 사용하면 빌드 파이프라인 전체에 걸쳐 소스 코드와 함께 사용되는 단일 파일로 표현할 수 있습니다. 파이프라인은 병렬화와 같은 강력한 기능을 지원하며 사용자의 직접 승인을 요청합니다.

파이프라인이 정상적으로 작동하도록 하려면 프로젝트 ID를 설정하도록 Jenkinsfile을 수정해야 합니다.

터미널 편집기에서 Jenkinsfile을 엽니다(예: vi).

▼ 명령어

vi Jenkinsfile

▼ 아웃풋

 

편집기를 시작합니다.

▼ 명령어

i

▼ 아웃풋

 

PROJECT_ID를 REPLACE_WITH_YOUR_PROJECT_ID 값에 추가합니다. PROJECT_ID는 실습의 CONNECTION DETAILS 섹션에 있는 내 프로젝트 ID입니다. gcloud config get-value project를 실행해서 찾을 수도 있습니다.

▼ 명령어

PROJECT = "REPLACE_WITH_YOUR_PROJECT_ID"
APP_NAME = "gceme"
FE_SVC_NAME = "${APP_NAME}-frontend"
CLUSTER = "jenkins-cd"
CLUSTER_ZONE = "us-west1-b"
IMAGE_TAG = "gcr.io/${PROJECT}/${APP_NAME}:${env.BRANCH_NAME}.${env.BUILD_NUMBER}"
JENKINS_CRED = "${PROJECT}"

Jenkinsfile 파일을 저장합니다. 그런 다음 Esc를 누릅니다(vi 사용자의 경우).

▼ 명령어

:wq

Modify the site

애플리케이션 변경을 표시하기 위해 gceme 카드를 파란색에서 주황색으로 변경하겠습니다.

html.go를 엽니다.

▼ 명령어

vi html.go

편집기를 시작합니다.

▼ 명령어

i

다음을 사용하여 <div class="card blue">의 두 인스턴스를 변경합니다.

<div class="card orange">

html.go 파일을 저장합니다. Esc를 누릅니다.

▼ 명령어

:wq

main.go를 엽니다.

▼ 명령어

vi main.go

편집기를 시작합니다.

▼ 명령어

i

버전은 이 행에서 정의됩니다.

const version string = "1.0.0"

다음으로 업데이트합니다.

const version string = "2.0.0"

main.go 파일을 한 번 더 저장합니다. Esc를 누릅니다.

▼ 명령어

:wq

Kick off Deployment

변경사항을 커밋하고 푸시합니다.

▼ 명령어

git add Jenkinsfile html.go main.go

git commit -m "Version 2.0.0"

git push origin new-feature

이렇게 하면 개발 환경 빌드가 시작됩니다.

Git 저장소에 변경사항이 푸시된 후 Jenkins 사용자 인터페이스로 이동하여 new-feature 브랜치의 빌드가 시작되었는지 확인합니다. 변경사항을 가져오는 데 최대 1분 정도 걸릴 수 있습니다.

빌드가 실행되었으면 왼쪽 탐색 메뉴에서 빌드 옆의 아래쪽 화살표를 클릭하고 Console output를 선택합니다.

몇 분 동안 빌드 결과를 추적하면서 kubectl --namespace=new-feature apply... 메시지가 시작되는지 지켜봅니다. new-feature 브랜치가 이제 클러스터에 배포됩니다.

참고: public-facing load balancer는 개발 시나리오에서 사용하지 않습니다. 애플리케이션의 보안을 강화하려는 경우 kubectl 프록시를 사용할 수 있습니다. 이 프록시는 Kubernetes API에 자신을 인증하며, 내 서비스를 인터넷에 노출하지 않고도 로컬 머신의 요청을 클러스터의 서비스로 중계합니다.

Build Executor에 아무것도 보이지 않아도 걱정하지 마세요. Jenkins 홈페이지에서 sample app으로 이동하면 됩니다. new-feature 파이프라인이 만들어졌는지 확인합니다.

모두 처리되었다면 background에서 프록시를 시작합니다.

▼ 명령어

kubectl proxy &

정지되는 경우 Ctrl + C를 눌러 종료합니다. localhost에 요청을 보내고 kubectl 프록시가 서비스에 전달하도록 하여 애플리케이션에 액세스할 수 있는지 확인합니다.

▼ 명령어

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

현재 실행 중인 버전인 2.0.0으로 응답해야 합니다.

아래와 유사한 오류가 발생한 경우에는:

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

frontend endpoint가 아직 전파되지 않았음을 의미합니다. 조금 기다렸다가 curl 명령을 다시 시도하십시오. 다음과 같은 결과가 나오면 계속 진행하십시오.

2.0.0

개발 환경을 설정했습니다. 이제 새로운 기능을 테스트하도록 canary 릴리스를 배포하여 이전 모듈에서 학습한 내용을 빌드하겠습니다.

 

Deploying a Canary Release

개발 환경에 있는 앱에서 최신 코드를 실행하고 있음을 확인했으므로 이 최신 코드를 canary  환경에 배포하겠습니다.

canary  브랜치를 만들고 Git 서버에 푸시합니다.

▼ 명령어

git checkout -b canary

git push origin canary

Jenkins에서 canary 파이프라인이 시작되었음을 알 수 있습니다. 완료되면 서비스 URL을 확인하여 일부 트래픽에 새 버전을 제공하고 있는지 확인할 수 있습니다. 약 5개의 요청 중 1개의 요청(특정 순서 없음)에 대해 버전 2.0.0이 반환되어야 합니다.

▼ 명령어

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

while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done

계속 1.0.0이 표시되면 위의 명령어를 다시 실행해보세요. 위의 동작이 확인되면 Ctrl + C를 사용하여 명령어를 종료합니다.

모든 작업을 마쳤으므로 canary 릴리스 배포가 완료되었습니다. 이제 새 버전을 프로덕션에 배포하겠습니다.

Deploying to production

canary 릴리스가 성공적이었으며 어떤 고객의 불만도 없었으므로 나머지 프로덕션에 배포합니다.

canary 브랜치를 만들고 Git 서버에 푸시합니다.

▼ 명령어

git checkout master

git merge canary

git push origin master

Jenkins에서 master pipeline이 시작되었음을 알 수 있습니다. 완료되면 서비스 URL을 확인하여 모든 트래픽에 새 버전인 2.0.0이 제공되고 있는지 확인할 수 있습니다.

▼ 명령어

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

while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done

다시 한번 1.0.0의 인스턴스가 보이면 위의 명령어를 다시 실행해보세요. Ctrl + C를 눌러 이 명령어를 중단할 수 있습니다.

▼ 아웃풋

gcpstaging9854_student@qwiklabs-gcp-df93aba9e6ea114a:~/continuous-deployment-on-kubernetes/sample-app$ while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done
2.0.0
2.0.0
2.0.0
2.0.0
2.0.0
2.0.0
^C

gceme 애플리케이션이 정보 카드를 표시하는 사이트로 이동할 수도 있습니다. 카드 색상이 파란색에서 주황색으로 변경되었습니다. 확인할 수 있도록 외부 IP 주소를 가져오는 명령은 다음과 같습니다.

▼ 명령어

kubectl get service gceme-frontend -n production

▼ 아웃풋

Congratulations!

이로써 Continuous Delivery / Continuous Deployment pipeline을 활성화하도록 Kubernetes 엔진에서 Jenkins를 사용하여 배포 및 작업하는 실습을 마칩니다. Kubernetes 엔진에서 중요한 DevOps 도구를 배포하고 프로덕션 적용을 위해 구성해볼 수 있는 기회였습니다. kubectl 명령줄 도구와 YAML 파일 내의 배포 구성을 사용해 작업하였으며 개발/배포 프로세스를 위한 Jenkins 파이프라인 설정에 관해서도 어느 정도 배웠습니다. 이 실습 경험을 기반으로 이제 DevOps shop에서 이러한 도구를 편안하게 적용할 수 있을 것입니다.

Take Your Next Lab

Continue your Quest with Hello Node Kubernetes, or check out these suggestions:

• Orchestrating the Cloud with Kubernetes
• Managing Deployments Using Kubernetes Engine

Next Steps / Learn More

• Read further on the Jenkins in Kubernetes Engine Solution.
• Learn how to use Jenkins to enable Continuous Delivery to Kubernetes Engine
• Read further on DevOps Solutions and DevOps Guides in the Google Cloud documentation
• Connect with the Jenkins Community!