✔️ Creating the Jenkins Pipeline
✔️ Creating a repository to host the sample app source code
gceme 샘플 앱 복사본을 생성하여 클라우드 소스 저장소에 푸시한다.
gcloud source repos create default
이 경고는 무시해도 된다. 이 저장소에 대한 과금은 발생하지 않는다.
샘플 앱 디렉토리를 자체 Git 저장소로 초기화한다.
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는 클러스터의 서비스 계정 자격 증명을 사용하여 클라우드 소스 리포지토리에서 코드를 다운로드한다.
Step 1: Jenkins 사용자 인터페이스에서 왼쪽 네비게이션에서 Manage Jenkins를 클릭한 다음 Manage Credentials를 클릭한다.
Step 2: Jenkins를 클릭한다.
Step 3: [Global credentials (unrestricted)]을 클릭한다.
Step 4: 왼쪽 네비게이션에서 [Add Credentials]을 클릭한다.
Step 5: Kind 드롭다운에서 메타데이터에서 Google Service Account from metadata을 선택하고 확인을 클릭한다.
Jenkins 작업 생성하기
Jenkins 사용자 인터페이스로 이동하여 다음 단계에 따라 파이프라인 작업을 구성한다.
Step 1: 왼쪽 네비게이션에서 [New Item]을 클릭한다.
Step 2: 프로젝트 샘플 앱의 이름을 지정하고 Multibranch Pipeline 옵션을 선택하고 OK를 클릭한다.
Step 3: 다음 페이지의 브랜치소스 섹션에서 소스 추가를 클릭하고 git를 선택한다.
Step 4: 클라우드 소스 저장소에 있는 샘플 앱 리포트의 HTTPS clone URL을 Project Repository 필드에 붙여넣는다.
[PROJECT_D]를 Project ID로 바꾼다.
https://source.developers.google.com/p/[PROJECT_ID]/r/default
Step 5: [Credentials] 드롭다운에서 이전 단계에서 서비스 계정을 추가할 때 작성한 자격 정보의 이름을 선택한다.
Step 6: [Scan Multibranch Pipeline Trigers] 섹션에서 [Periodly if not run] 체크박스를 켜고 [Interval]값을 1분으로 설정
Step 7: 작업 구성은 다음과 같다.
Step 8: [Save]을 클릭한다. 다른 모든 옵션은 기본값으로 유지된다.
이러한 단계를 완료하면 Branch indexing 작업이 실행된다. 이 메타 작업은 리포지토리의 분기를 식별하고 기존 분기에서 변경 사항이 발생하지 않았는지 확인한다. 왼쪽 상단에 있는 sample-app을 클릭하면 마스터 작업이 표시된다.
참고: 마스터 작업의 첫 번째 실행은 다음 단계에서 몇 가지 코드를 변경할 때까지 실패할 수 있다.
Jenkins 파이프라인을 만들었다! 다음으로 지속적인 통합을 위한 개발 환경을 구축해본다.
✔️ Creating the Development Environment
개발 브랜치는 코드를 라이브 사이트에 통합하기 위해 전송하기 전에 코드 변경을 테스트하기 위해 개발자가 사용하는 환경 세트이다. 이러한 환경은 애플리케이션의 축소 버전이지만 라이브 환경과 동일한 메커니즘을 사용하여 배포해야 한다.
✔️ Creating a development branch
기능 브랜치로부터 개발 환경을 작성하려면 브랜치를 Git 서버에 푸시하고 Jenkins가 환경을 배포하도록 할 수 있다.
개발 브랜치를 생성하여 Git 서버에 푸시한다.
git checkout -b new-feature
✔️ Modifying the pipeline definition
해당 파이프라인을 정의하는 Jenkinsfile은 Jenkins Pipeline Groovy 구문을 사용하여 작성된다.
Jenkins 파일을 사용하면 전체 빌드 파이프라인을 소스 코드와 함께 있는 단일 파일로 표현할 수 있다.
파이프라인은 병렬화와 같은 강력한 기능을 지원하므로 사용자의 수동 승인이 필요다다.
파이프라인이 예상대로 작동하려면 Jenkins 파일을 수정하여 프로젝트 ID를 설정해야 한다.
터미널 에디터에서 Jenkins 파일을 열어 수정한다.
vi Jenkinsfile
PROJECT_ID → REPLACE_WITH_YOUR_PROJECT_ID (PROJECT_ID는 CONNECTION DETAILS 섹션에 있는 정보이다.)
또는 gloud 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-east1-d"
IMAGE_TAG = "gcr.io/${PROJECT}/${APP_NAME}:${env.BRANCH_NAME}.${env.BUILD_NUMBER}"
JENKINS_CRED = "${PROJECT}"
✔️ Modify the site
응용 프로그램 변경을 입증하기 위해 gceme 카드를 파란색에서 주황색으로 변경한다.
vi html.go
다음과 같이 <div class="card blue">의 두 인스턴스를 변경한다.
<div class="card orange">
main.go를 열어 수정한다.
const version string = "2.0.0"
✔️ 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분이 소요될 수 있다.
빌드가 실행되면 왼쪽 네비게이션에서 build 옆에 있는 아래쪽 화살표를 클릭하고 Console output을 선택한다.
빌드의 출력을 몇 분간 추적한 후 kubectl --namespace=new-feature apply... 메세지가 시작하는 것을 확인하라
이것으로, new-feature의 브랜치가 클러스터에 전개된다.
참고: 개발 시나리오에서는 public-facing loadbalancer를 사용하지 않는다.
응용 프로그램의 보안을 위해 kubectl proxy를 사용할 수 있다. 프록시는 Kubernetes API를 사용하여 자신을 인증하고 서비스를 인터넷에 노출하지 않고 로컬머신에서 클러스터 내의 서비스로 요구를 프록시한다.
빌드 실행자에 아무것도 표시되지 않는다면, Jenkins 홈페이지 --> sample app에 접속한다.
new-feature 파이프라인이 작성되었는지 확인한다.
모든 처리가 완료되면 백그라운드에서 프록시를 시작한다.
kubectl proxy &
만약 정지하면 Ctrl + C를 눌러 종료한다.
localhost에 요청을 전송하고 kubectl proxy가 해당 요청을 서비스로 전송하도록 하여 어플리케이션에 액세스할 수 있는지 확인한다.
curl \
http://localhost:8001/api/v1/namespaces/new-feature/services/gceme-frontend:80/proxy/version
현재 실행 중인 버전인 2.0.0으로 응답하는 것을 볼 수 있다.
아래와 같은 에러가 발생했을 경우:
frontend의 endpoint가 아직 전파되지 않았음을 의미하므로 잠시 기다렸다가 curl 명령을 다시 시도한다.
다음의 출력이 표시되면, 계속 진행한다.
2.0.0
개발 환경을 설정했다! 다음으로 새로운 기능을 테스트하기 위해 카나리 릴리스를 배치하여 이전 모듈에서 학습한 내용을 기반으로 수행해본다.
✔️ Deploying a Canary Release
앱이 개발 환경에서 최신 코드를 실행하고 있는지 확인했으므로 이제 해당 코드를 카나리 환경에 배포한다.
카나리아 브랜치를 생성하여 Git 서버에 푸시한다.
git checkout -b canary
git push origin canary
젠킨스에서 카나리 파이프라인이 시작된 걸 볼 수 있을 것이다.
완료되면 서비스 URL을 확인하여 일부 트래픽이 새 버전에서 처리되고 있는지 확인할 수 있다.
버전 2.0.0을 반환하는 요청은 5개 중 1개 정도(별도의 순서는 없음)이다.
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를 눌러 명령어를 종료한다.
카나리 릴리스를 배포해보았다. 다음으로 새로운 버전을 prodution에 배포한다.
✔️ Deploying to production
이제 우리의 카나리 릴리스가 성공적으로 완료되었고 사용자의 컴플레인이 접수되지 않았으므로 나머지 프로덕션 플릿에 배포한다.
카나리 브랜치를 생성하여 Git 서버에 푸시한다.
git checkout master
git merge canary
git push origin master
젠킨스에서 마스터 파이프 라인을 시작된 것을 볼 수 있다.
완료되면(몇 분 정도 소요될 수 있음) 서비스 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
'Study > Study Jam' 카테고리의 다른 글
[Study Jam] Infrastructure as Code with Terraform (0) | 2022.03.27 |
---|---|
[Study Jam] Terraform Fundamentals (0) | 2022.03.27 |
[Study Jam] Continuous Delivery with Jenkins in Kubernetes Engine - 1 (0) | 2022.03.25 |
[Study Jam] Managing Deployments Using Kubernetes Engine - 2 (0) | 2022.03.24 |
[Study Jam] Managing Deployments Using Kubernetes Engine - 1 (0) | 2022.03.24 |
영차영차 성장 블로그
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!